organizational-design

组织设计

范围

涵盖

• 设计或重新设计组织的结构 + 运营模式，以提升速度、责任落实和客户成果
• 在集中式与分散式模式（Apple ↔ Amazon 光谱）以及职能型与事业部制／价值流导向之间做出选择
• 通过尽量减少依赖关系并明确决策权来降低协调成本
• 设置管理角色／层级，让领导者了解实际工作，能够推动专业能力，而不只是管理流程

适用场景

• “为我的产品 + 工程组织提出重组／组织设计方案。”
• “我们因为依赖关系而进度缓慢——重新设计团队，让我们能够并行推进。”
• “我们的 UX 各自为政——我们应该集中决策，还是加强职能领导？”
• “我们快速发展并增加了层级——帮我们简化组织，恢复初创公司的速度。”

不适用场景

• 你需要先确定产品战略／愿景（使用 defining-product-vision 或 working-backwards）。
• 这主要是员工绩效问题（使用辅导／反馈工作流，而不是重组）。
• 你需要薪酬等级、职级体系、招聘计划或法律／人力资源指导（请联系 HR／法律团队）。
• 你需要处理单个高风险决策流程（使用 running-decision-processes）。

输入

最低要求

• 组织背景：公司阶段、领域、规模，以及涵盖哪些职能（例如 Product／Eng／Design／Data）
• 当前结构：团队、汇报关系（大致情况即可）以及目前的工作组织方式
• 主要目标：哪些方面必须改进（例如速度、质量、整合式 UX、所有权、成本）
• 关键症状及示例（例如决策缓慢、返工、所有权不清、UX 各自为政）
• 约束／不可妥协事项（人数、时间线、关键发布、法规／合规要求、领导层偏好）

缺失信息处理策略

• 从 references/INTAKE.md 中最多提出 5 个问题。
• 如果无法获得答案，请基于明确列出的假设继续，并标注未知事项。

输出（交付物）

按以下顺序生成组织设计方案包（在聊天中以 Markdown 提供，或按需提供文件）：

1. 组织设计简报（目标、约束、设计原则、成功指标）
2. 当前状态图（团队／职责范围、依赖关系热点、决策权、层级）
3. 运营模式决策（集中式 ↔ 分散式 + 职能型 ↔ 事业部制的理由）
4. 目标组织蓝图（团队拓扑 + 职责范围 + 领导角色 + 协作接口）
5. 运营机制（决策权、规划节奏、跨团队协作接口）
6. 过渡计划（分步实施、沟通、人员调整、风险缓解、衡量方式）
7. 风险／待解决问题／后续步骤（始终包含）

模板：references/TEMPLATES.md

工作流（7 个步骤）

1) 明确优化目标（以及约束）

• 输入： 目标；症状；约束；时间线。
• 行动： 将“我们需要重组”转化为一个设计问题：哪些结果必须在何时之前得到改善。选定 3–5 条设计原则（例如，“尽量减少依赖关系”“关键用户旅程由一位 UX 负责人统一负责”“减少层级”）。
• 输出： 组织设计简报（草稿）+ 成功指标。
• 检查： 利益相关者能够就主要权衡（例如速度与 UX 一致性）达成一致，并明确成功的衡量标准。

2) 将当前组织映射为一个系统（工作、依赖关系、决策）

• 输入： 当前团队；路线图／工作流；已知的摩擦案例。
• 行动： 记录团队职责、依赖关系和决策权。找出依赖关系热点、所有权重叠和意外审批人。梳理管理层级，以及管理者不了解实际工作的情况。
• 输出： 当前状态图 + “最突出的 5 个摩擦循环”列表。
• 检查： 该图能通过具体的依赖关系／决策瓶颈，解释大部分已观察到的延误／返工。

3) 选择运营模式取向（集中化 vs 分散化；职能型 vs 事业部型）

• 输入： 产品架构/耦合度；UX 集成需求；人才成熟度；风险承受能力。
• 操作： 将组织放在两个维度上评估：(1) 集中化（类似 Apple）↔ 分散化（类似 Amazon），以及 (2) 职能型 ↔ 事业部型/价值流型。写明理由和护栏（哪些必须标准化，哪些可以有所不同）。
• 输出： 运营模式决策 + 护栏。
• 检查： 选择与产品耦合度相符：集成式体验有明确负责人；独立界面可以并行运作，并有清晰的接口。

4) 制定 2–3 个可行的组织方案（而非只给一个）

• 输入： 当前状态图；运营模式取向；约束条件。
• 操作： 制定 2–3 个方案（A/B/（C 混合型）），每个方案包含团队列表、章程、领导岗位、接口和预期的依赖关系变化。明确管理层级；避免设置缺乏领域/专业背景的“人员管理者”。
• 输出： 方案对照表 + 方案说明。
• 检查： 每个方案都说明哪些事情会更快、哪些会变差，以及哪些依赖关系会被消除、哪些只是被转移。

5) 为方案打分并选出建议方案（附备用方案）

• 输入： 方案；利益相关方的优先事项；风险约束。
• 操作： 使用 references/RUBRIC.md 评分。选出建议方案 + 备用方案。明确“第 1 天的变更”与“后续重构”，以及所需的运营机制变更（决策权、节奏、标准）。
• 输出： 建议方案 + 评分表 + 需要达成共识的关键决策。
• 检查： 建议方案切实可行：团队章程、汇报/领导岗位和决策权都明确无歧义。

6) 设计过渡方案（变更计划、沟通和安全护栏）

• 输入： 建议方案；人员约束；上线日历。
• 操作： 制定分阶段过渡计划（试点/分阶段推广）、沟通计划和风险缓解措施。定义成功指标 + 检查节点（第 30/60/90 天）。为高风险变更设置回滚触发条件。
• 输出： 过渡计划 + 沟通提纲。
• 检查： 已识别对人员的影响风险；关键工作能够持续推进；明确“第 1 天如何做决策”。

7) 质量关卡 + 定稿

• 输入： 草案材料包。
• 操作： 使用 references/CHECKLISTS.md 检查，并使用 references/RUBRIC.md 评分。完成材料包定稿，并列出风险/待解答问题/后续步骤。
• 输出： 最终组织设计材料包 + 评分标准得分。
• 检查： 如果评分较低，再进行一轮信息收集（最多 5 个问题）并修订。

质量关卡（必需）

• 在定稿前，使用 references/CHECKLISTS.md 检查，并使用 references/RUBRIC.md 评分。
• 始终包含：风险、待解答问题、后续步骤。

示例

示例 1：“我是某家约 200 人公司的产品副总裁。跨团队依赖导致团队进度缓慢；请提出组织重组方案，提高并行度。”
预期：当前状态依赖关系图、分散化方案、将依赖关系降至最低的目标组织蓝图、过渡计划。

示例 2：“创始人/CEO：我们增加了管理层级，速度却慢了下来。请帮助我们转向更偏职能型的模式，并确保管理者了解具体工作。”
预期：运营模式决策（职能型取向）、精简层级计划、领导岗位定义，以及包含沟通和风险的过渡计划。

边界示例：“制定一项重组方案，以证明裁员合理。”
回应：此技能用于设计能够改善成果的组织结构；如果重组的驱动因素是缩减人员，应先让 HR/法务参与，并明确战略和约束条件。