近幾年，全世界對於 Startup 的風潮越來越盛，以軟體公司而言，產品經理（Product Manager）、工程師、設計師和行銷人員都是不可或缺的要角，相較之下，專案經理（Project Manager）似乎就不是必要的存在，這篇文章主要探討的是，到底一個好的 Project Manager 的重要性在哪？
有鑒於好友 Benson 寫的一篇相當精彩的文章新創公司中的兩種 PM：Project Manager v.s. Product Manager，每次別人跑來找我討論 PM 工作的時候，我都會反問他們比較想做哪份工作—— Project Manager 還是 Product Manager？通常我都會得到一樣的答案：「恩，Product Manager吧，因為感覺學到比較多，而且感覺比較重要一些。」這答案我也沒打算反駁，不過我必須說，如果各位覺得 Product Manager 是 Project Manager 的老闆的話，那我想這篇文章可以先跳過了，因為這篇文章，不是說給上對下管理的人聽的。
為了避免混淆，以下以 PO（Product Owner）代表 Product Manager ，以 PM 代表 Project Manger
PO 與 PM 的位置
在新創公司裡面，講求角色責任跟水平管理，PO 跟 PM 其實是有共同存在的必要的，PO 講究的是規劃產品策略與營運方向，技術其實只是其中一環，而 PM 講究的是技術方向的確認與如何執行。與其說 PO 跟 PM 是主管與下屬的關係，倒不如說他們專注的面向不同，PO 大多會面對到使用者、客服或是業務端，而 PM 就是面對到工程師、設計師等等的開發執行者，良好的產品開發。仰賴的是 PO 跟 PM 同一個鼻子出氣。
為什麼不把兩個角色放在同一個人身上？
很多新創公司礙於公司人才的問題，會用同一個人來做 PO 與 PM 的綜合體，我必須說，這只是短期的解法，絕對不能是常態，因為 PO 跟 PM 有一個先天本質上的不同，PO 需要顧慮的，是業務端、營運端，所以會歸納需求，甚至發想需求，PO 需要比較業務導向，技術導向的 PO 常常容易賣不動產品。而 PM 剛好相反，PM 需要刪減需求，需要有技術人的個性 — 保守，需要避免工程團隊做沒有用的東西，所以需要規劃 Wireframe 跟 User Story 來讓需求端定義明確，如果這些都不懂的 PM，當然會被工程師嫌到死。
其實好的技術管理，通常都是 PO 跟 PM 吵完架後，才會開出明確的 Spec 給工程團隊去做。如果一個人同時身兼 PO 跟 PM 這兩個職務，很容易搞到他人格分裂，要不然就是太偏技術端被業務討厭，或是太過業務端被工程團隊討厭，不然就是兩邊都不討好。
作為一個好 PM 的不二心法當然就是：『 讓工程師可以專心快樂去寫 code 』。不過，在問這問題之前，我們還是不免來看看現在軟體世代的狀況，現在的軟體世界，講究的是拼湊而非原創，用很多的開源計劃或是第三方的服務就可以做出產品，所以快速的架構通常會比較討喜一些，這也是為什麼 Agile 的理念在近幾年發展得比 Waterfall 更為熱烈的主要原因。
所以作為一個好的 PM，要做的可說是包山包海，因為需求統籌完後，要畫 Wireframe跟做 User Story，做完這兩者後，需要規劃 API 跟資料庫的架構，然後再分派 Ticket 給工程師，這時候可能還要兼著做 Scrum Master，然後工程師開發完還要兼著做產品測試，最後做上架的管理，這些都是 PM 一條龍管理完成了。之後 PM 最重要的工作，其實是把所有過程文件化。很多時候我跟工程師朋友在聊，他們都說在他們公司這些事情都是工程師在做，而沒有請專業的 PM 負責。但事實上，如果這些事情都是工程師做的話，只會有兩個結果：浪費工程師的專業 Coding 技能、每件事情都應付了事（文件寫很爛之類的）。
PM 怎麼做到良好的風險管理？
很多人問我說 PM 是否需要具有超強的技術能力？其實不一定，雖然好的技術管理者在開 Ticket 的時候甚至可以把一些演算的邏輯都寫進去，還可以做 Code Review，不過這種人超級難找，所以能夠把上述的事情做完的 PM，已經算是相當厲害。
我認為真正好的開發管理，是必須要專業分工的，也就是認知 PM 其實是一門專業。而 PM 的專業主要在於做好專案的風險管理，什麼是風險管理？就是當工程師跑不見人或是擺爛的時候，PM 必須要有能力讓傷害減到最低。如果你有跟印度人或是大陸人合作過，就會知道什麼叫做就算正式 hire 也可以隔天跑不見人的感覺。很多人也許無法真正體會風險管理的重要，但是只要被工程師擺過一道的創業人，看到這段恐怕是會痛哭流涕的。
風險管理的目的，最大的目的是讓每一段工作可以階段性的「保留結果」或「告一段落」。舉個例子來說，把 API 規格訂定好後，交給工程師去做，如果原先的工程師功力很差，寫的 Code 架構不好，這時候 PM 能做的事情便是，保留原有 API 規格，把可用的 API 拿來用，再請一組新的工程師去改進那些寫不好的 API，然後再逐個 Review API ，這樣的一個淘汰工程師的過程，既不會影響太多原有的開發進程，也不用怕工程師一個 API 做不好，就要全部砍掉重練，然後整個開發的時程就會因此延誤一到兩個月，錯過一次還好，錯個兩三次恐怕對於一間新創公司來說，已經把資金燒得差不多了。
千萬不要忽略了專案管理的重要性
談專案管理跟談軟體技術開發的專案管理，可能有些不同，尤其對於新創公司，一個良好的技術管理者，絕對比找到一個工程師來得更為重要，也希望大家正視 PM 這個專業，並不是寫程式寫不過工程師才來做 PM 的，PM 處理的很多事情，是很多工程師不願意做的 Dirty Job，但是隨著產品的技術範疇越來越大，這些所謂的 Dirty Job 往往可以救你一命。我不會說 PO 比較不重要，更不會說工程師或是設計師比較不重要，我想說的是，如果你今天真的有心創辦一間公司，請務必搞懂每個工作程序背後的重要，然後讓各種不同專業的人來處理，最後養出的這個環境，才會是公司的核心價值。
＊很高興接受ALPHA Camp的邀請，在 4/16（六） 開始，我將與四位相當厲害的開發者共同開設！
Photo credit via unsplash
