作為産品經理，需求評審環節是非常重要的，遇上會溝通的技術皆大歡喜，遇上溝通困難的技術也在所難免。本文作者總結了一些産品與技術在需求評審各個階段中，可能會出現溝通困難的場景、複盤思路和應對建議，希望能給你帶來一些幫助。

入産品坑的這5年，我直接對接工作交流過的技術人員至少50 ，運氣好遇到好交流的技術，與他們進行需求評審時，他們總會非常認真地對自己認知不清晰的地方，以提出問題、同義轉化或作出假設等表達方式進行需求确認，或者将你在需求分析和産品設計之中的不足之處暴露出來，還非常積極地跟你一起讨論解決方案，更有甚者還能為你提供用戶體驗更好的參考設計，讓你的産品之路跟開了挂一樣地輕松、有趣。

運氣不好就會在需求評審時遇到一些“奇奇怪怪”的技術，例如：

• 提前發布了需求評審的相關材料後，技術不會提前閱讀，等評審會上過需求時，技術依然會問一些評審材料中已提到過的需求細節；
• 在需求評審過程中，當你詢問是否有疑惑或者技術難點時，技術穩坐泰山一般不表達自己的觀點，宛如對需求已經了然于胸；又或者提出一些似是而非的問題，當你追問是否有建議時，又不吭氣了，仿佛剛剛提問題的不是他；更有甚者職責分明的質問你：“這難道不是你作為産品該思考的問題？”。

作為産品經理，在需求評審環節能遇上會溝通的技術皆大歡喜，遇上奇奇怪怪溝通困難的技術也在所難免。

當遇到溝通困難的技術時少不得會忍不住吐槽：xxx技術好難搞啊！xxx技術事兒真多！xxx技術不配合産品工作！

說實話我之前也這麼吐槽過，也有過其他産品小夥伴響應我說遇到過同款技術。後面随着對工作的複盤和技術轉産品同學的分享才發現：在産品覺得技術“難搞”的時候，技術可能也是這麼看産品的。

換個角度，假設你是技術，在需求評審環節是不是也會有“一頭霧水”的時候？又或者是“不敢說”的情況？例如：産品給的資料都是什麼呀，東一份西一份的，到底哪個是重點？需求評審的資料要麼全是文字，要麼就一個不帶交互的原型圖，這也太簡單了吧！需求評審時産品講了半天，因為不知道需求背景沒聽懂，提問題反倒被産品說我是在故意找茬？我看到有個需求有問題，想提醒一下産品，一想到之前有遇到過向産品提問題就被怼的情況，還是不說了吧……

還記得之前“産品汪”與“程序猿”因為需求評審意見不合而爆出來的各種熱門文章麼？這些文章會通過文字或漫畫的形式，給讀者還原一些産品與技術在需求評審環節中搞笑、暴力、充滿火藥味的場景，由此火了很多自媒體賬号。這也說明産品跟技術關于需求的“意見不合”是長期存在的共性問題，而這些問題追根溯源實際上都是“溝通問題”惹的禍。

正所謂一個巴掌拍不響，在需求評審環節出現溝通不暢時，必然是雙方都有一定的因素，隻是多與少的區别。

當你遇到在需求評審環節中與技術對接過程中溝通不困難時，不要先急于從技術身上找原因，要先自省，檢查自己有沒有做好自己在需求評審過程中的本職工作。

怎麼進行自查呢？以讓你最崩潰的一次需求評審為基礎進行複盤，回顧一下在你在此次需求評審的各個階段。例如，你為該階段做了什麼準備工作？該階段你是怎樣與技術/産品溝通的？最終造成了怎樣的後果？你當時的情緒是怎樣的？你覺得對方當時的情緒是怎樣的？是否有思考過以下提到過的相關問題？

以下便是我總結的關于産品與技術在需求評審各個階段可能會出現溝通困難的場景、複盤思路和應對建議：

01 需求調研時

作為産品，你是否有做到在需求調研和規劃過程中，就會與技術同步客戶訴求或者産品規劃思路？是否有主動與技術溝通客戶新訴求中有哪些可能會涉及到新技術？

涉及新功能開發或新流程設計時，是否有給技術預留充足的技術選型時間？是否有在條件允許的情況下就讓技術參與與客戶進行需求确認時的需求确認會或者将相關信息事後同步給技術？整個需求調研環節中是否有過技術參與？提升技術的參與感強不強？

建議在每次需求調研結束後第一時間與技術同步信息，主動詢問技術是否有技術難點或者對客戶需求不明确的地方，如果有你則溝通好替代方案或想辦法砍掉後，再拿這些結果找客戶進行重點溝通确認，以确保需求符合客戶需求的同時技術可實現。

這個階段的溝通的技巧在于：選擇合适的場合與時間，主動“勾搭”你的目标人物，将你要說的内容以故事的形式傳遞出去。

例如：午飯時，産品和技術一起吃飯，這時候産品可以“不經意”的說起xxx客戶今天又給我打電話提新需求了，說的是……搞得我不知道怎麼搞，頭都想痛了，你覺得這個需求能整不？如果是技術，同樣可以在午飯時間問産品，今天聽到你好像在跟客戶讨論xx需求，這個是幹啥的？是我們後面要做的麼？是有新的功能還是可以套用現有功能呢？

另外，産品可以通過場景式的“用戶故事”引導技術代入到用戶的使用場景中，便于技術了解用戶需求、對研發難度有所評估。參考表達方式“我作為XXX角色，我希望擁有XXXX需求，目的是XXXX”。例如：當我要買一輛車時，我希望能同時看到尼桑逍客與長安75plus的各項配置，如大小、可選顔色、排量、價格等，好讓我能更方便的對比兩個車的配置哪一個更适合我。

至于為什麼會把這部分放在前面呢？因為需求調研是需求評審的“地基”。需求調研過程中産品與技術溝通良好、對項目的參與感強，才能讓技術同産品一樣，願意把此次要做的需求當作是自己的“孩子”，而不是全靠産品思考及規劃，能進一步地推動後續工作的有效開展，提升溝通的效率，同時雙方也會将需求背景、目标、内容等達成共同的認知，而不是等後期再向技術傳遞二次加工過的内容，導緻技術認知産生片面化。

02 需求評審前

咱們作為産品經理，需要提前準備好需求評審相關的所有資料，并發起需求評審會議。這時候要重點關注的點：評審資料裡包含什麼？是否有做好全部資料中文件名的備注，可以讓人直觀地了解文件是幹嘛的？

會議通知中是否有說清楚資料之間存在什麼關系？如何引導參會人按要求閱讀評審資料？怎麼檢驗參會人是否有在會前按要求完成資料閱讀/會前任務？哪些人必須參加需求評審會議？是否有跟必須參加的人員溝通确認好參與時間内肯定可以到場或遠程參與？

建議在需求評審前提前與主要的技術進行一些有互動性的溝通。例如，針對在評審會議通知的内容中，除了會議通知中必要的：會議主題、時間、地點、參與人、會議形式、會議地點、會議流程之外，一定要把附件的評審材料都包含哪些、閱讀順序是怎樣的講清楚，并設置會前任務。

如針對材料中的一些重點内容進行問題設定，要求哪些參會人員需要在什麼時間之前閱讀完材料并進行回答，以此促使技術提前閱讀材料，給自己預留會前與技術溝通并補充評審材料的時間。

由此可見，如果一個産品能做好需求調研和需求評審前的準備工作，技術能在需求評審前認真熟悉評審材料并進行過思考。等到需求評審時，就隻需敲定一些未被确認的事項及接下來的工作安排，這樣的需求評審效率肯定非常高！

等需求評審時才會真的沒有“硝煙”，而不是産品個人“脫口秀”造成的“全員靜默”。在評審會前有充分溝通的前提下，需求評審會可能就淪為查漏補缺過流程了。

03 需求評審時

有沒有過産品在上面講的“激情四射”，宛若無人之境一般不與技術進行眼神交流、互動問答？又或者一問技術有沒有問題，全場你看我我看你“大眼瞪小眼”，于是默認大家都聽懂了而結束評審環節？

有沒有技術看起來在需求評審時好像都聽懂了，但是等執行的時候卻發現，實際還有好多不清楚的地方？又或者聽産品講需求時會“神遊天外”或者“昏昏欲睡”？

建議産品每講完一個需求關鍵點後，就問下技術是否有問題、是否有建議等多與技術進行互動；如果沒有人回複，就點一個比較相熟或者負責該部分需求寫代碼的技術，讓其同義轉化一下，以确認對方真的有聽懂，而不是産品一人單方面的“演講”，讓技術也聽的“神遊天外”。

有互動的需求評審能讓會議參與的相關人員時刻保持相對集中的狀态，以防參會人被問到時，避免因沒認真聽而無法做出問答反饋所造成的尴尬。

這個環節可能産品和技術最擔心的就是因“情緒失控”造成會議“場面失控”，産品過需求時要思路要比較清晰，才能減少被技術噴的次數，而技術也要以具體問題具體分析的态度向産品提問，而不是抱着“事不關己”的态度把需求評審環節當作過場。

04 需求評審後

作為産品的你是否有做好需求評審會的會議記錄？是否有将評審會議記錄同步給所有參會人和計劃參會但無法參會的人？有沒有做好會後确認工作？是否有明确會後任務的具體執行人、交付時間和驗收标準？如果當前需求評審未通過，是否有确認二次需求評審的時間？

就此我提出以下建議：

首先，一定要将調研紀要整理好同步給所有産品相關人員，包括你的直屬領導、銷售、項目經理、UI、UE、技術、測試、運營等。這一步可以有效減少後期出現問題後“相互甩鍋”的現象，特别是将結果同步了領導知曉，有助于整個進度順利實施或争取資源。

其次，需要與主要的技術再次确認其是否已經明确了自己要做的任務内容、主流程情況等。必要的時候找平時溝通相對比較困難的技術，讓其對自己負責的需求進行同義轉化，簡單複述一遍以确認技術真的已經明白了需求。

最後，每次需求評審結束後對需求評審結果進行複盤：例如，整個評審各個階段是否順利？有哪些可以改進的地方？遇到過哪些問題？如果再遇到了該怎麼避免？哪些技術有一定的産品思維好溝通？哪些技術需要重點關注其對需求的了解程度等。

05 寫在最後

我換過比較多的公司，其中有一家公司在需求評審時就做得比較好：

第一點，有統一的參考模闆，包含會議通知、會議紀要、需求開發确認書、功能清單、數據口徑說明書、郵件彙報等。

第二點，會讓項目的核心技術盡量全程參與需求評審過程，從需求調研到需求評審結束。

第三點，會充分了解客戶各個層級對系統的需求，以用戶故事的方式轉達給技術。

第四點，團隊合作遇到困難時會開會進行複盤，而不是相互指責或則甩鍋。整個需求評審流程一環扣一環形成了閉環，所以經手的産品和項目很少有返工的現象，最多是微調數據口徑，客戶口碑還不錯。

由此可見需求評審的成功與失敗是和産品的成功與失敗直接關聯的。因為需求評審結束後形成的已确認材料，對接下來的研發工作是關鍵的指導性文件，團隊所有人都會以此為目标進行自己的工作安排實現最終的交付工作，所以必須要做到團隊成員通過需求評審實現對需求的認知一緻。

想達到需求評審環節的認知一緻，就需要需求評審在調研時、評審前、評審時和評審後都要做好。可以嘗試使用PDCA循環來管理，事先有計劃（Plan）、按計劃執行（Do）、設定檢查點（Check）、複盤并處理（Act）。

例如需求調研時，列好計劃要調研哪些人、哪些問題、什麼時間完成調研等，按計劃執行調研工作，定期檢查調研計劃是否有按計劃執行，輸出調研報告并複盤調研過程是否順利，有那些經驗教訓可以形成知識庫等。

因此，隻有項目團隊在需求評審過程中達成了共同認知，才能對後面工作的展開形成有效的溝通環境，才是做好産品的底層邏輯。

以上是我對如何形成需求評審閉環的方法論供大家參考，因文字有限，僅列舉部分，希望能對大家在需求評審時有所幫助。如有想詳細溝通的可直接找我交流，非常歡迎大家找我分享或者進一步研讨。

本文由 @瑤妹的分享彙 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部