很多產品經理談到需求評審都會心理咯噔一下，面色不大好，因爲總被虐的不要不要的，陰影面積不知道有多大。而相反有些產品經理卻對需求評審情有獨鍾，享受與各路大俠切磋、舌戰羣雄的快感，大有三國諸葛亮舌戰羣儒，排除衆議之勢。
接下來，先看下需求評審是什麼？
需求評審簡單來說就是一個評議、審查、明確需求、統一思想並確定實現過程的會議，俗稱撕逼大會、挑刺大會、逼死產品經理大會，是產品經理不得不面對的大會。
產品經理在大會中，要對需求及方案進行講解，並解答市場、運營、設計、技術、測試提出的各種疑問，最終號召大家一起往一個產品目標努力奮鬥。
那麼爲什麼要進行需求評審呢？
1.讓與會者明確需求是什麼，做這次需求對應的業務背景和目的是什麼，處於什麼樣的戰略位置，重要性如何
2.讓市場、運營、設計、技術、測試等各工種對需求的實現過程和方法達成一致，避免後續的撕逼
3.讓市場和運營提前瞭解項目，提前進行後期市場的推廣及運營的準備
4.讓技術和測試對產品方案有詳細的瞭解，對有問題的點進行提前提問質疑，以便後續能進行高效的開發
5.讓設計、技術及測試評估各自的工作內容及工時以確定方案實現的週期，並和市場及運營確定業務的重要性，看是否要進行模塊拆分，分期進行
所謂知己知彼者，百戰不殆，所以一定要明白各與會人員的需求，具體整理如下：
明確上面三個問題後，接下來從“評審會前、評審會中、和評審會結束”三階段如何做好對應的工作。
一、需求評審前
1.和市場及運營再次明確需求，及對應的解決方案是否滿足業務的需要
2.將需求、實現方法和核心人員小範圍提前溝通，提前消滅掉核心問題，保證整體方案沒有出現方向性錯誤
3.確認需求文檔、流程圖、原型是否都有完成，是否已經自查沒有問題
4.和核心與會人員進行時間的調解及確定
5.至少提前2天發出會議邀請，定好會議室（注：會議邀請要附需求文檔、流程圖、原型圖等相關資料）
6.提前到會議室，過一遍講述流程，對可能被問到的點進行整理
二、需求評審中
產品新人在進行需求評審時經常犯的錯有：
1.一上來就開始講具體功能
2.什麼功能都講，滿面開花
3.對別人提出的質疑，不能給出實際解決方案就開始互懟
針對上面的問題，我們如何進行解決呢？
1.會議開始時一定要先講需求背景和目的
很多產品經理在會議一開始就直接說功能或方案細節，這個功能實現了什麼，那個方案具體怎麼實施。試問，如果看一本書，直接看某一頁，你知道整本書是要說什麼？
所以，開頭一定要提綱挈領，說明需求的背景和目的，引導大家進入正題。讓大家都知道，爲什麼產品要進行該方案的設計。
2.要懂得抓大放小，重主幹輕枝幹
如果你滿面開花，首先是時間肯定不允許；其次參會人員會很不耐煩；更重要的是不能針對核心問題深入討論，確定解決方案。
所以，一定要針對主幹流程和核心功能進行詳細講解，對次要的比較常見的功能一筆帶過。比如電商類產品，要對用戶購買支付流程及訂單流程進行詳細講解，對於簡單的簽到、密碼修改等小模塊一句帶過就好。
3.短時間解決不了的可以記錄，會後進行討論
正常情況，核心功能是要在會前小範圍討論確認過的，會議上不會出現這樣情況。但是，不排除會出現之前遺漏的情況。
面對這樣的情況，就比較考驗產品經理臨場發揮能力，能解決的直接會上說出自己的解決方案，一起討論。如果暫時沒有想到合適的方案，而且需要會後進一步和其他部門確定的，可進行記錄，會後討論。
千萬不要不懂裝懂，和別人互懟。這會直接讓自己的信任度直接受到10000點暴擊，讓其他人覺得這產品經理不專業、不靠譜。
當然，作爲會議，肯定是有一套標準的會議流程作爲講解指南，這樣纔可以從大方向把控產品的節奏，不至於被別人帶跑偏。下面的會議流程圖，作爲參考：
三、需求評審後
是不是審覈後，沒啥事了呢？
童鞋該醒醒了，還有一大堆內容要你去處理呢，哪有開會後不總結整理的道理。我們在評審會議後需要做的內容有：
1.整理遺留問題，找相關人員溝通解決，給出對應的解決方案
2.發出會議記錄，每個問題都要有行動計劃
3.發出修改後的需求文檔、原型
4.明確責任人及反饋排期
注：如果需求評審涉及到方案的大改，則需要重新針對新的方案進行評審。
說起來容易，做起來難，還是需要童鞋們在理論和實踐中不斷去磨練和提高。在不斷被虐之後，我們的溝通能力、思考能力、統籌協調能力都會不斷的提高。
相信哪天你也可以和諸葛先生一樣，舌戰羣雄，想想就覺得自己牛逼的不要不要的。
作者：紫川君(產品設計及生活感悟隨筆作者) 公衆號：產品設計星球