stakeholders-org-design

利益相关方与组织设计

目录

1. 工作流
2. 利益相关方映射
3. 团队接口契约
4. 能力成熟度
5. 常见模式
6. 防护措施
7. 快速参考

工作流

复制此清单并跟踪进度：

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

影响力网络映射

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

团队接口契约

API 契约

明确：端点、数据格式/模式、身份验证、速率限制、版本控制/向后兼容性 示例：服务：用户身份验证 API | 负责人：身份团队 | 端点：/auth/login、/auth/token | SLA：99.95% 正常运行时间，p95 <100ms

SLA（服务级别协议）

定义：可用性（99.9%、99.99%）、性能（p50/p95/p99 延迟）、支持响应时间（严重：1hr，高：4hr，中：1 day）、容量（requests/sec、存储）

交接协议

设计 → 工程：规格、原型、设计评审签字 | 工程 → 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 种基本类型）

• 流对齐团队：产品团队，与变更流对齐
• 平台团队：构建内部产品，助力流对齐团队
• 赋能团队：帮助流对齐团队建立能力（临时）
• 复杂子系统团队：负责复杂领域的专家（ML、安全）

防护原则

康威定律不可避免：

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

团队规模限制：

• 两张披萨团队：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 个等级）、自定义评估

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

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