daci-framework

DACI 决策框架

概述

使用 DACI 框架（Driver、Approver、Contributor、Informed）明确决策归属，并减少决策反复。与侧重任务责任的 RACI 不同，DACI 专为产品决策而设计——明确由谁推动决策落地、谁拥有否决权、谁提供意见，以及谁需要知情。

四种角色简述：Driver（恰好 1 人，推动决策落地）、Approver（最多 1-2 人，拥有否决权）、Contributor（提供意见但没有否决权）、Informed（接收通知，不参与征询）。通过梳理当前状态、找出痛点、设计目标状态，并制定 30/60/90 天过渡计划来构建图表。角色规则、7 步构建流程和健康度指标详见操作手册参考文档。

适用场景

• 组建新团队——新的跨职能团队需要明确决策角色。
• 决策反复——由于无人清楚谁有决策权，决策陷入停滞。
• 团队扩张——团队发展导致各类决策的负责人变得模糊。
• 事件复盘后——发布失败或错过截止日期暴露出归属不明确的问题。
• 重组过渡期——角色变更造成治理缺口。

不适用场景

• 任务分配或项目执行（改用 RACI）。
• 分配个人贡献者的工作（使用冲刺规划）。
• 真正由一人独立做出的决策（无需增加治理开销）。

先明确信息

构建 DACI 图表之前，请确认以下信息。如果有任何一项未知或含糊不清，请先询问——不要自行假设：

• 需要梳理的具体决策——3-5 项高影响决策，而不是“所有事情”（每项决策对应图表中的一行；一次梳理过多是最常见的失败原因）
• 候选人员及其实际权限——谁真正有权批准或否决（这决定了 Driver 和 Approver 的安排；没有实际权限，图表就只是纸上谈兵）
• 当前痛点——目前哪些决策会陷入停滞或反复（这决定了当前状态到目标状态的差距，以及 30/60/90 天过渡计划）

停止规则：只询问最可能显著影响结果的 2-3 项信息。如果用户说“直接起草”，就继续，并在文档开头列出你的假设。

参考资料

• references/playbook.md——构建或运行 DACI 图表时请阅读：角色定义与规则、7 步构建流程（工作组 → 角色 → 决策 → 当前状态图谱 → 痛点 → 目标状态 → 过渡计划）、治理健康度指标、故障排查和成功标准。
• references/red-flags.md——发布图表或据此执行决策前请阅读：DACI 图表常见问题及依据角色规则编写的正反示例。

范围与限制

**适用范围：**创建 DACI 图表、梳理当前状态、设计目标状态、规划过渡方案、评估治理健康度、识别痛点、明确决策归属。

**不适用范围：**任务分配（使用 RACI）、项目执行跟踪（使用冲刺规划）、个人绩效管理、超出决策治理范畴的组织设计。

**重要注意事项：**DACI 在领导层承诺遵守该框架时效果最佳。如果没有高管支持，Driver 可能缺乏实际推动决策的权限。应从 3-5 项高影响决策开始，而不要试图一次性梳理所有事项。

集成点

集成	方向	流转内容
create-prd/	输入到	DACI 决策为 PRD 的 Contacts 部分和决策日志提供信息
identify-assumptions/	补充	揭示关于谁拥有权限的假设
brainstorm-okrs/	补充	OKR 归属与 DACI 决策归属保持一致
summarize-meeting/	输入到	会议摘要记录 DACI 决策结果
senior-pm/	补充	用于跨项目决策的组合层级 DACI

延伸阅读

• Productside 面向产品团队的 DACI 指南
• 介绍 Intuit 和其他产品驱动型组织所采用的 DACI 框架