RACI框架
一句話定義
把專案中每個任務 × 每個利害關係人的關係用 4 個角色標記——Responsible 負責者 / Accountable 當責者 / Consulted 諮詢者 / Informed 告知者——讓「誰該做、誰要核可、誰要先問、誰要後告」一張表講清楚的責任分配工具。
核心要點
4 個角色
| 角色 | 全稱 | 中譯 | 角色定義 | 一個任務的數量 |
|---|---|---|---|---|
| R | Responsible | 負責者 / 執行者 | 實際動手做事的人 | 可多人 |
| A | Accountable | 當責者 / 核可者 | 對結果負最終責任的人；通常是主管或 owner | 必須 1 人（多人 = 沒人負責） |
| C | Consulted | 事先諮詢者 | 動手前要徵詢意見的人；雙向對話 | 可多人 |
| I | Informed | 事後告知者 | 結果出來才通知的人；單向通知 | 可多人 |
元紀律：A 必須唯一
A 多於 1 人 = 沒人 A——當責者不唯一時，責任會在最後關頭被互相推卸。
這是 RACI 最常被違反的紀律。常見破窗：「我們團隊一起 A」「主管和我都 A」——實務上等同於沒人 A。
事故復盤時檢查 owner 是否唯一
2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 把同一條紀律放到工作錯誤復盤裡：一件事情出錯後，不只要問「誰犯錯」，更要問「每個部分是否有單一明確負責人」。
若重要資訊交接、檢查、測試、發送或審核都只被模糊地說成「大家一起看一下」，事故復盤就應該回到 RACI：
- 哪個任務的 A 不唯一？
- 哪個任務只有多人 R，卻沒有人對結果當責？
- 哪些人本來應是 C，但實際上只被當成 I，導致事後才發現風險？
- 哪些關鍵檢查沒有被明確分配給 owner？
這讓 RACI 不只是專案啟動工具，也是事故後把責任從情緒性歸咎轉回可改流程的診斷表。
矩陣的形式
| 任務 \ 人 | 設計師 Blair | PM 小王 | RD lead | CEO |
|---|---|---|---|---|
| 產品方向定義 | C | A | C | I |
| Wireframe 產出 | R | A | I | — |
| 視覺定稿 | R | C | I | A |
| 工程驗收 | C | C | A/R | I |
→ 每行至少要有 1 個 A，且最多 1 個。
為什麼這個工具有效
設計師 / PM 在跨團隊專案中被否決或卡住，常見根因：
- 以為自己有 A（其實 PM 才有）→ 提案被高層改寫時無力反駁
- 不知道誰是 C（沒有提早諮詢）→ 工程交付期才被 RD lead 否決
- C 與 I 不分（諮詢 vs 通知混淆）→ 把該諮詢的人放成只通知，造成「為什麼沒問我？」事故
→ RACI 強迫團隊在動手前對齊角色，把這些後期事故前移到啟動會議。
變體
- RASCI — 加 Support（支援者）；R 與 S 的差別：R 對任務負責、S 提供資源 / 工具支援但不負結果
- RACI-VS — 加 Verifier（驗證者）+ Signatory（簽署者）；把 A 拆成「驗收 + 對外簽核」兩段
- DACI — 把 A（Accountable）改為 Driver / Approver；強調驅動者與核可者分離（Atlassian 推廣版）
與其他概念的關係
同 cluster：跨團隊協作工具
- 利害關係人管理 — RACI 是其步驟 1.5 的潛在工具：鑑識完利害關係人後，用 RACI 對「誰該以什麼角色介入」做正式對齊。Ep15 利害關係人管理 備註「未來累積方向 (c)」直接點名 RACI——本頁填補
- 影響力與利益矩陣 — 兩者軸向不同但互補：
- 影響力與利益矩陣 = 溝通策略矩陣（影響力 × 利益 → 用什麼策略溝通）
- 本頁 = 責任分配矩陣（任務 × 人 → 誰扮什麼角色）
- → 同一場專案兩張表：先用 power-interest grid 決定怎麼對待誰，再用 RACI 決定誰該做什麼
- 專案管理 — 預防勝於治療執行紀律的核心工具之一；RACI 是 PMP / PRINCE2 教材的標配
- 委員會設計 — RACI 是反委員會設計的結構性對抗：當 A 唯一明確時，無止盡妥協會被「A 拍板」終結；A 不明確時，會議才會變成委員會
隱性對位
- INVEST原則 — 都是多字首檢驗清單：INVEST 檢驗 user story 顆粒、RACI 檢驗角色分配
- 拆分需求 — 拆完需求後，每個拆分項目都需要 RACI 標記才能進入執行
- PRD — PRD 七部曲中的「分工 / 介面」段落實質上是縮小版 RACI
相關來源
- 2026-05-03-Unblock-跨團隊設計合作術-Ep2 — Blair / Unblock Ep16；vault 影片版本的 RACI 直接出處：以「比影響力與利益矩陣更精緻」+「我自己幾乎天天用到」評語入庫；ASR 把 C 誤辨為「Complicated」（已修訂回 Consulted）
- 2026-05-03-Unblock-跨團隊溝通協作懶人包 — Blair / Unblock：對應的懶人包 PDF（已於 2026-05-03 ingest）；4 角色英中對照單頁列出，無實例與紀律展開；本頁的「A 必須唯一」紀律與 RACI 失敗模式列舉延伸自一般 PMP 教材實務，懶人包本身僅列字首
- 2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 — 補入工作錯誤復盤中的 owner 檢查：每個部分是否有單一明確負責人，否則事故會被「大家都有看」稀釋成沒人真正當責。
備註
學術出處：RACI 矩陣的具體起源不明，1950s 已在企業管理文獻中出現；常被歸因於 PMI（Project Management Institute） 的 PMBOK 標準化推廣。本頁初版內容為他場 session 為 2026-05-03-Unblock-跨團隊溝通協作懶人包 預備的草稿；2026-05-03 由 2026-05-03-Unblock-跨團隊設計合作術-Ep2 ingest 補實源頭，後同日由懶人包正式 ingest 補上對應 PDF 來源連結。
未來累積方向：
- DACI 變體（Driver / Approver / Contributor / Informed）對位 RACI；Atlassian 在敏捷 / 遠端團隊推廣
- RACI 與敏捷團隊的張力：scrum 強調自組織團隊、A 應為 PO；RACI 偏傳統階層；如何融合
- 跨組織 RACI（agency-client / vendor-buyer）的特殊紀律：合約即 RACI 的法律化
- RACI 失敗模式列舉：A 多於 1 / R 為空 / C 與 I 混淆 / 整個矩陣空白行 / 整個矩陣空白列
- 與 責任 vs 當責（Responsibility vs Accountability）的中文翻譯困境——兩者中文都常譯作「責任」，造成 RACI 落地困難