团队拓扑是什么
Team Topologies 是 Skelton 与 Pais 提出的组织设计方法：以团队为交付单元，按认知负荷与交互模式设计团队边界。四种团队类型是流动对齐型、赋能型、复杂子系统型与平台型，配三种交互模式：协作、服务与促进。核心主张是团队边界应服务于系统边界与认知负荷，而不是沿袭历史汇报线。小团队常出现一人兼顾多角色，不必机械套用四类划分。
基本信息
| 四类团队 | 流动对齐型 / 赋能型 / 复杂子系统型 / 平台型 |
|---|---|
| 三种交互 | 协作、服务、促进 |
| 核心原则 | 限制认知负荷、松耦合边界、适合变革的组织 |
| 团队单位 | 能共享上下文的小团队 |
| 演进信号 | 交互模式随阶段变化，需要重新设计 |
| 关联 | 与康威定律、平台工程互相印证 |
典型使用场景
- 组织设计：交付等待跨团队依赖过多时，重新划分服务与团队边界
- 平台建设：把重复建设的能力收敛为平台团队统一提供
- 知识扩散：关键知识集中在少数人时，设赋能型团队过渡
- 交互规范：明确跨团队协作的预期时长与退出条件
- 大规模重构：临时组建协作型团队，完成后回到常规模式
- 认知负荷治理：避免单个团队维护过多不相关系统
识别信号示例
识别信号示例
交付等待跨团队依赖过多 → 拆分或合并服务边界
平台能力重复建设 → 收敛为平台团队
关键知识只在少数人手中 → 设赋能型团队过渡
团队维护系统过多 → 按认知负荷拆分或交由平台承接团队类型与职责
| 类型 | 职责 | 交互方式 |
|---|---|---|
| 流动对齐型 | 端到端交付业务价值 | 与服务或平台协作 |
| 赋能型 | 传递技能与工具，短期进入 | 以促进为主，及时退出 |
| 复杂子系统型 | 维护高专业度子系统 | 以服务方式对接 |
| 平台型 | 提供自助式内部能力 | 以服务方式被消费 |
团队类型服务于业务需要，会随阶段变化；小团队常出现一人兼顾多角色，不必机械套用四类划分。