自從轉職當產品經理後，陸續聽到不少周圍的朋友抱怨他們公司的 PM 有多雷、多廢、多會扯後腿：設計師朋友覺得 PM 只會丟需求，連個 user story 和商業目標都講不清楚；工程師朋友抱怨 PM 不懂技術，每次客戶有問題，都還是得由工程人員出面解釋。就連自己先前待過的幾家公司換了新 PM，至今仍能透過各種管道耳聞新 PM 多不會寫 PRD、不懂得判斷優先序，只會透過頭銜壓時程。
到底是雷 PM 太多，還是上述這些純屬特例，又或者是好 PM 真的太難當？這篇文章將以 PM 的職位內容切入，先介紹 PM 的工作內容，再分析這些工作有做好 vs. 沒做好，各自會有什麼情形，最後則會試著提供一些推進這些工作（aka 盯緊 PM 有沒有好好工作）的小技巧。
這篇文章可能會對這些人有一些幫助：
- 對想要成為 PM 的人：了解 PM 的工作內容、影響力與重要性。對於「好的 PM 會帶來什麼價值、雷 PM 會多可怕」有個底
- 身為 junior PM 的人：更清楚自己所作所為帶來的影響、更了解「不做哪些事情會惹毛團隊」（聽起來真可怕）
- 常常跟 PM 合作的需求端 & 開發端：更了解該怎麼催促（逼迫）PM 做好工作，以便推動專案進度
可能有人會問：「身為 PM 的人，為什麼還要寫這篇文章告訴大家『怎麼盯緊 PM 工作』？這樣不就是要把 PM 們逼死嗎？」
但我認為，大家工作的目標基本上是一致的，就是為了推進進度、讓案子順利完工。且作為 PM，也不希望總是聽到大家抱怨自己公司的 PM 嘛……如果能藉此稍稍提高 PM 的工作品質，應該也算是功德一件（吧）。
PM 的 5 個主要工作內容
1. 訂定 product roadmap、產品目標、迭代範圍
一個合格的 PM，通常會對他負責的產品有想法，小至「短期內要做哪些事（修哪些 bug、做哪些功能）」，大至「產品的終極目標或任務」。而且有想法還不夠，應該要隨時將這些資訊同步給團隊，確保大家都知道現在在幹嘛＆下一步是什麼。
- PM 沒做好的話，會……
開發團隊若不知道產品或團隊的核心目標或願景，也不知道下一步要幹嘛、覺得每天都在修 bug 做小事，失去工作意義。
- 如果 PM 沒做好，該怎麼辦？
即使不是開發團隊，只要身為公司一員，基本上便有資格對於自家產品給予意見。如果發現 PM 似乎對於公司產品沒想法、大家都不知道長期目標是什麼，較簡單的方式是先私下跟 PM 聊聊，或許 PM 有什麼苦衷（比如老闆把持一切，PM 其實沒有決定權），或者 PM 真的沒意識到自己的缺失。
但若仍得不到較好的答案，可以在較公開的管道微微施壓，比如在公司週會或大群組等場合，透過「因為現在也快年底了，想知道公司明年對於產品有哪些想法或方向」等切入方式，表達自己對於產品的「關心」。
2. 競品分析、用戶訪談、數據分析、收集需求
有句老話說 “If you can’t measure it, you can’t improve it.” 意即「你無法去改善那些無法衡量的事」。在做決策時，通常會很仰賴相關的量化或質化資料，比如競品怎麼做、用戶怎麼說、目前的數據反映哪些情況等，有了這些相對客觀的資訊，產品經理才能夠不再用直覺做決策。
- PM 沒做好的話，會……
若 PM 沒有辦法提供量化或質化的佐證，開發團隊根本不知道這件事情有什麼意義、會對誰有幫助、會帶來哪些價值，就會覺得做任何功能或修任何 bug 都很沒有意義。
- 如果 PM 沒做好，該怎麼辦？
通常這應該是 UI 或 UX designer 比較會碰到這個問題，比如 PM 突然丟了一個需求或任務，沒頭沒腦地要設計師直接出圖；但作為設計師，通常需要較詳實的資訊：目標用戶是誰、現在碰到哪些問題、用戶想完成哪些事，才能依此規劃出較適合的使用體驗流程與介面。
不過每個團隊的分工方式不同，有的可能是設計團隊會自行研究，PM 不一定會經手；有的則是 PM 與設計師分工準備資料；有的則是 PM 要準備這些資訊，並且整理後與設計師分享。所以，如果碰到這個問題，可以主動要求跟 PM 分工，各自找尋需要的資料。
3. 將需求整理為產品文件（PRD）、繪製 wireframe
有了大方向與數據佐證，再來就是將其落實為一個個的待辦事項。合格的 PM 不只要告訴團隊「往哪走」，也要具體說明「怎麼走」，比如產品的大方向是「成為一套能讓員工追蹤自我成長的職涯輔助工具」，具體要做的功能可能是讓員工記錄自己的學習歷程、分析並繪製成長曲線等。
- PM 沒做好的話，會……
這情況還可再細分兩種
(1) PM 完全沒有整理需求：開發團隊不知道短期目標、無事可做，導致一切虛耗空轉
(2) PM 有收到需求，但轉達不清或有誤差：
老實說，將需求整理為產品規格的過程，難免會有一些缺漏，若只是一些文案或極端案例的小缺漏，那還算是可忍受，且很快可補齊；但如果 PM 完全沒有「把產品需求翻譯為產品規格」的能力，那就很可怕了。
比如今天電商網站做一個「折價券」的功能，PM 該想到的是：用戶是誰、前台跟後台各自的使用流程是什麼、金流怎麼算、有沒有法務問題、是否跟相關部門（客服、行銷、業務等）溝通過規則……等。而不是直接跟工程師說「欸欸 XX 部門說想要做一個折價券的功能」，這不是開需求，這只是把工程師當神燈精靈吧。
假如 PM 連最基本的理解力或表達力都有問題，很可能造成需求端與開發團隊之間的認知落差甚至隔閡，需求端覺得「明明都說了，為什麼開發團隊做出來卻跟期許的有極大落差」，開發團隊則覺得「但我收到的需求就是這樣，都照做了，為什麼需求端還這麼不滿」。
- 如果 PM 沒做好，該怎麼辦？
根據上面兩種情形，對應的方式有：
(1) 沒有需求的話：直接詢問 PM「再來要做什麼？」
其實我蠻常遇到這問題，即使團隊知道長期目標，但有時工程師一個突然開竅、寫 code 如有神，實作短期需求的時間比預估時間還要少很多，所以就會臨時多出 2–3 天的空檔。
超積極的工程師通常會找 PM「討事情做」，比如修一修積累的 bug、先看一下下次發版的範圍等；也有工程師會想要「修養生息」，或者研究一些技術的東西，那就不一定會主動找 PM 做事。
所以我很常在 JIRA 晃來晃去，每天早上都會看一下團隊工程師的進度，隨時確保他們的 backlog 永遠有一些零散小票可做，避免工程人力空轉。但當然也會先跟工程師說明每張票的死線，有些事情真的不急，就沒必要壓一個太趕的時間，這樣也只是讓 PM 和工程師兩邊都痛苦……
(2) 需求總是寫不清楚：勇敢地追殺 PM 或勇敢思考 PM 的適任度吧
如上段所說，需求缺漏難免，基本上大家互相提醒就好。但如果 PM 連 PRD 都不會寫、產品目標與用戶交代不清楚、UIUX 稿件都不齊，這就會讓團隊很難做事了。
朋友曾分享他在前公司的遭遇：有位據說經驗十足的 PM 加入他們這家新創網路業公司，大家滿懷期待，沒想到工程師們一收到這位 PM 開的票，就集體去找 COO 要求換人……因為這位 PM 的開票風格非常「極簡」，標題可能寫「新增折價券功能」，內文也很率性地寫「如題」。沒有折價機制、沒有時程、沒有 UXUI 可參考，當然也沒有使用條件、折價上限、可否與其他優惠搭配等使用案例。
如果碰到這種特別誇張的，要嘛發揮團隊精神，大家一起把這些規格補齊，避免功能開天窗；要嘛及早跟主管反應，看是要留校查看、請人指導還是資遣都可以。私下抱怨當然沒問題，上班族的怒氣總要有地方發洩，但更重要的是：抱怨之後的下一步是什麼？如果團隊願意接納這件事，那之後也沒什麼資格抱怨了；如果團隊吞不下，那就應該積極反應，而不是「縱容」能力不足的同事拖垮團隊進步的速度。
4. 安排優先序與交付時程
「時間有限，需求無窮」，PM 的 backlog 永遠有待辦事項，工程師的 JIRA board 永遠有 big tickets……但每個員工一天就只有 8 小時，所以合格的 PM 要能夠在諸多需求之中，判斷哪些緊急、哪些不急、哪些很重要、哪些沒那麼重要，並依此排出優先順序、妥善分配資源。
- PM 沒做好的話，會……
什麼需求都接、什麼東西都想做、每個任務的死線都是 ASAP，那很容易造成開發團隊過載、人員加班，長期下來可能導致團隊合作或產品品質問題。
反之，如果 PM 太會擋需求、什麼都不接、什麼都不做，也會導致需求端的專案時程延誤或無法實現，對於公司整體、跨部門合作仍會造成不良影響。
- 如果 PM 沒做好，該怎麼辦？
(1) 作為需求端，在提出需求後，務必問 PM：「什麼時候會做好？」
如果怕這樣太逼人，可以用一些話術如「不是要催你，但我需要跟主管回報進度，所以得知道預計交付的時間點」。而且照理來說，PM 也要能給出時間才是。
即使給不出來，應該也要能夠說明理由，比如「我得先讓工程師看一下需求，然後估時，才能告訴你要花多時間才能做完」、「因為今天剛好有另一個插件，那個插件的緊急程度較高，所以工程師會先處理，但插件的細節還未知，我得等拿到細節後，才能告訴你工程師什麼時候可以來做你的需求」或者「這個需求預計 xx/xx 會做好，不過中間如果有其他插件，時間就會被耽誤，所以現在給你的時間只是預估喔！」
(2) 作為設計師或工程師，可能同時要處理很多案子，這時就可以問 PM：「這些案子的預計上線日是什麼時候？」，這樣才能回推應該要先做哪個案子。
不可能每個案子都是 ASAP，如果每個需求都是急件，那其實也等於「沒有一個需求是緊急的」。
如果會同時對應到很多個 PM，當他們都說自己的案子最緊急時，也可以請 PM 先自己去喬時間，畢竟他們是最熟悉產品時程的人，必須要能做出對應的決定。
5. 產品測試與交付
終於來到產品即將完工的前一刻，如果產品目標沒改變、需求沒有轉譯錯誤、大家都認同並按照 PM 給出的時程表執行任務，照理說團隊就可以順利迎接上線了！
- PM 沒做好的話，會……
好不容易終於把東西做完了，最後關卡就是要測試、確認與驗收了。如果當初 QA 或 PM 有寫好一份測試清單，產品文件與設計稿也足夠完善，那很快就能以此對照有哪些地方缺漏或不一致。
一個產品的完善與否，不是單一環節可決定，而是層層積累的，所以如果根基沒打穩，到最後就很有可能因為某個小問題而觸發大災難，甚至打擊團隊士氣與信心，當然也會影響到產品經理本身的信譽和評價。
- 如果 PM 沒做好，該怎麼辦？
為了避免「做出的產品與需求不符」，團隊成員在規劃與實作的過程中，要問的除了 “how”（怎麼做），更要問 “why”（為什麼要這樣做）。
但如果產品上線後，仍發現與預期落差太大，通常要嘛是需求端自己理解有誤，要嘛是 PM 管理有問題。如果是前者，就讓 PM 去幫需求端梳理問題癥結；如果是後者，就得認真檢討到底是哪個環節出問題，避免未來重蹈覆徹。
但所謂的「檢討」不是說說而已，如果沒有列出具體的待辦事項與負責人，通常就會不了了之了。
以我現職公司為例，我們在每個產品線的大迭代的一週內，就會召開開發團隊（PM + QA + Dev）的 retro 會議，會議中會讓大家分享 “what we did well”（我們有哪些地方做得很好）以及 “What we can do better”（我們有哪些地方可以做得更好），最後再一起針對「可以做得更好的地方」想解法，每個解法也會列出下一步＆負責人，如此才能確保下一次不會碰到踩到一樣的坑。
結論
雖然講了這麼多，但一個 PM 的工作內容絕對不僅於此，所以即使做完上述這些，也不代表就能馬上得到對應的認可。
但至少，上面這些算是做好一個 PM 的基礎，有做到這些，多少能被當作一個「及格」的 PM，之後便可以隨著各種情境、突發狀況與產品屬性，持續將這些事情做得更快、更好、更完善，並且搭配自己與團隊的個性和工作習性，磨出一套最適合彼此的工作方式。
最後，雖然職場上有神人同事、也有豬隊友，但我還是樂觀地相信大多數人都是想把事情做好，所以如果對方有事情漏掉，我通常會先假設對方只是「不知道」或「忘記」，而非「怕事、想規避責任」，畢竟自己也菜過，很多事情也許對於老鳥來說是基本，但菜鳥不一定會知道嘛。
一般情況下，通常經過提醒後，對方通常都能把漏掉的事情完成；如果發現對方真的在躲責任，也有很多方式可以「提醒」，小至私下溝通、文件上標註對方，大至在群組直接點名負責人，或者找對方的主管反映。
可能會有人說：「啊我能說的都說了，但就是改變不了啊，我對到的 PM 就是一樣那麼雷！」，如果事情真的解決不了、向主管反映也沒用、偷懶不做事或能力不符的人依舊坐領乾薪，那麼很哀傷地，作為員工，該思考的或許不只是「人」的問題，而是公司整體的制度與價值觀是否與自己一致。
問問自己：「我真的想繼續在這樣的環境做事嗎？」、「繼續待在這個環境，對我是有幫助的嗎？（不論是金錢或經歷上）」，如果答案都是肯定的，那其實也沒什麼好抱怨的，因為這就是自己的選擇；如果答案是否定的，那就去找個更適合自己的新環境吧～
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
