最近不約而同的收到幾位 PM（Project Manager）來詢問在實務上遭遇的疑難雜事，多半都與人相關，我回答起來，也幾乎多不是工具和知識架構所能解決的問題。

是的，一個優秀的 PM 除了搞清楚專案本質，以及 WBS、資源、利害關係人……這些重要大事之外，還有幾項隱而不顯卻非常重要的「內部」工作，而這些事情還通常都沒人教。

1. 盡早把遊戲規則談清楚

首先，我要強調三次：愈早愈好、愈早愈好、愈早愈好，等你出事再來訂規則，不但效果不好，還會變成團隊的怨氣標靶。（出事時都要忙死了，還要應付 PM 新搞出來的規則，有事嗎？）

1.1 談清楚「會議規則」：專案會議怎麼開？哪些人需要參加？多久開一次？主要討論的內容是什麼？報告格式長怎樣？每一次的主持人、紀錄是誰？如果誰不能來，那麼他必須請代理人來參加嗎？

如果可以，最好在專案初期就先 Booking 好團隊或其他重要利害關係人的會議時間。

才不會等你想到這件事的時候，大家的時間都「剛好」湊不到一起，不是東缺一個西缺一個，就是會議根本無法順利展開，而且到時候才約時間，凡是一開始沒有先講好的，團隊絕對會認為是多出來的工作，得花上數倍的心力，還吃力不討好。

1.2 談清楚「範疇管理規則」：若有人發現不在專案範疇內的工作或任務，要怎麼回報？怎麼處理？有沒有統一評估的窗口？或者要怎麼在第一時間統一說法回覆客戶？

1.3 共識「假勤規則」：雖然在台灣，大多數的 PM 在跨矩陣組織中，都沒有團隊准假的實際審核權力，但與其怨天尤人，還不如先和團隊共識好，發生什麼狀況的時候，大家可能要暫時延後休假？哪些人和哪些人盡可能不要一起休假？

1.4 共識「代理制度」：專案內的代理人制度要如何運作？誰是誰的當然補位人選？

2. 決定權責結構

2.1 決定「客戶問題處理權責」：客訴發生的時候，誰是第一線？誰統一處理和回覆？不要到時候訊息大亂，每個人回給客戶的都是不一樣的答案，造成更大的麻煩和危機。

2.2 決定「內部執行規範權責」：（以軟體舉例）內部的開發或設計規範，要遵照什麼標準？誰有權限可以去調整和異動？不在這個規範當中的事情，由誰來負責拍板和決定 。所以我認真說，PM 絕對不應該是外行人，就算當下還少了團隊的專業，也要盡快的利用時間能補多少是多少。

2.3 決定「專案變動通報權責」：團隊如果預期專案可能要 Delay 或超支，什麼情況下必須主動通報？多少比例之內由誰來決定？多少比例之外要到誰來處理？

3.定義資料與資訊收集規則

3.1 大家必須要定期回饋哪些資料？多久一次？回饋給誰？

3.2 工作進度回饋的方式？認列進度的方法？特別是難以量化的工作（像是處理客訴、與供應商議價、測試程式等）。要如何認列回報進度的共同原則？

3.3 專案進行過程中，應該要給客人什麼東西？什麼時機點給？

3.4 要不要報專案工時？若要，專案工時的分類結構與定義為何？

3.5 哪些資料不能外流？哪些資料內部和提供給外部必須要是不同版本？

3.6 哪些類型的資訊可以透過 email 通知？哪些請盡量用電話或面談搞定？哪些問題「才」需要 c.c.（副本）給誰？到哪個層級？或是盡可能不要使用「密件副本」，因為很可能不小心沒發現自己是密件副本的收件者，突然跳出來回信，會「有點危險」。

所以，正在火線上的 PM 們，你的 Check List，絕對不會只有 WBS，多半我們能夠容易學到的，是方法和知識架構；而決定你的生存機率的，常常是這些看起來好像是微不足道的小事，但是卻很關鍵的規則。

原文轉貼自：Elva手記（原文連結）