【百工圖】PM都在做什麼？產品經理與專案經理經驗談 (上)

一間具有產品開發／研發能力的公司，勢必少不了「PM」這個職位。社會新鮮人對 PM 的工作或許不了解，但每間公司幾乎都有 PM 這個職缺。到底，PM 在做什麼？什麼樣的人適合擔任 PM？頭銜掛經理，實際工作到底在幹嘛？這篇文章整理七位在職 PM 的經驗，深入介紹 PM 一職。

---

1. PM 都在做什麼？

PM，可以指代產品經理（Product Manager），也可以是專案經理（Project Manager），顧名思義就是專注產品／專案的人員。

Really？我再講一下更清楚的工作流程，也許會更清楚。

每間公司開始一個專案／產品的原因跟考量不同，通常有幾個可能：

1. 上門客戶提需求
2. 異業談合作
3. 內部提案（包含上級的突發異想XD）

無論需求來源，PM 與需求端談完初次需求後，多半要據此提案（此時通常會產個初步 user story、wireframe 等，跟工程師與相關人員確認技術、所需時程），其後再次確認規格，無誤再跟工程師談版本時程分割等。

接著，就看每間公司的開發流程，可能會有些許差異，但以現在流行的敏捷開發為例，多半會以一到二週切時程，快速做出第一個最小可行版本。後續是否再開發，或者修正提案、改開發方向，又是後話。

聽起來似乎不難，但現實比較有可能是這樣：

(1) PM 談完 A 案的初次需求，旋即在技術面被打槍。回頭跟客戶調整需求，卻不被理解，遇上重重阻礙。

(2) A 案的初次需求沒遇上問題，但進入開發前期時，客戶覺得花太多時間評估了，決定撤掉 A 案。

(3) A 案開發到一半，由於其他即將上線的 B 專案需要資源，因此主力人員被調走，A 案無限期停擺。

以上所有狀況都很基本，更多離奇、PM 難以獨力處理的情況都會出現，因此「跨部門溝通力」跟面對案子各種狀況也不混亂的「大顆心臟」都很重要。

---

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 很容易就因為工作關係，成為部門之間的高級打雜員工。美其名是跨部門協調者，事實是什麼東西沒有職權歸屬、就會落到你身上。

此外，超長的回饋期與累積的挫折感，也非常折磨人。更別提因為自身技術不足或跨部門政治因素，所需面對的人事紛擾。

除了上下層與跨部門的兩極意見衝突以外，有更多問題會一波一波湧上來。如果是委外開發產品，還得控管外包、對內安撫同工者的不滿。

而由於整個專案、產品都由你掌握，久了自然也知道各個部門的境況與需求，因此只有你知道真正可能驗收上線的時間（也因此極度絕望）。

畢竟其他人都像瞎子摸象，只看到局部，有很多誤會與堅持的空間；說穿了只有從頭到尾跟著跑的你，看得見那頭大象生得什麼模樣，知道根本沒什麼美好的想像。也因此，你可能會長時間處於焦慮中。在正式上線交付營運團隊之前，即便有快樂與回饋，也都是短暫的。

總之，技術混雜著人事碰撞就是一團大災難。而解決這團災難，就是你的工作。

或者該問，你是否有足夠堅強的心理素質，面對四面八方（包括你自己）的質疑與挑戰呢？

---

4. PM的快樂與成就感

看完以上一大串經驗分享，也許你有點恐慌，搞不懂做 PM 有什麼必要。但先別急著下定論，讓我們來看看 PM 的快樂與成就感吧！

多數 PM 都認為，「產品如期推出、品質達到一定水準、獲取充分的用戶反饋」是漫長奮戰後最佳的回饋。要知道，即便是「小步快跑」、「敏捷開發」盛行的當代，產品開發依然是一條漫漫長路。

要在海量競品、複雜資訊、龐大數據中，梳理出用戶的需求，並規劃、執行整個產品與專案的開發，從來都不是一件容易的事。而由於 PM 既無管理權，又多半無自主開發的能力（比如 coding、美術），因此被質疑的機會很多，要抓緊所有工作夥伴一起向前衝，更是困難。

也因此，最終收穫的果實才會加倍甜美。

就這樣嗎？

對，PM的快樂就是這樣，但也很足夠了。

想想看，這世界上有多少產品與專案胎死腹中？你就能明白，看到產品與專案面市，獲得一位客人的評價，是多麼令人激動的事情。

也許再加一個：在一片混亂中梳理出一條可行的道路，其實某方面來說也是很有成就感的。這樣的成長非常明顯，尤其當你回頭看第一個專案的兵荒馬亂，再看看自己幾年後的不同，相信差別一定很大。如果還能被團隊夥伴肯定能力，就更錦上添花了。

希望你回看來時路，也是滿足多過於懊悔。

這篇文章太長，我們下一篇繼續談 PM 的薪資落點與養成方式，並於最後一篇分享職場實務與 PM 培養方法。