想要什么样的产品，先画什么样的团队
系列「人不按组织图做事」 · 第 5 篇／共 13 篇 · 第二部分 · 结构怎么塑造行为
序篇：组织图上看不到的人
一家公司在日本搭了两个工程团队，一个做移动端，一个做后台，分别向两个负责人汇报。一年后，产品有两套登录逻辑、两套错误提示、两份互相对不上的 API 文档。没有人决定要这样，但产品长成了组织图的样子。
系统复制沟通结构
Melvin Conway 1968 年的论文说了一句后来被叫做 Conway 定律的话：设计系统的组织，做出来的系统结构会复制这个组织的沟通结构。他举的例子是：让三个团队做一个编译器，你会得到一个三遍扫描的编译器。
原因不神秘。两个模块之间要有接口，接口要两边的人谈出来。谈得多的两个团队，接口就细；谈得少的，接口就粗、就重复、就各做各的。产品的缝，长在组织的缝上。
这条定律的争议不在它对不对，而在它有多强。有实证研究在开源项目和企业软件里找到了对应关系，也有人指出它更像一种倾向而不是定律：好的架构师可以有意识地跨过组织边界。我的看法是，倾向足够强，强到不设计就一定会被它牵着走。
反过来用：逆康威
既然产品会长成组织的样子，那就先决定产品该长什么样，再按它画组织。这个用法被叫做「逆康威」（Inverse Conway Maneuver）。
具体是三步。先画目标产品的架构：有几个主要模块，模块之间的边界在哪里，哪些边界要求紧耦合、哪些可以松。再按模块画团队：每个需要紧密协作的模块群归一个团队，团队之间的边界和模块之间的边界重合。最后才招人：按团队的职责定岗位，不是按市场上有什么人定团队。
Fig.1Conway 定律：右边的产品结构复制左边的沟通结构。逆康威是先画右边，再画左边。
多数公司的顺序正好相反：先按能招到的人成立团队，再看这些团队能做出什么产品。在人才市场紧的地方这很自然，但代价是产品架构被招聘结果决定了。
在日本搭工程团队的三个具体决定
一，一个产品的核心模块群，放在一个物理场所、一个汇报线之下。上一篇写的50 米在这里直接起作用：需要细接口的两个模块，做它们的人要坐在一起。
二，日本团队和海外团队之间的边界，要和产品里一个真实的模块边界重合。最常见的错误是按前后端分：前端在东京，后端在总部。前后端之间是全产品接口最密的地方，隔了时区和语言之后，产品会在这条缝上出问题。更好的切法是按功能域分：日本团队负责日本市场特有的一整块功能，从界面到数据，总部负责通用平台。
三，团队规模按模块的复杂度定，不按预算定。一个模块需要五个人，就五个人；给三个人，产品里对应的那一块就会简陋，给八个人，那一块就会过度设计。
接回方法论
我做组织设计的顺序是先画两张地图（市场和人才），再定产品，再定销售，最后定组织。Conway 定律是「先产品后组织」这一步的理论依据：组织是为产品服务的，不是反过来。它也和分类即命运那篇说的同一件事：框画在哪里，东西就长成什么样。
你们产品里最明显的那条缝，对应组织图上的哪条边界？
系列导航
上一篇：隔开 50 米，沟通就断了
下一篇：刚起步的日本法人，别用总部那套管
不够写成一篇的日常想法，我写在 LinkedIn 上。去 LinkedIn 关注我