1.2 团队拓扑与组织设计

概述与动机

你如何把人员划分为团队，决定了你能构建什么样的软件，以及你能以多快的速度构建它。这不是一个比喻，而是一个近乎机械式的必然结果，被称为康威定律：组织所设计出的系统，会映射出它们自身的沟通结构。如果三个团队来构建一个编译器，你得到的就会是一个三趟编译器。如果你的支付逻辑被拆分到一个前端团队、一个后端团队和一个数据库团队之间，那么每一次支付相关的变更，都需要三方协调。对一个小型组织而言，这还可以应付。对一个大型组织而言，组织架构图的形状会变成你工程、架构、交付速度和质量方面的主导性约束。因此，设计团队结构是一项一流的工程活动，而不是人力资源部门事后才想起来的事情。

团队拓扑为这种设计提供了一套刻意的词汇。成熟的组织不会任由结构在一次次重组和人员编制中意外累积，而是有意识地选择团队类型和互动模式，并随着系统和业务的演进不断重新审视这些选择。目标是让每个团队的认知负荷（）一个团队为了保持高效而必须记在脑子里的总量（）保持较低，从而使团队能够端到端地拥有自己的领域，并持续不断地交付价值，而不必总是等待别人。

对企业和政府而言，这门学科具有决定性意义。大型组织天然地会蔓延成深层的层级结构、排着长队的共享服务，以及能把一次两天的变更拖成一个两个月项目的交接链条。政府还会加上采购边界、承包商团队，以及强制性的职责分离，把所有权进一步分割开来。明确的拓扑设计，正是这些组织重新夺回”流动性”的方式：让团队与价值流对齐，构建能降低认知负荷的平台，并选择能让依赖关系变得可见、有意图，而不是隐藏且持续存在的互动模式。

关键原则

康威定律是无法逃避的；要按照你想要的软件工程结果来设计团队（即”反向策略”）。
要为团队的认知负荷进行优化，而不是为个人的最大化利用率进行优化。
优先选择端到端拥有一部分价值的流对齐团队。
平台存在的意义是降低流对齐团队的认知负荷，而不是充当把关者。
让团队之间的互动明确且数量有限：协作、“X 即服务”，或促成式协助。
把依赖关系最小化；每一次跨团队交接，都是一个队列，也是一个风险点。
团队结构是一种活的设计，必须随着系统和业务的变化而演进。

建议

使用四种基本团队类型

团队拓扑定义了四种能覆盖大多数需求的团队类型。流对齐团队是默认选项：每个团队都端到端地拥有针对某个特定产品、服务或用户旅程的持续工作流。平台团队提供内部产品（计算资源、部署、数据流水线、身份认证），供流对齐团队自助式地消费，从而降低他们的认知负荷。赋能团队是专家团队（测试、安全、可观测性），负责指导流对齐团队构建某项能力，然后退出。复杂子系统团队拥有那些需要深厚专业知识的组件（一个定价引擎、一个视频编解码器、一个加密模块），让每个团队都掌握这些知识是没有意义的。你的大多数团队都应当是流对齐团队；其余三种类型的存在，是为了支持它们。

应用反向康威策略

既然软件会映射出你组织的结构，那就塑造你的团队，去产出你想要的软件。想要松耦合、边界清晰的服务吗？那就创建松耦合、所有权边界清晰的团队。想要一个能按自己节奏发布的支付能力吗？那就组建一个从前到后端到端拥有它的支付团队。不要用英雄式的协调去对抗康威定律，而要重新划定团队边界，让你想要的架构成为阻力最小的路径。

明确地管理认知负荷

一个团队所能掌握的东西是有限度的。认知负荷包括领域复杂度、技术栈、运维负担，以及利益相关者的广度。当一个团队拥有太多互不相关的服务时，质量和速度都会崩溃。因此要把每个团队的职责范围界定在它真正能够掌握的领域之内，并用平台和赋能团队把无差别的复杂性从它的盘子里挪走。要把团队规模控制在大约五到九人：小到足以轻松沟通，也可以说是小到”两个比萨”就能喂饱。

有意识地选择互动模式

把团队之间的互动限定为三种模式。协作是两个团队在一段设定的时期内进行的紧密、高带宽的合作；它在探索阶段很有力量，但成本高昂，因此要让它保持临时性。“X 即服务”是一种界面定义清晰、提供方与消费方关系分明的模式，非常适合规模化的平台消费场景。促成式协助是一个团队帮助另一个团队学习，这正是赋能团队所做的事情。为每一段重要的跨团队关系指明它所处的模式，并把同一对团队之间长期持续的协作，解读为一个信号：他们之间的边界划在了错误的位置上。

为横切职能选择一种运营模式

安全、数据、设计等类似的学科，可以用三种方式来组织：中心化（一个团队为所有人拥有它）、联邦化（专家以兼职方式嵌入各团队，通过一个行会来协调），或嵌入式（每个流对齐团队内部都有一名专职专家）。中心化能带来一致性和深度，但会变成瓶颈。嵌入式能带来速度和上下文理解，但存在不一致和重复劳动的风险。联邦化（通常是一种轮毂辐条式，或称实践社区模式）介于两者之间。要按职能、按规模分别做出选择。大多数大型组织在这些学科上最终会落在联邦化模式，外加一个负责制定标准的小型中心核心团队。

投资于内源

内源把开源的协作模式带入组织内部：共享的内部代码仓库、公开发布的贡献指南、跨越团队边界的代码评审，以及明确的维护者。当一个团队需要对另一个团队的组件做出变更时，它可以直接贡献这项变更，而不是提交一张工单，然后排队等待。这在不消解所有权的前提下缓解了跨团队依赖，也让知识和标准在庞大的工程人员群体中自然地传播开来。

权衡：优点与缺点

横切职能的模式	优点	缺点
中心化（一个团队负责所有）	一致性、深厚的专业能力、清晰的标准	瓶颈、排队、丧失产品上下文
联邦化（轮毂辐条式、行会）	兼顾一致性和速度；传播知识	需要协调纪律；问责可能变得模糊
嵌入式（每个团队配专家）	速度快、贴近上下文、主人翁意识强	重复劳动、不一致、规模化时难以配齐人手

团队类型	最适合的场景	过度使用的风险
流对齐团队	大多数产品和服务交付	无；这应当是主导类型
平台团队	降低共享的认知负荷	变成象牙塔式的把关者
赋能团队	临时性地传播某项能力	变成一种永久性的依赖
复杂子系统团队	真正需要深厚专业知识的领域	被用作囤积普通工作的借口

反复出现的权衡是自主性与一致性之间的取舍。完全自主的团队行动迅速，但会在标准、工具和安全态势上逐渐分道扬镳。完全中心化的控制能保持一致性，但会扼杀流动性。好的拓扑设计能找到那道缝隙：为流对齐团队的交付保留自主性，同时为那些真正需要保持一致的事项，提供精简的中心标准和”铺好的道路”式平台（配套完善、能让合规选择成为最省力选择的默认工具）。

与团队讨论的问题

在质量崩溃之前，什么样的具体信号会告诉你一个团队的认知负荷过高了？ “把每个团队限定在它能够掌握的领域之内”这句话说起来容易，没有证据的话却很难落实，因为认知负荷在交付和可靠性开始恶化之前，一直是不可见的。要关注可度量的症状：一个团队拥有的互不相关的服务或代码仓库数量、入职培训需要多长时间、单个工程师在一周内必须在多少个领域之间切换上下文，以及一个团队职责范围边缘地带不断上升的事件率。对一个大型组织而言，这一点很重要，因为超负荷的团队会悄悄变成瓶颈，而任何组织架构图都无法预测到这一点。请把这些数字带到讨论中来，再加上团队自己对他们脑子里能记住和记不住什么的判断。如果这些信号显示超负荷，正确的做法是把无差别的工作转移给一个平台或赋能团队，而不是要求更多的英雄式付出。
在这里进行一次重组，真的值得付出这样的破坏性代价吗，还是你们正在助长一种”重组成瘾”？ 重新划定边界以应用反向康威策略确实很有力量，而每一次重组也都会破坏团队凝聚所需要的稳定性，并重置来之不易的领域知识。相互竞争的考量，是当前结构所带来的持续协调税，与改变它所带来的一次性成本和士气打击之间的权衡。在企业和政府场景中，采购边界、承包商团队和强制性的职责分离，会让重组变得更慢、更昂贵，因此门槛应当设得更高。请带上由依赖关系导致的延误证据：有多少项举措正因为等待另一个团队而被阻塞，被阻塞了多久。当这种等待是结构性的、且规模很大时，就应当重组；而当痛苦是暂时的、或者用内源贡献和更清晰的接口就能更便宜地解决时，就应当抵制重新洗牌的冲动。
对于安全、数据和设计而言，什么样的事件会触发你们在嵌入式、联邦化和中心化之间切换？ 本章的建议是按职能、按规模分别做出选择，而更难的功课，是提前决定什么样的增长或风险会促使你们重新审视这个选择。一个适合五十名工程师的模式，在五百人规模时可能会变成瓶颈或一致性灾难，企业和政府机构尤其需要明确指出，哪些标准是一个小型中心核心团队会始终坚持的。请带上每个职能当前的排队时间和一致性缺口：一个拥有数周审查队列的中心安全团队，是一个应当联邦化的信号；而嵌入式专家们产出互不兼容的数据模型，则是一个应当增设一个中心标准核心的信号。现在就确定触发条件，比如一个队列长度阈值或一项审计发现，这样这种变化就会成为一次有计划的演进，而不是一场危机反应。这个答案决定了你们应当把投资放在”铺好的道路”和推广者身上，还是放在一个中心枢纽上。
你们如何判断你们的平台团队究竟是在真正降低认知负荷，还是正在悄悄变成把关者？ 平台存在的意义，是通过自助服务让合规、可靠的选择成为最容易的选择，而同一个团队却可能逐渐演变成强制要求使用特定工具、对每一个请求进行人工评审，并增加了它本应消除的摩擦。对一个大型组织而言，这个区别决定了平台投资到底是获得回报，还是变成每个流对齐团队都要排在后面的中心瓶颈。相互竞争的考量，一边是一致性和控制，另一边是消费方的自主性和流动性。请带上消费方能够认可的证据：一个流对齐团队在不提交工单的情况下自助获得一个新环境或流水线需要多长时间、自助操作与人工介入操作的比例，以及以主动选择该平台的团队数量、而不是被迫使用的团队数量来衡量的平台采用率。在企业和政府场景中，要坚持让平台自动生成审计和合规证据，而不是通过人工关卡，因为一个通过插入一名人工审核者来满足职责分离规则的平台，实际上已经重新制造出了它本应被出资消解的那个瓶颈。
你们的哪些跨团队关系已经固化为永久性的协作，怎样才能把每一段关系转化为一个清晰的服务接口，或者一条重新划定的边界？ 协作模式本应是高强度且临时性的，而一段永远不结束的搭档关系，通常是一个信号，说明所有权被放错了地方，或者两个团队之间的接口从未被明确定义过。这一点在规模化的场景下尤为重要，因为未被命名的、常设的协作，正是协调成本藏身之处：它不会出现在任何组织架构图上，却会给这两个团队所触及的每一次变更征税。相互竞争的考量，一边是保持紧密联系所带来的探索价值，另一边是把这段关系转化为一份带有明确接口定义的”X 即服务”合约、或者把职责合并到单一团队之中所获得的流动性。请带上持续协作超过一个季度的团队配对清单、过去几个月里需要两个团队共同参与的变更，以及两者之间是否可以写出一份稳定的接口定义。对于企业和政府场景而言，承包商边界和采购批次可能会把一种交接方式冻结数年之久，因此要指明哪些关系可以通过接口和内源贡献来转化，哪些关系是合同上固定的、必须作为明确的依赖关系来管理。
当一个赋能团队帮助另一个团队构建某项能力时，你们如何知道它已经成功、可以功成身退，而不是变成一种永久性的依赖？ 赋能团队的用意，是指导一个流对齐团队掌握测试、安全或可观测性，然后继续前进，而如果没有明确的退出条件，这种辅导关系就会硬化为一项常设服务，流对齐团队实际上从未真正吸收它。对一个大型组织而言，这就是”把一项能力传播到数十个团队”与”创造一个每年都变得更糟的新共享瓶颈”之间的区别。相互竞争的考量，一边是一个专家团队所提供的深度和一致性，另一边是你正试图为流对齐团队建立的自主性和端到端所有权。请带上能力转移方面的证据：接收方团队现在是否能在赋能团队不在场的情况下处理这项工作、一个固定的赋能小组同时承诺服务了多少个团队，以及每一次协作已经超出预定交接时间多久。在企业和政府场景中，一项稀缺的专家技能可能藏身于一个单一的中心团队或一份单一的合同背后，因此要提前决定如何为能力转移和推广者提供资金，从而让专业知识扩散到交付团队之中，而不是一直锁在一个每次审计和发布都要排队等候的队列后面。

行业视角

初创企业。 只有少数几名工程师、跑道也很短，正确的拓扑是一个端到端拥有整个产品的单一流对齐团队，而纪律就在于拒绝在真正需要之前就制造出孤岛。要抵制雇一个孤零零的”DevOps 人员”或”QA 人员”、让他们变成一道关卡的冲动；要把这些技能作为一种嵌入式能力，融入到这一个团队之中。要通过保持组织扁平，让康威定律为你所用，从而让架构保持和团队一样简单、一样易于改变。

小型企业。 你配不齐一支专职的平台团队或赋能团队，因此要去”购买”平台：使用托管云服务、托管流水线和现成的安全工具，把无差别的认知负荷从你那一两个团队身上挪走。要把安全和数据这样的横切关切，当作你去配置和消费的东西，而不是你要自己构建的一项职能。要把任何定制化的所有权，留给那一个真正让你与众不同的复杂子系统，其余的交给供应商去承担。

企业。 在规模化的场景下，问题在于跨众多团队的协调成本，因此要把拓扑设计变成一项明确的、受治理的设计：一套四种团队类型的共享分类法、命名清晰的互动模式、一个”铺好的道路”式平台，以及用来缓解跨团队排队的内源。要把由依赖关系导致的延误和团队认知负荷，作为项目组合层面的指标来跟踪，并把重组当作有高门槛的、深思熟虑的演进来运行，而不是每年一次的条件反射。一个精简的中心核心团队负责那些必须保持一致的标准，而流对齐团队则在交付上保持自主性。

政府。 采购规则、承包商边界和强制性的职责分离，把所有权分割开来，因此要通过工具和清晰的接口，而不是通过人工交接，来设计满足这些约束的拓扑结构。要优先选择联邦化模式，配上一个小型标准核心，以及一个能自动生成审计和合规证据的平台，这样职责分离就由流水线来强制执行，而不是由审查队列来执行。要公开记录团队边界、互动模式和运营模式，从而让结构对审计人员、监督机构和为之买单的公众保持透明。

示例

初创企业。 一家十人规模的初创企业有一个端到端拥有整个产品的单一流对齐团队，这在其规模下恰到好处：没有交接，没有协调税，每个人共享同样的上下文。麻烦是从他们雇用了一名专职的”DevOps 人员”和一名独立的”QA 人员”、并因此无意中重新制造出了职能孤岛开始的，从此每一次发布都要等待这两个人。他们通过纠偏（）把这两个新雇员当作嵌入在这个团队内部的一项平台和测试能力，而不是工作必须通过的关卡（）来解决这个问题。在这个规模下，最经济的拓扑，就是那种能让所有人都处于单一流程之中的拓扑。

企业。 一家大型零售商的结账流程变更缓慢，因为前端、后端和履约逻辑被拆分到三个按职能组织的团队之间，迫使每一次变更都要经过三个待办事项列表。他们应用反向康威策略，围绕客户旅程（“浏览”、“购物车与结账”、“购后”）重组为流对齐团队，每个团队从前到后端到端地拥有自己的那一部分，并由一个以服务形式提供部署和可观测性的平台团队作为支撑。曾经需要一个季度的结账变更，如今几天之内就能上线，因为曾经跨越多个团队的协调，如今发生在一个团队内部。

政府。 一家政府税务机构曾经运行着一个审查每一次发布的中心安全团队，制造出一个数周之久的队列，拖延了关键修复。他们转向了联邦化模式：一个小型中心安全职能负责制定标准，并提供一条预先批准、自动扫描的”铺好的道路”流水线，而嵌入在每个交付团队中的兼职安全推广者则处理日常决策。该平台自动生成合规证据。强制性的职责分离要求依然得到满足，但是通过工具和清晰的接口，而不是通过一个人工瓶颈来实现的，这大幅缩短了发布前置时间，同时也提升了审计准备度。

商业论证：动机、投资回报率与总拥有成本

糟糕的团队设计，其代价体现在协调开销之中，而这种开销的增长速度，比需要为一次典型变更进行同步的团队数量增长得更快。每一次交接都是一个带有等待时间的队列，是一次会丢失信息的上下文转移，也是一次全新的误传沟通的机会。当一次常规变更需要三个团队对齐各自的路线图时，真正的成本并不是他们各自工作量的总和，而是排期、等待和返工所带来的远为庞大的成本。重新划定边界，让大多数变更能落在单一团队的所有权范围之内，这种开销就会自然消失。

采纳这种做法的成本是真实存在的。重组具有破坏性，构建平台和内源实践需要前期投资，回报才会到来。但不采纳的成本会不断累积。任由结构意外累积的组织，会堆积起交接链条、排着一个季度之久队列的共享瓶颈团队，以及被组织架构图固化的架构。要向领导层证明这件事的合理性，就要度量由依赖关系导致的延误：有多少项正在进行的举措正因为等待另一个团队而被阻塞，被阻塞了多久。平台和拓扑投资通常能通过把等待转化为流动而获得回报，表现为在不增加人头的情况下，前置时间缩短、吞吐量提高。

反模式与陷阱

忽视康威定律：设计出一种组织结构根本无法交付的架构。
职能孤岛：独立的前端、后端、QA 和运维团队，任何变更都必须协调。
共享服务瓶颈：一个每个项目都必须排队等候的中心团队。
平台变把关者：一个强制要求、而不是服务他人的平台团队，增加而不是消除摩擦。
认知过载：团队拥有一大堆互不相关、无法掌握的系统。
永久性的”协作”：两个团队永远纠缠在一起，暗示着一条被放错位置的边界。
重组成瘾：不断地重新洗牌，破坏团队凝聚所需要的稳定性。

成熟度模型

第 1 级，启动。 团队因意外、人员编制或遗留的层级结构而形成；没有人命名团队类型或互动模式；职能孤岛和共享服务瓶颈随处可见，依赖关系一直隐藏，直到它们阻塞一次发布。
第 2 级，发展。 一些流对齐团队已经存在，第一个平台或内源工作也已出现，但这种模式的应用并不均衡：一些团队端到端地拥有自己的那部分，另一些团队仍然要在中心职能后面排队，认知负荷只是被随口议论，而没有被管理起来。
第 3 级，标准化。 四种团队类型和三种互动模式已被记录下来，并在整个组织中被有意识地使用；平台和内源缓解了跨团队依赖；针对安全、数据和设计的运营模式已被选定并写下来，新团队是依据这些标准组建的，而不是临时拼凑的。
第 4 级，管理。 拓扑结构被对照基线进行度量和控制：团队跟踪认知负荷、由依赖关系导致的延误（举措因等待另一个团队而被阻塞、被阻塞了多久）、平台自助服务比例和采用率、互动模式的持续时长，以及诸如前置时间和变更频率这样的交付流动性指标。阈值会触发行动，例如一个迫使某个职能走向联邦化的队列长度，或一段标记出边界放错位置的常设协作，因此决策依据的是证据，而不是主观看法。
第 5 级，协同。 团队设计被持续改进，并与架构、产品和风险规划相整合；组织随着系统和业务的演进重塑边界，在能力转移完成后终止赋能式协作，并随着认知负荷的变化重新平衡平台投资，让快速流动成为一种自适应的、常设的属性，而不是一次性的重组。

讨论思路

对于一次典型的变更，需要多少团队进行协调，为什么？
我们的哪些团队正承载着过高的认知负荷，一个平台能卸下其中的哪些部分？
我们在哪些地方是在对抗康威定律，而不是重新划定边界？
我们的平台团队是在服务流对齐团队，还是在把关它们？
对我们而言，安全、数据和设计现在应当是中心化的、联邦化的，还是嵌入式的？
哪些”临时性”的协作已经悄悄变成了永久性的依赖？

关键要点

组织结构决定了架构和交付速度；要有意识地设计它。
使用四种团队类型，以流对齐团队为默认选项，其余三种作为支持。
应用反向康威策略，让期望的架构成为最省力的路径。
管理认知负荷；把每个团队限定在它能够掌握的领域之内。
限定并明确命名跨团队互动模式；把挥之不去的依赖关系，当作边界缺陷来看待。
按规模为横切职能选择中心化、联邦化或嵌入式模式，并用内源来缓解排队。

参考文献与延伸阅读

Matthew Skelton and Manuel Pais, “Team Topologies: Organizing Business and Technology Teams for Fast Flow”
Melvin Conway, “How Do Committees Invent?” (the origin of Conway’s Law)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Sam Newman, “Building Microservices” (on aligning services to teams)
Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” and the InnerSource Commons patterns
Frederick Brooks, “The Mythical Man-Month” (communication overhead)