不是技術職也非管理職，夾在中間的 PM 到底怎麼帶領專案往前衝？ 產品經理與專案經理到底有何差別？入門門檻不如想像高，要做得好卻極其困難的職位——PM。
1. PM 做什麼？
一間具有產品開發／研發能力的公司，勢必少不了「PM」這個職位。
PM，可以指代產品經理（Product Manager），也可以是專案經理（Project Manager），顧名思義就是專注產品／專案的人員。
主要工作內容以產品規畫、市場競合調查、核心版本進度控管、細節驗收與跨部門溝通為主。由於需要催生產品或專案，因此工作時接觸人的機會極高，很常卡在會議中，也因此被視為公司的跨部門專業協調員。
Really？我再講一下更清楚的工作流程，也許會更清楚。
每間公司開始一個專案／產品的原因跟考量不同，通常有幾個可能：
- 上門客戶提需求
- 異業談合作
- 內部提案（包含上級的突發異想 XD）
無論需求來源，PM 與需求端談完初次需求後，多半要據此提案（此時通常會產個初步 user story、wireframe 等，跟工程師與相關人員確認技術、所需時程），其後再次確認規格，無誤再跟工程師談版本時程分割等。接著，就看每間公司的開發流程，可能會有些許差異，但以現在流行的敏捷開發為例，多半會以一到二週切時程，快速做出第一個最小可行版本（MVP）。後續是否再開發，或者修正提案、改開發方向，又是後話。
聽起來似乎不難，但現實比較有可能是這樣：
(1) PM 談完 A 案的初次需求，旋即在技術面被打槍。回頭跟客戶調整需求，卻不被理解，遇上重重阻礙。
(2) 或者 A 案的初次需求沒遇上問題，但進入開發前期時，客戶覺得花太多時間評估了，決定撤掉 A 案。
(3) A 案開發到一半，由於其他即將上線的 B 專案需要資源，因此主力人員被調走，A 案無限期停擺。
以上所有狀況都很基本，更多離奇、PM 難以獨力處理的情況都會出現，因此「跨部門溝通力」跟面對案子各種狀況也不混亂的「大顆心臟」都很重要。
Photo credit: Lucas Allmann on Pexels
2. 兩個都叫 PM，有什麼不同？
產品經理與專案經理的英文簡稱，很巧地都是「PM」；簡單來說一個以產品為主，一個則以專案為導向。你也許仍聽不出兩者的差異，但沒關係，在中小企業佔多數的台灣，也許是企業規模不夠大的關係，或者是基於大家都知道的原因， PM 頭銜差異真的不大。（至少受訪的 7 位 PM，每一位都得兼著做。）
通常，Project Manager 比較偏技術與規格層面，由於其主要工作是確保專案能如期完工，因此需要解譯需求、思考做法，並在做法被工程師打槍後，提出其他解法（當然，也可以請工程師給你建議）。總之，與研發的溝通極為密切，也有非常多的技術活需要思考與判斷。
至於 Product Manager，則比較像是從使用者體驗與需求的角度，規畫一個產品應該有什麼功能、起什麼效果，從無到有生出一個產品。
用工作對象來分，Project Manager 的主要思維對內部（老闆、主管、團隊），Product Manager 的思維則偏向對外部（也就是 B2B 跟 B2C 中，後面的那個B跟C。總之就是對用戶！）
不過，為什麼需要兩種 PM 呢？
以流程來說，無論是誰發起了產品／專案的需求，都需要 Product Manager 深入思考功能對使用者的效用，以及需要調整的體驗；而 Project Manager 則在需求開出後，檢驗可行性、與工程師確認如何實作。兩人都需要針對開發現況，不斷調規格、找資源、溝通需求，是相輔相成的存在。
而到最後，其實兩種 PM 的思維會漸漸混同，想著客戶需求的同時，也明白技術的限制或可挑戰的部分；或者想著技術與需求的同時，會再思考用戶是否需要什麼、會不會需求開不到點等問題。這境界，就需要時間累積、與你自己的努力了。
如需更具體的說明，可以參考這篇文章：〈PM 有兩種，「專案經理」跟「產品經理」到底有什麼不同？〉
3. 當 PM 困難嗎？
知名的獵人頭「江湖人稱 S 姊」，在文章〈PM 在做什麼？PM 厲害在哪？我想當 PM 可以嗎？〉中，其實點出了 PM 的一個重要問題。
PM 是一個相對職缺較多、入門門檻不如想像高，要做得好卻極其困難的職位。S 姊點出的原因大致有三：
(1) 標準化流程不再重要
進入互聯網時代，專案／產品不再追求標準化或大量生產，因此不具管理權，也無專案決定權的 PM，缺乏「控管」的必要，企業似乎也想不出找個專職控管者的必要；
(2) 職銜廉價、信任感低
由於許多人以為 PM 只要會控時程、凹人凹錢凹資源就好，企業徵才也沒有列出具體條件，因此入門門檻很低；很多企業不知道該給員工什麼職銜時，往往也是套個 PM 就讓上了。
在這種職位氾濫、能力參差不齊的情況下，開發部門對 PM 的信任自然也很低。
更可憐的是，以前 PM 還可以靠那張貴爆的 PMP 證書證明自己，現在拿出來卻只是「努力」的證據，還有可能被以為「只會照本宣科」。
(3) 高級行政助理
不管你懂不懂專有名詞、是否了解公司的產品與政策，PM 很容易就因為工作關係，成為部門之間的高級打雜員工。
美其名是跨部門協調者，事實是什麼東西沒有職權歸屬、就會落到你身上。
此外，超長的回饋期與累積的挫折感，也非常折磨人。更別提因為自身技術不足或跨部門政治因素，所需面對的人事紛擾。除了上下層與跨部門的兩極意見衝突以外，有更多問題會一波一波湧上來。如果是委外開發產品，還得控管外包、對內安撫同工者的不滿。
而由於整個專案、產品都由你掌握，久了自然也知道各個部門的境況與需求，因此只有你知道真正可能驗收上線的時間（也因此極度絕望）。畢竟其他人都像瞎子摸象，只看到局部，有很多誤會與堅持的空間；說穿了只有從頭到尾跟著跑的你，看得見那頭大象生得什麼模樣，知道根本沒什麼美好的想像。也因此，你可能會長時間處於焦慮中。
在正式上線交付營運團隊之前，即便有快樂與回饋，也都是短暫的。
總之，技術混雜著人事碰撞就是一團大災難。而解決這團災難，就是你的工作。
你能經得起開發部門信誓旦旦告訴你：「這個功能不能做」「這個功能做不到」「不是原生規格很麻煩」，但其實功能早就在系統內、只是他懶得找或想敷衍你嗎？
你能承擔 3 週後核心版本要完工，但 KPI 的運算方法出不來、系統無法驗收，團隊無法加人加時，但客戶也不願放寬時程的龐大壓力嗎？
你敢不敢在上頭開出奇妙需求、或是自己對完規格，發現功能不可能做到時，回頭跟上司否決提案，而非壓著研發設計工程師（RD）強跑專案？
或者該問，你是否有足夠堅強的心理素質，面對四面八方（包括你自己）的質疑與挑戰呢？
Photo credit: freestocks.org on Pexels
4. PM的快樂與成就感
看完以上一大串經驗分享，也許你有點恐慌，搞不懂做 PM 有什麼必要。但先別急著下定論，讓我們來看看 PM 的快樂與成就感吧！
多數 PM 都認為，「產品如期推出、品質達到一定水準、獲取充分的用戶反饋」是漫長奮戰後最佳的回饋。要知道，即便是「小步快跑」、「敏捷開發」盛行的當代，產品開發依然是一條漫漫長路。
要在海量競品、複雜資訊、龐大數據中，梳理出用戶的需求，並規劃、執行整個產品與專案的開發，從來都不是一件容易的事。而由於 PM 既無管理權，又多半無自主開發的能力（比如 Coding、美術），因此被質疑的機會很多，要抓緊所有工作夥伴一起向前衝，更是困難。
也因此，最終收穫的果實才會加倍甜美。
就這樣嗎？
對，PM 的快樂就是這樣，但也很足夠了。
想想這世界上有多少產品與專案胎死腹中，你就能明白，看到產品與專案面市，獲得一位客人的評價，是多麼令人激動的事情。
也許再加一個：在一片混亂中梳理出一條可行的道路，其實某方面來說也是很有成就感的。這樣的成長非常明顯，尤其當你回頭看第一個專案的兵荒馬亂，再看看自己幾年後的不同，相信差別一定很大。如果還能被團隊夥伴肯定能力，就更錦上添花了。
希望你回看來時路，也是滿足多過於懊悔。
這篇文章太長，我們下一篇繼續談 PM 的薪資落點與養成方式，並於最後一篇分享職場實務與 PM 培養方法。
「本文獲 Selena 授權刊登，未經原作者同意，不得轉載。原文出處【百工圖】PM 都在做什麼？產品經理與專案經理經驗談 （上） 」
延伸閱讀
【職涯百談】PM的薪水有多少？產品經理與專案經理經驗談 （中）
【職涯百談】PM如何養成？產品經理與專案經理經驗談 （下）
