你還記得自己參加過多少場「需求評審會」嗎?不管自己是作為主機主導，還是作為僚機配合，「需求評審會」的現場都是讓人不明覺厲。而產品經理就是在這一個又一個的「需求評審會」中磨練過來的，是一個真正刷怪升級的過程。據說「需求評審會」又名「撕逼大會」，你可以感受下這其中的畫面感。

產品經理組織的「需求評審會」類似多方會談，與會人員很容易進入角色后產生「自主」情緒，形成正反兩派甚至是多派，最后由「討論」演變為「辯論」，有點類似「奇葩說」的形式。產品經理在這個「辯論」的過程中，不斷展示自己的觀點，希望獲得更多的認可，可不少產品經理都在這個「辯論」的過程中把自己搞的傷痕累累，十分狼狽。

關于「需求評審會」的個人目標

產品經理需要明確自己在這次「需求評審會」的個人目標是什么。這個目標是制定給自己的，而非給團隊制定的，說白了就是通過「需求評審會」達到什么效果。

比如：讓開發團隊、測試團隊的同學能認同自己本次迭代的產品方案，這是一個非常務實的目標。

比如：讓開發團隊、測試團隊知道自己和設計師在產品策劃階段盡了多大的努力和嘗試，這是一個展示設計團隊的目標。

比如：向開發團隊、測試團隊展示自己嚴謹的思維邏輯和出色的產品設計能力，這是一個偏個人的目標。

雖然出發點不同，但這些都算是一個前置條件。

關于「需求評審會」的原則

一、「不要試圖將自己的想法移植到別人的大腦中」

首先產品經理需要明確一點，我們召開「需求評審會」不是為了「移植想法」到別人的大腦中，而是通過「引導」和「討論」磨合得出大家都認可的產品方案。

我參加過不少「需求評審會」，產品經理們都是抱著「移植想法」、「說服你」的態度在進行需求宣講，產品經理絞盡腦汁把自己的想法「移植」到開發、測試同學的大腦中，可想而知這個過程是多么的痛苦;雙方又為了「說服」彼此，必然會找出自己經歷過的項目中比較極端的案例來支撐自己觀點，可想而知這個過程又是多么的火爆。

其實產品經理和開發團隊、測試團隊應該是一個「配合」的過程，也就是說在產品經理的基礎方案上，不斷的優化和調整的過程，如果開發同學有更好的想法，產品經理就應該去采納。可現實情況是，很多產品經理礙于「面子」問題，總覺得必須聽我的，別人說的「對」或者「不對」我都不管，一直在單方面的堅持自己。這就很沒必要了，對吧?

二、「不要在不同觀點上過于糾結，浪費時間」

我們本著「求同存異」的觀點來進行問題的「討論」，也就是說大方向相同，小細節可以有不同觀點，并且鼓勵大家表達出自己的觀點，產品經理的「開放」心態是很重要的。

在整個需求評審的過程中一定有不少大大小小的問題，對于彼此認可的地方我們確認完畢后快速帶過，對于彼此不認可的地方我們不再糾結，如果討論了5分鐘以上仍然沒有結論，產品經理就記下這個問題，先進行后面的內容，最后再掉回頭來討論之前有爭議的問題。

我經歷過一場很煎熬的「需求評審會」，從下午13：30一直持續到19：00左右仍未結束，原因就是由于產品經理沒有控制好問題討論的時間，以及細節討論的顆粒度，導致需求評審的戰線拖的很長，而且效果非常一般，大家苦不堪言。

三、「要給所有人明確本次需求評審會的背景及目標」

很多產品經理在「需求評審會」剛開始的時候就講交互流程，功能feature，這是大忌。大家都還沒有摸清狀況呢，怎么會進到你的流程中呢?又怎么能找到里面的細節問題呢?又怎么會認可你的方案呢?

所以產品經理在最開始需要給大家「調頻」，讓大家都到一個頻道上來。其實就是需要產品經理在「需求評審會」開始后先別急著講交互和功能，而是給大家介紹一下我們這個版本要「做什么」，「為什么做」，「有什么價值」這三個方面(其實也是做產品規劃時需要考慮的)，這也就是所謂的背景和目標。

這里其實也符合「金字塔原理」中的背景→矛盾→問題-解決辦法的思維模式，我在曾經的文章中有做詳細的描述。你可以點擊查看：產品經理必備技能：金字塔思維。

四、「不管現場狀況多么惡劣，產品經理不可露怯，不可紅臉，不可出言不遜」

在「需求評審會」的現場難免會遇到各種意外的狀況，不管發生了任何事，產品經理需要時刻謹記兩個字「隱忍」，不管任何觀點都要冷靜客觀的表達出來，千萬不要沒有控制好自己，把某些觀點加上了自己的主觀色彩，這樣就把一件簡單的事變的復雜了。

關于「需求評審」的三個階段

第一階段：「需求評審會」前

產品經理在這個階段需要注意幾點。

①提前3天與開發、測試、設計等團隊溝通協調時間，確保關鍵角色都有時間可以參加，最后確定好「需求評審會」的時間安排，訂好會議室，發出會議邀請，并拉好RTX工作討論組周知大家。簡單來講就是：哪個版本、哪些人、在哪、開會。

②提前2天將「產品交互原型」、「產品需求文檔」通過郵件及在RTX討論組發文件的形式發送給與會成員，并嚴格要求與會成員必須抽時間查閱相關文檔，并提出自己的問題。

③提前1天收集大家對于本次評審內容的問題，匯總好問題后逐一解答，以郵件的形式統一回復給大家。根據問題修改文檔，最后再次提醒大家「需求評審會」的時間、地點。

這也就是「需求評審會」的黃金72小時。我們要利用好這72小時，提前做好準備，將會大大提高「需求評審會」的效率，而且可以有效降低產品經理被誤傷和蹂躪的概率。

第二階段：「需求評審會」中

「需求評審會」說白了就是一次面對面的「討論會」，所以「中」這個環節是重中之重，不可怠慢。因為之前我們已經做了充足的準備，所以要放松一點，當成自己的「脫口秀」演講就好了。

①告訴大家我們這個迭代要為用戶講一個什么故事(做什么)，這個故事是怎么來的(為什么做)，用戶看完這個故事能得到什么(有什么價值)。這也是一個標準的背景和目標陳述的方式，切忌上來直接講交互、講功能，同時還要回想一下自己對于這次「需求評審會」的個人目標是什么。

②好了，我們進入到真正的主題了，開始講解這個迭代的功能點、產品交互原型、產品需求文檔，每個功能點逐一講解，事無巨細，不要有任何遺漏。講解的順序一定是先從功能點開始，然后講原型，最后才是需求文檔，一個由點及面的過程。

這時候我們普遍會遇到這幾種狀況。

第一種：你認可我的方案，這種是最理想的狀況，也是產品經理最期望的狀況，擼起袖子開工就好了。

第二種：你認可我的方案，但你有更好的想法，這也是一個非常和諧的狀況，整個屏幕滿滿的充滿了愛，優化細節，只會讓產品邏輯和策略變的更加完整，這種狀況甚至要好過第一種。

第三種：你不認可我的方案，你有更好的想法，OK，我們在這個狀況下先討論下關于背景和目標，這些你是否認可呢?如果認可目標，那我們來聽下你的方案，如果確實可行，我來調整，然后擼起袖子開干。如果不認可目標，我需要不斷的說服你(這里需要控制時間)，讓你認可這個目標，然后再擼起袖子開干，只不過這種很少見到。

第四種：你不認可我的方案，但你也沒有更好的想法，這個…你確定這個人不是無間道嗎?這種情況也非常少見。

③經歷了暴風雨后，我們已經可以看到了一些曙光了，稍安勿躁，勝利是屬于我們的。這時候「需求評審會」其實已經接近尾聲了，只是要提一句，關于細節討論顆粒度的問題，討論雙方必須站在同一個層面討論，已經下結論的地方不再重復，只討論同一個緯度的問題，不能我還在跟你講功能需求，你已經在跟我討論代碼的指針應該放在哪里。

噢，對了，所有討論的問題記得都寫在本子上。

第三階段：「需求評審會」后

①會后及時輸出會議紀要，羅列清楚問題或者爭議點，已經形成結論的地方就不再贅述，待確定的問題繼續找相關負責人進行討論，直到得出最后的結論。

②最后的最后，一封華麗麗的郵件周知給全部與會成員，郵件內容包括需求評審的爭議點和結論，最最最重要的是要將更新后的需求文檔發出來給大家。

③最后的最后的最后，督促開發、測試同學評估開發、測試周期，給出時間節點。

以上，一次費心費力的「需求評審會」終于完成了，從開始組織到最后的確認郵件，無一不飽含產品經理的汗水和淚水，但是一次好的「需求評審會」是會為產品的健康成長增加助力的，所以再多的付出都是值得的。

從目前實踐來看，產品經理在「需求評審會」上最好的開場就是自我總結，并且送上酸奶。一般比較復雜的迭代，在開場的時候我都會先總結一下自己在上個版本中作為產品經理，自己的過失有哪些，不要琢磨這么做是不是丟面兒了，其實開發和測試同學也都非常關心產品，所以想知道產品層面決策有哪些是對哪些是錯。而這種態度，是非常能夠得到他們認可的。我們不是經常說，產品如人品嗎?就是這個意思。