PRINCE2專案管理第三課：用「明確定義角色和職責」揪出不想扛責的人

這是 PRINCE2 專案管理方法論介紹系列的第四篇文章。（如果你還沒看過前面的文章，強烈建議你在閱讀完這篇後，回頭去補足專案管理的基本功喔！）

今天，我們要來聊聊 PRINCE2 方法論的第三項原則：「明確定義角色和職責」。

身為一位專案經理（PM），或是正準備踏入這個火坑……喔不，這個領域的你，這項原則對你到底有什麼意義？如果在專案中不去理會這件事，會有什麼下場？

簡單來說：在管理專案時，千萬別害怕把醜話說在前面、去把權責討論清楚。因為在權責不明的專案裡，一旦發展不順，最後被迫「背鍋受難」的，往往都是 PM 自己。

在深入探討之前，讓我們先來了解這項原則的核心。

原則三：明確定義角色和職責

一個專案要能順利推進，絕對離不開「人」。但專案裡的人，通常來自不同的企業、部門或背景，每個人心中盤算的目標和利益都不盡相同。如果要把這群人捏合成一個團隊、通力合作達成目標，「明確為每一組人定義角色與職責」就是生死攸關的大事。

這就好像一間公司，每個人都被分配到不同的部門，每個部門都有明確的KPI和日常工作。專案也是一樣的，它就像一家臨時成立的新創公司，需要各路人馬各司其職、互相配合，才有可能迎來成功。

為什麼本地職場這麼怕「明確定義」？

這項原則的核心，就在於「明確定義」這四個字。但在真實的職場環境中，大家似乎都很害怕把職責劃分得太清楚。也許是為了「以和為貴」，也許是怕破壞氣氛，很多 PM 總是避諱去談誰該負責什麼。

所謂的明確定義，意思是：讓參與專案的每一組人，先清楚自己在這個專案中的「定位」，接著了解這個定位該負起的「責任」，最後知道他們實際上必須產出的「工作結果」是什麼。

如果角色和職責含糊不清，專案管理必然走向混亂。

每個專案都是獨一無二的，規模大小會決定角色的細緻度。在小專案裡，一個人可能要身兼數職（校長兼撞鐘）；但在大型專案中，角色就會切分得很細，以降低單一個人的負擔。

以我熟悉的軟體開發專案為例：

• 用戶端（使用者）：他們的主要職責是介紹業務流程、提出系統需求、確認方案內容是否符合期望，以及最後的系統測試驗收。

• 業務分析師（BA）：負責記錄需求、編寫業務流程文件、與用戶確認系統方案等。

試想一下，如果在專案一開始沒有先確認好權責，有一天你身為 PM，發現「系統需求」遲遲沒人確認。你想去追究責任時，才發現原來所有參與者「都不知道需求到底是誰負責拍板決策」。這種連誰說了算都不知道的專案，真的能順利走到終點嗎？

此外，專案人員是會流動的，尤其是長期專案，人員進出更是家常便飯。對新加入的成員來說，如果沒有一份明確的職責列表，他根本不知道自己在這個坑裡該做什麼。

慶幸的是，在 PRINCE2 的框架中，已經為我們清晰列出了專案中最重要的角色及職責。例如：專案管理委員會、專案主管、用戶代表、供應商代表、PM、交付小組經理、專案保證、變更管理組織、專案支援等。

以「用戶代表」為例，PRINCE2 規定他們需要履行以下職責：

• 提供用戶對品質的期望，並定義驗收標準。

• 確保對期望的成果做出具體的規定。

• 確保專案產出的東西能夠滿足用戶需求。

• ……等等。

有了這份列表，PM 就可以拿著它去向相關人員說明，讓他們知道自己在專案中該做出哪些貢獻。

比「告知職責」更重要的，是「說明如何履責」

然而，光是把職責清單唸給對方聽是沒有意義的。對當事人來說，那些字眼太空泛了。

PM 更重要的任務是：在一開始，就要讓對方明白「履行職責的具體方式」是什麼。

舉例來說，當用戶代表的職責是「提供品質期望和驗收標準」時，這到底意味著什麼？是他必須親自去收集所有基層使用者的需求，然後整理給開發團隊？還是他只要在關鍵會議上，引導相關使用者發言，最後再由他帶頭和大家共同簽署驗收標準？

PM 必須打破空泛的描述，把「責任」轉化為「具體的行動想像」。畢竟，沒人聽得懂什麼叫作「確保對期望的成果做出具體的規定」，但如果你告訴他：「下週三開會時，你需要決定這個按鈕要放在左邊還是右邊，並在會議記錄上簽字」，他就完全明白了。

當然，把職責攤在陽光下，一定會遇到阻力。

最棘手的狀況，通常是客戶端的高階主管不願意承擔責任。我曾經帶過一個專案，客戶端的「用戶代表」非常抗拒確認需求。說穿了，他就是不想「簽字畫押」——他怕自己簽了名，結果系統做出來後基層員工不滿意，他就會被夾在基層和開發團隊中間裡外不是人。

我非常理解他的擔憂。為了推進專案，我選擇了靈活變通：我將「確認需求」的職責轉移到最終的基層使用者身上，並且更改了專案的執行方式。我們不再要求厚重的需求文件簽核，而是改為「快速產出原型、直接展示實際畫面」，並透過會議記錄讓基層使用者自己確認這是不是他們要的。

回過頭來看，為什麼這個專案最後能得救？正是因為我在專案「初期」，就試圖去明確他的職責。這個動作逼出了他的真實想法（不想背鍋）。明確定義職責，不是強迫別人接受他不想要的任務，而是像照妖鏡一樣，幫 PM 提早找出「誰其實不願意負責」。提早發現，我們才能提早調整角色配置（把確認權轉移給基層），而不是等到系統做完、要驗收時，才發現根本沒人願意簽字。

只談角色名稱、不談具體職責，是 PM 的失職

我觀察到，其實很少有 PM 會完全不建立專案組織圖。大家通常都會畫出一個基本的架構，並在每個格子裡填上某個人的名字（例如：A是設計師、B是用戶）。

但最大的問題在於：PM 沒有把這些格子的「職責」定義清楚。

很多 PM 習慣性地「預設」對方知道自己該做什麼。如果某個人被分配為「用戶」，PM 就預設對方懂得主動提需求、主動測試。但事實上，那個人的真實心態往往是「被動應對」——沒有明確的指令，我就只是掛個名、待命而已。

要注意的是，即便在同一家公司裡，職稱相同的人，做的事情也未必一樣。比如有些系統架構師要親自寫程式碼，有些測試工程師還要兼做售後客服。在相對穩定的企業裡都是如此了，何況是充滿變動的專案環境？

不去實踐這項原則的 PM，最大的特徵就是：「只談角色，避談職責」。

開會時，只跟工程師說「你負責交付」，卻不講清楚該交付什麼、標準在哪；只跟客戶說「你是用戶」，卻不告訴他何時該測試、何時該簽字。

如果不講清楚，專案的成敗就只能「賭人品」了。如果運氣好，遇到的人都很積極主動、願意多做份外之事，專案可能會成功；但只要團隊裡有人不主動，甚至喜歡推卸責任，專案出包的機率就會直線飆升。

試想這個經典的災難場景：

當用戶在測試系統時，發現功能東缺西漏，氣得跳腳指責開發團隊；開發團隊也不甘示弱，反嗆用戶當初根本沒把業務邏輯講清楚。而擔任變更管理的客戶端主管，為了平息下屬的怒火，無腦同意所有的系統修改要求。最後，開發團隊只能含淚加班硬幹，或者直接放棄治療、讓專案徹底爛尾。

沒有明確劃分職責，在專案實施的過程中，各方人馬就會開始瘋狂推諉卸責。而在這個互相指責的混亂場面中，你猜最後大老闆或客戶高層會找誰開刀？沒錯，就是 PM！

客戶會說：「你當初怎麼沒把我們的需求記錄清楚？」

開發團隊會抱怨：「PM 怎麼不擋下那些不合理的變更？」

大老闆會把你叫進辦公室痛罵：「專案管成這樣，你這 PM 到底在幹嘛？」

看到了嗎？當初為了「以和為貴」不去把權責劃分清楚的 PM，最後反而成了各方勢力的出氣筒。沒有白紙黑字的職責劃分，PM 連替自己辯護的武器都沒有，只能含淚吞下這個超級大黑鍋。

後記：保護自己，從醜話說在前面開始

其實，身為 PM，你大可以不理會這項原則。就算團隊成員都不清楚自己該做什麼，你或許也能靠著過人的個人魅力、威脅利誘，或是燃燒自己的肝，以一己之力扛起整個專案。

但是，PRINCE2 的這項原則，從來就不是為了一帆風順的專案設計的；它是為了應對那些「不怎麼合作」的專案參與者而存在的。

如果團隊成員不想盡責，出包時只會指責別人，身為 PM 的你該如何自保與管理？

你可以選擇無視這些原則，繼續靠運氣推進專案，然後在夜深人靜時大吐苦水、抱怨自己命苦；你也可以選擇按照這項原則，在專案一開始就「先小人後君子」，把各人的責任白紙黑字釐清，並確認對方的執行方式。

當對方不願意履行時，你才有依據去改變責任分配，或是向上呈報，讓高層來決定責任歸屬，而不是自己把苦水吞下肚。

我知道，要在一開始就跟大老闆或強勢的客戶談「責任」，很多人會覺得難以開口，怕氣氛弄得很僵。

其實，你不需要用命令的口吻。你可以試著用「保護專案」與「尋求協助」的角度來溝通。例如：

「王副總，為了確保這個系統最後做出來完全符合您的期望，不浪費您寶貴的時間，專案期間能不能麻煩您在每個關鍵節點（如需求訪談、畫面確認）擔任最終決策者？具體來說，大概每兩週需要您花半小時看一下進度並確認。這樣我們開發才不會走偏，您看這樣安排好嗎？」

用「賦能」與「確認期待」的包裝，去落實「明確定義職責」的本質。把醜話包裝成專業的建議，才是高段班 PM 的生存之道。

勇敢地去討論角色與職責吧！只有這樣，你的專案之路，才能少揹幾個黑鍋，走得更長、更遠。