最近一直在參與各種需求評審會，接觸了很多產品新人，發現好多剛入門的產品新人不太擅長需求評審會，常常是會議時間不受控，結果也未達到預期。趁此機會，將自己的經驗做一個小的復盤，一來形成SOP，二來為產品新人提供一下思路。本次擬從評審前、評審中、評審后三個方面進行描述，希望每位產品經理都能成長為獨擋一面的風云人物。

一、評審前：不打無準備之杖

參加PM培訓課程時，講師說過這么一句話：會議的目的是通過溝通就相關問題達成一致。

需求評審會議也是如此，最重要的目的是確保研發、測試甚至是領導等相關人員對需求的解決方案理解一致。既然是會議，那么組織會議之前一定要明確以下事宜：會議的背景、主題、時間、與會人員，需要討論的重點等，其中會議的主題、時間、與會人員等大家都知道，此文章不再贅述。本文重點梳理產品新人就“會議的背景”及“需要討論的重點”進行解釋。

1） 通知與會方并發送相關資料。

會議之前我們往往會提起通知相關與會方，在通知到大家之后，皮皮建議大家把本次需求評審會用到的：需求業務場景、業務流程圖、頁面線框圖、狀態描述圖等一起發送給大家，確保大家知道此次評審的內容是什么，并可以借助資料快速在大腦中串聯出業務或提前梳理出自己的疑惑或感興趣的點，評審時才能跟上產品經理的思路。

如果時間允許，還可以提前收集好大家有疑惑的內容、未覆蓋的特殊場景，準備好方案，會議統一討論。

2） 提前拋出重點要討論的方案或場景。

需要討論的重點是指本次需求中可能有一些場景由于技術、資源或者其余限制無法明確是否需要采用該種方案。這種一定要在會議前整理出來，并且確保團隊中相關核心人員都知道這是本次討論的重點，方便大家提前準備思路，避免出現討論時同事們有一種“What is he doing”的疑惑。

3）就整體設計思路與方案與主管達成一致。

組織過需求會議的產品兒都知道評審會議常常是跨部門的，把那么多人的時間協調在一起很不容易，所以會議最重要的就是效率。如何提高效率呢？所謂“擒賊先擒王”，組織大家上會前，我們一定要把本次評審你的設計思路、困難和解決方案等統統與相關領導達成一致。

提前搞定boss的好處數不勝數。

• 避免領導在會議上直接對你“發難”，影響你的心態及后續的發揮，而且有時搞定boss，他也會在評審時幫你舌戰群儒。
• 用領導做背書，研發等同事基本會直接“贊同”你的方案，聽起來是有點“狐假虎威”的感覺，但是工作的首要目標是完成任務；
• 有了同盟之后，你的每次會議基本都會比較順利，久而久之你自己也會信心大增，越來越得心應手。

二、會議時：自上而下，逐步深入

經歷過之前的準備工作，基本我們已經成功了40%，接下來只需要在評審時注意以下幾點即可。

1. 會議前我們已經將相關資料發送給參會人員，為避免大家沒有看或時間較久，已經遺忘，我們應該在正式進入功能細節之前先快速梳理本次需求的業務目標。
2. 確保大家明確業務目標之后，進而對業務邏輯進行串聯，注意這個環節需要串聯的是業務邏輯，而非你的頁面功能邏輯。該過程如果涉及到專有名詞或特殊場景應該進行著重解釋。
3. 梳理完業務邏輯之后，還需要對此次業務涉及到的角色或崗位進行描述，旨在讓大家明確該業務涉及多少崗位或角色，每個人負責什么。
4. 梳理完業務之后，才應該進入本次的需求設計，進入詳細設計之前，產品經理應該先對頁面組進行串聯和解釋。
5. 經過上述幾個環節，所有人對需求及角色、頁面等的關系網已經構建了初步形態，接下來我們要做的，是本次需求評審的重點部分，也是最耗費大家精力的部分——各頁面、各功能的細節評審。

通常我在評審頁面時會按照如下思路：

1） 首先描述該頁面需要實現的業務目標是什么，通過這個頁面用戶要完成那些工作，實現什么效果。其次描述哪些人都會操作這個頁面，這些人通過這個頁面功能都做什么事，頁面是否需要做數據權限控制。

大多時候我們也會把幾個事情混合在一起說，如果準備充分，角色或業務復雜時，大家可以列一個簡單的用戶畫像表格，說清楚角色、功能、數據之間的關聯關系即可。很多種方法，大家選擇自己擅長的即可，目的是把事情說清楚。

總之這個環節不要一進來就陷入細節介紹。就好像展臺上放了個大黑塊，臺下的人還不知道這個大疙瘩是啥呢，你就開始說里邊的按鈕了，最終導致的結果就是“雞同鴨講，貌合神離”，這也是很多小伙伴疑惑的明明評審時大家都沒有問題，開發實施時怎么突然就各種說不通的原因。

2）重中之重：逐個講解各個功能需求?。?！

在講解功能時，產品可以先講解這個功能的場景，再講解其操作先決條件，再說做了這個操作之后，系統應該有什么響應或處理，如果涉及到狀態改變，還應該描述其狀態變更情況。

以講解一個新增發貨單的功能為例，我常說的話術是這樣：

庫存操作人員線下收到銷售的發貨單之后會登錄系統，創建發貨申請，點擊：【新增】按鈕，逐步填入發貨及收貨信息相關字段，校驗全部信息填寫通過后進行保存，保存時如果不符合需求文檔描述的規則，按照文檔所述給出提示。

保存成功后，該發貨單的狀態更新為“待提交”。

另外重點補充下，操作人所選貨物庫存不足時，系統應在添加貨物不足提示時，同步告知該貨物的庫管員及采購人員聯系方式，方便其電話溝通。這一點在需求文檔中也有說明。

3） 補充整體說明

當前頁面全部功能描述結束后，如果該頁面有一些別的補充規則，應該同步進行描述，比如：列表排序規則，界面適配顏色要求，字體要求，涉及三方接口等。

4） 答疑及討論

以上環節都結束后，該頁面的需求基本已經結束，我們再進入答疑環節，詢問大家對需求是否有異議或者不理解的地方，逐步解答。如果有會議前收集到的疑問或需要重點討論的內容，也可以放在這個環節。

新的產品兒在評審時一定要不斷告訴自己：我是古希臘掌管需求的神，他們得先聽我說。我最近參與的好幾次評審，新人都是不斷被打斷，常常講這個功能時，別人在問那個場景的問題，節奏完全被打亂，自己講的很痛苦，同事聽的也很云里霧里。

三、評審后：查漏補缺，完美收官

相信前兩部分結束了之后，很多產品人懸著的心終于放下了，畢竟我們的需求評審會議已經完成了90%，但是也別忘記要善始善終哦。

評審會議結束了，但是需求評審還沒結束。產品經理還需要快速根據各方的意見對需求細節進行修改，并將結果同步給相關方。這里有個小建議就是速戰速決，避免拖延導致遺忘部分內容。

四、全文總結

最后對全文做一個總結，組織一場好的需求評審會主要關注以下幾點：