你的组织是否已经无法像过去那样快速地交付价值？

团队是否频繁切换任务，承担的工作多到难以兼顾？成员是否对日常工作失去了投入感？团队之间的沟通是否正在拖慢交付？

或许你已经意识到，团队需要改变协作方式，却很难说清楚组织究竟该如何调整。

如果这些问题似曾相识，团队拓扑交互建模可以帮助你识别并记录现有团队及其沟通关系，再用一套清晰的术语，讨论团队及交互方式应如何演进，让工作流动得更顺畅、价值交付得更快。

团队拓扑结合了一系列原则与实践，帮助组织在协作、自主性、交付和产品目标之间取得更好的平衡。借助团队拓扑的图形符号与绘图规则，我们可以记录组织在不同时刻的状态，理解团队为什么以当前方式沟通，以及哪些关系需要改变。

从现状入手

团队交互建模的目的不是一次画出“完美”的组织设计，而是在需要时用图示帮助大家讨论：团队目前如何互动，将来又可以如何互动。

在团队拓扑中，“团队”有特定含义：它是组织中最小的交付单元，通常由 5 至 9 名成员组成，人员相对稳定，并作为一个整体朝共同目标努力。

保持团队稳定很重要。若人员频繁变动，组织就更需要关注是否建立了足够的信任。每个团队通常也应与业务领域中的一个或多个领域或子系统相对应。

团队拓扑没有规定唯一的实施路径。下面提供一种可供参考的建模步骤。

识别现有团队，并映射到四种基本团队类型

第一步是弄清组织目前有哪些团队、各自负责什么。你可以先沿用组织中的现有称谓，例如基础设施团队、组件团队、工具团队、架构团队或支持团队，同时标记出职责可能需要调整的团队。

此时不必急于重新命名。如果暂时无法确定团队属于哪种基本类型，可以先用图中的**“未定义团队类型”**符号记录；图里的“Comp X”表示“能力 X”。

接下来，再考虑这些团队能否对应团队拓扑的四种基本类型：流对齐团队、赋能团队、复杂子系统团队和平台团队。分类时要看团队实际承担的职责和表现出的行为。如果目前还不符合某种类型的定义，就暂时保留“未定义”的标记。

团队类型	主要特征与职责
流对齐团队	通常由约 5 至 9 人组成，长期负责某项由软件支撑的服务的设计、构建和运行。
赋能团队	由具备专长的成员组成，通过指导和促进，帮助流对齐团队补足能力、发现障碍，减轻其内在认知负荷；通常不负责软件组件的长期所有权。
复杂子系统团队	集中处理需要专门知识的复杂部分，以服务形式向其他团队提供能力，减轻流对齐团队的额外认知负荷。
平台团队	将通用能力作为服务提供给流对齐团队，减少它们需要自行处理的非差异化工作和额外认知负荷。

你可能发现，现有团队没有一个能完全归入这四种类型。这并不妨碍建模。重要的是先看清团队现在如何互动，才有依据讨论组织接下来如何演进。

创建第一张团队交互图：三种交互模式

团队拓扑使用三种交互模式描述团队应如何合作：协作、X 即服务和促进。

• 协作：具备不同技能的团队在明确的时间范围内紧密合作，通常持续数周，适用于需要共同探索或快速适应变化的工作。
• X 即服务（XaaS）：一个团队提供责任归属清晰、便于使用的服务，其他团队按需使用。它通常是在协作帮助双方找到合适边界后形成的交互方式。服务应提供良好的使用体验，并像产品一样得到持续管理。
• 促进：一个团队帮助另一个团队清除障碍、提升能力。这是赋能团队常用的工作方式。与协作一样，促进通常也是临时的，应关注支持是否有效，而不是形成长期依赖。

完成团队类型的初步映射后，我们就可以观察工作如何经过这些团队。假设某个组织目前还没有符合四种基本类型定义的团队，第一张图便可以如实呈现现状。

图中的灰色菱形表示交接。要让价值从左向右传递，工作可能依次经过项目管理办公室（PMO）、用户体验（UX）、开发、测试和运维团队。交接越多，等待通常越多；一个团队在等待下游团队处理工作时，可能又接下新任务，使在制工作不断增加。

在研发场景中，可以结合 PingCode 中从客户反馈、需求、开发、测试到发布的工作记录，查看事项在哪些环节反复移交或停留。工具中的记录可以为绘制交互图提供线索；是否需要调整团队边界，仍要由相关团队结合实际工作判断。

另一种常见情况是两个团队长期“协作”：只要一方的工作出现新变化，就必须找另一方沟通。日常语言中，这或许也叫协作；但在团队拓扑中，协作应有明确目的和期限。因此，可以先用**“未定义交互模式”**符号标出这种长期的协作依赖，留待进一步讨论。

从“现状”走向“目标状态”

看清现有团队的类型和交互方式后，我们可以追问：这些交接与长期依赖是否阻碍了工作流动？如果是，目标状态又该是什么样？

设计第一步团队演进

减少交接的一种思路是：从现有团队中识别必需的能力，组成一支约 5 至 9 人的流对齐团队，让它能够围绕某条价值流，承担面向客户的端到端交付责任。

讨论目标团队需要哪些能力后，便可以画出从“现状”走向“目标状态”的第一步。

例如，在赋能团队的帮助下，团队 A、B、C、D 可在限定时间内协作，逐步形成一支初始的流对齐团队。这支团队应具备为特定价值流交付端到端价值所需的核心能力。

控制团队的认知负荷

初步组建流对齐团队后，交付速度未必会立刻达到预期。进一步观察可能发现，团队难以掌握某项特定能力，因此工作仍在放缓。

团队交互图可以用图形大小表示相对认知负荷：图形越大，团队需要处理的复杂性越多。示例图中的“大脑”图标只是辅助说明，并非建模所必需的符号。

此时可以问：

• 团队规模与工作量是否匹配？
• 团队是否需要帮助，降低工作本身带来的内在认知负荷？
• 是否有可以移除或简化的额外认知负荷？
• 团队是否承担了过于复杂、适合由专门团队负责的子系统？

答案不同，调整方式也不同。

借助平台服务减轻负担

如果某项通用能力使流对齐团队不得不处理大量额外复杂性，可以考虑由平台团队将其封装为服务。使用团队便能以更简单的方式获取所需能力。

将复杂子系统交给专门团队

如果某项工作涉及高度复杂的数据科学、机器学习或其他专门领域，也可以考虑成立复杂子系统团队，由其负责相应部分，并向流对齐团队提供清晰的服务。

由赋能团队补足能力

有时问题不在于工作应由谁负责，而在于流对齐团队暂时缺少完成工作所需的知识。这时，赋能团队可以提供有期限、有目标的指导，帮助团队掌握能力。

寻找拆分单体系统的边界

单体系统也可能使组织难以划分出规模合适、目标明确的流对齐团队。如果存在这种情况，可以寻找适合拆分系统的自然边界，减少团队之间的耦合与依赖。

当团队认知负荷已经过高，而继续扩充人数又会妨碍有效协作时，应重新审视其职责：哪些通用能力可以交由平台团队提供？哪些复杂部分适合由复杂子系统团队负责？哪些能力缺口可以通过赋能团队的短期支持补足？

明确引导并限制团队间的协作

有了团队类型和交互模式，就可以画出更完整的团队交互图，记录组织在某一时刻的协作关系。建模时，应标出**“变更流向”**箭头，说明工作预期如何流动。在本文的示例中，流向为从左到右；如果两个团队在图中处于同一纵向位置，则可能存在需要进一步检查的交接关系。

示例图中，流 A 与复杂子系统团队正在协作。这应是一段有明确期限的合作，用于共同定义并开发未来的“X 即服务”交互，使流 A 日后可以更快地交付价值。

图中还显示，复杂子系统团队、流 B 和流 C 都在使用流 D 提供的服务；流 D 是平台 A 的组成部分。同时，流 C 正与流 D 协作，可能是在探索另一项可供流 C 使用的平台服务。

此外，赋能团队 A 正为流 A 提供支持，例如帮助其改进持续集成与持续交付（CI/CD）流水线，或完善自动化测试。具体支持内容取决于赋能团队具备的能力。

画出现状之后，还需要持续观察：哪些协作确实用于探索新问题？哪些已变成成本高昂的长期依赖？跨职能团队可以借助 Worktile 的任务、项目和文档功能，记录共同事项、责任人及约定的协作期限，方便定期回看。频繁或持续较久的协作，应促使团队讨论能否形成更清晰的服务边界，并在适当情况下转向 X 即服务。

在后续示例中，部分协作关系转变为 X 即服务关系。流 A 和流 C 不再需要为使用相关能力持续进行密集沟通，其认知负荷有望降低，交付吞吐量也可能改善。

图中，平台 C 提供了一项新服务，流 A 和流 C 已开始使用，流 B 则尚未采用。一个可能的原因是，流 B 认为该服务还不符合自己的需要。与此同时，赋能团队 A 结束了对流 A 的支持，转而帮助流 B。

让团队结构持续演进

技术、工作方式和业务需求都在变化，团队结构也需要随之调整。可能的信号包括：软件系统已复杂到单个团队难以承担；交付节奏逐渐放缓；或多个业务服务都依赖同一组庞大的底层服务。

出现这些情况时，应重新检查现有团队的职责与交互设计，判断它们是否仍能支持顺畅交付。

通过团队交互感知组织问题

当稳定的团队清楚地负责软件系统的不同部分，并以明确的方式相互协作时，组织就更容易从日常工作中发现需要调整的信号。例如：

• 我们是否误解了用户真正需要的行为或体验？
• 是否需要改变团队交互模式，让工作流动得更顺畅？
• 某项能力还应由内部开发，还是适合采用外部服务？
• 团队 A 与团队 B 的协作仍然有效吗？是否应该转向 X 即服务？
• 团队 C 的工作流程被什么阻碍了？
• 平台是否满足团队 D、E、F、G 的需要？是否需要赋能团队提供一段时间的支持？

团队交互图能让这些问题更容易被看见和讨论。

绘制团队交互图的规则与原则

使用团队拓扑的图形符号时，应遵循以下约定：

1. 图中应清楚表示变更的流向；本文的示例采用从左到右的方向。
2. 流对齐团队应对变更进入线上服务或系统的过程承担端到端责任。因此，在图中，它与右侧客户或用户之间不应再有负责交接工作的团队。
3. 团队图形应使用实心样式，表示团队是相对长期、稳定的单元。
4. 交互模式图形应使用约 50% 的透明度，表示交互关系可能随工作阶段变化。
5. 流对齐团队通常不应直接面向其他团队提供 X 即服务；需要对外提供的数据或服务，一般应通过平台呈现。
6. 如果一项 X 即服务或协作关系涉及多个团队，可以用黑色星号“*”标明实际参与交互的团队。

最后，请把图表当作讨论的起点。每张图只是组织在某一时刻的快照，它的价值在于帮助团队看见交接、依赖和认知负荷，并共同决定下一步如何调整。