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

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

關(guān)于「需求評審會」的個人目標

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

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

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

比如：向開發(fā)團隊、測試團隊展示自己嚴謹?shù)乃季S邏輯和出色的產(chǎn)品設計能力，這是一個偏個人的目標。

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

關(guān)于「需求評審會」的原則

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

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

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

其實產(chǎn)品經(jīng)理和開發(fā)團隊、測試團隊應該是一個「配合」的過程，也就是說在產(chǎn)品經(jīng)理的基礎(chǔ)方案上，不斷的優(yōu)化和調(diào)整的過程，如果開發(fā)同學有更好的想法，產(chǎn)品經(jīng)理就應該去采納?？涩F(xiàn)實情況是，很多產(chǎn)品經(jīng)理礙于「面子」問題，總覺得必須聽我的，別人說的「對」或者「不對」我都不管，一直在單方面的堅持自己。這就很沒必要了，對吧?

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

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

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

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

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

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

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

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

四、「不管現(xiàn)場狀況多么惡劣，產(chǎn)品經(jīng)理不可露怯，不可紅臉，不可出言不遜」

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

關(guān)于「需求評審」的三個階段

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

產(chǎn)品經(jīng)理在這個階段需要注意幾點。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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