產品經理在推動產品設計落地的流程中，大多會經歷需求評審這一環節，通過需求評審，產品經理可以盡快完善需求，同時加深其他成員對需求的理解。那么，產品經理要如何才能做好一場需求評審？過程中有哪些注意事項？本篇文章里，作者便進行了經驗總結，一起來看一下。

需求評審是每個產品人在產品設計環節都經歷過的重要環節。產品經理需要通過需求評審使團隊成員對需求理解達成共識，并且在這個過程中發現需求不合理的點，從而完善需求。通過評審后的需求才開始真正的推動落地，產品經理也才可以階段性的松一口氣。

需求評審做的好，評審各方皆大歡喜，產品經理邁著自信的步伐走出會議室開始指點江山。做不好，評審各方怨聲載道，產品經理唉聲嘆氣的坐在位置上看著別人離開的背影開始陷入深深的自我懷疑。更有甚者感慨著“此處不懂爺自有懂爺處”打開了招聘軟件。

所以需求評審還是需要我們好好準備，認真對待打贏一場場需求評審會，通過每一次的需求評審會完善產品，并且在這個過程中提高產品經理做產品的信心。

一、糧草先行

自古以來就有“兵馬未動，糧草先行”的重要戰略指導。我們也一樣，需求評審的戰爭在需求評審會之前就已經開始了。要在評審會前準備好從充足的糧草，也就是需求評審會需要用到的各種資料。

1. 需求的介紹資料

從需求提出的背景、所屬業務的現狀、目前暴露的問題和期望得到的結果四個方面準備介紹內容。

除自己描述的內容外，爭取根據業務屬性準備一些與需求背景、場景相關的圖片/視頻材料，用戶反饋，行業文章，政策性文件等材料輔助各方人員能夠更容易理解需求內容。

2. 需求的設計方案

提供產品經理進行需求設計時的產出物，如流程圖、腦圖、原型、需求文檔等。一般流程圖、腦圖、原型是會經常被翻閱和評審的，因為圖的形式更易理解和傳播。

而需求文檔則可以根據所屬團隊的工作習慣來判斷此時提供的需求文檔的顆粒度甚至是否提供。比如我所經歷的團隊，有的需要在評審前準備好詳細的需求文檔，否則研發同事就認為產品經理的工作還沒完成，不愿意此時參加評審會。

也有的不需要準備需求文檔，評審時僅根據原型來確定大部分的功能，具體的細節功能會后再通過詳細的需求文檔提供給研發同事即可。

有條件的話也可以提供產品經理在思考需求設計過程中的思路歷程，將自己的思考過程和歷史設計版本介紹給大家，引導大家跟著自己的思路了解到自己當前的設計理念。

3. 重難點的解釋資料

針對需求和設計中的重難點部分，可以突出進行專門的介紹，有利于各方快速找到并了解和理解重難點內容。

4. 需要討論的內容清單

一些情況下我們在評審時并不是已經具備十分完善的方案了，可能是已經完成了百分之九十的內容，還有百分之十的內容是仍有疑問的或者多個方案等原因需要多方一起討論解決的。

這部分內容可以提前梳理清晰，可以讓各評審方一目了然的了解到你在需求設計中的疑惑和需要大家解決的主要問題。

5. 推演問題的答案

這份資料就不是給大家準備的了，而是給自己準備的。我們在需求評審前，作為需求的設計者，應該是最了解這個需求設計的人。關于這個設計有哪些點可能是會被別人關注而可能會被詢問的，我們應該有一定的預判，從而提前做好合適的答復。

避免在評審會時的公眾場合出現產品經理被問倒、答非所問、答案出錯等尷尬的情況，這些情況的發生對我們產品經理在團隊中的影響力和信譽度是有高度負面影響的。

二、逐個擊破

準備好相關資料后，先別著急拉著大家一起開會評審?？梢誀幦≡谡降脑u審會前就將關鍵評審方逐個擊破。

也就是在正式的評審會前可以與各個評審方分開溝通，爭取在會前就發現和解答各方的疑惑，發現和完善需求設計的方案，并達成相同的共識。

畢竟一場需求評審會涉及的部門、崗位較多，每個人因為角色不同所關心的部分和期望的效果都有所差異。

如果全部寄希望于在一場數小時的公共會議上能夠與各方達成一致，有一定困難。且不可控因素與負面效果的情況發生幾率也較大，會議的效率與質量就無法得到保證。

如果能在會前就可以解決各方大部分問題，會上與各方再次進行確認即可。這樣需求評審會的過程就處于可控的狀態，有利于我們得到想要的結果。

我在工作中遇到過有的同事在會前沒有和自己的領導確定方案，導致會議剛開始，方案還沒講完，就被自己的領導否掉了?？上攵@樣的場景有多尷尬，其他參會人員都會覺得你們內部意見都還沒有統一、方案不成熟，不具備評審條件，評審會也算是直接被結束了。

還有的同事和沒有和研發同事溝通，在會議中與研發變成了討論模式，討論方案實現方式和各處細節的處理，結果是所有人員陪著開了一天會，都還沒有拿到確定的結果。

更有甚者需求評審會變成了戰斗模式，產品和研發僵持不下，相互輸出不符合社會主義價值觀的話語，會議被迫終止。

如果需求評審會發生了這些情況，評審各方一定會懷疑我們作為產品經理的綜合工作能力。產品經理是應該作為產品的意見領袖核心形象存在，而不是一個讓大家覺得只會浪費大家時間的角色。

所以需求評審并不是把功夫都只花在需求評審會上，在一定程度上來講，需求評審的大部分工作在需求評審會之前就已經基本完成。

三、馳騁疆場

會前工作做的好，到了需求評審會時壓力就會小很多了。不過雖然在會前已經和各方基本達成共識，但需求評審會時還是不要掉以輕心，仍要全力以赴。

在多方參與的情況下可以挖掘到讓方案更加完善的點，同時讓各方收獲良好的會議經歷，最終實現在公共會議上通過需求評審的目的。

在會議開始時，先描述需求背景，將自己準備的需求介紹資料娓娓道來，讓大家進入到你的故事場景中。接著展現你的設計方案，帶著大家一起理解你的需求設計。之后指出重難點部分，并著重展開介紹。

需求評審會的前半部分基本作為產品經理個人show time，是作為B端產品經理的我們為數不多的可以個人演講的機會，這種場合一定要把握好機會馳騁疆場。

即鍛煉自己的演講能力，也提升自己在團隊中的影響力，爭取用一場生動的演講讓大家為夢想窒息！

方案的介紹完成后，打開需要討論的清單，各方就可以針對方案設計中關注的部分展開討論，對仍有疑惑的地方展開問答。

而你應該已經推演過可能的問題與答案，可以做到胸有成竹、游刃有余的主持討論、回答問題。

由于關鍵方在會前已經和你就方案設計進行過討論并且達成共識，所以這里主要注意在會上額外發現的需求可完善點和各方需要其他方協調和依賴的工作。

如果出現了關鍵性的問題仍然要認真對待，會上積極協調和解決。而出現的無關緊要的問題則可以保持尊重的態度禮貌的告訴各位”：我后會考慮把這里補充完善，這里不占用大家時間討論?！?/p>

或者為了讓對方不糾結于這些無關緊要的地方也可以直接讓步將部分優先級低的設計按照對方的要求調整。

而如果已經做好了上述工作仍然出現了無法達成共識的重要問題，可以綜合各方提出的情況和自己的分析找到關鍵決策者做定奪，借助關鍵決策者的力量定下方案調整，避免會議和方案陷入僵局導致工作無法推進。

四、持續跟進

各方對于需求的方案設計沒有較大異議的情況下，通常就可以結束會議也代表著需求評審會通過了。但是這并意味需求評審會的工作到這里完全結束了，會后還要持續跟進下列事項。

1）方案的調整完善。根據會前會中與各方討論的情況，將判斷需要調整的內容進行完善。

2）可能的再次小范圍評審。內容調整后，與涉及的相關方可以進行小范圍的再次評審，告知方案調整內容。

3）確定人員與排期。最終關鍵評審方都知曉和確認最終方案后，與相關方如UI、UX、研發、測試等部門、確定具體負責人員與日期安排。

4）會議紀要廣而告之。完成了上述內容之后，還要記得留下書面痕跡與證據?？梢詫⑿枨笤u審會的會議內容與會后安排的情況通過會議紀要的文檔形式用郵件、微信等方式廣而告知所有評審方，避免發生問題出現責任推諉、耍賴的情況發生！

五、最后

我們能切實地感受到，一場好的需求評審除了對產品的設計有莫大的益處，對我們產品經理的自信的提升也有很重要的影響。

很多產品通過需求評審獲得一次次的正反饋便更加堅定了做產品的信念，也有一些產品不能收獲到正反饋而漸漸喪失信心。所以需求評審是真正值得我們精力去認真對待的一件事情。

尤其是B端產品面對的是更加專業的業務背景，需求評審時產品經理需要Hold住全場，獲得大家的認可。讓大家知道你是懂業務懂產品有實力的選手，在這行人人都是產品經理沒那么簡單！