⚡

团队拓扑学技能Skill team-topologies

团队拓扑学技能用于设计和优化团队结构，基于四种基本团队类型（流对齐团队、平台团队、使能团队、复杂子系统团队）和交互模式，帮助组织提高效率、降低认知负荷，并促进敏捷交付。适用于软件开发、产品管理和组织架构设计。关键词：团队拓扑学，团队设计，组织架构，敏捷团队，平台工程，使能团队，软件开发架构。

架构设计 0 次安装 0 次浏览 更新于 3/11/2026

name: 团队拓扑学 description: 来自团队拓扑学的四种基本团队类型和交互模式 allowed-tools: 读取, 全局搜索, 搜索, 写入, 编辑

团队拓扑学技能

何时使用此技能

在以下情况下使用此技能：

  • 团队拓扑学任务 - 处理来自团队拓扑学的四种基本团队类型和交互模式
  • 规划或设计 - 需要团队拓扑学方法的指导
  • 最佳实践 - 希望遵循既定的模式和标准

概述

使用来自团队拓扑学的四种基本团队类型设计团队结构。

强制：文档优先方法

在应用团队拓扑学之前：

  1. 调用docs-management技能 用于团队设计模式
  2. 通过MCP服务器验证团队拓扑学概念 (perplexity)
  3. 基于Skelton & Pais方法论指导

四种基本团队类型

团队拓扑学模型：

┌─────────────────────────────────────────────────────────────────┐
│                       流对齐团队                       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │  功能       │  │  功能       │  │  功能       │              │
│  │  团队 A     │  │  团队 B     │  │  团队 C     │              │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘              │
│         │                │                │                      │
│         └────────────────┼────────────────┘                      │
│                          │                                       │
│         ┌────────────────┴────────────────┐                      │
│         ▼                                 ▼                      │
│  ┌─────────────────┐              ┌─────────────────┐            │
│  │    平台         │              │     使能        │            │
│  │    团队         │              │     团队        │            │
│  └─────────────────┘              └─────────────────┘            │
│                                                                  │
│                   ┌─────────────────┐                            │
│                   │  复杂子系统团队 │                            │
│                   │                 │                            │
│                   └─────────────────┘                            │
└─────────────────────────────────────────────────────────────────┘

流对齐团队

流对齐团队

目的：主要价值交付，端到端所有权

特征：
• 对齐单一业务流
• 跨职能（开发、测试、运维、用户体验）
• 端到端责任
• 接近客户
• 大多数团队应为此类

职责：
• 拥有价值流的一部分
• 交付功能到生产环境
• 响应客户反馈
• 拥有运营方面
• 持续改进流程

示例：
• 结账团队（电子商务）
• 移动应用团队
• 客户入职团队
• 支付团队

反模式：
✗ 依赖许多其他团队
✗ 频繁受阻
✗ 无生产所有权
✗ 不明确的客户/用户

平台团队

平台团队

目的：减少流对齐团队的认知负荷

特征：
• 将平台视为产品
• 内部客户是其他团队
• 目标是自助服务
• 关注API和文档
• 促进流对齐团队的快速流动

职责：
• 构建内部开发者平台
• 提供自助服务能力
• 维护稳定性和可靠性
• 记录和支持平台
• 收集消费团队的反馈

示例：
• 基础设施平台团队
• 开发者体验团队
• 数据平台团队
• 安全平台团队

平台分层：
┌─────────────────────────────────────────┐
│           平台层                        │
├─────────────────────────────────────────┤
│ 开发者体验                              │
│ (CLI、门户、模板、文档)                  │
├─────────────────────────────────────────┤
│ 运行时平台                              │
│ (容器、无服务器、数据库)                 │
├─────────────────────────────────────────┤
│ 基础设施                                │
│ (云、网络、安全)                        │
└─────────────────────────────────────────┘

使能团队

使能团队

目的：帮助流对齐团队克服障碍

特征：
• 特定领域的专家
• 临时参与模式
• 关注知识转移
• 研究和评估选项
• 不为团队做工作

职责：
• 识别能力差距
• 研究解决方案
• 教练和指导团队
• 帮助团队采用新实践
• 衡量改进

示例：
• DevOps使能团队
• 架构顾问团队
• 质量工程团队
• 敏捷教练团队

参与模式：
┌─────────────┐     ┌─────────────┐
│  使能       │────►│  流对齐     │
│  团队       │     │  团队       │
└─────────────┘     └─────────────┘
       │
       ▼
[时间盒参与]
       │
       ▼
[转移知识并离开]

反模式：
✗ 创建永久依赖
✗ 替代使能做工作
✗ 无知识转移
✗ 无明确退出标准

复杂子系统团队

复杂子系统团队

目的：处理复杂技术领域

特征：
• 复杂领域的专家
• 减少他人的认知负荷
• 领域需要稀有专业知识
• 定义良好的接口
• 相对罕见的团队类型

何时创建：
• 数学重算法
• 遗留系统专家
• 专用硬件集成
• 复杂监管领域
• AI/ML模型专家

示例：
• 视频编解码团队
• 机器学习平台团队
• 金融计算团队
• 密码学团队

警告标志不需要：
✗ 为“拥有”技术而创建
✗ 架构宇航员综合症
✗ 避免分享知识
✗ 政治而非复杂性

团队类型选择指南

决策矩阵：

┌─────────────────────────────────────────────────────────────┐
│ 问题                           │ 指向                      │
├─────────────────────────────────────────────────────────────┤
│ 对齐业务能力？                 │ 流对齐团队               │
│ 使能其他团队？                 │ 平台或使能团队           │
│ 创建自助服务产品？             │ 平台团队                 │
│ 转移知识后离开？               │ 使能团队                 │
│ 需要稀有专业技能？             │ 复杂子系统团队           │
│ 有内部“客户”？                 │ 平台团队                 │
│ 有外部客户？                   │ 流对齐团队               │
└─────────────────────────────────────────────────────────────┘

目标分布：
• 80%+ 流对齐团队
• 10-15% 平台团队
• 5-10% 使能团队
• <5% 复杂子系统团队

团队规模

团队规模指南：

邓巴数和团队：
• 每团队5-9人（理想）
• 15人最大松散团队
• 信任超过这些限制会减弱

双披萨规则：
• 如果不能用两个披萨喂饱，太大
• 优化沟通

认知负荷原则：
• 团队必须能理解其领域
• 太大=太多知识
• 太小=每人太多

反模式：
✗ 1-2人团队（巴士因子、孤立）
✗ 20+人团队（沟通开销）
✗ 频繁团队变更

团队演变

团队如何演变：

团队创建：
1. 从使命/目的开始
2. 识别所需技能
3. 定义边界
4. 建立交互模式

团队成长：
1. 逐渐增加能力
2. 关注认知负荷
3. 当>9人时考虑拆分

团队拆分：
1. 识别自然接缝
2. 确保每个有明确目的
3. 定义新交互模式
4. 计划过渡期

团队合并（罕见）：
1. 仅当有强协同效应时
2. 关注文化冲突
3. 需要明确组合目的

评估模板

# 团队拓扑学评估：[组织/产品]

## 当前状态

### 团队清单

| 团队 | 当前类型 | 规模 | 依赖关系 | 问题 |
|------|--------------|------|--------------|--------|
| [名称] | [类型] | [N] | [列表] | [问题] |

### 依赖关系图

```text
[ASCII依赖关系图]

分析

流对齐团队

  • 数量：[N]
  • 百分比：[%]
  • 问题：[列表]

平台团队

  • 数量：[N]
  • 百分比：[%]
  • 问题：[列表]

使能团队

  • 数量：[N]
  • 百分比：[%]
  • 问题：[列表]

复杂子系统团队

  • 数量：[N]
  • 百分比：[%]
  • 问题：[列表]

建议

团队类型变更

团队 当前 推荐 理由
[名称] [类型] [类型] [为什么]

需要的新团队

团队 类型 目的
[名称] [类型] [为什么]

要合并/拆分的团队

操作 团队 理由
[拆分/合并] [名称] [为什么]

实施路线图

  1. [阶段1行动]
  2. [阶段2行动]

工作流程

应用团队拓扑学时：

  1. 映射当前状态：清点现有团队
  2. 分类类型：识别当前团队类型
  3. 评估差距：与目标分布比较
  4. 识别问题：依赖关系、认知负荷、阻碍
  5. 设计目标：最优团队结构
  6. 计划演变：如何从当前到目标
  7. 逐步执行：进化性变革，非大爆炸

参考文献

详细指导：

最后更新： 2025-12-26