PM絕對不是只會訂便當而已（上）
來聊聊這些年我所認知的「專案管理」
前言
「專案管理」這件事情，一向是軟體研發或遊戲開發相關產業常聽到的名詞，衍生的還包括「版本控管」（註一）和「資源/資料控管」等等議題。
在業內，提到所謂 PM（Project Manager）（註二）的時候，有時也會打趣的以「就只是負責訂便當」之類的諷刺一下。（遊戲業或IT業尤其嚴重）
但 PM 真的就只是個跑腿職位嗎？專案管理究竟是怎麼個管理法呢？
這次分上下兩篇來談，上篇聊聊管理的本質，下篇再談談「專案經理」這個職位在實務上會遇到的困難。
廢話不多說，讓我們開始吧！
註一關於「版本控管」，可以參考筆者的另一篇文章：
遊戲企劃必修課：來聊聊「版本管理」註二常見的PM有兩種簡稱，一個是產品經理(Product Manager)，另一個是專案經理(Project Manager)。本篇介紹的是後者。其餘的類型可以參考底下的延伸閱讀。
延伸閱讀
專案管理的本質
所謂的「專案管理」，其實目的只有一個。
將產品以足夠好的品質，在時間限制內完成。
簡單來說，就是在死線前交出考卷，然後還要及格才行。
為了達到這個目標，管理者需要能夠讓專案內每個人都了解到自己該做什麼，該做到哪種程度，以及哪些事情要優先完成。
專案管理的價值，會根據團隊成員的數量逐漸提昇。
對小團隊而言，也許不需要太多管理流程或輔助工具，但一旦規模提昇（例如數十人或百人團隊），讓所有人都能「朝著同一個目標努力」其實真的不是一見容易的事。
細分的話，可以把「專案管理」這件事情拆成四個層面：
- 資訊同步
這裡指的是資訊的傳達與同步。針對不同部門與職能，哪些資訊需要傳達，哪些不用，確保該知道的人收到資訊，避免不需要知道的人因為過多的資訊而混亂，這是把控資訊同步程度的重點。 - 阻礙排除
所謂阻礙排除，就是針對所有的工作內容，做前置項目確認與順序調整，避免任何工作因為各種原因導致延宕。 - 優先定序
讓專案內每個職能都知道工作內容的優先程度，除了可以自行運轉消化工作外，也能讓所有人對當期版本的目標和想像趨於一致。 - 避免疏漏
人無完人，在做重複性或大量工作時，沒有檢查難免會有疏漏，除了 QAQC 職能可以協助產品驗測之外，製程上的工具和 SOP，可以協助避免很多人為錯誤。
其實所有的「專案管理工具」，都是為了強化這四個核心而存在的。
在細聊上面這四個主題之前，我們先來聊聊「溝通」是什麼。
什麼是「溝通」？
在語義學上，語言之所以能達成溝通，其實是這樣的：
溝通雙方對使用的語言或符號，達成「共識」
打個比方來說
A今天說「杯子」。
B聽到之後，腦海中根據記憶提取出定義區域，形成「是杯子」的區域和「不是杯子」的區域。
A和 B對於「是杯子」的區域定義，要盡可能的趨於「一致」，這樣才不會產生誤解（註三），也就是雙方認知不一致的情況。
當雙方達成共識時，有效的「溝通」就完成了。
人類對世間萬物的定義都是由貼標籤開始的，藉由「東西不屬於『某個概念』」，我們能夠將所有的物件都做分類。
然後藉著這個分類，人類才能「溝通」。
也因此，「團隊所有成員的高度共識」是所有管理人員的核心追求。
註三關於「誤解」這部份，可以參考筆者另一篇文章：
遊戲企劃必修課：如何做好遊戲的UX設計？
專案管理核心一-資訊同步
專案管理的第一個要點，就是將資訊同步給專案內的成員。
光是「傳遞」這一點，就有很深的學問在裡面。
例如
- 團隊內有哪些成員需要知道這則資訊？
有些時候，不是「所有人都需要知道所有的資訊」。
舉例來說，在遊戲研發中，「一隻角色的裝甲顏色要做調整」，這件事情，需要知道的僅包括「角色設計相關職能」與「敘事包裝的決策者」。
工程師或是數值企劃不需要被這樣的訊息干擾。 - 他們需要知道的「資訊詳細程度」為何？
即便是需要知道的成員，對消息的詳細程度需求也是有差異的。
例如若是要在全體成員的聊天頻道提醒大家下午兩點有個會議，只需要附上時間、地點、會議主題和與會人士即可，不需要詳細到會議內容和議題，或是附上一大堆的參考連結網址。 - 資訊是否有「時效性」？
大部分工作上的資訊都是有時效性的，只是時間長短差異。
短時間內需要被同步的資訊，在PM的工作清單內就要被拉到很高。
例如會議時間臨時調整，就需要在會議開始前同步給原本要參加會議的人，避免他們因為不知道這件事情而傻傻的在會議室裡等人到齊。 - 資訊的重要性如何？是否需要「確保被得知」？
承上一點，有些資訊，PM必須確保「該知道的人確實有接收到」，不能只是傳個訊息而已，工作上一忙很可能就會錯過。
如果擔心漏看或是對方忘記，甚至可能要用多個管道、同步多次來確保對方有收到。
這相當考驗PM對每個成員的了解程度與互動的分寸拿捏。 - 資訊是否有被誤解的可能？
對跨職能領域而言，「既定術語」是相當容易被誤解的。
例如企劃所謂的「斷線重連」功能，常常指的是營運類連線遊戲，關閉重開後恢復遊戲進度的功能，但程式所謂的「斷線重連」，僅僅只是Client和Server之間連線斷開後重新連線的功能，筆者待過的專案就曾經因為這個術語的關係導致協作上有誤會。
在傳遞消息給不同部門和職能的時候，需要特別留意這點。
因此產業知識儲備對PM的工作來說也相當重要。
資訊傳遞這個核心技能上，很多是需要拿捏「分寸」的。
環境和公司文化的差異，導致這些東西很難被系統性的量化或傳承，在一個專案的經驗，往往很難被直接套用在另一個專案上。
這也造成 PM 這個工作崗位需要更多的彈性和自我迭代的能力。
專案管理核心二-障礙排除
為了讓專案每一個成員都能沒有後顧之憂的衝進度，「排除障礙」就是非常重要的工作。
工作項目的前置條件是一種阻礙。
死線是一種阻礙。
成員出缺勤可能是一種阻礙。
外包返回的時程也是一種阻礙。
可能的Delay更是一種阻礙
所有可能會拖慢或阻擋團隊成員工作的事物，都會是一種阻礙。
PM 就像是掃雷兵，需要提前發現這些潛在的風險和障礙。
這些包括
- 個別工作是否有相依性？
工作是否有前置條件或順序性，如果A工作沒有完成，B工作就沒辦法開始的話，我們就稱A工作Block（阻擋）了B工作。
在工作安排時，需要按照順序來指派，不然就會導致明明應該開始的工作卻無法進行。
以遊戲公司舉例，企劃要先有「功能企劃案」，交付給美術成員製作「美術資源」後，才能讓程式「帶入介面或製作實際功能」。 - 時程安排是否有衝突？
例如公司可以同時間安排複數個會議，但同一個人沒辦法出現在兩個地點。如果有重疊的與會人員，會議的安排就應該要錯開。（雖然大部分的中小型團隊沒這個困擾就是了）
除此以外，人員的出缺勤（例如請假）也都會影響時程安排。 - 是否有安排容錯空間？
如果每一件工作都安排的環環相扣，當其中一個環節出了問題，後面一整系列的工作都將無法進行。
因此在環節之間填入容錯空間就變得相當重要。
例如在遊戲公司中，UI製作（美術工作）和UI帶入（程式工作）之間，至少要間隔數天到一週，以免美術Delay時，整條程式工作線都受到影響。
這也是為什麼遊戲公司十分強調企劃和美術先行（進度比程式快1～2個週期），正是為了確保容錯空間。
「提前認知到障礙」以及「預測可能出現的障礙」，並調整工作安排來預防，更重要的是要有危機處理能力。
這些都是專案管理非常重要的技能。
專案管理核心三-優先定序
在專案管理中，判斷「哪些工作要優先做」這件事情非常重要。
舉凡「向投資人彙報」、「遊戲上線營運」或是「版本更新維修」等等，總有重要和不重要的事情。
如何分辨優先級也是專案管理的核心能力。
上面這張圖應該很多人看過，也有很多專案管理會拿來說明優先級。
利用「重要性」和「急迫性」這兩個要素，把工作劃分為四種類型。
- 重要且緊急
就是第一優先，例如營運開服前發現的惡性Bug，包含版本運行會有閃退或阻礙問題、玩家可以免費獲得大量資源等。
這些事情必需要優先處理，不然死線一到馬上就爆炸。 - 不重要但緊急
很多人比較常疑惑的是這個區域的工作，為何不重要的工作也可以「緊急」呢？
其實就是「在時間段內必須處理，但其實不做也沒關係」的事情。
例如以遊戲研發舉例：「某次短期營運活動中說明文字出現錯字」。
這個錯字在活動結束後玩家就看不見了，且不修復也不會造成玩家誤解。此時這個問題就是「不重要但緊急」的事情，因為現在不修以後也不需要修了。 - 重要，不緊急
重要但不緊急，其實就是死線離你比較遠而已。遲早都是要做完的事情。
例如某個尚未開放的大系統的Bug，或是下個版本需要追加的功能需求。 - 不重要也不緊急
這個區域就是一些優先很低的事情，例如不太影響遊戲體驗的優化、調整某一條道具描述的文字內容讓其更通順，或是微調角色身上某個裝備的外觀等等。
要知道，「急迫」這件事情，其實是跟「死線」夠不夠近有關。
因此，上面這張圖可以再簡化一下：
基本上，就是上面看到的這樣。
- 右上角是一定要做的內容。
- 右下角確認一下重要性，如果不比左上角高，就丟到左下角區域內。
- 最後是左上角的內容。
大概會是這樣的優先定序。
可能有人會疑惑，到底為什麼「優先分級」這件事情這麼重要？
這是因為在實際研發過程中，工作內容永遠都是多過團隊能消耗的範圍的。
因此為了做出取捨，才需要有「哪些工作必須優先執行」的決斷。
如果只是認為死線前全部做完就好的話，只要出現 Delay，產品的品質就很容易不如預期（因為時間都耗費在不重要的事情上）。
專案管理核心四-避免疏漏
正所謂「人無完人」，人類畢竟不是電腦（更何況電腦也有低機率出錯）。
只要是人，就一定會有犯錯的可能。
除了前面提到的，事先留出「容錯」的空間之外，「積極地避免」發生錯誤也是很重要的工作。
在做專案製程管理時，可以思考看看以下的問題。
- 專案運行中，特定區塊是否有可能因為人為疏失導致錯誤發生？
例如遊戲工作中，企劃維護配置表的內容時，大量內容用公式自動生成才能避免手填誤植的問題。 - 這個錯誤影響的層面為何？
錯誤影響的層面大小，也會決定製程是否需要馬上調整。 - 能否用自動化的方式規避，或是用驗收機制降低錯誤機率？
例如讓同職能花一點時間檢查同事們的產出工作（像是 Code Review 就是一種類似的流程），或是讓遊戲在測試服（QA Server）上先做一段時間的測試，通過之後才正式更新給玩家使用等等。 - 回顧以往的運作經驗，是否有什麼問題重複發生且沒有獲得改善？
如果一件事情發生超過三次以上，肯定是某個環節出了問題。「人性」是很不可靠的，單純只是「請大家多多注意提高警覺」，同樣的事情一定會再次發生。
如何建立能自我除錯的流程，和使用輔助工具非常重要。
人性偏好忽略潛在的風險，但專案管理的工作可不能無視這些，只要有風險，就需要提出來討論。
發生的錯誤已經發生，無法挽回，但讓錯誤變成團隊進步的動力，則是專案管理者的責任。
額外補充-專案管理中 Retro 會議的目的
在專案管理的工具中，有一種會議被稱為回顧會/Retro會議，也就是 Retrospective Meeting。
在這個會議中，通常會提出「整個專案運作中需要被改善」的各種議題，然後團隊成員一起討論如何優化這些問題，讓以後的協作更順暢。
舉幾個例子讓大家體會一下：
Q1：這次迭代中，有發生程式工作開始時，美術資源尚未到位的情況，之後該如何避免呢？
A1：管理人員需要提前發現並排除。可以利用甘特圖搭配連線的方式，將會阻礙的工作單串連起來，避免出現被迫空轉的情況。
Q2：上週有遇到企劃這邊在做前期系統規劃時，不確定程式實做的可行性，導致設計出來的系統無法落地，下次遇到類似情況要怎麼處理？
A2：請負責企劃整理一下內容，直接找程式主管安排會議，和未來該功能實做的程式人員直接討論，確定落地方案。
Q3：前幾天同事遇到不可抗力請假，導致專案進度受到不小的影響，有沒有辦法可以降低這部份的風險？
A3：工作的安排需要再多預留一些容錯空間，除此之外每個迭代週期的「高優先」工作內容不能超過 60% ，盡可能爭取更大的緩衝時間。
在敏捷開發中，Retro & Review 環節尤其重要，如果沒辦法連「製程」都持續優化的話，就失去敏捷開發的意義了。
小結
專案管理算是一門非常大的學問，上面這些算是筆者自己一點一點積累的實務方法論，和管理學領域的專業知識體系可能有些差異（請管理專業的讀者們多多包容哈），有興趣的朋友也可以搜尋看看相關內容做些比較。
但無論哪一種管理理論，實踐後才是真正屬於你自己的。理論容易淪為空談，但實戰經驗永遠不嫌多。每個團隊、專案甚至每個人，都有各自適合的管理方式，沒有什麼是一條路走到底不用轉彎的。
下一篇我們會來聊聊 PM（專案經理）這個職位，究竟在實務上會遇到哪些問題，以及一些管理輔助工具的運用。
那今天就先到這邊。
我是水狼，我們下次見。
