又跟研發同學吵了一架

雖然產品經理與研發團隊之間的溝通和協作是項目成功的關鍵。然而，由於立場和視角的不同，雙方在需求評審會上的衝突往往難以避免。

———— / BEGIN / ————

前天需求評審會上，跟研發同學又“小吵”了一架。原因很簡單，我想解決問題，他們想“解決需求”；我想推進項目，他們想推掉項目。

咱們來還原一下這個場景。

當時評審的需求是：

場景1：夜班遇節假日，以0點爲界限，自動拆分爲工作時長（1倍工資）和節假日加班時長（3倍工資）。比如9月30日夜班20:00-次日8:00，期望結果是9月30日工作4小時，10月01日節假日加班8小時。

場景2：節假日夜班，遇工作日，以0點爲界限，自動拆分爲節假日加班時長（3倍工資）和工作日時長（1倍工資）。比如10月3日（法節）安排夜班加班20:00-次日8:00，期望結果是10月03日是節假日加班4小時，10月04日工作時長8小時。

第一輪“質疑”：幹不了？

評審剛開始不久，研發同學就開始了第一輪的“質疑”。

研發說：“需求工作量太大了，計算量太大，我們做不了。尤其是安排夜班時，目前默認都是工作時長，我們的日報、月報等部分，如果要做就得強幹。另外，我們需要處理的場景太多了，根本處理不了”。

客觀而言，實現該需求確實成本高，預估至少56人日。涉及多種班次類型、日期類型、跨天方式、班次屬性等，預計產生48個場景和64個分支。

產品經理（即產品）回覆：“嗯，工作量確實不小，所以咱們只聚集解決關鍵場景。即只做固定班次、只考慮工作日跨法節跟法節跨工作日”。

又問：“日報、月報呢？我們現在的報表結果，都是基於班次的，如果9月30日夜班，只能全部歸屬於9月30日，不能拆分至10月01日”

PM回覆：“咱們先看看工作量，期望還是最好可以拆分，否則用戶看報表數據不一致，可能也不太行”

研發問：“做不了，都沒有班次，工作時長是用應出勤時長-異常時長-請假時長，怎麼生成日報？”

研發小組長在旁友插問：“競品是怎麼實現的？咱們可以看看。”

第二輪“質疑”：競品實現了嗎？

PM說：“主要競品都實現了，每個系統在建設之初就存在較大差異，咱們即使知道競品怎麼做，參考價值也有限，何況很多細節並不能調研，比如日報是否有拆工作時長”

研發問：“肯定不會這麼幹，沒人會這麼處理。”

PM說：“目前沒辦法調研到這種程度，可能他們確實沒這麼處理，也可能是處理了咱們不清楚細節，可以再看看”

第三輪“質疑”：你的鍋？

研發說：“咱們現在就是在開倒車，需要把去年做的日曆功能，完全重做一遍，當時5-6個人幹了1個多月，到現在壓根就沒用到，現在又需要再改回去。”

PM說：“嗯，當時確實考慮的是國際化，所以做了底層日曆相關功能，但現在國際化戰略不是很清晰，那個確實沒辦法放開，咱們只能看看怎麼處理。比如在它的基礎上，封裝一個獨立的邏輯，單獨進行判斷。”

研發說：“那你現在可以保證做了這期後，後續不會再做國際化時，又要改一遍嗎？”

PM說：“我沒辦法保證，企業戰略可能會發生變化，只能說目前確實沒這個規劃。”

第四輪“質疑”：不做是不是也可以？

研發說：“這個需求目前只有幾家客戶，現在也有解決方案，無非就是多創建幾個班次，排班繁瑣，咱們有必要做這個需求嗎？”

PM說：“如果我們要主打製造業，尤其是合資/國際化背景的企業，合規就非常重要。每年大概有11天節假日，每次都需要手動處理的話，效率太低，用戶體驗也很差。第二，現有的解決方案，員工沒辦法連班打卡；第三，我們銷售環節已經承諾了2家客戶，所以做是一定要做。如果工作量大，我可以再調研下客戶場景，咱們進一步聚焦場景解決問題。”

大結局

第一，PM又再調研了2家客戶需求，明確了關鍵場景，收斂了需求場景。即從第一輪收斂48個場景到第二輪10個需求場景，最後一輪，收斂到只有3個關鍵場景。

第二，PM又再調研了2家競品，通過對應產品手冊，明確了它們的解決方案，有一定參考價值，卻有限。

第三，PM和研發都進行了一些妥協。比如日報無法處理，但月報一定要處理；所有異常時長、請假時長等，不再100%按0點進行扣除，而是定義規則爲“遲到優先扣除第一天時長；早退優先扣除第二天時長”；關鍵3個場景的改動，工作量大也必須做。

最後，在第二輪評審時，基於以上信息，很快就達成了共識。

反思

你需要深入理解用戶場景和競品研究。避免評審時陷入被動，確保能有效迴應研發。

你需要懂得切換視角。評審時，你既需要站在用戶視角，堅守底線，也需要站在研發視角，合理取捨。

你需要提前預研。評審前，你最好提前跟核心研發同學溝通，避免所有難題全放到評審會上。

第一，功夫在平常。產品經理跟研發屬於“合作與對立”並存的模式。合作是說屬於同一個團隊，需要協作解決用戶問題；對立是說他們代表各自不同的立場，前者代表用戶的理想立場，後者代表企業的現實立場。

因此，日常工作/生活中，產品經理應主動與研發同學建立良好關係，增進相互理解。例如，選擇靠近研發團隊的工位，參與日常交流；共進工作餐等。後續如果工作中有些“爭執”，不至於弄得“老死不相往來”，畢竟合作纔是你們的常態，而不是對立。

第二，信息與數據透明。你可能比研發同學掌握更多的信息、數據（比如企業的產品戰略變化、用戶信息、用戶數據等），你應該把它們分享給所有的項目成員（即使有些成員覺得不需要）。

比如每次評審前，我一定會同步最近的信息（包含項目預告、項目背景、產品規劃、規劃邏輯、產品運營情況等），讓他們享有信息權與確定感。

第三，數據勝於雄辯。應依靠數據而非主觀觀點來支撐論點。與研發討論時，用數據說話，避免無謂的觀點或邏輯衝突。比如客戶量、需求數、用戶頻次、人效、收入等；

第四，講好用戶故事。如果無有效數據支撐，則一定要有一個好的用戶故事。堅持代表用戶把他們的故事講好，在關鍵用戶故事上，不能做妥協。比如跟研發同學溝通前，至少需要明確1-2個用戶故事（或用戶場景）。

第五，擁有一個好心態。應保持“對事不對人”的態度，理解研發同學同樣如此。不同角色可能導致不同立場和觀點，這是正常現象。將爭執和質疑視爲交流的一部分，避免人身攻擊，保持平和心態，以推進項目進展。

最後，懂得有效取捨。不應固執己見，認爲自己的觀點絕對正確，不容挑戰。在說服研發時，也要重新審視自己的方案和觀點，並在用戶價值和商業價值之間做出有效權衡和取捨。

作者：邢小作，人人都是產品經理專欄作家

來源微信公衆號：產品方法論集散地

題圖來自 Unsplash ，基於 CC0 協議

品牌推廣｜ 內容撰寫｜廣告投放｜培訓合作