前言
需求評審，對於產品人來說是基本功之一。不管所處項目屬於那種類型，需求評審是整個項目環節中不可或缺的一環。
需求評審是項目（功能迭代）進入研發階段的最後一個環節。在我認爲需求評審本質上就是指明目標，拋出問題，安排計劃。
如何做好需求評審，我將結合自身經驗與總結，從需求評審前、中、後三個維度進行說明。
需求評審前
在需求評審前，主要分爲以下三個準備：項目準備、會議準備、會前準備。
項目準備
項目相關背景資料
- 項目背景、項目目標（迭代目標）。
項目產品資料
- 原型、核心流程圖、核心架構、業務專有名稱、功能優先級。
- 通用模塊整理。
項目技術相關參考
- 部分技術調研、關聯繫統對接、關聯繫統改動、相關物料列表（接口、三方平臺信息）。
項目研發相關
- 項目人員、項目預計研發週期。
其它
- 預估風險點、待定點（準備多種方案）
會議準備
會議的形式：線上會議還是線下會議。內部會議還是有相關合作方參與。
不同的會議所要進行準備的方式不同。比如說線上會議，一般會提前創建會議，等待相關人員加入。線下會議則需要提前進行會議地點，會議時間的提前確定。（部分公司會議室有限，需要提前預約或者提前溝通會議室的使用）。
相關人員：這裏分兩種，參會人員和非參會人員。
參會人員要提前梳理，包括相關研發人員、業務人員、對接人員（公司內外），人員確定後，需要進行部分核心人員的時間溝通，防止時間衝突。尤其是在一些合作項目中，相關人員構成比較複雜，需要提前進行時間的溝通。
非參會人員，部分人員屬於非參會人員，但是在整個項目也是不可缺少的組成人員。此時要判斷需求評審會議是否要告知，是否需要郵件抄送。
如果遇到相關人員時間衝突，需提供一些解決方案，例如：提前進行單獨溝通，會後溝通等等。但是在溝通相關人員參會準備時，需儘可能的協調時間，確保所有人相關人蔘與。
會議時間點、預計時長
在相關會議形式、相關人員確定後，結合對應的溝通，調整預期的會議時間。並估算會議時間。
注：一般部分公司會有固定的項目研發週期與階段，此時會有固定的下版本需求評審時間。具體的時間節點是一個多重因素影響的結果。時間的安排，最重要的盡最大可能性保證相關人員的齊全。這樣可以在會議上拋出問題，防止信息差導致不必要的問題。
通知方式：郵件、羣公告、@指定人
在所有準備就緒後，需要考慮通知方式，一般常用的是以郵件的方式進行通知。在郵件中簡述本次需求評審內容，並附相關資料。
如果只是一個內容的迭代會議，可以在羣中進行通知，例如羣公告、@全體消息等。
如果只是小的部分改動的，可能涉及到只是部分端，可以在羣中@指定人。
注：通知方式，具體要結合對應的公司的流程。做到通知到人，有所記錄即可。
會前準備（半個小時左右）
線下會議，需提前進行會議室的準備，機器的調試，相關資料的打印等等，會前10分鐘左右相關人員提醒。
線上會議，直播平臺的熟悉準備，設備的調試。
注：會前準備，主要是排除會前設備故障的大問題，防止會議被其它“干擾”。不然可能會遇到尷尬的事件如會議開始了，投影有問題無法顯示等等。雖然有些時候這些設備管理不屬於我們處理，但是一定要提前有所檢查。線上會議，一定要提前熟悉平臺，不同的平臺可能部分操作不一致，尤其是首次使用時。目前主流的線上會議平臺都可以免費使用，有時間可以自行下載提前熟悉下，畢竟在用到的時候就能從容應對。
需求評審中
在需求評審中，其實最重要的是講，講產品背景、邏輯、需求等等，但是還需要部分進行問、點、記進行輔助。
問：主動進行提問，拋出部分提前準備的風險點問題。
點：事最終要落地到人到崗位，所以在部分重要的事情上，一定要點到相關人員崗位。（注：此處需判斷部分問題是否會上必須提醒）。
記：問題速記，要在對應的間隔時間，採用速記的方式（自己能看懂的方式即可）進行部分問題的記錄。
回顧需求評審本質：講，如何講好，是一場需求評審的核心。
- 思路明確：從什麼地方開始講，在什麼地方強調，什麼地方可以粗略。如何講的思路，需要在會議前進行自我講解流程梳理。如果自己講的沒頭沒尾，可能下面的人聽得就雲裏霧裏了。
- 快慢結合：在講的過程中，要對語速進行有所控制，在覈心流程的部分，講慢點，保證大家全部能夠接收到有效信息，在常用公共組件或非核心功能部分，需要提快速度，減少時間的佔用。
以下是筆者進行一場需求評審的核心流程（個人總結流程，僅供參考）。
- 介紹項目背景，涉及端、平臺都有哪些、涉及哪些部門、涉及協調崗位有哪些，
- 項目做什麼、爲什麼、怎麼做、有什麼要求。
- 引出系統名稱：系統專有名詞，規範名詞（已經有規範約束的名詞，例如：CRM、HRM、DMD）等進行單獨說明，達成大家的共識。爲核心流程說明防止名詞理解的歧義。
- 展示核心流程、核心數據流動方向（端到端，角色角色）、數據交互。提問環節：對應名詞、核心流程進行提問回答。
- 模塊化逐一介紹功能、目標、指標，同時每個模塊完成後，進行提問，拋出問題進行記錄。涉及核心功能，需要提及到具體的人或端。在模塊化中引入對應風險點、待定點、拋出問題進行討論（初步討論，注意時間把控）。
- 進行功能優先級劃分，劃分對應的里程碑節點。
- 整體提問，針對問題進行回答。
- 人員協同安排：根據提前準備的人員項目情況，溝通對應項目衝突情況，估計預計時間（針對計劃進行微調）。
- 同步相關物料整理進度，給出提供的節點。
- 遺留問題整理，約束解決時間（問題+人（部門）+時間）。
- 會後進行部分問題相關人員討論。
需求評審後
- 會上問題總結。
- 涉及需求變動調整。
- 待定問題處理節點整理。
- 部分項目物料提供時間節點確定。
- 歸納至會議紀要。
- 項目排期安排、項目人員協調安排、功能優先級微調等。
- 進行相關會議材料歸納彙總，相關郵件發送。
最後
自我覆盤，總結經驗。什麼地方有不足，如何改進。