想寫這篇文章，是因為這幾年工作下來，被不少人問過各種產品問題：怎麼寫 PRD、怎麼開始重新設計一個產品、怎麼跟需求端打交道，仔細回想後，發現這些問題看似難以歸類，但說到底，或許都是因為原本沒有一套規則或模板可以參考，當事人必須自己重新打造，所以才會有種無頭蒼蠅的無助感。
又或者，不管是否身為 PM，只要有跟 PM 共事過，應該難免會覺得 PM 的工作包山包海、難以用一句話定義清楚。
每當同事們問起：「怎麼這個事情也是你來做？」，通常也只能說：「PM 的工作就是去處理那些『不屬於工程師、不屬於設計師、也不屬於測試』的事情」。
之前寫過一篇〈職場不是只有是非題，更需要「與不確定、時刻變動相處」的能力（how to deal with ambiguity）〉，不過當時談的是「變動」本身，裡面提到的偏向大原則以及如何培養「應對變化」的心態，並沒有太具體的舉例；這篇文章則是想更具體地聊聊 PM 常遇到的幾種「模糊不清」的情境，以及對應的處理方式。
情境 1：工作流程未定
在一個組織中：尤其是發展尚未成熟的新團隊或新創公司，應該很常遇到「沒有流程」或者「流程很亂」這種事。
比如今天要做某個功能，到底應該從哪裡先下手： 是 PM 可以自己發想一個草稿，還是得把公司的老大們都請示過一輪？PM 可以發問卷收集使用者意見嗎？還是行銷或業務部門會有其他意見？
在這種情況下，有 2 種比較常見的解決方式：
- 消極版：不知道流程，那就找人先把流程定好吧。但既然都擺明說是「消極版」，顯然不會是 PM 本人自己去做，所以那個「人」可能是 PM 的下屬，也可能是 PM 的上司，端看組織的運作常態。
有的 PM 可能會請 APM 先把 SOP 定好，也有的 PM 可能會去跟主管求救，畢竟主管一般會對團隊運作的流程更熟悉，更能掌握各種眉角。
- 積極版：普遍來說，大家（大至公司、中至部門、小至主管）都期待 PM 有「當責 (ownership)」的精神，所以如果沒有工作流程，那就會期待 PM 把流程生出來。
怎麼生？其實跟平常在做產品功能一樣，不外乎是要釐清目標、確認要解決什麼痛點、跟相關的人一起找出解法，最後再落實到組織裡。（如果真的有興趣，這個可以再另寫一篇）
至於為什麼要分「消極版」跟「積極版」，是因為各公司也有不同的作風和文化。很哀傷地說，在某些組織裡，積極的 PM 不一定就會被肯定，搞不好有人覺得太有侵略性、管太寬；消極的 PM 也可能在某些鼓勵發聲的組織裡被認為太被動，所以還是得視情況調整。
情境 2：需求模糊
作為 PM，很多時候可能會收到用戶說「這個功能好難用」或者老闆丟下一句話說「我想要 xxx 功能」。這種乍看之下明確（畢竟用戶的直線思考就是「那就把功能改得好用一點啊」、老闆則是想「就是把 xxx 功能變出來啊」），但不管是對於 PM 還是設計師，在這個需求階段時，最重要的不是 “what” 或 “how”（做什麼、怎麼做），而是 “why”（為什麼要做）。
不管在什麼情境，都得盡量提醒自己「記得先問『為什麼』」。不過也得承認，有些組織或有些人的管理風格就是很「由上至下」，大主管基於各種原因而覺得「你照做就對了 / 我懶得跟你解釋」，如果真的碰到這種，試過後也改變不了的話，那就……沒辦法了。不過，正常情況下，如果碰到需求模糊，通常 PM 都是會被預設有「釐清需求」的權利的。
分享個親身經歷，我的現職工作是負責一些內部系統的開發與維護，且以人事相關的系統為主，所以平時會接觸不少公司內的人資同事。由於公司是個規模頗大的跨國集團，新加坡是全球總部，其他十幾個國家都有各區域的當地部門會回報給總部。
我剛開始因為不太熟悉組織的運作模式，所以跟人資合作的方式比較簡略，就是請他負責收集整理各區域的使用者痛點，看看用戶對系統有什麼意見，我們再來看怎麼改善。
這套流程跑了好幾個月，其實問題也不大，只是後來發現，畢竟我得到的是「二手資訊」：各區域人資會跟各區域主管收集意見，然後分享給總部的人資，總部的人資問完十幾個區域後，再把這些意見整合起來給我。雖然我省去了收集意見的麻煩，但這些意見在傳達過程中可能會有些理解誤差，所以拿到的資訊可能會少掉一些脈絡，比如：使用者現在的使用流程是什麼？為什麼覺得這個是痛點？那他的期望是什麼？這些資訊都可能被漏掉或轉達錯誤。
所以後來要收集需求前，我會先和總部人資開會，先跟他一起梳理這陣子累積的用戶反映，然後追問他上述問題，如果連人資都不太清楚，我們就會再去尋找各區域人資，請他們幫忙約幾個主要的區域主管來聊聊，也就是我、總部人資、區域人資，一起了解區域主管（也就是系統真正的使用者）的想法。
久而久之，這套流程逐漸標準化，需求文件也有一份公版，讓大家更方便填寫，而且人資也會更清楚為什麼我想要知道這些資訊，以及這些資訊將如何幫助產品團隊做後續的功能規劃。
或許有人會覺得這樣很花時間，不過 PM 會收到的需求百百種，有簡單的、也有複雜的，通常只有複雜的需求才會需要花這麼多心力去釐清，且有了這些真實用戶的說法，PM 在撰寫 user story 和構思解法時，也會更有信心！
此外，根據受訪的主管們所說，他們也很高興有這樣的討論場合，因為這讓他們有更直接的管道能反映自己遇到的問題，且會覺得自己的聲音能夠被聽見。
關於更多釐清需求的方法，可看之前寫過的文章〈如何改善產品？功能優化怎麼做？step 2：定義問題與目標〉。
情境 3：責任歸屬不清
跟上述情境類似，有的公司不管是流程還是分工都是一團亂；有的則是空有流程，但沒有對應負責人；也有的是職位分明，卻沒有對應的分工流程。而更常見的，或許是兩者都有，但界線很模糊，難免會有那麼幾件事不知道該由誰負責。
以下列舉幾個最常跟 PM 合作的角色，並依序列出兩種角色合作時，最常遇到的「踩線」或「兩不管地帶」情境：
PM vs. stakeholder / 需求端
作為 PM，在跟需求端打交道的時候，應該很常遇過這幾種情況：
- 需求端想提需求，但需求說得零零落落、目的跟痛點也講得不清不楚。
- 需求端沒有仔細拆解自己的痛點或根本需求，只是看到表面問題就直接去想解法，然後逼著產品端去開發對應功能，但功能上線後，卻發現原本的痛點還是沒有被解決。
- 需求端來自太多部門或單位，人多嘴雜，沒有一個統一對接的窗口或負責人。
- 消極版解法：提供一個需求模板與範例，讓各個需求端自己填上。這麼做的好處是，至少有同一份文件能看到所有人在使用同一個產品時遇到的問題和期望的解決方式，PM 就不用從各個管道收集資訊，少去一些整理文件的時間。不過「人多嘴雜」這件事情還是沒有得到解決。
- 積極版解法：不只提供一個需求模板與範例，同時也協助整合需求端窗口紊亂的問題，但這個通常要搬出主管來幫忙，比如由主管要求其他單位各自找出對接窗口，而不是同個團隊同時有好幾個人各自做事，有問題也不會內部先溝通好，就直接找到 PM。
「搬弄職級」這件事說來心酸，但畢竟事關跨部門協作，有時候就需要一些講話比較有份量的人，大家才會願意協助。
此外，也可以透過團體會議或一對一的方式慢慢引導並「教育」需求端，畢竟需求端通常更貼近用戶、更了解用戶遇到什麼問題，所以需求端其實可以幫助 PM 寫出最真實的 user story 並給予實例。
然而，需求端的職能百百種，可能有人資、財務、法務、行銷、業務，他們不一定（也沒必要）知道 PM 是怎麼跟產品團隊發想並溝通需求的，所以 PM 就需要好好地引導需求端，讓他們知道「為什麼要把痛點講清楚」、「知道痛點之後能幹嘛」、「為什麼不要一開始就直接討論解法」。
PM vs. UX/UI
之前聽過有些人說，即使公司有設計師，PM 還是會自己畫 wireframe。這邊的「自己畫」到底是「不得不自己畫」還是「PM 也想自己畫」則因人而異，但從此可以知道的是：PM 和設計師們，難免有些工作內容上的重疊或矛盾。比如：
- PM 提需求時，已經有很具體的想像了，所以會想直接畫 wireframe，覺得這樣比較好溝通；但設計師覺得這個直接從問題跳到解法了，有點太直線思考。
- PM 提需求時，真的沒什麼想法，覺得需求很合理，但也沒什麼好的建議，所以就只帶著需求去找設計師；設計師覺得 PM 怎麼一點想法都沒有，這樣很難往下討論。
- PM 在收集需求時，也會一併詢問使用者的意見，這種非正式的用戶訪談，要不要把設計師也一起抓進來？邀了設計師，但用戶講的東西太零散，設計師覺得「PM 把訪談內容歸納完後，再來討論就好」；看完歸納好的東西又說「這種訪談應該把我也邀進來，這樣我對整個脈絡會更清楚」。
上述這些例子都是真人真事，搞得 PM 時而怕踩線，時而怕設計師覺得自己只想單打獨鬥，PM 難為，PM 找不到好解法……。
- 消極版解法：全力配合設計師，以他的工作習慣為主。
- 積極版解法：在合作前就先和設計師聊聊，了解彼此的工作習慣；往後合作遇到問題時，也要即時討論、釐清癥結點，避免問題再度發生，並確保接下來合作更順利。
PM vs. QA
功能做好後，在上線前通常會經過一段測試時間，確保沒有致命 bug 會影響該功能運作。理想情況下，大家通常會期待有專職的測試工程師負責測試，但有時也會導致 QA 跟 PM 可能會做重工，比如：PM 測試時，也測到 QA 在 test case 裡面的測試項目，那這樣是誰要負責追蹤這個 bug？且如果團隊還有習慣開票（或透過任何形式，比如寫在某份 google doc 作為測試結果的回報文件）追蹤 bug 的話，那誰要負責開票？
或者，測試過程中碰到某些操作細節沒有定義清楚，那是要讓 QA 自己跟工程師與設計師討論，還是 QA 要先找 PM，讓 PM 去主導整個討論？
又或者，QA 測到的 bug 比預想中還多，工程師很可能無法在預定時間全數修完，那就需要把 bug 排出修復的優先級。
- 消極版解法：全力配合 QA，以他的工作習慣為主。
- 積極版解法：在合作前就先和 QA 聊聊，了解彼此的工作習慣；往後合作遇到問題時，也要即時討論、釐清癥結點，避免問題再度發生，並確保接下來合作更順利。
其實這邊寫的解法跟上一段差不多，為免這段太水，補充個實際案例好了
我自認和現職公司的 QA 合作得還不錯，不過主要原因並非在我，而是這位 QA 非常認真可靠！再加上我們一起工作快三年了，合作的頻率也很高，所以也累積了一些工作默契，很少有出現「雙不管地帶」或意見衝突、合作不順的時候。
先說明一下 PM 和 QA 合作的流程。在 QA 開始測試前，我會請 QA 先估時，看看預留的測試時間是否夠用，如果不夠，我們也會為了彼此盡量調整（比如跟工程師討論，能否分批交付，讓 QA 分批測試；或者跟其他產品線喬時間，避免讓 QA 加班測試）。
確認時程後，QA 會根據 PRD 和 UX doc（裡面會有 wireframe 和交互細節）提供一份 test case 清單，裡面詳載要測試的項目與預期結果。剛開始合作時，因為對彼此工作方式還不熟，所以我們會約個時間一起過這份清單，但後來習慣後，QA 就只需要把清單傳給我（如果有不確定的部分，他會在清單中加註），我只要另外抽時間確認與回覆就好。
開始測試後，如果發現測試結果與預期不符，基本上都是由 QA 回報，簡而言之就是「誰發現的 bug 就是誰回報＆誰驗收」；但如果 QA 測試時發現 PM 或 UX 沒有定義明確的流程，QA 就會在群組裡標註對應的人，負責的人看到就得去回覆（如果需要討論，那負責的人就會另外約時間）。
如果因為有時間壓力，QA 測到一些很微小的 bug，會自己降低修復的優先級，工程師也會參考該優先級，決定要先修哪些 bug。作為 PM，我在測試期間也會每天「巡田水」，定時追蹤 bug 的修復進度與優先級。另外，如果發現 bug 太多、需要取捨的話，我會再主動調降一些 bug 的優先級，並在 bug 票裡面留言，以便日後參考，同時也讓 QA 知道我改動的原因（如果 QA 不同意，我們會另外線下討論，但由於已經有工作默契，QA 和我對於優先級的認知通常不會差太多）。
總之，謝謝這位很讚的 QA，完全是工作上的神隊友。
不過，之前在別家公司也碰過有 QA 以測到 bug 為樂……甚至陷入了「重量不重質」的「開 bug 票狂喜」境界。
一般而言，QA 測試時，應該會把主要的操作流程先跑過、跑通，後面才會開始看交互細節，比如點「儲存」後有沒有出現確認視窗、點「送出」後有沒有出現成功提示等超小細節。
但這位 QA 就是專門挖細節來測試，文字拼錯開一張票、某個畫面的 UI 跑版開一張票、顏色錯誤開一張票，開了一堆細節 bug 票，但主要流程卻沒測多少，還在公司大肆炫耀「我已經開了 100 張 bug 票囉 ^_^」，搞到最後工程師都快集體抗議了……。
工程師們倒不是生氣自己被雞蛋裡挑骨頭，而是這位 QA 不懂輕重緩急，畢竟一個功能要能夠上線，「能用」才是基本，但今天連是否「能用」都還沒測完，QA 就先去鑽牛角尖地看很多相較之下微不足道的地方，這難免會讓人覺得「好像把力氣花在錯的地方了吧」。
PM vs. PM lead
在一個扁平開放或鼓勵創新的組織，通常 PM lead 對於 PM 們可能會是比較「放羊吃草」的管理方式，也就是讓 PM 自己去管各自負責的產品或功能。不過如果產品本身太大，通常還是會由更高層的人去定義好產品定位、受眾、願景等，下面的人就是按照定好的方式去執行細部任務。
然而，如果是在中小型組織，PM 主管與 PM 的工作界線相對模糊，難免會有些事情讓 PM 主管覺得「這個就給 PM 發揮就好」，然而 PM 則會覺得「這不是應該 PM 主管要先想好嗎」。遇到這種雙方認知不一致的情況，該怎麼做呢？
- 消極版：聽令辦事，主管說要幹嘛就幹嘛。（若遇到非常強勢的主管或者分工太細的大公司，應該就很容易產生這種結果）
- 積極版：PM 主動定義並規劃與主管的協作方式，確立兩人的工作範圍，比如明定哪些事項需要向上請示或討論、哪些可由 PM 自己決定。
但！也不需把這件事想得太死板，其實善用一些與主管一對一的會議時間，就可以完成這種討論了；且這些工作方式與默契也需要時間培養，不用逼自己得一次到位。
像我剛到職時，再小的新功能都會找主管一起看 UX wireframe，但隨著合作時間變長，逐漸觀察到主管其實對這些細節不會過度講究，最主要還是想知道 “why”（為什麼要做）而非 “how”（怎麼做），所以後來也就只有碰到「不確定這樣的產品改版方向是否恰當」這種大問題時，才會去找主管。
結尾
上面列了 3 種較常見的情境，說穿了，其實 PM 每天做的事情很一樣、但也很不一樣：一樣的是，每天都在面對各種模糊不清又變動頻繁的人事物；不一樣的是，每個人事物都有自己的個性和脈絡，需要花很多心力去理解。
有人覺得這充滿挑戰性，有人覺得這些變動因子令人厭煩，但不論是否從事 PM 這份工作，「面對模糊不清」依舊是極常見的工作情境，甚至可以說是必備的工作之一（吧）。總之，希望這篇文章能對需要的人有些幫助！
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
