name: stakeholders-org-design description: 当设计组织结构（团队拓扑、康威定律对齐）、按权力-兴趣映射利益相关者以进行变更倡议、定义团队接口合同（APIs、SLAs、决策权、交接）、评估能力成熟度（DORA、CMMC、敏捷成熟度模型）、计划组织重组（功能团队到产品团队、平台团队、共享服务）时使用，或当用户提及"org design"、“team structure”、“stakeholder map”、“team interfaces”、“capability maturity”、"Conway’s Law"或"RACI"时使用。

利益相关者与组织设计

目的

利益相关者与组织设计提供框架，用于映射影响网络、设计与系统架构对齐的有效团队结构（康威定律）、定义清晰的团队接口和职责，并评估组织能力成熟度以指导改进。

何时使用

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

设计或重组组织团队（功能团队→产品团队、单体→微服务团队、平台团队）
为变更倡议映射利益相关者（权力-兴趣矩阵、影响网络、倡导者/阻碍者）
定义团队接口和合同（APIs、SLAs、交接协议、决策权）
评估能力成熟度（DevOps/DORA、安全/CMMC、敏捷、数据、设计成熟度模型）
应用康威定律（将团队结构与期望的系统架构对齐）
建立治理框架（RACI、决策权、升级路径）
规划跨职能协作模式（产品三驾马车、嵌入式 vs 集中式）
设计团队拓扑（流对齐、平台、赋能、复杂子系统）

触发此技能的用户短语：

“我们应如何构建团队？”
“为[倡议]映射利益相关者”
“定义团队接口”
“评估我们的[能力]成熟度”
“康威定律”
“团队拓扑”
“RACI矩阵”

是什么

一个结合以下元素的框架：

利益相关者映射：权力-兴趣矩阵、影响网络、用于决策权的RACI
组织设计：与架构和战略对齐的团队结构
团队接口合同：APIs、SLAs、交接协议、沟通模式
能力成熟度：使用标准模型评估（DORA、CMMC、CMM、自定义评分标准）

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

利益相关者地图：

高权力，高兴趣：工程副总裁（赞助者）、产品团队（客户）
高权力，低兴趣：首席技术官（通过指标保持满意）
低权力，高兴趣：个人工程师（保持信息同步）

团队结构：

平台团队（8人）：开发者体验、基础设施、可观测性
接口：自助服务APIs、文档、办公时间
SLA：99.9% 正常运行时间、<2周功能交付、<4小时关键bug修复

能力成熟度（DORA指标）：

部署频率：每日→每周（目标：每日）
交付时间：1周→2天（目标：<1天）
平均恢复时间：4小时→1小时（目标：<1小时）
变更失败率：15%→5%（目标：<5%）

工作流程

复制此清单并跟踪进度：

组织设计进度：
- [ ] 步骤1：映射利益相关者和影响
- [ ] 步骤2：定义团队结构和边界
- [ ] 步骤3：指定团队接口和合同
- [ ] 步骤4：评估能力成熟度
- [ ] 步骤5：创建带治理的过渡计划

步骤1：映射利益相关者和影响

识别所有利益相关者，按权力-兴趣分类，映射影响网络。参见利益相关者映射了解权力-兴趣矩阵和RACI框架。

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

设计与架构和战略对齐的团队。对于直接重组→使用resources/template.md。对于带康威定律的复杂组织设计→研究resources/methodology.md。

步骤3：指定团队接口和合同

定义APIs、SLAs、交接协议、团队间决策权。参见团队接口合同了解合同模式。

步骤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% 正常运行时间、<100ms p95

SLA（服务等级协议）

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

交接协议

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

决策权（DACI）

D - 驱动者（协调）、A - 批准者（仅一个）、C - 贡献者（输入）、I - 知情者（通知）示例：架构（技术负责人批准、架构师贡献） | 招聘（招聘经理批准、面试官贡献） | 路线图（产品经理批准、工程/设计/销售贡献）

能力成熟度

DORA指标（DevOps成熟度）

指标	精英	高	中	低
部署频率	多次/天	每周-每日	每月-每周	<每月
交付时间	<1小时	<1天	1周-1个月	>1个月
平均恢复时间	<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：平台团队提取

触发点：多个产品团队重复基础设施工作
设计：创建提供自助服务工具的平台团队
接口：平台团队APIs + 文档、办公时间、SLA
人员配置：工程的10-15%（每7-10名产品工程师配1名平台工程师）

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

嵌入式：安全/QA/数据工程师在產品团队内（紧密协作）
集中式：专家在单独团队（一致性、专业深度）
混合式：卓越中心（设定标准）+ 嵌入式（实施）
选择因素：团队规模、成熟度、领域复杂性

模式4：康威定律对齐

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

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

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

防护措施

康威定律不可避免：

团队将产生反映其沟通结构的系统
为期望架构有意设计团队
重组团队 = 重组系统边界

团队规模限制：

双披萨团队：5-9人（亚马逊）
邓巴数：5-15个紧密工作关系
太小（<3）：脆弱，缺乏技能多样性
太大（>12）：沟通开销，形成子组

每团队认知负荷：

每个团队对领域/系统的能力有限
简单：每团队1个领域
复杂：2-3个相关领域
复杂：每团队最多1个复杂领域

接口所有权清晰度：

每个接口需要一个明确所有者
共享所有权 = 无所有权
记录：所有者、SLA、联系方式、升级路径

避免矩阵地狱：

最小化双重报告（混淆问责）
如果需要矩阵：明确主要 vs 次要经理
明确定义决策权（RACI/DACI）

利益相关者疲劳：

不要平等管理所有利益相关者
高权力/兴趣 = 频繁参与
低权力/兴趣 = 最少更新
随权力/兴趣变化调整

成熟度评估现实主义：

不要基于愿望评分
基于证据的评估（指标、工件、观察）
常见陷阱：高估当前状态
尽可能使用外部基准

快速参考

资源：

快速组织设计：resources/template.md
康威定律与团队拓扑：resources/methodology.md
质量评分标准：resources/evaluators/rubric_stakeholders_org_design.json

5步流程：映射利益相关者→定义团队→指定接口→评估成熟度→过渡计划

利益相关者映射：权力-兴趣矩阵（高/低 × 高/低）、RACI（负责人/问责人/咨询者/知情者）、影响网络

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

成熟度模型：DORA（部署频率、交付时间、平均恢复时间、变更失败率）、通用CMM（5级别）、自定义评估

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

防护措施：康威定律、团队规模（双披萨、邓巴）、认知负荷限制、接口所有权清晰度、避免矩阵地狱

利益相关者与组织设计Skill stakeholders-org-design