## 什么是团队拓扑？

团队拓扑（Team Topologies）是一种设计团队及其协作方式的方法，目的是让价值更快地从构想传递给客户。

这一方法建立在对不同行业、不同规模、不同技术背景的组织进行多年研究的基础上，旨在回答两个关键问题：

1. 组织规模扩大时，如何保持甚至提高价值交付速度？
2. 如何让系统架构与组织结构同步演进，使两者相互促进，而不是制约业务发展？
3. ![26.png](https://blog-app-pc-smart-growth-release-1251945081.cos.ap-shanghai.myqcloud.com/uploads/26_476a5278fb.png)

团队拓扑提供了一套模式语言和思维模型，帮助组织找到适合目标架构、能够促进价值快速流动的团队设计。

### 四种基本团队类型

* **流对齐团队**：围绕一条价值流开展工作，通常对应某个业务领域、产品或用户群体，对端到端的交付结果负责。
* **赋能团队**：帮助其他团队克服障碍、补足能力，使其能够更独立地完成工作。
* **复杂子系统团队**：负责需要深厚数学、计算或技术专长的子系统。
* **平台团队**：以内部产品的方式提供可复用的能力，降低其他团队的工作复杂度，加快交付。

 

### 三种团队交互模式

* **协作**：两个或多个团队在限定时间内紧密合作，共同探索新的接口、实践或技术。
* **X 即服务**：一个团队提供定义清晰的服务，其他团队按需使用，尽量减少日常协调。
* **促进**：一个团队为另一个团队提供有针对性的指导和支持，帮助其跨越知识或能力上的障碍。

## 团队拓扑的核心理念

### 九项原则

1. **关注价值流动，而不只是组织结构**

   真正重要的是，工作能否从构想顺畅地走向客户，并持续创造价值。组织架构图设计得再精巧，如果工作仍被审批、交接和等待拖住，也无法改善交付。我见过一些看似完美的组织设计，最终带来的却只是更多会议和文档。

2. **建立高度信任**

   信任不是一句口号，而是团队自主决策、有效协作的基础。缺乏信任的组织，往往会用层层审批、过量文档和防御性流程来寻求控制，结果是所有人都走得更慢。我见过一些组织因不信任员工，在繁复的流程上投入巨额成本，却没有解决真正的问题。

3. **保持团队稳定**

   如果可以选择，我更愿意与一支合作多年的团队共事，而不是临时拼凑一支明星团队。稳定的团队能够积累共同知识、协作默契和有效的沟通方式。频繁重组会打断这些积累，其隐性成本常常被低估。

4. **尊重团队的认知极限**

   团队能够理解和处理的复杂性是有限的。每增加一种工具、一项职责或一个业务领域，都会占用团队的注意力。如果领导者不断增加任务，却不相应地减轻负担，再出色的团队也会变得迟缓。

5. **从小处着手，稳妥推进**

   能够持续交付小幅改进的团队，通常比每季度押注一次大规模发布的团队更容易获得反馈、控制风险。产品变更如此，团队调整也一样。持续、稳妥地创造价值，比把希望寄托在一次重大变革上更可靠。

6. **让团队直接接触客户**

   有些团队从未与产品用户交谈，只能接收经过层层转述的需求。信息在传递中容易失真，决策也随之变慢。直接了解客户的团队，更容易看清真正的问题并及时作出判断。这同样需要信任：组织应相信团队有能力理解客户，而不是事无巨细地干预每一次互动。

7. **接受复杂性，增强适应能力**

   现代软件系统过于复杂，无法事先准确预测每一步。与其试图把所有事情一次规划妥当，不如设计能够根据反馈及时调整的工作方式。我见过不少项目失利，原因正是团队误以为计划可以覆盖所有变化。正如迈克·泰森那句广为流传的话所说：“人人都有计划，直到挨上一拳。”

8. **支持持续探索**

   好想法往往来自有时间实验、验证和学习的团队。如果无穷无尽的待办事项占满了所有时间，团队就只能机械地完成眼前任务。我见过团队通过定期探索新方法，找到显著改善工作成效的机会。探索不是可有可无的附加工作，下一次突破可能就从这里开始。

9. **减少团队之间的等待与依赖**

   一个团队等待另一个团队，是交付速度最常见的阻碍之一。许多组织只关注单个团队是否足够忙碌，却忽略了团队之间漫长的等待。我见过有些组织增加了人手，交付反而减少：问题并不在人手，而在频繁的交接和相互依赖。要改善的是端到端的工作流，而不只是某个团队的效率。

   对研发团队来说，客户反馈、需求、开发、测试与发布之间的信息交接值得重点检查。使用 **[PingCode](https://PingCode.com?utm_source=insights&utm_medium=%E5%93%81%E7%89%8C%E8%AF%8D)** 这类覆盖研发全生命周期的工具，可以将这些环节及相关知识记录衔接起来，让团队更容易发现工作停滞在哪里。但工具只能帮助呈现和流转信息，职责边界与交接规则仍需团队共同厘清。

## 使用团队拓扑时需要注意什么？

有人批评团队拓扑没有教人如何绘制完整的组织地图，或直接给出一张新的组织架构图。这种批评误解了它的用途。

团队拓扑帮助我们识别：业务表现是否因流程、团队设计和系统架构之间的不匹配而受到影响；又该如何调整这些关系，让价值流动得更快。如果目标只是画出一张新的组织架构图，还需要借助其他方法。

团队拓扑首先帮助组织看清实际工作是如何开展的、价值在哪里流动或受阻，再利用这些认识设计业务团队与技术团队之间的协作关系。

其中任何一个部分都不能孤立使用。如果只采用“四种团队类型”，却不关注认知负荷、交互模式和价值流，就很难取得明显成效。

## 四种团队类型如何随变化而演进？

 

图中的工作流从左向右推进。流对齐团队围绕某个业务领域或其他价值流开展工作，尽可能承担端到端的责任，减少不必要的交接。它们通常遵循“自主开发、自主运营”的理念，并根据需要获得平台、赋能或复杂子系统团队的支持。

这幅图呈现的只是某一时刻的关系。随着目标变化、团队获得新的认识，职责边界和交互方式也会随之调整。

## 团队拓扑的六种实践模式

原则解释了**为什么**要改变团队设计；以下六种模式进一步说明**如何**在实践中着手。

1. **明确四种团队类型**

   四种基本类型分别是流对齐团队、平台团队、赋能团队和复杂子系统团队。

   流对齐团队沿着价值流直接为客户创造价值，并对结果负责；平台团队提供内部产品和服务，让其他团队更快地工作；赋能团队在一段时间内帮助其他团队提升能力；复杂子系统团队则负责需要专门知识的组件。

   使用这些类型，是为了厘清团队的主要职责和彼此的关系。若随意增加类型，或让一个团队长期承担彼此冲突的职责，反而可能使责任边界更加模糊。

2. **明确三种交互模式**

   许多团队依赖之所以混乱，是因为没有人说清楚团队应该怎样合作。

   * **协作**适合共同探索未知问题，需要密切沟通，因此投入较高，通常应有明确的期限和目标。
   * **X 即服务**适合提供边界清晰、便于使用的能力，让使用方以较少的协调完成工作。
   * **促进**适合有针对性地传授知识、排除障碍，目标是让受支持的团队逐渐具备独立完成工作的能力。

   与其笼统要求团队“加强协调”，不如明确当前需要哪一种交互方式。跨职能团队还可以借助 **[Worktile](https://worktile.com/?utm_source=insights&utm_medium=%E5%93%81%E7%89%8C%E8%AF%8D)** 的任务、项目和文档功能，记录共同目标、责任人与工作进展，使约定更容易落实。

3. **管理团队认知负荷**

   就像计算机负载过高会运行迟缓一样，团队承担过多复杂性时，决策和行动也会变慢。组织应持续观察团队需要掌握多少领域知识、工具和职责，并主动减少不必要的负担。我见过领导者不断向团队叠加责任，最后却把由此造成的迟缓归咎于团队“表现不佳”。

4. **建设最薄可行平台（TVP）**

   内部平台容易在不断增加功能的过程中变得臃肿，让使用团队承受新的学习和协调成本。最薄可行平台强调从真正需要的能力起步，以尽可能简洁的方式帮助团队加快交付，再根据使用反馈逐步发展。

5. **保持团队边界灵活**

   产品、技术和业务需求会变化，团队的职责边界也应适时调整。鼓励相关团队根据实际工作情况讨论并协商边界，有助于及时解决问题，避免所有调整都积累到下一次自上而下的大规模重组。

6. **持续适应**

   组织设计没有一劳永逸的终点。建立反馈机制，持续观察交付速度、团队依赖和认知负荷，并据此进行小幅调整，才能让团队结构跟上业务、技术和人员的变化。通常，及时进行小幅调整，比等问题积累后再被迫大规模重组更稳妥。

PingCodeDocs

团队拓扑（Team Topologies）是一种设计团队及其协作方式的方法，目的是让价值更快地从构想传递给客户。

这一方法建立在对不同行业、不同规模、不同技术背景的组织进行多年研究的基础上，旨在回答两个关键问题：

组织规模扩大时，如何保持甚至提高价值交付速度？

如何让系统架构与组织结构同步演进，使两者相互促进，而不是制约业务发展？

团队拓扑详解：四种团队类型、三种交互模式与实践原则