作為 PM，應該每天都在跟不同部門＆職能的人打交道，比如跟工程師討論哪個需求的哪個部分不好做，有沒有替代方案、跟 QA 確認測試範圍和各種極端案例該怎麼處理、跟設計師來回拉扯畫面上的各種排版、顏色、文案與字級大小，此外，還得跟需求端討論要處理哪些需求、怎麼排優先級、時程該怎麼調整。
跟需求端溝通，既需要腦力也需要耐力，這邊並不是說需求端有多可怕（但當然，有些真的很可怕……），而是因為多半的需求端並非來自產品或技術相關背景，他們不知道（也沒有義務知道）這些系統背後的運作邏輯是什麼、哪個功能是怎麼做出來的、為什麼這個功能只要這樣用……等，即使我自己也被需求端搞瘋很多次，但理智的我還是認為，一個好的系統或產品應該要讓用戶能「無痛」上手，不該是用戶去習慣或刻意認識某些功能或介面。
話雖如此，還是會有許多情境得仰賴 PM 的腦力和耐力，用最簡單但明瞭的方式讓需求端知道 why & why not，以下會以各種「PM 跟需求端協作時，常會遇到的頭痛情境」舉例，或許會對於需要頻繁和需求端溝通的 PM 有些幫助。
「需求端」是誰、怎麼定義「需求端」
「需求端」來自四面八方，在此先把他們的「用途」視為「PM 所負責產品的主要聯絡窗口」，比如產品改版需要收集用戶意見、安排時程等，這個「需求端」通常即有一定的責任和權力和 PM 一起處理這些事。
所謂的「需求端」，可能是「客戶」，也可能是「用戶」。比如做 to C 產品，通常各種需求都是來自於第一線的使用者，就像你我對於 instagram 就是這樣的關係；做 to B 產品，提需求的人很可能只是負責採購或導入這個產品到企業端的「間接」使用者，可以廣泛地稱他們為「客戶」，且他本人不一定真的是該產品的使用者，有時只是負責轉達其他人的需求。
至於我現在做的企業內部產品，提需求人的既是直接用戶，也是間接用戶 — — 比如財務系統的 PM 的需求端就是來自於財務部門的某個同事，這位同事本人平常就有在使用財務系統，但與此同時，他也會需要收集其他人的意見，並且和財務系統的 PM 一起討論這個系統後續有哪些要優化的地方、哪些優化又應該被視為最高優先級、這些優化該什麼時候上線等。
介紹完需求端，下面就列出一些常見的 PM 與需求端溝通的情境，看看 PM 有哪些比較適合的應對方式。
1. 需求 / 痛點太模糊
一個產品 / 功能的需求端來自各個部門，其中很多人都沒有產品相關背景，所以討論需求時，難免會讓 PM 有種「你怎麼連話都說不清楚」的感覺，這時 PM 就要扮演循循善誘的角色了（後面會一再出現「循循善誘」的相關例子）。
最近一次發生的案例是，某個部門的 HR 跟我說：「你們這個考核系統用手機真的是太難用了，能改一下嗎？」
在最初設計這個系統時，由於資源有限且當時沒有需求，就沒有考慮到行動版的使用場景（但也沒有完全阻斷行動版的入口），所以的確用手機進入考核系統的網站後，就會感受到一場災難……，但我除了說明這些背景、同意 HR 感受到的痛點之外，也有追問 HR：「是怎麼樣的『難用』呢？我想知道你會常用哪些頁面或功能，我們可以著重改進那些地方，不然整個系統如果都要做成行動版，這樣要等太久了。我們先從最有感的地方改起好嗎？」
所以接下來我們就一起討論，並決定要優先改良行動版操作體驗的部分（比如哪幾個頁面、頁面上的哪些功能等）。這整個過程讓我可以更清楚用戶的痛點、需求到底是什麼；對 HR 來說，他也藉此了解要怎麼把需求說得越來越清楚。
後記：這次優化上線後，我稍微感受到的是，HR 似乎頗有成就感，對產品團隊的信賴感也有提升；若要猜測原因，或許是因為他提的意見和疑問都有被好好解答，需求也有被好好處理吧。
💡 當需求端給的需求 / 痛點太模糊，PM 就是一直往下追問、追問再追問！更多關於釐清需求＆痛點的文章，可以看這裡：
- 產品經理該怎麼處理灰色地帶、模糊不清或未定義的問題？
- 為什麼要做這個產品功能？使用者想要的到底是什麼？論 User story 的重要性
- 身為 PM，該怎麼評估一項新需求？身為需求端，又該怎麼跟 PM 提需求？
2. 需求太不合理
PM 做久了，或許會有一種「什麼需求都有、什麼需求都不奇怪」的麻痹感，但如果照單全收，也很容易造成自己在跟設計師或工程師過需求時被挑戰，所以如果接下了連自己都無法認可的任務，到時累的也是自己……那不如在一開始就先好好把關。
有些需求很具體，但卻「不合理」。但「不合理」又分兩種，一是「痛點本身就不合理（或者痛點並非產品所造成）」，二是「痛點合理，但（需求端提的）解決方式不合理」。
如果是前者，通常我會直接（委婉地）告知對方，這是流程問題、不是產品問題，已經超出產品本身能協助的範圍了。這邊再拿上面提到的考核系統為例，曾有主管反應寫考核的時間太短，希望能有 AI 生成內容、考核模版等輔助功能，以便他在更短時間內寫完所有下屬的年度考核。然而，「寫考核的時間太短」這個痛點並非考核系統所造成，可能是該名主管的時間管理能力有待加強，也可能是公司給的寫考核時間真的太短。
但無論如何，提供「AI 生成內容」或「考核模版」對考核系統這種企業內部工具來說，都不是一個優先級很高的需求，且甚至不太合理。因為「考核」重視的是「品質（主管是否有給出有建設性且務實的意見）」而非「數量（主管完成考核的時間、整體效率）」。
上面說的例子是「痛點本身就不合理（或者痛點並非產品所造成）」，那如果是二「用戶痛點合理，但（需求端提的）解決方式不合理」呢？
有時候 PM 在收到需求時，儘管覺得不合理，但無法馬上說服需求端並擋下需求，或者需求端聽不進去，如果兩邊意見不同，盡量試著爭取時間去驗證這個需求的合理性與效益，比如做用戶調研（用戶訪談或問卷等）、數據埋點 / 撈數據等。
如果時間真的太有限，來不及做上述事情，至少請對方提供更多佐證或資訊，比如先問問需求方：
- 這個需求是怎麼來的？
- 為什麼你會覺得這個需求這麼重要？
- 現在沒有這個功能，那你們是怎麼解決這個痛點？
- 如果我們沒有做出這個功能，會怎麼樣？
- 如果真的做出這個功能，用戶會怎麼使用？他們為什麼會喜歡或想要這個功能？
根據個人經驗，有時候需求端不一定有仔細想過這些問題（畢竟他們上面也是有老闆），可能只是某個主管施壓或隨口提到「如果可以 #$%^ 就好了」，他們就沒想太多來找 PM 討論……，一旦有時間細想，禁不起這些「靈魂拷問」的偽需求就會逐漸消失了。
💡 當需求端給的需求太荒謬，建議 PM 還是要擔任「需求守門員」，別只把自己當成需求傳聲筒，這樣久而久之，只會讓團隊越來越感受不到 PM 的重要性和價值。
3. 時程太緊繃
這應該也是產品開發的過程中必然會遇到的問題，就是需求端期待的時間 vs. 開發端需要的時間很常沒有共識。PM 們應該很常聽到需求端說：「這個很簡單吧？」、「改一下很快吧？」、「這個小東西應該不難做，兩三天能做完吧？」而且，不要以為只有不熟技術的人會這樣說，其實我也很常遇到工程師這樣說！
有時候（尤其做內部產品，其實是「很多時候」）這些需求和時程都擋不住，大老闆就是想要「又快又快」，那麼底下的產品團隊也只能在內心高歌一句「需求來得太快太像龍捲風」（2000 年的杰倫金曲，現在還有人知道這首歌嗎？），然後硬著頭皮加班趕工。
但如果可以，作為 PM 的我還是會盡量跟需求端討價還價，苦口婆心地跟他們說明時程來不及的原因，希望他們可以好好考慮調整預期的死線。在這整個過程中，我的心態都是「寧可囉唆，也不要馬虎帶過」，畢竟還是希望維持和需求端的合作關係，沒有必要為了一個不合理的死線而讓雙方的溝通馬上陷入死局（尤其來日方長，未來搞不好還得跟同一人繼續共事）。
比如一個功能需要 15 個工作天才能做完，需求端卻期待 5 天做完，這時我不會只說「真的來不及」，而是會試著給一些折衷方案，比如：功能可不可以簡單一點？適用的情境可否縮減一些？可否用其他方式達到同樣目的？這時，如果需求端還是不接受，至少 PM 的立場可以是「不是沒有給你選項，而是這些選項你都不要」；如果什麼都沒給，需求端很可能會覺得 PM 沒有在解決問題，這對雙方的合作關係也沒幫助。
雖說不想跟對方交惡，但如果碰到太強硬的需求端，建議 PM 還是得設好底線，並且要好好尊重這個底線！比如上面這些折衷方案都被拒絕的話，我也只能告訴對方：「我有提供這些選項，但如果我們都沒辦法各退一步，那不好意思，我們真的沒辦法在你預期的時間完成你想要的東西」。
作為 PM，有時得勇敢當壞人（或者把主管推出去當壞人），如果碰到什麼需求都照單全收、什麼荒謬死線都答應，最後只會搞得整個產品團隊都在加班趕死線。個人認為「加班是最蠢的解法」，一旦答應了加班，往後有類似情況，很容易給人一種「沒有加班解決不了的問題，如果有，就再繼續加班」。
前陣子耳聞現職公司的某團隊在某地區的工作文化是「直接壓死線，不需工程師估時」。也就是說：不管這個功能要做 5 天還是 50 天，都沒關係，因為工程師的估時是「被」死線決定的，如果平日 8 小時做不完，那就加班；如果還是做不完，那就週末繼續。
作為 PM，個人認為這個工作的職責是「在合理範圍內使命必達」，而不只是那麼簡單的「使命必達」。
4. 開發資源不足
當 PM 終於釐清需求、跟需求端討論好要做哪些東西、協調雙方都同意的死線後，功能終於可以準備進入開發了。但～總是會有那麼一個「但」，可能原本排好的開發資源被借走了，那該怎麼辦？
這又是一個我很常經歷的悲慘情況。我目前負責 4~5 個企業內部產品，在人力有限的情況下，這些產品之間必定得先排出優先級，更麻煩的是，這些產品所屬的工程師們，他們也是一人得兼顧多個產品，所以「工程師得先做哪一個產品」也有優先級，PM 之間也時常需要協調同一個工程師手上的多個產品的優先級。
以我目前負責的某產品來說，已經長達一年沒有工程資源，但產品本身還是有極大量的內部用戶存在，所以 bug 待修清單也只能越累積越長了……。
有的需求端聽完上述情況後，知道再怎麼提需求也沒用，不如繼續忍受現況；但我也碰過非常有毅力的用戶，剛開始是動之以情（「沒有這個功能真的太崩潰啦，每次要手動自己處理都很花時間，能不能幫個忙，請個工程師來看一下，這個功能做起來很快的～」），到後來還搬出他團隊的工程師說之以理（「我們這裡總共有 xx 個團隊都需要這個功能，也能節省大約 xx 的時間，影響非常大的！而且我看了一下，你們改動大概也只需要 xx 天，做起來效益很高」），真的是非常鍥而不捨。
然而，沒資源就是沒資源，再怎麼喬也沒用，最後我還是只能用一樣的原因（真的沒有開發資源）拒絕這位用戶的需求（儘管他的需求真的非常合理、也很值得開發）。
💡 如果做不了這個需求，我還是會建議 PM 就說「現在真的做不了」，不要為了敷衍對方或拖延而說「有機會會安排」或「我們再看看」這種模糊的話，因為這會給需求端錯誤期待，或許過幾天他又會來問「那安排得如何」？PM 能做的就是把這些願望們放到 backlog，之後真的有餘裕時，可以從 backlog（有點像是產品的待辦清單）撈一些功能來做。
5. 需求在最後關頭變動、有臨時插隊的需求
註：這篇文章起筆於 4 月，但東拖西拖就這樣來到了 7 月……不過我也剛好在最近碰到「需求在最後關頭變動」這個問題，剛好可以寫進來分享。
這段又得拿前面的考核系統為例，由於公司固定會在 5 月進行年中考核，所以作為考核系統的 PM，我在 Q1 就會開始跟各部門的 HR 收集需求，這樣才能在四月時整理需求、發想功能，以便後續進入設計與工程階段，等到 5 月的年中考核來臨前，就可以把相關需求都完成並推上線。
然而時間來到四月中，團隊已經準備要開始做某個功能了，這時突然有個公司的高階主管跟 HR 反應，他覺得系統內缺少某個功能，讓他使用上非常困難且困擾，所以要求 HR 想辦法，於是 HR 就找上我了。我和 HR 在最短時間內釐清這個高階主管的痛點、和設計師一起討論解法，結論是：HR 擋不了這個（說話很有份量的）高階主管突如其來的許願，而工程師評估這個功能不算太難做，一週內可以搞定，所以這個需求算是非做不可。
但問題來了：我們在年中考核來臨前已經排滿了開發時間表，沒有那奢侈的一週空檔可以讓這個需求插隊。
這個問題跟上一段提到的類似，就是實務上很難兼顧「最短時間」、「最少人力」、「最多 / 最佳功能」，不過「幸好」這次是需求端（HR）自己先變卦，所以作為 PM 的我更有立場去討價還價。像這次原本已經要做 3 個需求，現在再加進第 4 個的話，要嘛拿原本的需求來換，要嘛延長死線，畢竟凡事都得有個取捨嘛。
剛開始 HR 有點為難，畢竟這些需求已經是他們精挑細選過的，所以他們也不知道該拿掉哪個需求；但 HR 也不能改動需求要上線的死線，因為全公司的考核時間都是一樣的，不能因為這個功能而異動原本的考核時間線。
我也理解他們的猶豫，於是我給了另一個方案：原本做完這些需求後，整批開發團隊要去趕另一個內部系統的功能。如果他們可以自己跟那個內部系統的需求端協商，那我們就有時間可以做這個功能。後來他們真的也協調好了，決定先以考核相關的需求為優先，另一個系統的需求可以暫緩，所以這 4 個需求最後也如期上線啦。
💡 PM 要不斷「提醒（教育）」需求端「什麼叫做『取捨』」，取捨很難，但就是有取捨的必要！如果每一個需求都很重要，那不就代表什麼都不重要了嗎！
結尾：心態的轉變
會想寫這篇文章，一方面是想分享一些工作心得（就如前面幾段寫的），另一方面其實是想記錄自己心境上的一些變化，我就寫在最後這段了。
作為 PM，工作中每天都在面對各界壓力、每天都在喬時間喬人力橋功能，剛開始的我，會想要盡善盡美，覺得重要的事情能做就盡量做。
我永遠記得，加入公司後的第一個中秋節適逢週末，我和幾個同事相約去烤肉，在賣場採買時，手機突然響起，是某個需求端透過公司通訊軟體打給我，要跟我討論某個需求。那時候還很奴（他奴我也奴），他提完需求後，我還真的再打給工程師，問對方一些技術細節。後來回到同事家備料時，我幾乎沒有參與那個過程，因為我一直在打字和講電話……。
現在回想起來，真的很對不起那位工程師（當下也覺得很對不起他，但還是希望能把需求端那邊顧好），也很對不起當時的烤肉夥伴（那個當下我只是『肉身』在現場，但根本沒有參與到活動），以前的自己總是想要多做一些，會為此四處找資源、壓時程、砍規格，需求端的確很滿意，但自己和開發團隊真的好累好累。
經過這幾年後，歷經公司的一些風波和個人經驗，總覺得自己和團隊的努力越來越被當作理所當然 — — 「多做的」被當作「該做的」，而且兩者並沒有得到很不同的迴響或實質鼓勵，久而久之，要說自己的心態被玩壞也好，要說是變得自私 / 務實 / 勢利都好，總之，終於有種「看開了」的頓悟感。
註：這個「頓悟感」是來自很具體的兩個工作上的事件，礙於隱私，這邊不能細說。但這種「頓悟」本來就是很個人的事情，每個人都有不同的「引爆點」，大概真的要碰到了才會知道吧。
現在碰到上面這些情境，第一個念頭不再是「要怎麼才能達到你的期望？」，而是覺得「我何必把自己和團隊逼死？」。
所以呢～現在碰到有需求端想要壓死線，有時候甚至還有些更激動的人會說「我請我主管去跟你主管聊聊好吧？」之類的話，意思約莫就是暗示「既然跟你談沒用，那就叫你主管出來」。
碰到這種，我剛開始還會覺得有點不好意思，不想要因而驚動到我主管，也怕主管難做人。但現在碰到這種人，我會欣然接受……都會直接跟他說「你可以去找我主管沒問題，如果能幫我要到資源就更好了！我也跟組內爭取過很多次了，但就是沒人呀～你去說，或者找你主管一起去說，搞不好更有份量呢！」
我也沒有想要酸對方，而是真心這麼覺得。如果他在我主管那邊碰壁，代表我和主管口徑一致，對方也會更加心服口服、尊重我的判斷與決定。如果主管真的答應了，那這就是另一場我（以及開發團隊）和主管的戰爭了，不過這個和這次談的主題就沒關係，如果真的有碰到（希望不要），再寫成別的主題分享吧。
最後的最後，還是要強調一下，最後這段結語的意思，絕對不是叫大家將就或隨便，該做的還是要好好做！重點是要找到一個「甜蜜點」，也就是在完成（大多數）用戶期待之餘，也要注意自己與團隊的身心是否健康、做的事情是否有價值，而不要淪為需求端的應聲蟲，畢竟這樣長久下來，對自己、對團隊都不是一個很友善且能永續的工作方式。
