軟體 PM 應具備的十八般武藝（上）
我在科技業已有十幾年的工作經驗，也勉強算是個科技人吧，目前也是在一間老新創僑外資當一位小小的資深 PM。最近由於疫情關係，我身邊有非常多的朋友想換工作，可怕的是，清一色都想轉 PM，但他們根本不清楚 PM 是在幹嘛，也不知道當 PM 需要什麼能力，但就是想做 PM，從業助、業務、RD、服裝設計師到房地產退休的總經理，幾乎各行各業的各個職業都有人想做 PM，讓我瞬間覺得：原來 PM 這麼夯呀！
看著朋友們臉上對 PM 滿滿的綺念，我心中懷著對 PM 滿滿的怨念…說錯了，是正念，今天想要分享一些關於軟體 PM 應該具備的能力，但為了增加一絲絲可參考的可信度，還是要上一點人權說明，請容許我廢話一下我的背景：
曾擔任過資深軟體工程師-簡單來說就是開發 Windows PC 的應用程式、
曾擔任過資深 SI 工程師-簡單來說就是我們常說的 IT 系統整合、
曾擔任過業務部門主管-簡單來說就是跑業務、
曾擔任過 IT 部門主管-簡單來說就是要管 MIS 又要管軟體開發、
後來才開始擔任軟體專案經理(PJM)、軟體產品經理(PDM)、軟體產品部門主管等-簡單來說就是聊聊需求、看看競品、寫寫規格、測測市場等雜七雜八的事情。於科技業的軟體 PM 工作約有近 10 年左右的實務經驗，歷經了台灣科技業 PM 領域的種種有趣面，親身體會到產品管理跟專案管理雖然都叫做 PM，但實際上做的事情還是有些區別。
但是，由於台灣的職場文化跟西方國家有蠻大的差異，通常在台灣我們提到 PM，就是商業分析(BA)也要做、系統分析(SA)也要做、產品管理(PM/PDM)也要做、專案管理(PM / PJM)也要做、產品行銷(PMM)也要做、甚至產品銷售(BD / Sales)也要做，在企業中就是一個超級大雜燴，萬事皆要沾、萬事皆要懂的重要核心人物。以下將從我的軟體 PM 實務經驗中，擷取一些實務精華與大家分享，讓大家能了解身為一個軟體 PM，應該具備哪些能力。
文章將分為（上）（下）篇，本篇文章將先行分享軟體PM應具備的三項關鍵能力：商業分析(Business Analysis)、系統分析(System Analysis)、專案管理(Project Management)
一、商業分析(Business Analysis)
身為一個軟體 PM，應懂得商業分析的手法，以達成下述目標：
1. 學習如何製作商業企劃案(Business Case)：根據公司的發展願景與商業目標、評估公司現有的能力與預期達到的位置，分析這中間的 Gap，並提出最可行的解決方案，以滿足公司的商業需求。
2. 了解專案 / 產品的利害關係人是誰，引出他們內心真正的需求與期望，以做好利害關係人管理，讓高重要性關係人滿意、低重要性關係人了解狀況，最終達到雙贏。
3. 了解專案 / 產品產出的假想敵(競爭對手)是誰，以做好競爭者分析，如果專案 / 產品的產出會推到公司外部去銷售、使用，就會面臨到同性質競品的挑戰，為了超越競品，就可能要比競品便宜、品質更好、體驗更佳，最後的產出也要圍繞著這個目標完成；如果專案 / 產品的產出是公司內部使用，可能是為了替換公司內部系統、也可能是為了改善某個流程，不論是哪一個，最後的產出一定要比之前的系統方便或有所改良，不然一定會讓同事們怨聲載道。
4. 了解專案 / 產品的產出，使用者會如何使用，哪邊用起來卡卡的？哪邊使用起來容易有誤解？要不要作 A/B Testing 驗證？以優化使用者流程或體驗，也就是業界常說的使用者體驗(User Experience, UX)，使用者體驗這塊一般是由 UX 設計師來負責，但通常只有大公司才有可能招聘此崗位人才。
其實以上事項應由商業分析師(Business Analyst)來分析，但台灣的企業大部分都不認為有聘用商業分析師的必要，所以通常都會由老闆或 PM 兼著做。
二、系統分析(System Analysis)
身為一個軟體 PM，應懂得系統分析的手法，以達成下述目標：
1. 通常業務前往客戶公司拜訪，都會帶著一位 SA 或懂技術的 PM 前往，最主要的目的是，客戶當下聽完業務簡報後，如果有興趣合作，當場就會詢問很多技術相關的問題，以確認我們的產品是否能解決客戶的問題。通常客戶會希望馬上獲得答案，而不是還要由業務回去公司跟 RD 討論後再Email回覆客戶，一來一往不僅曠日費時、文字敘述也很難說明白。此時 SA 或 PM 就可以派上用場了。以我的不可靠歷史經驗來說，當場正確回覆並解決客戶的疑惑，會比回去公司問完 RD 後回覆客戶的成交率還要高。
2. PM 如果學會系統分析，意味著 PM 對於技術是有一定的理解，PM 在寫需求文件、產品規格文件與技術規格文件時，RD 會更清楚 PM 要的是什麼，溝通起來也會更順暢。
看到這，也許會有人問：為什麼 PM 要寫技術規格文件？不是由 SA 負責撰寫嗎？在台灣科技業，考量到預算問題，公司內不一定會有 SA 這個職位，且 RD 通常不太喜歡寫文件，甚至連程式碼的註解都不太寫，如果 PM 能代替 RD 撰寫技術規格文件，RD 一定會對你刮目相看。換個角度想，台灣科技業的 RD 平均薪資通常會比 PM 高，RD 也比 PM 難招募(因為 RD 需求量更高)，所以 PM 能代替 SA 或 RD 寫技術規格文件，也會幫公司省下很多成本(溝通、時間、金錢)。
三、專案管理(Project Management)
身為一個軟體 PM，應該要了解如何在有限的時間、成本與資源下，有效率地完成已界定好的範疇，並達到一定的品質水準，這都需要 PM 有一定的專案管理知識、經驗與適當的工具，才能在眾多考量因素拉扯下取得平衡點。在 PMBOK 非常清楚的說明了 PM 應具備的專案管理知識，在此幫大家複習一下，分別是：
專案管理五大流程群組：起始階段、規劃階段、執行階段、監控階段、結束階段。
專案管理十大知識領域：整合管理、範疇管理、時程管理、成本管理、品質管理、資源管理、溝通管理、風險管理、採購管理、利害關係人管理。
我特別想提兩個 PM 應多加關注的部分是：
1. 溝通管理：要判斷這個 PM 是不是一個厲害的 PM，最主要是看跨部門溝通這塊是否做得到位。在專案執行過程中，PM 大約有 80% 的精力都花在溝通上，不論是對 RD 溝通、對客戶溝通、對其他相關部門溝通、甚至是對您的直屬主管與老闆溝通，厲害的 PM 總是可以把事情講得清清楚楚、邏輯分明且讓人佩服；笨拙的 PM 則總是把事情講的模糊不清、前後不一且讓人懷疑。我認為，溝通真的是一門 PM 一輩子都需要精進的技能。
2. 風險管理：每個專案都一定會有風險，因為【不確定性】就是一個風險，也並不是每個風險都是不好的，在風險管理中，我們將風險分為正面(好)風險與負面(壞)風險兩種。一個厲害的 PM 除了要能辨識、記錄風險與規劃風險回應之外，更要提高正面(好)風險的發生機率、降低負面(壞)風險的發生機率與衝擊，以提高專案的成功機率。
在專案管理工具部分，我建議大家可以學習使用 OPPM(One Page Project Management)這項工具，它是一個用 Excel 就可以簡單製作完成的A4專案管理表單，你可以只用這張 A4 紙簡單管理一個專案的範疇、時程、成本、資源(RACI)、風險、里程碑、專案目標與進度報告，我已使用這個工具超過 5 年以上的時間，此工具可以適用在短至數週、長至數年的專案上，金額更從數萬到數千萬的專案我都使用過，非常易用方便，範例可見下圖。之後我會再另外寫一篇文章，分享如何簡單運用 OPPM 這個專案管理工具。
軟體 PM 是一間公司的核心人物，需要跟公司內部幾乎所有部門、或是公司外部的供應商、客戶與使用者等利害關係人合作，故應具備的知識與技能當然是越多越好，才有辦法在一樣米養百種人的環境下，跟合作夥伴順暢溝通，在下一篇文章《軟體 PM 應具備的十八般武藝（下）》我將繼續分享軟體 PM 應具備的其他關鍵能力：產品行銷(Product Marketing)、產品銷售(Sales)、程式設計(Programming)、產品管理(Product Management)。
