常见研发团队结构碰到的问题

一般软件研发团队组成方式无非几种：按职能划分的职能团队，按系统结构划分的组件团队，以客户为中心的特性团队。这些团队结构各有各的问题和挑战。

职能团队

业务分析团队，设计团队，架构师团队，开发团队，测试团队，按照职能来划分。完成价值交付的过程会出现明显的阶段和交接传递。理想状况是一个需求流畅的从一个团队流畅的流动到下一个团队，直到价值交付到客户手中。

往返传递

现实情况是通常下一个职能团队为上一个团队提供反馈，需求可能会回到上一个职能团队进行调整，需求会在职能团队间来回传递。比如，开发团队完成开发后交给测试团队，测试团队发现bug又交还给开发团队修复，这个过程会反复多次。这样的反复通常无法预期，会经常影响两个团队的原计划，这又加剧了职能团队的下一个问题。

等待队列

工作性质和团队工作能力的不同，导致一些团队会有不能及时处理的任务堆积，形成队列。这些等待中的任务是半成品，不能直接产生价值，是一种浪费，还会使事情变复杂，比如需要有人来维护这个队列。队列会降低工作的流动性，从而降低价值交付的速度。

组件团队

组件团队是按照架构模块或系统组件来划分团队。比如GUI团队，API团队等。

限制设计

按照康威定律，“任何设计系统的组织……都不可避免地产生出与其组织沟通结构一致的系统设计”，团队的组成结构会限制设计。然而大多数情况下，一开始产生的设计都不是最完美的，组织的灵活性对有效的设计有着举足轻重的作用。而组件团队恰恰限制了设计的有效性。

强化瀑布，增加协调复杂度

组件团队还会加强瀑布的开发过程。通常组件团队的存在会导致工作安排按照组件来分配给各个团队，这意味着所有组件团队完成各自的工作后还需要集成并完成最后的测试，反馈被延迟了。当然我们可以用持续集成等方法来加快反馈频率，但这中间的协调工作也确实变多了，你的Team Leader或者Scrum Master是不是经常为这样的事情疲于奔命？想想如果每个团队的工作是完成相对完整的功能，协调工作是不是会减少许多？组件团队有自己的计划安排，但往往需要和其他组件团队协调（比如联调），导致计划总在被打乱？

系统问题

同时，组件团队和职能团队都会导致：团队往往只关注于完成手头上的工作而非价值；团队与团队间形成职责壁垒，各自只为各自工作负责，也不愿其他人碰自己的工作（典型的如开发人员不愿意其他人碰自己的代码），这也意味着各个团队会更倾向于局部优化，比如在团队工作内容不多的时候，团队会制造些活来干，或者基于专业性来挑选工作而非客户价值。

特性团队

特性团队是由长期合作、跨职能、以学习为导向、多技能的人员组成，能完成端到端客户特性的团队。通常团队的职责包括需求分析、交互设计、计划、设计、编程、测试等，这样团队就能全神贯注地完成端到端的客户特性。

大多数组件团队的缺陷也得以弥补了，比如计划、协调等工作被大大简化了，交接与等待的浪费也减少了，整体的生产周期也被缩短了。同时，团队的技能约束少了，计划和安排工作的灵活性就提升了，可以更多的专注于真正高优先级或更有价值的功能开发上。当然特性团队的好处虽多，但也有不少的挑战和问题：

团队及其成员需要扩展技能和相应的产品知识，以便尽可能的修改系统的任意部分
同时修改同一个代码的机率变高了，冲突的可能性也提高了，这就意味着需要频繁提交代码等一系列持续集成的实践来减小工作批量，缩短集成周期。
各个组件的设计责任被分散到了各个团队，除了持续集成外，还需要其他的实践来保持设计的合理性和持续改善，比如测试驱动开发，重构，演进式设计，组件守护者等。
有些特定的技能比较难以掌握，比如视觉艺术，或者稀有专家掌握的知识和能力（比如图像渲染中的光线追踪算法）
可能需要组织结构的调整，一般组织是以组件或者职能线的汇报关系，最终需要转变成多个团队向共同的上级经理汇报。

如果你正纠结于团队结构或者其它团队在研发过程中碰到的问题，可以考虑参加我的培训：

或者也可以找我聊聊，可以通过zbcjackson@odd-e.com 或者微信