team-topologies

团队拓扑

Matthew Skelton 和 Manuel Pais 在《Team Topologies》中提出了一种以团队为先的组织设计方法：四种基本团队类型、三种交互模式，并有意关注 Conway 定律和团队认知负荷。借助它，可以构建工程组织，实现变更的快速流动，并在系统、技术和市场发生变化时持续演进组织。

核心原则

团队是交付的基本单位，组织交付的是自身的沟通结构。 Conway 定律保证系统架构会映照团队的实际沟通方式，因此，团队边界和交互方式必须像软件本身一样经过审慎设计。应根据各团队的认知负荷设定职责范围，让大多数团队围绕业务变更流对齐，明确团队的交互方式，并将形成的拓扑视为持续演进的架构决策，以优化变更的快速流动。

评分

目标：10/10。 根据以下原则，为组织和团队设计打分（0-10）。报告当前分数，以及达到 10/10 所需的具体调整。

• 9-10： 流对齐团队负责端到端的工作范围，且其规模与认知负荷相匹配；平台团队、赋能团队和复杂子系统团队只在有助于降低认知负荷时存在；交互模式明确，并有计划地演进
• 7-8： 大多数团队都按流对齐，且拥有真正的平台，但仍存在一些共同负责的事项、未声明的交互模式，或某个负荷过重的团队
• 5-6： 虽然标明了团队类型，但边界仍按技术层划分；协作范围不受约束；平台采用是强制性的
• 3-4： 到处都是组件团队；共享服务由工单驱动；每项变更都要经过多个团队
• 0-2： 组织无视 Conway 定律：人员随项目频繁变动、“人人都和人人沟通”，也没有认知负荷的概念

框架

1. Conway 定律与逆 Conway 策略

核心概念：“任何设计系统的组织，最终都会产生一种设计，其结构是该组织沟通结构的复制品”（Mel Conway）。组织沟通与系统架构是同态的——它们受现实力量驱动而相互映照，并非只是比喻。逆 Conway 策略利用了这一点：先确定想要的架构，再调整团队及其沟通路径，让这种架构自然形成。

**为何有效：**团队只能构建自己能够协调的接口，因此组织能够探索的设计空间受其沟通路径限制。重塑组织就会重塑系统；反抗 Conway 定律只会造成持续摩擦和架构退化。

关键洞见：

• 接口出现在团队沟通之处；接缝出现在团队不沟通之处——系统记录着组织的对话
• 驱动架构的是实际的沟通结构（聊天、代码审查、会议邀请），而非组织架构图
• “人人都和人人沟通”会产生纠缠不清的系统：不受约束的沟通意味着不受约束的耦合
• 设计良好的组织需要更少而非更多的团队间沟通——广泛的跨团队交流表明边界划分有误，而非协作健康
• 任何参与团队划分、汇报关系或招聘的人都在做架构决策——架构师必须共同设计组织，重组也需要架构评审
• 当目标架构与团队结构冲突时，胜出的是团队结构

应用场景：

场景	应用方式	示例
目标架构	先调整团队，再预期架构随之形成	希望服务解耦 → 建立规模小、彼此解耦且能够独立部署的团队
重组提案	将其作为架构变更进行评审	团队合并需由技术负责人/架构师签字，而不只是人力资源部门批准
系统纠缠不清	绘制实际沟通情况，而非组织架构图	聊天和代码审查关系图揭示了“独立”团队之间隐藏的耦合

2. 四种基本团队类型

核心概念： 将所有团队归为四种类型之一。流对齐团队端到端负责业务变更流——这是主要类型，也是大多数团队所属的类型。赋能团队在流对齐团队中培养能力，然后继续前进。复杂子系统团队封装深厚的专业知识（例如 ML 模型、编解码器或定价引擎）。平台团队提供有吸引力的内部产品，降低流对齐团队的认知负担。

为何有效： 模糊的职责范围（“API 团队”“DevOps 团队”）会积累无处归属的工作，且协作方式难以预测。定义清晰的四种类型能让职责空缺和重叠一目了然，让每个团队都清楚自己在变更流中的职责，并让组织其他部分清楚地了解对团队的预期。

关键见解：

• 流对齐团队是默认类型；只有当其他三种类型能减轻流对齐团队的负担时，才有存在的理由
• 从不退出的赋能团队已经变成了依赖项——应以转移的能力而非关闭的工单来衡量它
• 复杂子系统团队的存在理由应是真正的专业性，而非管理上的便利——大多数组织不需要此类团队，或只需要一个
• 平台的目的是减轻流对齐团队的负担：如果采用平台比自行托管更困难，那么它就是负担，而非平台
• 反模式：共享服务团队会成为工单队列瓶颈；开发与运维之间的“DevOps 团队”会增加第三个孤岛；到处都是组件团队，则意味着每项功能都要经过多个团队

应用场景：

场景	应用方式	示例
模糊的团队职责	从四种类型中明确选择一种	“核心服务团队” → 面向内部客户并提供 SLA 的平台
深厚的专业能力	通过简单接口提供复杂子系统	推荐引擎团队向各流对齐团队提供评分 API
推广新实践	设定时限的赋能团队	测试自动化专家辅导各流对齐团队 8 周，然后退出

参见：references/team-types.md

3. 三种交互模式

核心概念： 团队之间的交互严格分为三种模式：协作（两个团队紧密合作以探索问题）、X-as-a-Service（一个团队通过明确的接口使用另一个团队提供的服务），以及辅导（一个团队帮助另一个团队学习或改进）。对于每一对有交互的团队，都要选择一种模式并明确声明。

为何有效： 大多数组织层面的痛点都源于交互模式不明确：期待获得服务的团队被拉进联合设计；期待得到辅导的团队却只能排队提交工单。明确声明交互模式，可以设定双方预期、限制协调成本，并将人际摩擦转化为可用于设计的信号。

关键见解：

• 协作适用于探索，但成本高昂——它会模糊边界并增加双方团队的认知负担；应设定时间限制，并限制每个团队同时只参与一项协作
• X-as-a-Service 以牺牲探索速度换取可预测性——适用于已确立的接口，不适用于边界仍不明确的情况
• 模式应有计划地演进：先通过协作探索接口，再在接口稳定后转为 X-as-a-Service
• 持续的摩擦是组织感知数据：尴尬的协作表明边界可能划分不当；笨拙的服务表明平台需要进行产品改进
• 临时且明确声明地切回协作，是采用重要新平台能力的标准方式

应用场景：

场景	应用方式	示例
新的平台能力	先协作，再转为 X-as-a-Service	Stream 团队和平台团队围绕日志 API 合作 6 周，然后开始使用该 API
两个团队陷入无休止的会议	明确声明预期的交互模式	双方确认这是服务关系 → 取消定期同步会议，发布 API
Stream 团队存在能力缺口	辅导式协作	赋能团队与 Stream 团队结对，交流可观测性实践，并在一个季度内退出

参见：references/interaction-modes.md

4. 团队认知负荷与团队规模适配的软件

核心概念： 让职责与团队的认知能力相匹配。团队面临三种负荷：内在负荷（工作本身所需的技能和技术）、外在负荷（交付机制：工具、环境、流程）和相关负荷（创造价值的领域思考）。尽量减少外在负荷，兼顾内在负荷，并为相关负荷保留能力——软件规模应与团队匹配，绝不能反过来。

为何有效： 当负荷超出能力时，团队就会疲于应付：频繁切换上下文、所有权浅薄、计划趋于保守、前置时间变长、值班令人畏惧。限制每个团队负责的领域数量，才能让所有权足够深入，从而精通相关领域；长期稳定的团队则能摊薄小组磨合所需的数月时间。

关键洞见：

• 衡量领域数量，而非人数：每个团队负责一个复杂领域，绝不能负责两个；一个团队可以负责两到三个简单领域；绝不能将一个复杂领域拆分给多个团队
• 增加团队规模并不能解决过载问题——减少领域数量才行；如果软件规模超出团队能力，就拆分软件
• 团队 API 让团队更易于协作：通过代码、文档、值班安排、聊天频道和工作约定，让他人无需开会也能与团队协作
• 长期稳定的团队优于按项目组建团队——解散一个已磨合成熟的团队会白白丢掉数月积累的信任，还得再次付出磨合成本
• 尊重邓巴数规模的群体：每个团队约 5–9 人；多个团队组成的群体则在接近 15、50 和 150 人时会触及自然规模上限
• 外在负荷最容易消除：标准化路径、模板和平台服务能释放相关负荷所需的能力，无需重组

应用：

场景	应用方式	示例
团队报告疲于应付	统计并分类团队负责的领域	1 个复杂领域 + 3 个简单领域 → 卸下其中两个简单领域
跨团队入职缓慢	发布团队 API	每个团队列出负责人、文档、值班安排、频道和请求流程
项目结束	保留团队，转移工作	让已磨合成熟的团队转向下一个工作流；默认情况下绝不解散团队

参见：references/cognitive-load.md

5. 裂缝平面：按团队所有权拆分软件

核心概念： 沿着自然边界——裂缝平面——拆分软件，让每个部分都由一个团队完全负责。业务领域（DDD 限界上下文）是默认的拆分平面；其他平面包括法规合规性、变更节奏、团队所在地/时区、风险、性能隔离、技术和用户角色。

为何有效： 软件规模超出一个团队的认知负荷时，就会被多个团队共同负责；而随意拆分或按层拆分，则会重现跨团队耦合。沿着变更同步的边界拆分，可以让大多数变更由一个团队负责；当服务边界与团队边界相吻合时，康威定律就会为你所用，而不是与你作对。

关键见解：

• 默认按业务领域拆分；只有在存在明确的驱动因素时，才采用其他平面（PCI 范围、性能热点达到 10 倍、变更节奏冲突）
• 技术通常是最糟糕的拆分平面——按前端/后端/DBA 拆分，必然导致每项功能都需要三个团队
• 检验任何拆分方案的试金石：这部分能否作为独立服务或 SaaS 提供？如果不能，边界就存在泄漏
• “单体”不仅仅是代码：单体数据库、相互耦合的发布列车，以及强制全组织统一标准，都会妨碍团队独立性
• 由三个团队负责的代码，等于无人负责——为每个制品指定一个负责人、将其提取到平台，或将其作为由维护者负责的内部开源项目运行
• 同一系统的不同部分可以沿着不同平面拆分；不必让一个平面支配整个系统

应用场景：

场景	应用方式	示例
拆分单体	先梳理限界上下文	订单、支付、目录 → 由三个团队分别负责的服务
各处都存在合规负担	按法规范围拆分	将 PCI 流程隔离在一个经过审计的服务和团队中
变更频率不一	按变更节奏拆分	将每周变更的定价与每年变更的账本分开

参见：references/fracture-planes.md

6. 将平台作为产品并感知、持续演进

核心概念： 将平台作为内部产品来运营，其客户是流对齐团队；从最精简可行平台（Thinnest Viable Platform）起步——也就是能加速各个流的最小方案，它可以只是一份整理并甄选可靠服务的 Wiki 页面。然后，将整个拓扑视为动态系统：通过摩擦、等待时间和待命信号，感知团队边界和交互模式何时需要改变。

为何有效： 强制采用、用户别无选择的平台会逐渐官僚化，因为失败没有反馈渠道；自愿采用会迫使平台持续保持吸引力，而产品思维能让平台持续解决实际需求。将拓扑视为一次性重组的组织，会随着产品和市场变化，再次陷入康威错位。

关键洞察：

• 衡量平台的标准是它消除了多少认知负荷，而非交付了多少功能——平台越大并不代表越好
• 遵循最精简可行平台原则：从整理服务和编写文档开始（“使用这些服务，并按此方式使用”）；只有在整理和文档不再够用时才构建软件
• 内部开发者就是客户：开展用户研究、发布路线图和 SLA，并像跟踪产品指标一样跟踪采用率和开发者体验
• 如果各个流可以离开，平台就必须以价值取胜——强制采用会掩盖平台的失败，直到问题变得灾难性
• 影子平台、等待时间增长、反复出现的跨团队摩擦和待命负担，都是拓扑需要演进的感知信号
• 没有一成不变的拓扑——每隔几个季度，根据信号而非仪式，重新审视团队边界和交互模式

应用场景：

场景	应用方式	示例
组建平台团队	采用产品实践	路线图、内部用户研究、开放办公时间、带 SLA 的版本化 API
平台泛滥	回归最精简可行平台	精简至各个流实际使用的六项服务；其余服务只做整理和筛选
组织再次感到“不对劲”	开展感知评审	根据摩擦记录和等待时间数据，有意识地调整一项边界

参见：references/case-studies.md

常见错误

错误	失败原因	修正方法
在开发和运维之间组建“DevOps 团队”	增加了第三个孤岛和另一个交接队列	组建平台团队，提供自助工具；或组建赋能团队，提升能力
长期保留赋能团队	能力永远无法转移；各个流持续依赖该团队	为合作设定时限，并明确退出标准
强制采用平台	用户别无选择会掩盖失败；平台会逐渐官僚化	保持采用自愿；让平台以价值取胜
按技术层划分团队	每项功能都要跨越多个团队；交接主导交付周期	沿业务领域断层线划分；由流对齐团队负责所有权
项目结束时解散团队	丢弃已建立的信任；每次都要重新付出组建和磨合的代价	组建长期团队；让工作流向团队，而非让人流向项目
将共享服务团队变成工单队列	所有流的工作都要排入同一个瓶颈，按顺序处理	将其转变为产品化平台（自助服务）或赋能团队
按人数而非认知负荷确定团队规模	即使团队很大，领域过多或过于复杂时仍会陷入混乱	统计并划分领域；每个团队最多负责一个复杂领域
不明确交互模式	预期不一致；协调会议不断增多	为每对团队明确一种模式；定期审视并有意识地调整

快速诊断

问题	如果否	行动
每个流对齐团队都能独立交付典型变更，无需交接吗？	团队间的队列阻塞了流动	将团队重新对齐到端到端的业务变更切片
每个团队都能归为四种类型之一吗？	职责模糊会导致遗留工作不断累积	对每个团队进行分类；调整或解散不匹配的团队
是否为每对存在依赖关系的团队声明了交互模式？	预期不一致会产生摩擦	为每对团队声明协作、X 即服务或赋能模式
每个团队负责的领域数量是否符合认知负荷启发式原则？	频繁切换、归属感浅薄、交付缓慢	重新分配领域；每个团队最多负责一个复杂领域
服务和代码库边界是否与团队边界一致？	康威定律失配；共享所有权逐渐增多	沿断裂面重新划分；每项成果只设一个负责人
是否可选择采用平台，并以其减少的工作量衡量效果？	强制要求掩盖了平台的缺陷	将平台作为产品运营；跟踪自愿采用情况和开发者体验
赋能合作是否设有明确的时间期限和退出标准？	永久依赖取代了学习	预先设定结束日期和能力移交目标
是否有定期机制来感知并演进团队拓扑？	随着系统和市场变化，设计会逐渐过时	每季度审查摩擦、等待时间和待命信号

延伸阅读

• "团队拓扑：构建业务与技术团队，实现快速流动"，作者：Matthew Skelton 和 Manuel Pais
• "加速：精益软件与 DevOps 的科学"，作者：Nicole Forsgren、Jez Humble 和 Gene Kim
• "人月神话：软件工程论文集"，作者：Frederick P. Brooks Jr.

关于作者

Matthew Skelton 是 Conflux 的创始人。Conflux 是一家致力于帮助软件组织实现快速流动的咨询公司，他也是《团队拓扑》的合著者。Manuel Pais 是一位独立的 IT 组织顾问和培训师，专注于团队交互和交付实践。两人都致力于以团队为先的组织设计，优化变更的快速、可持续流动。