跨部門合作總是互相推托 ? RACI工具一次解決

WHY | 為什麼你需要 RACI？

你有沒有遇過這種情況：一個任務大家都以為別人在負責，最後沒人做。或者一個決定討論了三次，還是不知道誰有最終決定權。

這不是團隊的工作態度不好，是合作安排出問題。

團隊裡的角色沒有明確對應到每一件事，就會出現三種狀況：重工（兩個人做同一件事）、漏接（沒人做），以及決策卡關（沒人敢拍板）。

RACI 就是來解決這件事。它不是複雜的框架，只是一張簡單的表格，把任務對應到四種角色，這樣每個人就清楚自己應該做什麼事。

WHAT | RACI 是什麼？

RACI 是四個英文字的縮寫，代表四種角色：

R — Responsible（執行者）
實際動手做事的人。一個任務可以有多個 R，例如工程師、設計師都是執行者。

A — Accountable（當責者）
對結果負責的人，最終審核和拍板的那個人。每個任務只能有一個 A，不能是零，也不能是兩個。當責任被分攤，就等於沒有人真的負責。

C — Consulted（諮詢者）
決策前需要徵詢意見的人，例如法務、資安、其他部門的專家。是雙向溝通，他們的意見需要被納入考量。

I — Informed（知悉者）
只需要知道結果的人，不參與執行，也不需要被諮詢。是單向通知，例如高層主管、跨部門的利害關係人。

用一個例子來說

假設你是 PM，正在推一個新功能上線：

你一眼就能看出：上線決策的 A 在 VP，PM 是 R，不是你決定，但你負責推進。

HOW | 怎麼實際建一張 RACI？

第一步：列出所有任務
把這個專案或流程裡每一個需要被完成的事情列出來，一行一個任務。

第二步：列出所有角色
不是列人名，是列角色。例如「PM」、「前端工程師」、「產品設計師」、「法務」。

第三步：填入 RACI
對每個任務，問自己：

• 誰實際在做？→ R
• 誰對結果負責、最後簽核？→ A（只能一個）
• 誰的意見需要被聽？→ C
• 誰需要知道但不需要參與？→ I

第四步：跟團隊一起確認
不要自己填完就發出去。把草稿帶進會議，跟相關人確認。如果有人覺得自己的 A 被別人拿走，或根本不知道自己是 C，這個對話本身就是最有價值的事。

第五步：放到看得到的地方
RACI 不是做完就封存的文件。放在 Notion、Confluence、或專案 Wiki，讓大家有爭議時可以拉出來對。

三個常見錯誤

不是每個任務都有一個 A → 沒有人真的在負責，出了事才開始互推。

A 給了兩個人 → 等於沒有 A，決策還是卡。

C 給太多人 → 徵詢意見變成開大會，流程變慢，還容易意見衝突。

總結

現在可以做一件事：拿你手上正在跑的任何一個專案，花 10 分鐘填一張最簡版 RACI，只要三欄：任務、A 是誰、R 是誰。光是這樣，你就能發現哪些地方現在是沒有人負責的狀態。

常見問題

Q：R 和 A 有什麼差？一個人可以同時是 R 和 A 嗎？
可以，而且很常見。例如 PM 自己負責寫 PRD（R），也是這份文件的最終負責人（A）。但要小心：當 R 和 A 是同一個人時，沒有人在幫你把關。

Q：一個任務可以有多個 R 嗎？
可以。一個功能可以有多個工程師一起執行，他們都是 R。但 A 只能一個。

Q：如果某人不在這個任務裡，要填什麼？
留空就好，不要硬塞一個 I。不相關的角色出現在 RACI 裡只會讓表格變複雜。

Q：RACI 適合所有團隊嗎？
對小型、扁平的團隊來說可能過重。但只要團隊超過 5 人、任務超過一個部門，RACI 就值得花時間做一次。

Q：RACI 和 DACI 有什麼不同？
DACI 是 Amazon、Atlassian 很常用的版本，把 A 改成 D（Driver，推進者），強調誰在驅動這件事往前走。適合更強調決策流程的場景。