stakeholders-org-design

利益相关方与组织设计

目录

1. 目的
2. 适用场景
3. 这是什么
4. 工作流
5. 利益相关方映射
6. 团队接口契约
7. 能力成熟度
8. 常见模式
9. 护栏
10. 快速参考

目的

利益相关方与组织设计提供了一套框架，用于绘制影响力网络、设计与系统架构相匹配的有效团队结构（康威定律）、明确团队接口与职责，以及评估组织能力成熟度以指导改进。

适用场景

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

• 设计或重组组织团队（职能型 → 产品型、单体 → 微服务团队、平台团队）
• 为变革计划绘制利益相关方图谱（权力-利益矩阵、影响力网络、支持者/阻碍者）
• 定义团队接口与契约（API、SLA、交接协议、决策权）
• 评估能力成熟度（DevOps/DORA、安全/CMMC、敏捷、数据、设计成熟度模型）
• 应用康威定律（使团队结构与期望的系统架构保持一致）
• 建立治理框架（RACI、决策权、升级路径）
• 规划跨职能协作模式（产品三人组、嵌入式与集中式）
• 设计团队拓扑（流对齐型、平台型、赋能型、复杂子系统型）

会触发此技能的用户表述：

• “我们应该如何构建团队？”
• “为 [计划] 绘制利益相关方图谱”
• “定义团队接口”
• “评估我们的 [能力] 成熟度”
• “康威定律”
• “团队拓扑”
• “RACI 矩阵”

这是什么

一个结合以下内容的框架：

1. 利益相关方映射：权力-利益矩阵、影响力网络、用于明确决策权的 RACI
2. 组织设计：与架构和战略相匹配的团队结构
3. 团队接口契约：API、SLA、交接协议、沟通模式
4. 能力成熟度：使用标准模型（DORA、CMMC、CMM、自定义评分标准）进行评估

快速示例（平台团队设计）：

利益相关方图谱：

• 高权力、高利益：工程副总裁（发起人）、产品团队（客户）
• 高权力、低利益：CTO（通过指标维持其满意度）
• 低权力、高利益：工程师个人（及时告知）

团队结构：

• 平台团队（8 人）：开发者体验、基础设施、可观测性
• 接口：自助式 API、文档、办公时间
• SLA：99.9% 正常运行时间、功能交付时间 <2 周、严重错误修复时间 <4 小时

能力成熟度（DORA 指标）：

• 部署频率：每日 → 每周（目标：每日）
• 前置时间：1 周 → 2 天（目标：<1 天）
• MTTR：4 小时 → 1 小时（目标：<1 小时）
• 变更失败率：15% → 5%（目标：<5%）

工作流

复制此清单并跟踪进度：

Org Design Progress:
- [ ] Step 1: Map stakeholders and influence
- [ ] Step 2: Define team structure and boundaries
- [ ] Step 3: Specify team interfaces and contracts
- [ ] Step 4: Assess capability maturity
- [ ] Step 5: Create transition plan with governance

步骤 1：梳理利益相关者及其影响力

识别所有利益相关者，按权力和关注度分类，并绘制影响力网络。有关权力—关注度矩阵和 RACI 框架，请参阅利益相关者映射。

步骤 2：定义团队结构和边界

设计与架构和战略相契合的团队。对于简单的重组 → 使用 resources/template.md。对于涉及 Conway 定律的复杂组织设计 → 研读 resources/methodology.md。

步骤 3：明确团队接口和契约

定义团队之间的 API、SLA、交接协议和决策权。有关契约模式，请参阅团队接口契约。

步骤 4：评估能力成熟度

使用成熟度模型（DORA、CMMC、自定义模型）评估当前状态。有关评估框架，请参阅能力成熟度。

步骤 5：制定包含治理机制的转型计划

定义迁移路径、决策权和评审周期。使用 resources/evaluators/rubric_stakeholders_org_design.json 进行自检。最低标准：平均分 ≥ 3.5。

利益相关者映射

权力—关注度矩阵

象限	沟通方式	示例
高权力、高关注度	密切管理（频繁沟通）	执行发起人、产品负责人
高权力、低关注度	维持满意（更新状态）	技术项目的 CFO、法务
低权力、高关注度	保持知情（征求反馈）	个体贡献者、早期采用者
低权力、低关注度	持续关注（尽量少沟通）	边缘团队

RACI 矩阵

• R - 负责执行（Responsible）：执行工作（可以有多人）— 示例：工程团队构建功能
• A - 负最终责任（Accountable）：对结果负责（每项决策恰好一人）— 示例：产品经理对功能成功负责
• C - 征询意见（Consulted）：决策前提供意见（双向沟通）— 示例：就身份验证设计征询安全团队意见
• I - 知会（Informed）：决策后接收通知（单向沟通）— 示例：通知支持团队产品发布事宜

影响力网络映射

识别：倡导者（支持者）、阻碍者（抵制者）、桥梁人物（连接者）、把关者（控制访问权限的人） 映射：谁会影响谁？正式与非正式权力、信任关系、沟通模式

团队接口契约

API 契约

指定：端点、数据格式/架构、身份验证、速率限制、版本管理/向后兼容性 示例：服务：用户身份验证 API | 所有者：身份团队 | 端点：/auth/login、/auth/token | SLA：99.95% 可用时间、p95 <100ms

SLA（服务级别协议）

定义：可用性（99.9%、99.99%）、性能（p50/p95/p99 延迟）、支持响应时间（紧急：1 小时，高：4 小时，中：1 天）、容量（请求/秒、存储）

交接协议

设计 → 工程：规格、原型、设计评审签核 | 工程 → QA：功能完成、测试计划、预发布环境 | 工程 → 支持：文档、运行手册、培训 | 研究 → 产品：发现、建议、原型

决策权（DACI）

D - 推进者（统筹）、A - 批准者（恰好一人）、C - 贡献者（提供意见）、I - 知情者（接收通知） 示例：架构（技术负责人批准，架构师提供意见）| 招聘（招聘经理批准，面试官提供意见）| 路线图（PM 批准，工程/设计/销售提供意见）

能力成熟度

DORA 指标（DevOps 成熟度）

指标	精英	高	中	低
部署频率	每天多次	每周至每天	每月至每周	<每月
前置时间	<1 小时	<1 天	1 周至 1 个月	>1 个月
MTTR	<1 小时	<1 天	1 天至 1 周	>1 周
变更失败率	0-15%	16-30%	31-45%	>45%

通用成熟度级别（CMM）

级别 1 初始：不可预测、被动响应 | 级别 2 可重复：基础项目管理 | 级别 3 已定义：有文档记录、标准化 | 级别 4 可度量：数据驱动 | 级别 5 持续优化：持续改进

自定义能力评估

模板：能力名称 | 当前级别（1-5，附证据）| 目标级别 | 差距 | 行动项

常见模式

模式 1：职能团队 → 产品团队（Spotify 模型）

• 之前：前端团队、后端团队、QA 团队、DevOps 团队
• 之后：产品小队 1（全栈）、产品小队 2（全栈）
• 接口：小队负责端到端功能，共享平台团队负责基础设施
• 收益：更快交付、减少交接、职责明确

模式 2：组建平台团队

• 触发条件：多个产品团队重复开展基础设施工作
• 设计：创建平台团队，提供自助工具
• 接口：平台团队 API 和文档、办公时间、SLA
• 人员配置：占工程团队的 10-15%（每 7-10 名产品工程师配备 1 名平台工程师）

模式 3：嵌入式与集中式专家

• 嵌入式：在产品团队内部配置安全、QA、数据工程师（紧密协作）
• 集中式：专家组成独立团队（确保一致性、深入专业知识）
• 混合式：卓越中心（制定标准）+ 嵌入式人员（实施）
• 选择因素：团队规模、成熟度、领域复杂性

模式 4：遵循康威定律

• 原则：系统设计反映沟通结构
• 应用：按照期望的架构来设计团队
• 示例：微服务 → 每个服务由小型自治团队负责
• 反模式：单体团队结构 → 单体架构持续存在

模式 5：团队拓扑（4 种基本类型）

• 流对齐团队：产品团队，与变更流对齐
• 平台团队：提供内部产品，赋能流对齐团队
• 赋能团队：为流对齐团队构建能力（临时）
• 复杂子系统团队：复杂领域的专家（机器学习、安全）

防护原则

康威定律不可避免：

• 团队会产出反映其沟通结构的系统
• 有意设计团队，以实现期望的架构
• 重组团队 = 重组系统边界

团队规模限制：

• 双披萨团队：5-9 人（Amazon）
• 邓巴数：5-15 段紧密的工作关系
• 太小（<3 人）：脆弱，技能多样性不足
• 太大（>12 人）：沟通开销大，容易形成小团体

团队认知负荷：

• 每个团队处理领域和系统的能力有限
• 简单：每个团队负责 1 个领域
• 较复杂：2-3 个相关领域
• 复杂：每个团队最多负责 1 个复杂领域

明确接口所有权：

• 每个接口都需要明确的负责人
• 共同负责 = 无人负责
• 记录：负责人、SLA、联系方式、升级流程

避免矩阵式管理混乱：

• 尽量减少双重汇报（责任归属不清）
• 如需矩阵式管理：明确主要与次要经理
• 明确定义决策权（RACI/DACI）

利益相关者疲劳：

• 不要以同等方式管理所有利益相关者
• 权力/关注度高 = 频繁沟通
• 权力/关注度低 = 尽量少更新
• 随权力/关注度的变化进行调整

切合实际地评估成熟度：

• 不要根据愿景打分
• 基于证据进行评估（指标、成果、观察）
• 常见误区：高估当前状态
• 条件允许时使用外部基准

快速参考

资源：

• 快速组织设计：resources/template.md
• 康威定律与 Team Topologies：resources/methodology.md
• 质量评估标准：resources/evaluators/rubric_stakeholders_org_design.json

5 步流程：梳理利益相关方 → 定义团队 → 明确接口 → 评估成熟度 → 制定转型计划

利益相关方梳理：权力-利益矩阵（高/低 × 高/低）、RACI（负责/最终负责/咨询/知会）、影响力网络

团队接口：API 合约、SLA（可用性/性能/支持）、交接协议、决策权（DACI/RAPID）

成熟度模型：DORA（部署频率、交付前置时间、MTTR、变更失败率）、通用 CMM（5 个等级）、自定义评估

团队类型：流对齐团队（产品）、平台团队（内部产品）、赋能团队（能力建设）、复杂子系统团队（专家）

护栏：康威定律、团队规模（两张披萨、邓巴数）、认知负荷限制、明确接口所有权、避免矩阵地狱