PM絕對不是只會訂便當而已（下）
「專案經理」的二轉之路與專武一覽
還沒看過上一篇的，請走這邊：
本篇會來聊聊 PM 職能在實務上會遇到的問題，以及推薦一些好用的專案管理軟體。
PM 的核心職責與原罪
前一篇聊了這麼多，大家應該可以理解，「專案管理」這件事情，其實是相當專業的一門學問。
所謂的PM（專案經理），最重要的工作其實是：
以自己為中轉站，降低所有人的溝通成本
沒錯，簡單來說就是把自己當成所有人的共用腦來運轉。這也是為何每一場會議 PM 都需要參加的原因。
PM 就像兵團中的斥候（偵察兵）一樣，重點要放在「視野」上。當出現有可能的風險時，第一時間通知所有需要知道的單位。
從上一篇的四大核心來看，PM 的基礎工作其實包括：
1.知道不同職能的溝通方式，並且只同步必要資訊的給對應人員，避免干擾成員的工作。
2.理解哪些工作會有「依賴」（Dependency / Block），或是哪些工作的死線將近，能提前示警並提供調整方案。
3.清楚專案的方向，理解工作的優先級標準，提供團隊在全力運轉時的工作 順序。
4.能在專案運作過程中，找出可能會有疏失的節點，利用工具或驗收排程，來降低出錯風險。
上面這些，就是一位專業的 PM 應該要有的能力。
但為什麼，這類工作總是給人一種吃力不討好的感覺？
其實是因為，最難的地方在於
PM 需要有管理思維，卻沒有決策權。
Project Manager 職稱內有 Manager，但其實 PM 並不是管理職。
即便需把自己的腦容量貢獻出來給團隊當作計算機，PM 並沒有決策的權力。（各職能成員的績效評估仍然是各領域主管給出，而非是 PM 來做決定）
所以才會常常出現把團隊其他人得罪光光，但專案 Delay 卻又要算到自己頭上的悲慘後果，或是跟 HR 一樣，容易陷入「冒名頂替症候群」等困境……
這也是為什麼有人戲稱 PM 是高級助理（高階打雜）的原因了。
PM 的生存悖論
PM 對專案運作而言是不可或缺的存在，但往往整個專案不會太過於注重 PM 這個職能的權力和發揮效用，主要是因為這個職能的定位是存在矛盾的，包括：
- PM 的工作量是漸進且無法預支或推遲的，必須要跟著專案走。換句話說，就是無法藉由加班來增加產出。這個特性往往會導致在其他職能眼裡，PM 變成類似應援團的角色，在團隊陷入忙碌時，很難做出貢獻。反過來說，團隊空閒時也不見得會降低工作量。
- 和企劃產能或是 UX 設計一樣，PM 的工作產出是難以被量化的。沒有阻礙的時候大家不認為是 PM 的功勞（因為太順暢沒有感覺），但出現阻礙的時候往往是 PM 的責任。
- PM 往往希望「讓團隊內所有人」都對專案管理有一定程度的了解，以此讓專案運作的更為順利，也可以降低 PM 的工作量，但這麼做反而會「讓專案對 PM 的需求下降」。
最終，沒有 PM 或者不需要 PM 的團隊，會演變成幾種不同的專案型態：
1.由 QA 作為製程推進的最終單位
這常見於各大博奕遊戲公司中，因為產品的穩定性（例如金流）往往是最重要、優先級最高的目標之一。
因此會演變成 QA 對產品最終表現負責，而研發團隊對 QA 負責，整個產品的製程由 QA 來推動的神奇現象。
2.由職能主管共同分擔 PM 工作
不需要 PM 的團隊，往往是小團隊，或是習慣了小規模、敏捷迭代開發的製程，由製作人或是總監定下每個週期迭代的大目標，由各自職能拆解（Break Down）並實現目標（註一），最終這些專案管理的工作，會被職能主管們吸收掉。
3.由業務職能（或Project發起人）兼職 PM 工作
在部份行業中，也是有由業務職能發起一個Case，推動整個製程的例子。這在軟體研發行業中也不算少見。
由業務直接從外部獲得業主的需求，然後回到內部進行工作安排。如果公司規模較小，就可以不需要專職 PM 協助，這部份工作直接由業務吸收。
註一Break Down 在研發工作中是很重要的能力。以筆者自己參與的專案來說，每兩週（一個Sprint，或稱為迭代）要確認目標，並且由程式、美術和企劃主管將工作拆細，指派給團隊成員進行實做。
因此專案管理的工作大部分由主管們開會吸收，對專職的 PM 需求就比較小了。
講到這裡，聽起來好像有點絕望，PM 究竟存在的價值是什麼，又應該把什麼當作職涯目標而努力呢？
PM 的自我修養
上面講這麼多，並不是要證明 PM 沒有存在的必要（畢竟如果專案管理不重要，那筆者前一篇文章就是在寫心酸的），而是要說明 PM 這個職能如果只做訊息同步或會議記錄等工作，實際上被替代的可能性是很高的。
這時我們就要回過頭來看看 PM 的工作本質是什麼了，或者應該說，「專案管理」的本質，而這點其實前一篇就有提到：
將產品以足夠好的品質，在時間限制內完成。
沒錯，這是專案管理的目的所在。
而 PM 的基礎工作，只是實現「專案管理」的「其中數種方法」而已。但專案管理不能只有 PM 出力，實際上，應該要由整個團隊共同負擔。
因此 PM 的首要目標，是教導團隊製程與協作的方法，而不是讓自己成為那個方法。
一個好的團隊，可以不需要 PM 而獨立運作。
有讀者可能會問，那 PM 存在的意義到底是什麼？存在的目的難道是消滅自己嗎？
PM 存在的目的，是幫助團隊更有效率的運作，而非成為團隊不可或缺的存在。
PM 是乘法。
要做的不是取代原本的基值，而是讓基值損耗降低，或是提高乘法的倍率。
如果身為 PM，想讓自己變成團隊中不可或缺的一員，那麼會過得非常辛苦，和同事之間的關係也會變得緊繃。
這邊列出一些比較重要的觀念，讓各位在專案管理的道路上不至於太想死......喔不是，不至於太挫折。
- 理解做事的分寸
包含「自身的責任範圍」與「付出努力的上限」。
PM 沒有決策權，因此也不需要背負產品的責任，PM 的工作是確保所有人知道該知道的訊息，避免製程上的雷點。
但產品 Delay 做不出來，大家要加班爆炸絕對不是 PM 的責任，因為無論時程安排做的再好，有些事情會爆炸就是會爆炸的。 - 把「最終團隊不再需要我」作為中長期目標
如同上面所說的，PM 需要教導團隊成員更多製程和管理上的知識（當然，不要朝令夕改讓他們覺得你在故意衝康），盡量把「團隊能脫離 PM 獨立運作」當成一個目標。 - 理解 PM「 不應該一直待在同一個專案內」
承上所述，實際上 PM 最大的價值與專業能力，會展現在「建立製程」和「優化製程」的階段，但對於已經穩定的專案或產線，工作難度下降，也代表該是時候換換跑道了。建制的經驗積累越多，對 PM 職涯發展絕對是百利而無一害。相反的，在同一個專案待到終老，也許並不是一個最好的選擇。 - 理解 PM 這個職能對自己的最大價值
實際上，PM 這個位置能積累的最大價值，是「經驗」，尤其是一個領域內製程的經驗。
「天天都在開會和整理資料」聽起來好像沒什麼技術含量，但如果理解為「參與並了解一個專案從立項到上線的所有製程細節」，瞬間就變得很厲害了對吧？
PM 真正的價值，實際上正是深度參與和經驗積累，筆者見過很多研發 PM 做久了，直接轉做製作人或是營運發行的例子。（另一個角度想，以遊戲研發來說，整個專案中，大概也就只有 PM 或主企劃看到的視野會比較貼近製作人。） - PM 同時也是職場的「學士學程」
不知道大家對大學中的「學士學程」有沒有印象？那是一個專門給會讀書、但不是很清楚自己興趣的學生選擇的科系。
學生可以在大學第一年盡量體驗各科系的課程，然後留待大二才做決定。
PM 就有點像是這樣的存在，什麼技能專長都沒有，實際上就意味著有更多的可能性。（更何況在專案中，以 PM 的名義，兼職或嘗試其他職能，遠比你什麼都沒有要應徵上一個特定的職位來的容易很多）
筆者也有些朋友是 PM 轉企劃或工程師，都是在職場中積累經驗，確認興趣後才決定轉換跑道的例子。（註二）
註二PM 能轉換的跑道，或是升職的方向其實很多，包括：1.更貼近市場面：產品經理（Product Manager）、營運銷售，或是商務、業務相關。
2.更貼近產品面：產品經理、製作人、UX設計、QA Lead 或是 創意總監。
3.更貼近管理面：部門主管（部門負責）、專案組長（專案負責）或是管理顧問等。除此以外，所有在 PM 工作中接觸到的團隊成員，都是你可以請教和轉換跑道的目標（當然不要讓他們覺得你在騎驢找馬就是了）。
PM 核心能力
「知識儲備和記憶力」以及「邏輯」是PM最重要的核心能力。管理相關學歷出來的新人，往往因為「知識儲備」不足，在職場上很難說服其他人，或是在經驗上因為對製程的不熟悉，做出錯誤判斷。
「信用」是前兩者體現後的積累，也需要時間才能養成。
而 PM 的專業，需要前三者共有才能體現，也就是「知識儲備」、「邏輯」和「團隊內的信用」。
在完全陌生的領域擔任 PM ，前期最好能多花時間了解產業基本知識，「多聽少說」才是最保險的。
等對整個產業狀態比較理解，也取得同事的基本信任後，再來優化製程才不會困難重重。
要記得：「沒有誰有義務要聽 PM 的指揮」，在沒有實際決策權時，這很重要。
「專案管理」是所有研發管理職的必修
這點算是筆者自己這幾年來的體悟。
簡單來說：
不熟悉產業製程，或是沒有專案管理經驗的管理職，是一場「災難」。
恩對，筆者可以很果斷的這樣說。
「專案管理」可以說是所有管理職的前置技能（註三），退一萬步來說，「自我管理」如果都很勉強的話，管理其他人一定就是災難 XD。
專案管理要做的好，需要迫使管理者把視野拉到「整個專案」的層級，而非只是自己的工作領域範圍。
例如以遊戲研發來說，美術職能在產出資源的同時，也應該要關注企劃需求和規格書的進度，以及程式何時要接入功能。如果只關注自己負責的領域，協作時肯定不會順利的。
這部份留待未來分享管理經驗的文章再來細談。
註三也有看過一些公司會把 PM 這個位置會留給儲備幹部或是儲備製作人，經過這個職位的訓練，擔任管理職會更為順利。
額外補充：專案管理工具推薦
說實在，以軟體或遊戲研發來說，專案管理工具都長的大同小異，付費功能也都差不多。
但非常建議專職 PM 至少要「精通」一款，要能夠作到客製化製程的程度。畢竟每個專案的情況都不一樣，有預算的情況下，能用管理工具解決的事情就用工具解決。
以下推薦幾款筆者有用過或是朋友推薦的工具：
Trello
這款工具筆者在另一篇文章「身為企劃，隨身帶著XX也是很合理的吧？」中有提到過。
基本上就是便利貼板，大部分的專案管理都是以模擬便利貼，方便紀錄和挪動小紙條作為原型設計的。
付費後額外提供自動轉單、多開不同的板子（Board）等等功能。
Asana
目前筆者參與的專案，使用的就是這款管理工具。
老實說，用起來跟Trello或Jira差不多。
優點是最低額度的付費帳號可以開通時間流甘特圖（Roadmap），將工作單以進度條的形式顯示在時間河道上，方便用連線的方式展現依存關係（Dependency）。
付費功能包括Roadmap、自動轉單、導入Atlassian工具等等。
參考資料
Jira
目前應該仍然是大型團隊比較喜歡的管理工具。彈性最大，但價位也是最貴的。
和Trello一樣被Atlassian公司買下來了。
付費一樣支持 Roadmap 功能，自動轉單等等。
比較重要的是筆者之前在協助建制 Jira 專案時，研究了一下這款工具的 Workflow 自定義功能，非常強大，可以自行編寫腳本，讓工作單依照各種條件轉單、切換狀態。
例如可以定義 Bug 單只能由 QA 職能開出，開出後會自動轉給企劃，企劃手動轉給對應的程式後，程式修復完成會自動轉回給企劃驗證，最後再自動轉給 QA 做復驗和追蹤。這讓整個專案製程變得非常方便，省下很多溝通時間。
另外，針對不希望機密外洩的公司來說，Jira 公司也提供建制服務，業主可以直接在本地端架設內往用的 Jira 環境，保證資料不外流。
ClickUp
這款算是比較新的管理工具，除了上述的功能之外，還有內建例如「工作時間追蹤」等功能（Time Tracking），搭配一些插件甚至可以紀錄工程師在工作上究竟實際上花了多少時間。（對某些公司而言 KPI 可以用這個計算）
參考資料
P.S.這篇文章是ClickUp整理的，所以其實目的是為了展示自家產品有多厲害XD，作為參考就好。
寫在最後
寫完這篇，筆者還要回過頭來檢查一下有沒有什麼地方的用語太過偏激，因為目前筆者在專案中就是兼職 PM 的角色，雖然不是第一次了，但在這種情況下寫出來的東西，比較容易有失中立（笑）。
PM 確實是個吃力不討好的職位，但只要抱持著正確的態度，這個職位所能回饋你的經驗值也可以是非常豐厚的。
那麼，今天就先到這邊。
我是水狼，我們下次見。
