最近一直在參與各種需求評審會，接觸了很多産品新人，發現好多剛入門的産品新人不太擅長需求評審會，常常是會議時間不受控，結果也未達到預期。趁此機會，将自己的經驗做一個小的複盤，一來形成SOP，二來為産品新人提供一下思路。本次拟從評審前、評審中、評審後三個方面進行描述，希望每位産品經理都能成長為獨擋一面的風雲人物。
一、評審前：不打無準備之杖
參加PM教育訓練課程時，講師說過這麼一句話：會議的目的是通過溝通就相關問題達成一緻。
需求評審會議也是如此，最重要的目的是確定研發、測試甚至是上司等相關人員對需求的解決方案了解一緻。既然是會議，那麼組織會議之前一定要明确以下事宜：會議的背景、主題、時間、與會人員，需要讨論的重點等，其中會議的主題、時間、與會人員等大家都知道，此文章不再贅述。本文重點梳理産品新人就“會議的背景”及“需要讨論的重點”進行解釋。
1） 通知與會方并發送相關資料。
會議之前我們往往會提起通知相關與會方，在通知到大家之後，皮皮建議大家把本次需求評審會用到的：需求業務場景、業務流程圖、頁面線框圖、狀态描述圖等一起發送給大家，確定大家知道此次評審的内容是什麼，并可以借助資料快速在大腦中串聯出業務或提前梳理出自己的疑惑或感興趣的點，評審時才能跟上産品經理的思路。
如果時間允許，還可以提前收集好大家有疑惑的内容、未覆寫的特殊場景，準備好方案，會議統一讨論。
2） 提前抛出重點要讨論的方案或場景。
需要讨論的重點是指本次需求中可能有一些場景由于技術、資源或者其餘限制無法明确是否需要采用該種方案。這種一定要在會議前整理出來，并且確定團隊中相關核心人員都知道這是本次讨論的重點，友善大家提前準備思路，避免出現讨論時同僚們有一種“What is he doing”的疑惑。
3）就整體設計思路與方案與主管達成一緻。
組織過需求會議的産品兒都知道評審會議常常是跨部門的，把那麼多人的時間協調在一起很不容易，是以會議最重要的就是效率。如何提高效率呢？所謂“擒賊先擒王”，組織大家上會前，我們一定要把本次評審你的設計思路、困難和解決方案等統統與相關上司達成一緻。
提前搞定boss的好處數不勝數。
- 避免上司在會議上直接對你“發難”，影響你的心态及後續的發揮，而且有時搞定boss，他也會在評審時幫你舌戰群儒。
- 用上司做背書，研發等同僚基本會直接“贊同”你的方案，聽起來是有點“狐假虎威”的感覺，但是工作的首要目标是完成任務；
- 有了同盟之後，你的每次會議基本都會比較順利，久而久之你自己也會信心大增，越來越得心應手。
二、會議時：自上而下，逐漸深入
經曆過之前的準備工作，基本我們已經成功了40%，接下來隻需要在評審時注意以下幾點即可。
- 會議前我們已經将相關資料發送給參會人員，為避免大家沒有看或時間較久，已經遺忘，我們應該在正式進入功能細節之前先快速梳理本次需求的業務目标。
- 確定大家明确業務目标之後，進而對業務邏輯進行串聯，注意這個環節需要串聯的是業務邏輯，而非你的頁面功能邏輯。該過程如果涉及到專有名詞或特殊場景應該進行着重解釋。
- 梳理完業務邏輯之後，還需要對此次業務涉及到的角色或崗位進行描述，旨在讓大家明确該業務涉及多少崗位或角色，每個人負責什麼。
- 梳理完業務之後，才應該進入本次的需求設計，進入詳細設計之前，産品經理應該先對頁面組進行串聯和解釋。
- 經過上述幾個環節，所有人對需求及角色、頁面等的關系網已經建構了初步形态，接下來我們要做的，是本次需求評審的重點部分，也是最耗費大家精力的部分——各頁面、各功能的細節評審。
通常我在評審頁面時會按照如下思路：
1） 首先描述該頁面需要實作的業務目标是什麼，通過這個頁面使用者要完成那些工作，實作什麼效果。其次描述哪些人都會操作這個頁面，這些人通過這個頁面功能都做什麼事，頁面是否需要做資料權限控制。
大多時候我們也會把幾個事情混合在一起說，如果準備充分，角色或業務複雜時，大家可以列一個簡單的使用者畫像表格，說清楚角色、功能、資料之間的關聯關系即可。很多種方法，大家選擇自己擅長的即可，目的是把事情說清楚。
總之這個環節不要一進來就陷入細節介紹。就好像展台上放了個大黑塊，台下的人還不知道這個大疙瘩是啥呢，你就開始說裡邊的按鈕了，最終導緻的結果就是“雞同鴨講，貌合神離”，這也是很多小夥伴疑惑的明明評審時大家都沒有問題，開發實施時怎麼突然就各種說不通的原因。
2）重中之重：逐個講解各個功能需求！！！
在講解功能時，産品可以先講解這個功能的場景，再講解其操作先決條件，再說做了這個操作之後，系統應該有什麼響應或處理，如果涉及到狀态改變，還應該描述其狀态變更情況。
以講解一個新增發貨單的功能為例，我常說的話術是這樣：
庫存操作人員線下收到銷售的發貨單之後會登入系統，建立發貨申請，點選：【新增】按鈕，逐漸填入發貨及收貨資訊相關字段，校驗全部資訊填寫通過後進行儲存，儲存時如果不符合需求文檔描述的規則，按照文檔所述給出提示。
儲存成功後，該發貨單的狀态更新為“待送出”。
另外重點補充下，操作人所選貨物庫存不足時，系統應在添加貨物不足提示時，同步告知該貨物的庫管員及采購人員聯系方式，友善其電話溝通。這一點在需求文檔中也有說明。
3） 補充整體說明
目前頁面全部功能描述結束後，如果該頁面有一些别的補充規則，應該同步進行描述，比如：清單排序規則，界面适配顔色要求，字型要求，涉及三方接口等。
4） 答疑及讨論
以上環節都結束後，該頁面的需求基本已經結束，我們再進入答疑環節，詢問大家對需求是否有異議或者不了解的地方，逐漸解答。如果有會議前收集到的疑問或需要重點讨論的内容，也可以放在這個環節。
新的産品兒在評審時一定要不斷告訴自己：我是古希臘掌管需求的神，他們得先聽我說。我最近參與的好幾次評審，新人都是不斷被打斷，常常講這個功能時，别人在問那個場景的問題，節奏完全被打亂，自己講的很痛苦，同僚聽的也很雲裡霧裡。
三、評審後：查漏補缺，完美收官
相信前兩部分結束了之後，很多産品人懸着的心終于放下了，畢竟我們的需求評審會議已經完成了90%，但是也别忘記要善始善終哦。
評審會議結束了，但是需求評審還沒結束。産品經理還需要快速根據各方的意見對需求細節進行修改，并将結果同步給相關方。這裡有個小建議就是速戰速決，避免拖延導緻遺忘部分内容。
四、全文總結
最後對全文做一個總結，組織一場好的需求評審會主要關注以下幾點：
本文由 @皮皮是個寵物 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。