康威定律Conway's Law

组织共同设计系统时，系统的分块与连接会复制人的沟通方式。

亚马逊要让软件各部分独立更新，也得让负责它们的人能独立做决定。1998 年，在西雅图，杰夫·贝索斯领导的亚马逊仍让各开发团队共同维护一个庞大的购物网站程序。发布一次更新，各队都得协调。此后，公司把程序拆成较小的服务，也把团队改成各自负责产品或服务的小组。开发者开始拥有明确的负责范围，团队能独立发布更新。软件里哪些部分连在一起、哪些部分分开，与人们怎样分工和协商一起改变了。

为什么成立

系统接口要先在人之间谈妥

两支团队各自设计下单和支付功能，就得先商量怎样把它们接起来。订单编号怎么传、付款失败怎么办、退款由谁发起，都要有人共同决定。如果这些人难以直接协商，各队就会优先完成自己能掌控的部分，把难题留在交接处。人与人之间难以跨过的边界，会变成系统里难以跨过的接口。

组织会筛掉难以协调的设计

同一个需求可以有多种设计，组织更容易做成符合自身沟通方式的那一种。团队内部能随时讨论，成员便容易共用数据、一起修改功能；跨团队改动要等待答复和批准，设计者便会减少共同改动，划出各自维护的模块。久而久之，系统的分块和连接就带上了组织的形状。这就是康威定律：设计选择受设计者之间的沟通结构约束。

真正起作用的是人们怎样交换信息、协商和拍板。组织图上分属两部门的人，如果长期共同设计，也能做出紧密整合的系统；同一部门里互不商量的两组人，也能做出彼此割裂的功能。

想改变系统，就要改变必要的协商

先画出用户需要的流程，才能看出哪些设计者必须共同做决定。要让下单和退款贯通，就让负责两端的人共同约定数据和异常处理，并给他们修改接口的权力。这种反过来安排团队的做法被称为“逆康威操作”：用想要的系统结构，指导人的协作结构。

出处

康威定律来自软件设计，也属于组织研究。梅尔文·康威于 1967 年提出，1968 年 4 月在《Datamation》发表《委员会如何发明？》。原文记述：五人和三人分别开发两种编译器，成品分别分成五个和三个处理阶段。布鲁克斯后来在《人月神话》中将其称为康威定律。

换个领域看

商业

统一产品决策

苹果把专业团队放在全公司的范围内协作，而非让每条产品线各养一套班子。1997 年乔布斯回归后，将分散的业务部门整合为按专业职能划分的组织。用康威定律看，这种安排为跨产品共用技术、协调软硬件提供了沟通通道：统一体验背后，要有人能跨过产品线共同决定。

公共服务

窗口复制科室

医院让科室各自设计预约流程，患者就会遇到按科室切开的服务。门诊办只管挂号，检验科另发预约单，影像科再让患者打电话确认；设计时没人共同约定转诊信息，患者便得自己串起三套流程。让三方共同设计一次就诊的完整路径，才能把科室间的交接搬进系统，而非留给患者。

个人生活

装修接缝露馅

厨房里接不上的地方，能暴露装修时谁没和谁商量。夫妻一人订橱柜，一人买洗碗机，分别向商家确认尺寸，却没有一起确认进水、排水和插座位置。安装时柜子装得下机器，管线却接不上。把两家商人和安装师傅拉到同一张图前确认，改变的正是这套厨房背后的沟通结构。

遇事时问自己

用户在哪些交接处重复填资料或等待，而负责两端的人平时怎样商量？
系统现有的分块，是顺着用户需求划分，还是顺着团队各自的负责范围划分？
想让两个功能紧密配合，哪些人必须共同决定数据、接口和异常处理？
我们要求系统改变的同时，是否也给相关团队直接协商和修改接口的权力？
评估一家企业的整合能力时，它承诺打通的业务之间，有没有共同设计和拍板的人？

边界与误用

康威定律最适合解释多人协作、且仍有设计选择的系统。采购成熟产品、遵守固定协议，或受严格物理约束时，组织对结构的影响会减弱。最常见的误用，是拿组织图逐格预测产品：实际起作用的是设计沟通，包含跨部门联系和共同遵守的接口约定。同一团队也能设计多个模块。看到组织与系统相似，也不能直接认定组织导致了架构；既有架构同样会迫使企业这样分工。改汇报线却不改协商方式和决策权，接缝仍会留在原处。

练一练

一家游戏公司准备打通好友邀请与排位匹配。社交组决定邀请状态，竞技组决定入场条件，两组只通过月度需求单交流。测试时，好友已接受邀请，却因段位变化无法入场。经理把两组划到同一位总监名下，需求单和审批权限保持原样。

接下来哪种情况最可能出现？

一家保险集团收购了养老服务公司，宣布半年内推出统一会员产品。保险购买与入住申请目前使用不同的客户资料和账户。管理层已设立联合事业部，投资者想判断这次整合能否按期落地。

哪项调查最能检验这项整合承诺？

某市采购了一套已经定型的地震监测平台。平台按国家固定协议分成采集、校验、预警三个环节，市里无权改动。市监测中心恰好也设有三个对应科室。一篇报道据此断言，科室之间沟通困难，所以平台被切成了三段。

对这篇报道，哪种判断最站得住？