《从康威定律看团队架构》是我在12月3日《DDD领域驱动设计峰会》上分享的主题。在十数年的IT从业生涯中，我坚持工作在一线，带领着越来越大的数字化研发团队。我一直在思考：什么样的组织架构设计能更好地激发团队效能，有没有行之有效的方法帮助我们顺畅地开启数字化转型之旅。本次分享，是近期思考的一部分，不尽之处，欢迎随时交流，谢谢。
从“康威定律”说起
康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。” 中文直译的意思是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。更直白的说：你想要什么样的系统，就搭建什么样的团队。
“康威定律”从提出至今，已经半个多世纪了。“康威定律”仍然有效吗？
康威定律经常被用来证明团队组织的变化是合理的。在开启数字化转型之旅时，各组织应遵循“康威定律”，改组自己的工程团队，包括文化、汇报结构和激励计划，以配合他们的架构和技术发展战略。然而，许多组织并没有这样做，却对转型无法带来显著的生产率提升感到诧异。
康威定律认为一个系统的技术架构反映了构建这个系统的人员组织架构。作为软件从业者的我们，不难发现这样的规律：组织的团队结构在处理得当时，仍然是一个关键的推动因素，而在处理得不好时，则会变成严重的障碍。
康威定律是一条双行道
技术设计影响人员组织设计，同时研发团队的架构也会对根据该架构建立的系统产生重大影响。数字化时代，如何搭建成熟的大型研发团队，康威定律是非常关键的推动因素。
“团队优先”的概念是美国陆军四星上将麦克里斯特尔其畅销书《赋能：打造应对不确定性的敏捷团队》中指出的：表现最突出的团队“之所以能够取得非凡的成就，不仅仅是因为团队成员的个人素质，还在于这些成员凝聚成了一个整体”。
在软件开发中，现代软件密集型系统所需的速度、频率、复杂性和变更的多样性意味着团队是必不可少的。依赖个体本质是不可持续的。谷歌在针对他们自己团队的研究中发现，团队活力远比谁在团队中更重要。因此，我们必须从团队入手实现高效的软件交付。有许多方面值得思考和培养，比如团队规模和团队关系。
团队规模
我们经常会遇到下面的问题
团队人数不够怎么办？
团队成员能力不足怎么办？
在《人月神话》中有个著名的论断：“向进度落后的项目中增加人手，只会使进度更加落后”。其中一个很大的原因是，新员工总是需要老员工进行指导，这其中就会产生看不见的沟通成本。这些沟通成本挤占了老员工原本的计划工作时间，造成在短期内无法提升项目进度——增加的人手越多，沟通成本所带来的影响越大。
同时，因为被迫不断扩大的团队规模，导致业务梳理分裂、技术设计碎片、人员能力也难以得到提升。这在大型系统的设计和开发中成为了常见问题。
怎么做呢？
“话说天下大势，分久必合，合久必分。”系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案：分不同的层级，分不同的小团队，让团队内部完成自治理，统一对外沟通。
我们来看一个例子：如果一个团队有3个team在协作，而每个team都是前端、后端、测试职责分明。
如果尝试进行能力合并，则是全功能团队，可能的模式就变成下图所示：
全功能团队负责编写代码、单元测试、接口测试、集成测试等环节，以敏捷的方式实现端到端的协同，整体效率开始提升；但我们面对的是大型的系统研发，即需要至少超过50人的研发团队。我们再尝试一种变化：
这是一种从外部视角来组合组织关系的方法：尝试通过抽象、构建通用组件来尝试达到能力复用。
这有点像不断演进的平台型组织架构，小到一个研发团队，大到一个组织设计，其中的道理是相通的：你需要构建什么样的系统，就搭建什么样的组织结构。这句话有一种逆向作用力：如果控制不好，就会导致重复建设、效率低下、部门墙，且最终可能没有对任何一个问题域打穿，陷入各自为政的尴尬境地。
所以，在团队人数不够，或是团队能力不足的时候，我们首先思考的应该是能否以及如何将问题域打穿。因此，我们需要一个动态的平台型组织，其核心原则是协同与赋能。
团队关系
《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：
5人项目组，需要沟通的渠道是 5*(5–1)/2 = 10
50人项目组，需要沟通的渠道是50*(50–1)/2 = 1,225
150人项目组，需要沟通的渠道是150*(150–1)/2 = 11,175
这也是为什么敏捷组织都追求小团队的原因之一。沟通的问题会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。
组织设计的产品/设计等价于这个组织的沟通结构。通俗地说，就是你组织是什么风格，你交付的产品就是什么风格。
阿里的组织架构和沟通机制比较层级化，因此阿里的产品架构也非常严谨，先顶层设计，后逐步细化。阿里善于总结和提炼，所以在去SuperCell学习后，回来就将中台吸纳、提升为中台概念。
腾讯的组织架构和沟通机制更偏社交，组织架构相对比较“散”，所以QQ、微信都很成功。而且腾讯将SuperCell收购之后，依然是独立管理。
在设计沟通方式的时候，我们需要用端到端的视角来看待整个研发团队，特别是要以业务价值为导向，而不是以研发人员的产出为导向。比如，绝对化的代码行数、功能数、用户故事数就是非常局部的度量方式，而前置时间(Lead Time)、周期时间(Cycle Time)是目前用户比较推崇的整体度量指标——软件产品最终是交付给用户的，用户往往只关注产品何时能够按质量交付，也就是端到端的整体效率。
您可以拿康威定律套一下您自己所在团队，看看这个定律在您公司是否也一样生效。
分布式团队
我们现在看到越来越多的企业正在组建分布式的数字化团队，其好处不言而喻：
降低成本
使员工能够专注于核心业务
使用远程开发团队解决产能问题
获得智力资本：每个地区都有自己独特的思考方式和所擅长的技术
凯捷研究院有一期专刊，讲的是《未来远程混合工作模式的挑战和机会》。这时候我们需要思考，如何利用康威定律，更高效地组建分布式团队。
下面我们举个具体的例子：
系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差。这种现象就越明显。平台团队的设计，就是为了解决这样的问题。
一个个工作单元可以有XXX名工作级顾问，通常按技术栈配备（前端、后端、移动端）
根据项目情况配备有N名入门级顾问，时间上按需投入
工作单元可以有行业属性（汽车、零售、商业地产、高科技、供应链等）
我目前所在的团队面临着大型复杂的系统的设计和开发，需要大团队协同作战。如今十分流行的中台组织架构、敏捷组织，秉承同样的核心思想：你的组织构架会决定团队写出的产品代码，这是由颠覆不变的康威定律决定的，相对应的我们需要不断地优化组织结构以超越康威定律。
总结
博物学家斯蒂芬.杰.古尔德曾在书里讲过一个故事：两个女孩在游乐场聊天，其中，一个女孩问：“如果蜘蛛能变得和大象一样大，还能到处爬，那岂不是很可怕吗？”另一个女孩回答说：“才不会。如果蜘蛛有大象那么大，那它就会变得跟大象一样笨重了，笨。”
古尔德解释说，第二个女孩说得对，因为组织体的大小很大程度上决定了其形态。如果蜘蛛真的变得和大象一样大，那么它的形态和行为也会变得和大象类似，因为这是体积变大的必然结果。
对软件项目，我们可以提出一个类似的问题：如果一个敏捷项目变得非常大，会不会很可怕呢？也许不至于很可怕，上文关于大象和蜘蛛大小的一系列分析，对项目来说同样适用。
这个故事的寓意与我今天分享的主要思想是不谋而合的。现在的绝大多数企业的数字化只聚焦在工具和数字，而非基于流程和组织的重新思考。希望我们在从康威定律看团队结构的时候，能运用以下的思维模式来指导我们的实践：
1、团队规模：您想要什么样的系统设计，就架构什么样的团队。建议按业务来划分团队，这样能让团队自然的自治内聚，每个小团队都对自己模块的整个生命周期负责。
2、团队关系：要用一切手段提升沟通效率，比如看板，always on。每个人、每个系统都有明确的分工，权责明晰。
3、考虑康威定律的逆向作用，我们需要一个动态的平台型组织，其核心原则是协同与赋能。
本文作者万学凡，数字化转型专家，凯捷咨询首席战略顾问。作者保留本文一切权利，未经许可请勿转载。