架构即未来 - 组织的设置 读书笔记

2019独角兽企业重金招聘Python工程师标准>>>

rasci 工具

完全负责人 responsible 决策批准人 accountable 提供资源人 supportive 提供数据或者资源人 consulted 需要了解相关情况人 informed

一个任务会有一个 R 和 一个 A，多人负责一个项目等于没有人负责。

组织设置

团队规模

团队规模下限为6人，上限为15人。当团队内出现沟通不畅，生产率低下，士气低落时都是团队规模太大 的信号。团队规模过小，需要注意业务合作伙伴，微观管理的经理，过度劳累的成员，团队可能无法及时 交付，或者被合作放抱怨需要更多的交付。

拆分团队，必须要考虑一些事情，比如谁出任新的经理，每个团队成员的参与度有多高，于业务负责人的关系怎么处理？首先要根据代码和工作来聚焦，最佳方案时根据故障域来拆分团队和代码，通过隔离服务来限制故障所带来的影响。

我们团队目前出现的情况是，过度劳累，有好些同学私底下再问目前的状况什么时候能结束，太累了。另外一方面，需求方还在不停地抱怨，什么时候他们提的需求可以上线。

职能型团队

在一个采用瀑布型开发方法的职能型组织中，研发的责任显然落在工程团队上。因为软件工程师都向工程部门的负责人汇报，质量保证工程师均向质量保证部门的负责人汇报，所以非常容易制定，发布，遵循和执行标准。

职能型或者直线型结构的问题包括缺乏单一的项目负责人和跨职能部门的沟通效果不佳。项目很少只发生在一个职能部门内。大多数软件研发项目，特别时通过网络交付的服务，总是需要不同技能的人来共同完成任务。

在职能型组织中，跨部门沟通出奇难。例如，软件工程师想告诉质量保证工程师，必须进行某个测试以验证功能是否正常。为此，软件工程师很可能要浪费宝贵的时间，在质量保证的管理层级中上下求索，知道找到负责的测试同学。工程师可能会依赖现有的设计规范文档，通过流程来传递这些信息。可以想象，研发和测试之间，写一个20页长的测试规范比面对面对话要带来多少额外的负担。

另外一个挑战是，团队之间的冲突。这个团队没有能按时完成任务和那个团队交付的产品存在错误，这些都是那些按照职能型结构组织起来的团队在合作时经常听到的抱怨。工程师们想要有归属感和被同伴接受，其他不同的人（测试工程师，产品经理，甚至运维）经常被当作圈外人士，而不被信任，甚至有时候被成为公开的敌对目标。

好处是同质性，责任简单清晰，有标准可议。不利的地方包括没有单一的责任人和沟通不顺畅。

目前，我们遇到了类似的问题，虽然，有纵向的团队在一起做事，但是太过临时，相当于是把职能型团队微观化了。团队成员之间交流少，开发流程更接近瀑布模式。

矩阵式团队

一个人汇报给多个经理，而这些经理并不能理解每个人的任务优先级。

之前一直想往矩阵式团队靠，现在看来问题确实挺多，仔细想想向多人汇报就觉得够头疼的了。目前的状况看起来，我们的团队组织形式是强职能型的矩阵式开发合作团队。

敏捷型组织

聚焦团队搭建，最好的构架，需求和设计源于自组织的团队。它不是以角色为基础，而是专注于满足客户的需求。

每个敏捷团队都拥有一个用户服务，并且包括了需要的所有技能。（包括了，研发，测试，运维，产品等）

改善冲突，授权和组织边界来实现创造力的提升。团队按照服务组织起来，自主管理并让人员跨越职能部门，结果是大幅度地降低了情感性冲突。团队成员共享一个目标，不再需要争辩谁来负责或谁应该负责某个任务。每个人要对其提供的高质量，高可用性并能满足商业目标的服务负责。

劣势是，为了按照计划的方式正常发挥作用，团队需要按照构架设计中面向用户的服务重新组织。如果高质量的功能和高可用性的服务来度量，当敏捷型结构的团队在代码质量和责任上出现重叠的时候，团队将无法自治，会导致较低的创新力。

希望目前的小团队可以继续在一起工作，成立第一个敏捷型的团队。

转载于:https://my.oschina.net/pengfeix/blog/793303