DACI 決策框架 DACI Decision Framework

什麼時候該用它？

DACI 最適合在「大家都覺得自己有權決定，但沒人真的拍板」的時候拿出來。它不是要解決技術問題，而是解決組織問題——讓每個決策都有明確的權責歸屬。

• 跨部門專案啟動：三個部門都覺得自己是 owner，先用 DACI 釐清誰是 Driver、誰是 Approver
• 功能優先級爭議：PM 說做 A、業務說做 B、老闆說都要做，DACI 讓「誰有最終決定權」變得透明
• 組織擴張期：公司從 30 人長到 100 人，原本「找誰都行」的決策方式開始失靈
• 遠端團隊協作：分散在不同時區的團隊特別需要書面化的角色定義，避免等一個人回覆就卡住全部
• 重大技術選型：選用哪個框架、遷移到哪個雲端平台，這種影響深遠的決策需要結構化的諮詢流程

框架結構

DACI 把每個決策中的參與者分成四種角色，每個角色的權利和義務都不同。

D — Driver（驅動者）

負責推動決策流程的人。搜集資訊、安排會議、整理選項、確保時程——但不一定是最終拍板的人。

• 每個決策只有一個 Driver
• Driver 不等於 Approver——這是最常搞混的地方
• 通常是 PM 或 Tech Lead

A — Approver（批准者）

擁有最終決定權的人。當意見分歧無法收斂時，Approver 做最後裁決。

• 每個決策只有一個 Approver（最多兩個，但強烈建議只有一個）
• Approver 可以否決 Driver 的建議
• 通常是產品負責人、VP、或該領域的最高主管

C — Contributors（貢獻者）

提供專業意見和資訊的人。他們的觀點必須被聽取和考慮，但不代表 Driver 必須照做。

• 可以有多個 Contributors
• 他們的責任是提供誠實的專業判斷，不是附和 Driver
• 通常是技術專家、設計師、法務、數據分析師

I — Informed（被通知者）

決策做完後需要知道結果的人。他們不參與決策過程，但需要了解結論以便後續行動。

• 可以有很多 Informed
• 不要把 Informed 拉進決策討論——這是最常見的效率殺手
• 通常是執行團隊、客服、其他受影響的部門

來源與歷史

• 1960s：RACI 矩陣（Responsible, Accountable, Consulted, Informed）出現，成為專案管理的基礎工具
• 2006：Intuit 內部發展出 DACI 變體，將 RACI 中的 R 和 A 重新定義為 Driver 和 Approver，更適合產品決策場景
• 2015：Atlassian 大規模導入 DACI，並將它整合到 Confluence 的決策模板中，透過 Atlassian 的生態系統推廣到全球
• 2018：Spotify、Stripe、Airbnb 等科技公司陸續在內部採用 DACI 或其變體，成為矽谷標準的決策框架
• 2020s：遠端工作時代，DACI 的「書面化角色定義」特性變得更加重要，成為異步決策的基礎設施

真實案例：Atlassian 的決策加速

Atlassian（Jira、Confluence 的母公司）在 2015 年員工從 1,000 人成長到 2,000+ 人時，發現決策速度嚴重下滑。

問題診斷：

1. 決策癱瘓：平均一個中型產品決策需要 3-4 週，因為「每個人都覺得自己需要被諮詢」
2. 責任模糊：決策做完後出了問題，沒人知道是誰決定的
3. 會議膨脹：決策相關會議平均 8-12 人參加，其中一半的人其實只需要收到結果通知

導入 DACI 後的變化：

1. 角色明確化：每個產品決策都有一頁 DACI 表格，直接放在 Confluence 上
2. 會議瘦身：決策會議只邀 D + A + C（通常 3-5 人），I 的人收到會議紀錄就好
3. 時程承諾：每個 DACI 表格都有「決策截止日」，到期必須有結論

結果：中型決策的平均耗時從 3-4 週降到 1 週以內。Atlassian 後來把這套方法論公開在他們的 Team Playbook 上，成為業界參考標準。

使用步驟

Step 1：定義決策問題

把要做的決定用一句話寫清楚。不是「我們要討論行動 App」，而是「我們要決定 Q3 是否投入資源開發 iOS 原生 App，還是繼續用 PWA」。

Step 2：指派四個角色

填寫 DACI 表格：

Step 3：Driver 蒐集資訊、準備選項

Driver 向 Contributors 蒐集意見，整理成 2-3 個具體選項，每個選項附上 pros/cons 和預估成本。

Step 4：決策會議

只邀 D + A + C。Driver 簡報選項（15 分鐘），Contributors 補充觀點（15 分鐘），Approver 做決定或要求補充資訊。

Step 5：記錄與通知

決策結果寫進 DACI 文件，包含：做了什麼決定、為什麼、還有哪些考慮但沒選的方案。通知所有 Informed 的人。

這樣做 vs 避免這些

這樣做

• 每個決策的 Approver 只能有一個——兩個 Approver 等於沒有 Approver
• 把 DACI 表格放在團隊都能看到的地方（Confluence、Notion、Google Doc），讓角色透明
• 在決策截止日前完成，到期沒結論就由 Approver 根據現有資訊裁決
• 決策後回頭更新 DACI 文件，記錄實際結果，作為未來決策的參考

避免這些

• 不要把所有人都放在 Contributors——如果有超過 5 個 Contributors，你需要重新思考誰真的有必要參與
• 不要讓 Driver 和 Approver 是同一個人——這樣就失去了「推動」和「把關」的分離機制
• 不要用 DACI 管理小決定——按鈕要用藍色還是綠色不需要 DACI，它是為「影響範圍大、涉及多方的決定」設計的
• 不要在決策做完後才告訴 Informed——他們應該在流程開始時就知道「有這個決策在進行中」