stakeholders-org-design
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseStakeholders & Organizational Design
利益相关者与组织设计
Table of Contents
目录
Purpose
目的
Stakeholders & Organizational Design provides frameworks for mapping influence networks, designing effective team structures aligned with system architecture (Conway's Law), defining clear team interfaces and responsibilities, and assessing organizational capability maturity to guide improvement.
利益相关者与组织设计提供了一系列框架，用于映射影响力网络、设计与系统架构对齐的高效团队结构（Conway's Law）、明确团队接口与职责，以及评估组织能力成熟度以指导改进。
When to Use
适用场景
Invoke this skill when you need to:
- Design or restructure organizational teams (functional → product, monolith → microservices teams, platform teams)
- Map stakeholders for change initiatives (power-interest matrix, influence networks, champions/blockers)
- Define team interfaces and contracts (APIs, SLAs, handoff protocols, decision rights)
- Assess capability maturity (DevOps/DORA, security/CMMC, agile, data, design maturity models)
- Apply Conway's Law (align team structure with desired system architecture)
- Establish governance frameworks (RACI, decision rights, escalation paths)
- Plan cross-functional collaboration models (product triads, embedded vs centralized)
- Design team topologies (stream-aligned, platform, enabling, complicated-subsystem)
User phrases that trigger this skill:
- "How should we structure our teams?"
- "Map stakeholders for [initiative]"
- "Define team interfaces"
- "Assess our [capability] maturity"
- "Conway's Law"
- "Team Topologies"
- "RACI matrix"
在以下场景中调用此技能：
- 设计或重组组织团队（职能型→产品型、单体架构→微服务团队、平台型团队）
- 为变革项目映射利益相关者（权力-利益矩阵、影响力网络、支持者/反对者）
- 定义团队接口与契约（API、SLA、工作交接流程、决策权限）
- 评估能力成熟度（DevOps/DORA、安全/CMMC、敏捷、数据、设计成熟度模型）
- 应用Conway's Law（使团队结构与目标系统架构对齐）
- 建立治理框架（RACI、决策权限、升级路径）
- 规划跨职能协作模式（产品三人组、嵌入式 vs 集中式）
- 设计团队拓扑（流对齐型、平台型、赋能型、复杂子系统型）
触发此技能的用户表述：
- “我们应该如何构建团队结构？”
- “为[项目]映射利益相关者”
- “定义团队接口”
- “评估我们的[能力]成熟度”
- “Conway's Law”
- “团队拓扑”
- “RACI矩阵”
What Is It
概述
A framework combining:
- Stakeholder Mapping: Power-interest matrix, influence networks, RACI for decision rights
- Organizational Design: Team structures aligned with architecture and strategy
- Team Interface Contracts: APIs, SLAs, handoff protocols, communication patterns
- Capability Maturity: Assessment using standard models (DORA, CMMC, CMM, custom rubrics)
Quick example (Platform Team Design):
Stakeholder Map:
- High Power, High Interest: Engineering VP (sponsor), Product teams (customers)
- High Power, Low Interest: CTO (keep satisfied with metrics)
- Low Power, High Interest: Individual engineers (keep informed)
Team Structure:
- Platform Team (8 people): Developer experience, infrastructure, observability
- Interface: Self-service APIs, documentation, office hours
- SLA: 99.9% uptime, <2 week feature delivery, <4hr critical bug fix
Capability Maturity (DORA metrics):
- Deployment frequency: Daily → Weekly (target: Daily)
- Lead time: 1 week → 2 days (target: <1 day)
- MTTR: 4 hours → 1 hour (target: <1 hour)
- Change failure rate: 15% → 5% (target: <5%)
这是一个整合了以下内容的框架：
- 利益相关者映射：权力-利益矩阵、影响力网络、用于明确决策权限的RACI
- 组织设计：与架构和战略对齐的团队结构
- 团队接口契约：API、SLA、工作交接流程、沟通模式
- 能力成熟度：使用标准模型（DORA、CMMC、CMM、自定义评估表）进行评估
快速示例（平台型团队设计）：
利益相关者映射：
- 高权力、高利益：工程副总裁（发起人）、产品团队（客户）
- 高权力、低利益：CTO（通过指标保持满意）
- 低权力、高利益：一线工程师（保持信息同步）
团队结构：
- 平台型团队（8人）：开发者体验、基础设施、可观测性
- 接口：自助式API、文档、办公时间
- SLA：99.9%可用性、<2周功能交付、<4小时关键bug修复
能力成熟度（DORA指标）：
- 部署频率：每日→每周（目标：每日）
- 前置时间：1周→2天（目标：<1天）
- 平均恢复时间（MTTR）：4小时→1小时（目标：<1小时）
- 变更失败率：15%→5%（目标：<5%）
Workflow
工作流程
Copy this checklist and track your progress:
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 governanceStep 1: Map stakeholders and influence
Identify all stakeholders, categorize by power-interest, map influence networks. See Stakeholder Mapping for power-interest matrix and RACI frameworks.
Step 2: Define team structure and boundaries
Design teams aligned with architecture and strategy. For straightforward restructuring → Use resources/template.md. For complex org design with Conway's Law → Study resources/methodology.md.
Step 3: Specify team interfaces and contracts
Define APIs, SLAs, handoff protocols, decision rights between teams. See Team Interface Contracts for contract patterns.
Step 4: Assess capability maturity
Evaluate current state using maturity models (DORA, CMMC, custom). See Capability Maturity for assessment frameworks.
Step 5: Create transition plan with governance
Define migration path, decision rights, review cadence. Self-check using resources/evaluators/rubric_stakeholders_org_design.json. Minimum standard: Average score ≥ 3.5.
复制此清单并跟踪进度：
组织设计进度：
- [ ] 步骤1：映射利益相关者与影响力
- [ ] 步骤2：定义团队结构与边界
- [ ] 步骤3：明确团队接口与契约
- [ ] 步骤4：评估能力成熟度
- [ ] 步骤5：制定带治理机制的过渡计划步骤1：映射利益相关者与影响力
识别所有利益相关者，按权力-利益分类，映射影响力网络。查看利益相关者映射获取权力-利益矩阵和RACI框架。
步骤2：定义团队结构与边界
设计与架构和战略对齐的团队。对于简单重组→使用resources/template.md。对于结合Conway's Law的复杂组织设计→研究resources/methodology.md。
步骤3：明确团队接口与契约
定义团队间的API、SLA、工作交接流程、决策权限。查看团队接口契约获取契约模式。
步骤4：评估能力成熟度
使用成熟度模型（DORA、CMMC、自定义）评估当前状态。查看能力成熟度获取评估框架。
步骤5：制定带治理机制的过渡计划
定义迁移路径、决策权限、评审节奏。使用resources/evaluators/rubric_stakeholders_org_design.json进行自我检查。最低标准：平均得分≥3.5。
Stakeholder Mapping
利益相关者映射
Power-Interest Matrix
权力-利益矩阵
| Quadrant | Engagement | Example |
|---|---|---|
| High Power, High Interest | Manage Closely (frequent communication) | Executive sponsor, product owner |
| High Power, Low Interest | Keep Satisfied (status updates) | CFO for tech project, legal |
| Low Power, High Interest | Keep Informed (engage for feedback) | Individual contributors, early adopters |
| Low Power, Low Interest | Monitor (minimal engagement) | Peripheral teams |
| 象限 | 参与策略 | 示例 |
|---|---|---|
| 高权力、高利益 | 密切管理（频繁沟通） | 执行发起人、产品负责人 |
| 高权力、低利益 | 保持满意（状态更新） | 技术项目的CFO、法务团队 |
| 低权力、高利益 | 保持告知（征集反馈） | 一线贡献者、早期采用者 |
| 低权力、低利益 | 监控（最少参与） | 外围团队 |
RACI Matrix
RACI矩阵
- R - Responsible: Does the work (can be multiple) — Example: Engineering team builds feature
- A - Accountable: Owns outcome (exactly one per decision) — Example: Product manager accountable for feature success
- C - Consulted: Provides input before decision (two-way) — Example: Security team consulted on auth design
- I - Informed: Notified after decision (one-way) — Example: Support team informed of launch
- R - 负责（Responsible）：执行工作（可多人）——示例：工程团队开发功能
- A - 问责（Accountable）：对结果负责（每个决策仅一人）——示例：产品经理对功能成功负责
- C - 咨询（Consulted）：决策前提供输入（双向沟通）——示例：设计认证时咨询安全团队
- I - 告知（Informed）：决策后通知（单向沟通）——示例：通知支持团队发布信息
Influence Network Mapping
影响力网络映射
Identify: Champions (advocates), Blockers (resistors), Bridges (connectors), Gatekeepers (control access)
Map: Who influences whom? Formal vs informal power, trust relationships, communication patterns
识别：支持者（倡导者）、反对者（阻力）、桥梁（连接者）、守门人（控制访问权限）
映射：谁影响谁？正式与非正式权力、信任关系、沟通模式
Team Interface Contracts
团队接口契约
API Contracts
API契约
Specify: Endpoints, data format/schemas, authentication, rate limits, versioning/backward compatibility
Example: Service: User Auth API | Owner: Identity Team | Endpoints: /auth/login, /auth/token | SLA: 99.95% uptime, <100ms p95
明确：端点、数据格式/ schema、认证、速率限制、版本控制/向后兼容性
示例：服务：用户认证API | 所有者：身份团队 | 端点：/auth/login, /auth/token | SLA：99.95%可用性，p95延迟<100ms
SLA (Service Level Agreements)
SLA（服务水平协议）
Define: Availability (99.9%, 99.99%), Performance (p50/p95/p99 latency), Support response times (critical: 1hr, high: 4hr, medium: 1 day), Capacity (requests/sec, storage)
定义：可用性（99.9%、99.99%）、性能（p50/p95/p99延迟）、支持响应时间（关键：1小时，高优先级：4小时，中等：1天）、容量（每秒请求数、存储）
Handoff Protocols
工作交接流程
Design → Engineering: Specs, prototype, design review sign-off | Engineering → QA: Feature complete, test plan, staging | Engineering → Support: Docs, runbook, training | Research → Product: Findings, recommendations, prototypes
设计→工程：规格说明、原型、设计评审签字确认 | 工程→QA：功能完成、测试计划、预发布环境 | 工程→支持：文档、运行手册、培训 | 研究→产品：研究结果、建议、原型
Decision Rights (DACI)
决策权限（DACI）
D - Driver (orchestrates), A - Approver (exactly one), C - Contributors (input), I - Informed (notified)
Examples: Architectural (Tech Lead approves, Architects contribute) | Hiring (Hiring Manager approves, Interviewers contribute) | Roadmap (PM approves, Eng/Design/Sales contribute)
D - 驱动者（Driver）（统筹协调）、A - 批准者（Approver）（仅一人）、C - 贡献者（Contributors）（提供输入）、I - 告知者（Informed）（被通知）
示例：架构决策（技术负责人批准，架构师贡献） | 招聘（招聘经理批准，面试官贡献） | 路线图（产品经理批准，工程/设计/销售贡献）
Capability Maturity
能力成熟度
DORA Metrics (DevOps Maturity)
DORA指标（DevOps成熟度）
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | Multiple/day | Weekly-daily | Monthly-weekly | <Monthly |
| Lead Time | <1 hour | <1 day | 1 week-1 month | >1 month |
| MTTR | <1 hour | <1 day | 1 day-1 week | >1 week |
| Change Failure Rate | 0-15% | 16-30% | 31-45% | >45% |
| 指标 | 精英级 | 高级 | 中级 | 初级 |
|---|---|---|---|---|
| 部署频率 | 每日多次 | 每周-每日 | 每月-每周 | <每月 |
| 前置时间 | <1小时 | <1天 | 1周-1个月 | >1个月 |
| 平均恢复时间（MTTR） | <1小时 | <1天 | 1天-1周 | >1周 |
| 变更失败率 | 0-15% | 16-30% | 31-45% | >45% |
Generic Maturity Levels (CMM)
通用成熟度等级（CMM）
Level 1 Initial: Unpredictable, reactive | Level 2 Repeatable: Basic PM | Level 3 Defined: Documented, standardized | Level 4 Measured: Data-driven | Level 5 Optimizing: Continuous improvement
等级1 初始级：不可预测、被动响应 | 等级2 可重复级：基础项目管理 | 等级3 已定义级：文档化、标准化 | 等级4 已管理级：数据驱动 | 等级5 优化级：持续改进
Custom Capability Assessment
自定义能力评估
Template: Capability Name | Current Level (1-5 with evidence) | Target Level | Gap | Action Items
模板：能力名称 | 当前等级（1-5，附证据） | 目标等级 | 差距 | 行动项
Common Patterns
常见模式
Pattern 1: Functional → Product Teams (Spotify Model)
- Before: Frontend team, Backend team, QA team, DevOps team
- After: Product Squad 1 (full-stack), Product Squad 2 (full-stack)
- Interfaces: Squads own end-to-end features, shared platform team for infrastructure
- Benefit: Faster delivery, reduced handoffs, clear ownership
Pattern 2: Platform Team Extraction
- Trigger: Multiple product teams duplicating infrastructure work
- Design: Create platform team providing self-service tools
- Interface: Platform team APIs + documentation, office hours, SLA
- Staffing: 10-15% of engineering (1 platform engineer per 7-10 product engineers)
Pattern 3: Embedded vs Centralized Specialists
- Embedded: Security/QA/Data engineers within product teams (close collaboration)
- Centralized: Specialists in separate team (consistency, expertise depth)
- Hybrid: Center of Excellence (set standards) + Embedded (implementation)
- Choice Factors: Team size, maturity, domain complexity
Pattern 4: Conway's Law Alignment
- Principle: System design mirrors communication structure
- Application: Design teams to match desired architecture
- Example: Microservices → Small autonomous teams per service
- Anti-pattern: Monolithic team structure → Monolithic architecture persists
Pattern 5: Team Topologies (4 Fundamental Types)
- Stream-Aligned: Product teams, aligned with flow of change
- Platform: Internal products enabling stream-aligned teams
- Enabling: Build capability in stream-aligned teams (temporary)
- Complicated-Subsystem: Specialists for complex areas (ML, security)
模式1：职能型团队→产品型团队（Spotify模式）
- 之前：前端团队、后端团队、QA团队、DevOps团队
- 之后：产品小组1（全栈）、产品小组2（全栈）
- 接口：小组负责端到端功能，共享平台型团队负责基础设施
- 优势：交付更快、减少交接、所有权明确
模式2：平台型团队拆分
- 触发因素：多个产品团队重复进行基础设施工作
- 设计：创建提供自助式工具的平台型团队
- 接口：平台团队API+文档、办公时间、SLA
- 人员配置：占工程团队的10-15%（每7-10名产品工程师配1名平台工程师）
模式3：嵌入式vs集中式专家
- 嵌入式：安全/QA/数据工程师加入产品团队（紧密协作）
- 集中式：专家在独立团队（一致性、专业深度）
- 混合式：卓越中心（制定标准）+嵌入式（落地执行）
- 选择因素：团队规模、成熟度、领域复杂度
模式4：Conway's Law对齐
- 原则：系统设计反映沟通结构
- 应用：设计团队以匹配目标架构
- 示例：微服务→每个服务对应小型自治团队
- 反模式：单体团队结构→单体架构持续存在
模式5：团队拓扑（4种基础类型）
- 流对齐型：产品团队，与变更流对齐
- 平台型：为流对齐型团队提供支持的内部产品团队
- 赋能型：为流对齐型团队构建能力（临时）
- 复杂子系统型：负责复杂领域的专家团队（ML、安全）
Guardrails
注意事项
Conway's Law is inevitable:
- Teams will produce systems mirroring their communication structure
- Design teams intentionally for desired architecture
- Reorganizing teams = reorganizing system boundaries
Team size limits:
- 2-pizza team: 5-9 people (Amazon)
- Dunbar's number: 5-15 close working relationships
- Too small (<3): Fragile, lacks skills diversity
- Too large (>12): Communication overhead, subgroups form
Cognitive load per team:
- Each team has limited capacity for domains/systems
- Simple: 1 domain per team
- Complicated: 2-3 related domains
- Complex: Max 1 complex domain per team
Interface ownership clarity:
- Every interface needs one clear owner
- Shared ownership = no ownership
- Document: Owner, SLA, contact, escalation
Avoid matrix hell:
- Minimize dual reporting (confusing accountability)
- If matrix needed: Clear primary vs secondary manager
- Define decision rights explicitly (RACI/DACI)
Stakeholder fatigue:
- Don't manage all stakeholders equally
- High power/interest = frequent engagement
- Low power/interest = minimal updates
- Adjust as power/interest shifts
Maturity assessment realism:
- Don't grade on aspirations
- Evidence-based assessment (metrics, artifacts, observation)
- Common pitfall: Over-rating current state
- Use external benchmarks when available
Conway's Law不可避免：
- 团队产出的系统会反映其沟通结构
- 为目标架构有意识地设计团队
- 重组团队=重组系统边界
团队规模限制：
- 双披萨团队：5-9人（亚马逊）
- 邓巴数：5-15个紧密工作关系
- 过小（<3人）：脆弱，缺乏技能多样性
- 过大（>12人）：沟通成本高，形成小团体
团队认知负荷：
- 每个团队的领域/系统处理能力有限
- 简单场景：每个团队负责1个领域
- 复杂场景：2-3个相关领域
- 高度复杂场景：每个团队最多负责1个复杂领域
接口所有权明确：
- 每个接口需要明确的唯一所有者
- 共享所有权=无所有权
- 文档记录：所有者、SLA、联系人、升级路径
避免矩阵混乱：
- 尽量减少双重汇报（问责模糊）
- 如需矩阵结构：明确主次经理
- 明确定义决策权限（RACI/DACI）
利益相关者疲劳：
- 不要同等管理所有利益相关者
- 高权力/高利益=频繁互动
- 低权力/低利益=最少更新
- 随权力/利益变化调整策略
成熟度评估务实：
- 不要按期望评分
- 基于证据的评估（指标、工件、观察）
- 常见误区：高估当前状态
- 尽可能使用外部基准
Quick Reference
快速参考
Resources:
- Quick org design: resources/template.md
- Conway's Law & Team Topologies: resources/methodology.md
- Quality rubric: resources/evaluators/rubric_stakeholders_org_design.json
5-Step Process: Map Stakeholders → Define Teams → Specify Interfaces → Assess Maturity → Transition Plan
Stakeholder Mapping: Power-Interest Matrix (High/Low × High/Low), RACI (Responsible/Accountable/Consulted/Informed), Influence Networks
Team Interfaces: API contracts, SLAs (availability/performance/support), handoff protocols, decision rights (DACI/RAPID)
Maturity Models: DORA (deployment frequency, lead time, MTTR, change failure rate), Generic CMM (5 levels), Custom assessments
Team Types: Stream-Aligned (product), Platform (internal products), Enabling (capability building), Complicated-Subsystem (specialists)
Guardrails: Conway's Law, team size (2-pizza, Dunbar), cognitive load limits, interface ownership clarity, avoid matrix hell
资源：
- 快速组织设计：resources/template.md
- Conway's Law与团队拓扑：resources/methodology.md
- 质量评估表：resources/evaluators/rubric_stakeholders_org_design.json
5步流程：映射利益相关者→定义团队→明确接口→评估成熟度→制定过渡计划
利益相关者映射：权力-利益矩阵（高/低×高/低）、RACI（负责/问责/咨询/告知）、影响力网络
团队接口：API契约、SLA（可用性/性能/支持）、工作交接流程、决策权限（DORA/RAPID）
成熟度模型：DORA（部署频率、前置时间、MTTR、变更失败率）、通用CMM（5个等级）、自定义评估
团队类型：流对齐型（产品）、平台型（内部产品）、赋能型（能力构建）、复杂子系统型（专家）
注意事项：Conway's Law、团队规模（双披萨、邓巴数）、认知负荷限制、接口所有权明确、避免矩阵混乱