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