看似沒人有意見的順利會議，為什麼可能是專案危機的開始？

星期一早上十點，你召集行銷、設計、工程與業務部門，討論公司即將推出的電商網站，會議進行得非常順利，行銷部門表示會準備商品文案，設計部門說會配合網站視覺，工程師也表示技術上沒有太大問題。

會議結束前，你詢問大家：「那這樣有沒有什麼問題？」所有人都回答沒有。

你放心地結束會議，心裡以為專案已經正式啟動，然而兩週後卻發現：

• 商品文案還沒有完成，因為行銷部門正在等待業務提供商品資料
• 設計稿沒有進度，因為設計師認為應該先取得完整文案
• 工程師也還沒開始開發，因為網站功能規格尚未確認

每個人都有合理的理由，但專案就是沒有往前推進。

這時候，真正的問題可能不是團隊不願意合作，而是大家知道要做什麼，卻不知道誰應該負責讓事情完成及推進。

而這時身為專案負責人的你該怎麼辦呢？

• 本文適合哪些人閱讀： PM 新手、專案負責人、部門主管、行銷企劃，以及需要協調不同部門的職場工作者
• 本文重點： RACI 責任矩陣、專案管理、跨部門溝通、專案責任分工、專案進度管理

專案分工最常見的問題：有人參與，不代表有人負責

在一般工作中經常使用到「大家一起處理」這種說法。

例如：

• 老闆說：「這個活動行銷和業務一起負責」
• 產品經理說：「網站的部分設計跟工程一起確認」
• 財務長說：「預算就請相關部門共同討論」

這些說法聽起來合理，卻可能隱藏責任不清的問題。

• 當兩個部門共同負責一件事情，究竟誰應該主動追蹤？
• 如果雙方意見不同，誰可以做最後決定？
• 當工作沒有完成，應該由誰說明原因？

如果這些問題沒有事先確認，專案就容易出現等待、重複作業或互相推諉的情況。

分工不只是分配工作，有效的專案分工，至少需要釐清三個問題。

• 第一，誰實際執行？
• 第二，誰對成果負最終責任、向上回報？
• 第三，哪些人需要參與討論或接收資訊？

這也是 RACI 責任矩陣可以協助解決的問題。

什麼是 RACI？四種角色一次搞懂

RACI 是一種用於釐清及定義專案中各項任務角色的管理工具，能降低團隊中定位不清、互相推卸責任的問題。

它將參與任務的人員區分為四種角色。

角色	英文	主要責任
R	Responsible	實際執行工作的人
A	Accountable	對成果負最終責任的人
C	Consulted	執行前或過程中需要諮詢的人
I	Informed	需要知道進度或結果的人

Responsible：誰要把事情做完？

例如公司需要製作一份活動報名頁面，設計師負責畫面設計，工程師負責功能開發，他們就是各自工作項目的 Responsible。

同一項任務可以有多位執行者，但最好能進一步拆分工作，避免彼此不知道誰負責哪個部分。

Accountable：誰要對結果負責？

這是 RACI 中非常重要的角色，假設活動頁面需要在月底上線，即使設計、工程、行銷都有參與，仍應明確指定一位對該項交付成果負最終責任的人。

通常建議每項任務只有一位 Accountable，避免決策權分散，不過這不代表 Accountable 必須親自完成所有工作，而是要確保工作有明確的負責窗口。

Consulted：誰的專業意見不可忽略？

例如設計活動報名頁面時，可能需要詢問法務部門個資蒐集規範，也需要確認客服部門後續如何處理報名問題。

這些人不一定實際製作頁面，但他們的意見可能影響最終成果。

Informed：誰需要知道結果？

例如公司主管可能不需要參與每一次設計討論，但需要知道網站是否能如期上線，這時候主管就可能屬於 Informed。

需要注意的是，同一個人在不同任務中，可能扮演不同角色。

實際案例：如何使用 RACI 管理電商網站專案？

假設一間中小企業準備建立官方電商網站，參與角色包含專案經理、行銷、設計、工程與業務主管，可以先建立以下責任矩陣。

工作項目	PM	行銷	設計	工程	業務主管
網站需求確認	R	C	C	C	A
商品文案製作	I	R/A	C	I	C
網站視覺設計	I	C	R/A	C	I
購物功能開發	I	C	C	R/A	I
上線驗收	R	C	C	C	A

這只是一個示範，實際角色應依公司權限與組織結構調整。

例如在某些公司，PM 本身就具有網站需求的最終核准權；在其他公司，可能必須由產品負責人或業務主管確認。

RACI 的目的不是讓每家公司使用相同分工，而是讓團隊清楚知道：每項工作應該由誰執行、誰有權確認，以及哪些人需要參與。

除了責任分工，還要建立明確的決策機制

即使已經完成 RACI，專案仍可能卡在另一個問題：沒有人願意做決定。

例如設計師提供兩個首頁版本，行銷部門偏好 A 版，業務部門認為 B 版比較適合客戶，雙方討論了一個星期，卻始終沒有結論。

這時候，PM 應該先確認：

• 這項決策的最終負責人是誰？
• 有哪些必要的評估標準？
• 最晚需要在哪一天完成決定？

不要把每件事情都交給所有人表決，跨部門合作不代表所有決策都必須取得全員共識。

• 有些事情需要專業部門決定，例如技術架構
• 有些事情則需要商業負責人決定，例如預算與產品定位
• 如果每個人都擁有否決權，卻沒有人負責最後決策，專案就可能停滯

因此，PM 應協助建立清楚的決策規則，例如：

• 網站首頁的品牌方向由行銷主管確認
• 技術可行性由工程負責人評估
• 超過核定預算的修改，必須由專案贊助人核准

這些規則越早確認，後續越容易推進。

會議結束前，PM 一定要確認的四件事

很多專案會議之所以沒有效果，是因為大家只討論問題，卻沒有確認後續行動。因此，每次會議結束前，可以用四個問題進行檢查。

1. 今天決定了什麼？

例如確認首頁採用 A 版設計，如果尚未決定，也應清楚記錄原因。

2. 接下來要做什麼？

例如設計師需要完成手機版畫面，工程師需要確認會員登入流程，工作內容應具體到可以判斷是否完成。

3. 每項工作要誰負責？

每項工作都應指定明確負責人，不要只寫「設計部門處理」，最好直接指定負責窗口。

4. 什麼時候完成？

沒有期限的待辦事項，很容易被其他工作取代，但期限也應經過合理評估，而不是由 PM 單方面決定，最好在會議上就安排好下次各項工作回報的時間。

例如：「設計師將於本週三下午五點前提供手機版首頁，行銷主管將於本週四中午前完成確認。」這樣的紀錄比「請大家盡快處理」更容易追蹤。

如果工作已經延誤，PM 應該怎麼追蹤？

當任務沒有如期完成，直接詢問「為什麼還沒做好？」不一定能幫助專案往前推進；更有效的方式，是先了解阻礙。

例如：「原本預計今天完成的商品資料，目前還有哪些部分尚未確認，或是否需要其他部門協助呢？」

接著再確認下一步：

• 如果問題出在資料不足，就協調提供資料的人
• 如果問題出在工作量超過預期，就重新評估時程
• 如果問題出在決策尚未完成，就找出有權決定的人

要適時追蹤進度，不要天天不斷催促；專案追蹤的目的，是及早發現可能影響交付的問題。

如果 PM 每天只是詢問「完成了嗎」，卻沒有協助排除障礙，團隊可能只會感受到壓力；相反地，當 PM 能協助確認需求、整合資訊與取得決策，團隊就比較容易將時間投入實際工作。

RACI 不是萬能工具，使用時要避免三個錯誤

第一個錯誤，是將所有工作都拆得過於細碎。

如果連回覆一封普通信件都需要建立責任矩陣，反而增加管理成本，RACI 比較適合用於跨部門合作、權責容易混淆，或影響重要交付成果的任務。

第二個錯誤，是只有表格，沒有實際溝通。

即使 PM 已經建立完整矩陣，也應讓相關人員確認自己理解並接受的責任。

第三個錯誤，是專案開始後就不再更新。

當組織人員、專案範圍或決策權限改變時，責任矩陣也應該即時修正調整。

專案推不動，有時不是執行力問題，而是責任沒有說清楚

當專案進度停滯，我們很容易認為團隊缺乏效率，但真正的原因可能是責任分工不明確、決策權分散，或工作完成標準沒有取得共識。

RACI 提供了一種簡單的方法，協助團隊釐清角色與責任，搭配明確的會議結論、工作期限及進度追蹤，就能讓跨部門合作更有方向。

好的 PM 不是自己跳下去埋頭苦幹完成每項工作，應該是要確保重要任務都有清楚的負責人、決策者與下一步。