起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理，遇到很扯的需求，做還是不做？
我們在收集需求時，總會遇到一些看起來不是那么合理的需求，不論是來自用戶、來自調研還是來自老板。這些需求基本都會過濾掉，但不排除有時候這些看起來很扯或者毫不合理的需求，也需要做。這種時候，怎么辦？
我有個朋友，最近又再跟我抱怨，說最近的這段時間，他活得比較擰巴，不能做自己的滋味太難受。
在我的不斷逼問下，他跟我說清楚了事情的來龍去脈。
他們公司最近在拓展一項新的業務，在發展的過程中，他們公司需要和其他公司進行業務上的對接，我姑且稱之為A公司吧。
但是在和A公司的對接過程中他發現，對方公司完全就沒有所謂的對接一說，所有的“對接”都是通過比較傳統的郵件方式來進行的。
這樣的方式，就導致了在整個系統鏈路中一個關鍵的訂單數據不能自動同步。
而這個訂單數據，分成兩部分，一部分業務數據是他們公司自己處理，一部分后置處理是需要A公司提供的。他們公司需要將用戶的信息提交給A公司，然后A公司再將訂單數據返回給他們公司，但是就因為A公司的現狀，導致了整個訂單流程的不連貫。
于是我的朋友向他們公司負責這個項目的重要干系人（我姑且稱之為B吧）建議，這部分的數據就不要在系統里展現了。畢竟也只是一個后置動作，并不影響他們自己系統的用戶使用。對于A公司通過郵件發送過來的數據，就讓他們公司的業務人員自己保存好就行了。
但是B卻提出了一個想法，那就是在他們自己的系統里做一個功能，將A公司通過郵件發送過來的數據（其實就是一個訂單號和狀態），保存到系統里，并且提供查詢。
我的朋友心想，這不就是做一個線上的便簽或者叫Excel嘛，完全沒有必要呀。隨便找個騰訊文檔、飛書文檔或者本地保存都可以呀，何必要自己做呢。
我朋友也將自己的上述想法同B說了，但最終的結果我想大家也知道了，這個需求被批準了。在系統增加一個叫做訂單狀態回傳的功能，也就是將A公司的訂單，通過郵件附件下載下來，然后上傳到他們自己的系統，然后在頁面上可以按照訂單號進行查詢。
這就是我朋友郁悶的地方，那些看似很扯的需求，卻總是需要在不情愿的狀態下去完成。
一、這樣的情況不可避免
不開玩笑，不是我悲觀，也不是我矯情，可現實有時候就是如此，不以我們的意志為轉移。
真相就是，我們每個人都是在妥協中堅持，都是在權衡利弊中推進事情的發展。
生而為人，就會面臨著很多不得不的事情。小時候，我們不得不聽家長的話；上學時，我們不得不聽老師的話；工作后，我們不得不聽老板的話。每個人都是這樣過來的，那些不愿聽話的人，在大家眼里，永遠都是“異類”。
具體到產品經理這個角色，在不懂行的外人看來，頭銜是個“經理”，那至少也是有點權威或者地位的。但實際情況是怎樣，我想身處業內的大家比誰都清楚。
很多時候，作為產品經理，能夠做的決定真的少之又少，能夠確定的內容也是在反復修改中磨合出來的，能夠堅持下去的也是內心足夠強大的。
進一步具體到需求管理這個工作上，作為產品經理，我們需要考慮的是多方干系人的想法，我們需要權衡的是多方干系人的利益，我們需要綜合的是多方干系人的使用體驗。
這些干系人，包括但不限于：領導、老板、用戶、開發、設計、交互、銷售、市場、客服，等等。產品經理就是要在各種角色的需求中，排除那些相互沖突的，尋找那些共同的，也就是所謂的求同存異，然后推動下去。帶著鐐銬跳舞，說的就是我們。
既然產品經理這個崗位，就天然的帶著這樣的屬性，那身為這個崗位下的員工，我們也必然會面臨著這些問題。
想清楚了這一點，也就坦然接受了。我朋友眼里那些看似很扯的需求，也就變得貌似合理了。
二、試著從他人角度考慮
很多時候，我們和別人存在意見的分歧，是因為各自的出發點不同。如果我們試著站在對方的立場上來看待事情，有些問題可能也就不能稱之為問題了。
所謂同理心，就是能夠打破雙方對立的局面，試著了解事情的本真，試著了解問題的本質，抱著解決問題而不是爭論對錯的態度。
也許你會說，如果大家都能夠站在對方的角度上思考問題，那為什么不是別人遷就我，而非要我去遷就別人呢？
這是個好問題，這也是一個無解的問題。如果非要給個理由，那我只能說，想解決問題的是誰，誰就需要進行所謂的妥協。
如果雙方都不愿意讓步，那問題必然無法得到有效的解決，事情也就會陷入永無止境的拉扯狀態。
如果你不想解決，那自然不用考慮所謂換位思考的問題。但是，但凡想要有任何一點突破，這一點嘗試是必須要我們自己去開始的，這關鍵的一步，也必須是我們自己才能踏出。
回到我朋友遇到的問題上來，如果他和B都各自堅持自己的立場，那他們的狀態就會永遠陷入僵局。
我朋友認為B提出的需求沒有任何的價值，不僅不能給產品帶來什么質的提升，反而會增加很多無謂的開發工作量。從投入產出比上來說，這個需求完全不值得做。同時，這個需求的的滿足，其實有很多的替代方案，無論是在線表格還是本地文檔，都可以很好的解決那個所謂記錄的問題。
而B則認為，既然是提供了一整套的解決方案，那必須是任何功能都要滿足的。用戶使用系統時不需要理由，用戶不使用系統時則會找出100個不合理出來。為了避免這種情況的發生，系統所包含的功能，必須100%覆蓋用戶的使用場景。
這時候，如果我的朋友，可以試著站在B的立場上，一切都顯得那么合情合理。因為B是交付方，他是最終面向客戶的人，他所面臨的都是實實在在遇到的問題。他有這樣的述求，肯定是在以往的交付過程中遇到過類似的情況。
當然，我的朋友不能指望B能夠像他一樣考慮問題。
三、回歸到使用者本身上
說一千道一萬，都沒有回歸到使用者本身來得有價值。
其實這個過程就是我們準備用戶畫像的內容，我們需要清楚的了解自己產品的目標用戶是誰。
千萬不要小看這個角色的定位問題，這是非常重要的核心要素。
用戶會在什么場景下使用什么功能，在使用過程中會遇到什么問題，用戶是通過什么方式解決問題，這些統統都是需要我們重點關注的。
舉個簡單的例子，如果一個供貨商（商家），跟你說淘寶APP有多么多么的難用，管理起來又多么多么不方便，你會怎么想？
你肯定會覺得，他們的這些需求都可以忽略，因為他們并不是淘寶的目標客戶群，他們應該去使用千牛（淘寶賣家管理工具）。
從用戶的角度出發，洞察用戶日常的的內容，發現需求并不斷優化。
回到我朋友遇到的問題上來，其實他和B都沒有必要在那個問題上糾結來糾結去，直接找最終使用這個系統的運維人員問問就知道了。
后來的事實也證明，很多時候，用系統的人和做系統的人，想法完全是南轅北轍。他們根本就不關心所謂的記錄問題，他們關心的是另外一個我朋友他們之前完全沒有考慮到的問題（出險后用戶如何理賠的問題）?？纯矗F實有時候就是這么的不講道理。
四、一些想說的話
這個世界，存在即合理。
所謂產品，需求都可以。
只不過我們要想清楚，那些我們自認為很牛逼很哇塞的功能，真的是“用的人”關心的嗎？
而真正“用的人”所關心的那些內容，我們這些“做的人”又真的可以保持敬畏的耐心面對嗎？
專欄作家
明天上線，微信公眾號：明天上線，人人都是產品經理專欄作家。做過運營，當過客服。擅長原型設計、邏輯梳理，目前專注于B端產品領域。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 pexels，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
這是現在工作的困境。
要我去直接對接客戶的話 太多了。
但是從項目實施中間過一道的話，需求又變模糊了。
感覺這種業務流轉不是很正常的方式嗎。商城業務，前期用郵件等線下方式處理多供應商的商品發布或者發貨信息都是這么解決的。不過你背景沒有描述清楚，為啥要單獨開發一個池子保存和查詢？目的是啥？這個信息不應該直接錄入到訂單履約中心去嗎？
你朋友遇到的這個需求并不扯