好书精读 · READ 922

《Team Topologies》

Team Topologies · 马修·斯凯尔顿 & 曼努埃尔·派斯（Matthew Skelton & Manuel Pais）· 2019

EN →

一句话

这本书只主张一件事，但主张得非常彻底：组织结构不是 HR 的事，它是一项架构决策——你画的团队图，就是你三年后一定会得到的系统图。所以别再等着「等系统烂了再重组」，而要反过来先设计团队：让每个团队认知负荷可承受、边界与业务边界对齐、彼此之间的协作方式被显式选定，系统的模块化会跟着长出来。作者给出的全部工具只有两组：四种团队类型，三种交互模式。

坐标

斯凯尔顿与派斯都是 DevOps 咨询出身，2019 年由 IT Revolution（《凤凰项目》《Accelerate》的同一家出版社）出版此书。它在工程组织类书里的位置很特别：它不讲个人怎么做事（那是《The Effective Engineer》），也不讲怎么带人（那是《The Manager's Path》），它讲的是「团队与团队之间应该是什么关系」——这是绝大多数组织从没有人认真设计过的一层。书很薄，观点密度很高，且几乎不谈流程与工具，全部力气花在边界上。

核心论点

• 组织设计与系统架构是同一件事的两面，因为康威定律（Conway's Law）不可违抗。与其被动接受它，不如主动利用它：先想清楚你要什么样的架构，再照着那个架构组建团队。
• 交付的基本单位是团队，不是个人。因此团队应当长期稳定、有明确所有权，让工作流向团队；把人当可调度的资源来回抽调，是在持续摧毁交付能力。
• 限制一个团队的责任范围，本质是限制它的认知负荷（cognitive load）。团队装不下的系统，无论怎么排优先级都做不好——「再加一个服务给你们维护」是有真实上限的。
• 团队类型只需要四种，交互模式只需要三种；其余一切名目繁多的团队都应该被归并进这四种，一切说不清楚的协作都应该被显式定成三种之一。并且，交互模式本身应当随时间被主动切换。

核心概念，逐个讲透

康威定律与「反向康威操作」

康威定律来自梅尔文·康威（Melvin Conway）1968 年的一篇文章《委员会如何发明？》，原话大意是：设计系统的组织，其产出的设计必然是这些组织自身沟通结构的翻版。它常被当成一句俏皮话，其实机制很朴素：系统里的「接口」出现在需要沟通的地方。两个组之间沟通成本高、见面少，他们就会在自己的两块之间定一个粗糙、正式、尽量少变的接口；同一个团队内部的两块代码，因为随时能喊一声，就会长成紧耦合、边界模糊的一坨。所以架构图不是画出来的，是沟通成本长出来的。最广为流传的例子是：四个小组一起写编译器，最后得到的往往是一个四趟（four-pass）的编译器——不是因为四趟最优，而是因为组有四个。

这条定律有一个残酷的推论，也是本书的起点：你不可能靠一群沟通紧密纠缠的团队，造出一个松耦合的系统。架构师画再漂亮的微服务图，只要两个团队每天必须开会才能推进一个需求，那条边界迟早会被磨掉。很多「微服务改造失败」的真相不是技术选型错，是团队边界从来没跟着切——于是得到的是「分布式的单体」：部署上分开了，改一次仍然要三个团队一起发版。

本书主推的对策叫「反向康威操作」（Reverse Conway Maneuver，这一说法由 ThoughtWorks 提出）：不要让现有组织结构去决定架构，而是先确定你想要的架构，再倒过来调整团队与沟通结构，让康威定律替你干活。——注意它的力量与它的前提同样大：这一招要求你已经知道目标架构长什么样；而在很多真实项目里，目标架构恰恰是还没搞清的那件事。这一点后面「批评」里会再说。

团队才是单位：团队 API，以及重组的真实成本

本书把「团队优先」（team-first）当作前提而不是结论，理由很实在：一个刚拼起来的团队不会立刻开始产出。作者引用心理学家塔克曼（Bruce Tuckman）那个经典的四阶段模型——组建（forming）、震荡（storming）、规范（norming）、执行（performing）——指出一个团队通常要几周到几个月才走到「执行」。于是每一次「把这三个人抽去支援那个项目」，代价都不是三个人月，而是把两边同时打回震荡期。结论：团队要长期稳定，让工作流向团队，而不是让人流向工作。

与之配套的是一个很好用的说法：团队 API——一个团队向外暴露的全部东西，不只是代码接口，还包括它维护的服务、文档与版本约定、工作方式（迭代节奏、值班安排）、以及别人该怎么找它（走什么渠道、多久回应）。把这些写下来这件事本身就有价值：绝大多数跨团队摩擦不是技术问题，是「我不知道该问谁、也不知道多久有回音」。一个说不清自己 API 的团队，对组织的其余部分而言就是一片必须靠开会才能穿过的雾。

认知负荷：全书真正的新东西

如果说这本书只贡献了一个概念，那就是它。认知负荷（cognitive load）原是认知心理学家约翰·斯威勒（John Sweller）1988 年提出的学习理论：人的工作记忆容量有限，学习时的负荷分三类。本书把它从「一个人学东西」搬到了「一个团队维护系统」上：

• 内在负荷（intrinsic）——任务本身固有的难度：这门语言怎么写、这个框架怎么用。降低它的办法是培训、结对、更好的工具。
• 外在负荷（extraneous）——与要解决的问题无关、纯属环境带来的负担：怎么申请一台机器、发版要提几个工单、日志埋在哪。这一类应该被压到接近零——这正是平台团队存在的全部理由。
• 相关负荷（germane）——真正产生价值的那部分：这块业务领域到底怎么回事、用户在什么场景下会怎么做。这是你希望团队把脑子花在上面的东西。

于是有了一条清晰得可怕的管理判据：一个团队的总容量是固定的，你每往它头上多压一份外在负荷，就等量地挤掉它用于理解业务的相关负荷。「让他们再顺手维护一下那个老服务」不是零成本的排期问题，它是从这个团队理解业务的能力里直接扣钱。

本书据此给出团队职责范围的经验法则：把领域按难度分成简单、复杂（complicated，指需要专门知识但可解）、繁杂/不确定（complex，指要靠试错才能摸清）三档；一个团队可以扛两三个简单领域，但不应该同时扛一个以上的复杂领域，而高度不确定的领域往往需要一个团队专门盯着、甚至不止一个团队。作者也承认它没法精确测量，实践中的做法是直接去问团队：「你们需要装在脑子里的东西，是超载了、刚好、还是有余量？」——这个问题粗糙，但它把一件从来只靠感觉抱怨的事，变成了可以定期复盘的指标。

与之配套的是团队规模：本书借用人类学家罗宾·邓巴（Robin Dunbar）关于人际关系上限的分层（约 5 人是高度互信的核心、约 15 人是能彼此深度信任的圈子、约 150 人是能维持稳定关系的上限），主张团队保持在 5–9 人，并且团队之上的分组也要照这些数量级去切。亚马逊的「两个披萨团队」是同一条直觉的另一种说法。

四种团队类型：其余的都该被归并掉

本书最出名的部分。作者的主张不是「这四种很有用」，而是更强的：四种就够了；你组织里任何叫不上号的团队，都应该被改造成其中之一，否则它就是一个边界不清的负债。

四种团队类型，及各自最常见的走样方式。判断一个团队属于哪种，看它的产出如何被消费，而不是看它叫什么。

这里最容易被跳过、却最要害的一句是：平台必须「有吸引力」（compelling），而不是被强制使用。作者的逻辑很硬：如果流对齐团队宁可绕开你的平台自己搞，说明你的平台没有真的降低他们的负荷；靠行政命令把人赶上来，只会把痛苦从「用不了」变成「用了更痛苦但不能说」。「内部平台要像外部产品一样去竞争用户」这条标准，比任何组织架构图都更能验证一个平台团队是真是假。

三种交互模式：以及「模式必须随时间切换」

这是本书第二个、也是被低估的贡献。绝大多数组织只画了团队框图，从没规定过框与框之间的线是什么线——于是所有关系默认退化成「有事就拉个群」。作者说，团队之间只该有三种关系，而且必须显式选定：

三种交互模式。同一对团队在不同阶段应该用不同的模式，这才是这张表真正的用法。

把这两张表拼起来，才得到本书真正的操作方法：用「协作」去发现边界，边界一旦摸清，立刻切换成「X 即服务」。这句话解决了一个常年的两难：完全靠协作，速度快但永远长不出清晰接口，团队越来越纠缠；一上来就定接口，接口十有八九是错的，然后大家绕着一个错接口做三年。正确做法是把「协作」当成一段有终点的勘探期，它的产出物就是那个接口本身。

反过来，这也给了一个极其好用的诊断信号：如果某两个团队之间的「协作」永远结束不了、每次需求都得凑在一起才推得动，那说明边界划错了，而不是他们协作得不够努力。作者把这种能力叫组织的「感知」——团队拓扑不是画一次就完的图，而是要根据这类信号持续演化。

断裂面：一个系统该从哪儿切开

知道要切，还得知道从哪切。作者借用了「断裂面」（fracture plane）这个说法——地质学里岩石天然容易裂开的那个面；顺着它敲，一下就开，横着敲，怎么砸都是碎渣。软件里的断裂面候选包括：

• 业务领域边界——最重要的一条。这里用的是领域驱动设计（DDD）的「限界上下文」（bounded context）：同一个词在不同上下文里指的根本不是一回事——「订单」在结算系统里是一笔应收，在仓储系统里是一张拣货单。模型只在自己的上下文内部保持一致，跨过去就必须翻译。团队边界应该与限界上下文重合，而绝不该从中间穿过。
• 变更节奏——一天上线十次的东西和一年动一次的东西，绑在一个团队里，快的那部分一定会被拖慢。
• 合规与风险——受严格监管的那块（支付、医疗数据）审批流程完全不同，切开可以让其余部分不必陪着走重流程。
• 用户画像——服务专业用户与服务新手的两条流，节奏与判断标准都不一样。
• 技术与性能隔离——需要特殊硬件、或必须独立扩缩容的部分。
• 地理位置与时区——现实约束：跨十小时时区的两半，几乎无法维持「协作」模式，只能走 X 即服务。

贯穿所有断裂面的唯一判据仍然是那句话：切完之后，每个团队要能在自己的认知负荷之内，端到端拥有一件完整的事。按技术层次切（前端组、后端组、DBA 组）之所以是最常见的错误，正是因为它在每条业务流上都制造了三次交接，没有任何一个团队能独立交付一个用户价值——而每一次交接都要排一次队，于是「改个按钮文案」和「重写结算逻辑」在流程上花的时间会诡异地趋同。作者对「优化人力利用率」的批评也在这里：把每个人排到 100% 满，等于保证任何一次交接都必须等待；流动速度与利用率是互相冲突的两个目标，而绝大多数组织在毫无意识的情况下选了后者。

精华骨架

第一步，承认康威定律不可违抗。系统的形状会向组织的沟通结构收敛，你抵抗不了，只能选择是被它塑造还是用它来塑造。

第二步，把优化目标改成「变更的快速流动」。不是人力利用率，不是成本，而是一个想法从提出到上线的顺畅程度。利用率拉满的组织必然流动缓慢——每个人都排满了，任何一次交接都要排队。

第三步，把团队当成不可拆的单位，并给它设一个真实的容量上限。团队长期稳定、拥有明确的东西，而它能拥有多少，由认知负荷决定，不由排期意愿决定。

第四步，用四种类型把组织重画一遍。绝大多数是流对齐团队；平台团队负责把外在负荷压到零并且必须做成有人愿意用的产品；复杂子系统团队仅在确有深度专业性时设立；赋能团队以让自己被淘汰为目标。

第五步，把团队之间的每一条线显式定成三种模式之一，并且随阶段切换。用协作去勘探边界，用 X 即服务去固化边界，用促进去补能力。协作若长期结束不了，是边界错了的信号。

第六步，把这套东西当成持续演化的过程，而不是一次重组。沿断裂面切，观察哪些接缝在持续发痛，据此再调——组织本身就是一个需要被持续重构的系统。

常见误读 & 批评争议

误读一：把它当成一张可以照抄的组织架构图。书里最容易被截图传播的就是那四个方块，于是常见结果是：把运维组改名平台团队、把架构组改名赋能团队，交互方式一动不动。作者本人反复强调，决定一个团队属于哪种类型的是它的产出如何被消费，不是它的名字；不改交互模式的改名，是纯粹的「拓扑表演」。

误读二：平台团队 = 基础设施团队。本书的平台是产品：自助、有文档、有版本、有内部用户、可以被绕开。一个靠工单驱动、需要人工审批的基础设施组，在本书的定义里根本不是平台团队，而是一个被制度化的外在负荷源。

误读三：流对齐团队意味着「你构建你运维」（you build it, you run it）什么都得自己扛。恰恰相反——本书的整个平台论证，就是为了让流对齐团队不必什么都懂。所有权的边界应当由认知负荷决定，而不是由一句口号决定。

最实在的批评：证据基础薄。这套框架来自咨询实践与案例，不是对照研究；《Accelerate》那类基于 DORA 指标的量化证据支持的是「小批量、松耦合、自主团队更快」这类更一般的结论，并没有验证「恰好这四种类型」。换句话说，它的价值更接近一套好用的词汇表与检查清单，而不是一个被检验过的因果模型——把它当定律用会失望。

「认知负荷」这个概念本身经不起严格推敲。斯威勒的理论说的是个体在学习任务中的工作记忆负荷，本书把它整体搬到「团队维护系统」这个完全不同的对象上，既没有测量方法，也没有明确的加总规则——最后落到一份主观问卷上。公允地说：作为思考工具它极其好用（它把「我们扛太多了」变成了一句能被认真对待的话），但别把它说得像个可以量化的指标。

反向康威操作有一个先有鸡还是先有蛋的问题。它要求你先知道目标架构，可对新领域而言，架构恰恰是要靠做才能发现的。此外，学术上关于「组织结构与架构相互映射」的假说（研究中称为 mirroring hypothesis）虽有大量支持，但并非普遍成立——开源项目常常是明显的反例：一群从不开会、分散在全球的人，照样能维护高度模块化的系统。这提示康威定律描述的其实是沟通结构而非行政结构，而这两者在开源里恰好脱钩了。

邓巴数字本身在学界有争议——近年有复现研究质疑那个具体数值的可靠性。它作为「团队规模有上限」的直觉支撑没问题，作为精确阈值就不宜当真。

最后一条实践者的抱怨也值得记下：书很薄，难的部分它没讲。画出目标拓扑是最容易的一步；真正难的是预算怎么重分、谁的团队被拆、平台团队的价值如何向不写代码的高层证明。这本书给了你一张地图和一套词汇，但没给你走过去的政治学。

十句话精华