起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求評審指導方案：如何才能不被研發圍攻？
最近產品評審有同事被噴到桌子底下了，我也被噴到桌子底下了，所以在被教育后寫了篇評審指導方案，希望對自己，對要做評審的同學能有幫助。
一、評什么？
產品評審產品評審，在做評審前一定要搞清楚要評什么，自己的心里要跟明鏡兒似的，也能夠幾句話跟別人講清楚，一般來說主要是下面幾方面的問題，搞明白了基本就算清楚評什么了。
- 什么產品
- 背景是什么
- 為什么要做
- 什么時候做
- 怎么做的
- 哪些人來做
- 期望結果是什么
二、怎么評？
怎么評，說到底是評審主講人準備給大家講解些什么，一般產品評審包括PRD（產品需求文檔）和DRD（交互設計文檔）兩大塊，大部分時候DRD是融合在PRD中的，這些是基本準備，關鍵點看下文。
2.1 PRD文檔
- 背景：產品背景、評審背景
- 用戶構成：產品的用戶是誰
- 產品架構：產品的構架、功能結構、信息結構
- 業務流程：包括任務流程、頁面流程
- 具體case：每一個功能模塊、功能點的case
- 其他產品需求：性能、數據監控、兼容性
2.2 DRD文檔
- 狀態
- 規則
- 反饋
- 跳轉
- 動畫
上面這是完善的評審素材資料，但是要具體情況具體對待，不是說每一個評審都需要如此的完善，而是要針對性的結合評審的產品模塊或功能提取出適合本次評審的產品文檔，要不評審沒被噴死，寫文檔倒是寫死了，世界上第一個死在PRD文檔桌前的PM并不是一件光榮的事。
三、評審流程是怎樣？
3.1 評審前
準備評什么
清楚的【熟悉】自己要評審的產品和功能，這里是熟悉??！不是清楚或了解，只有你真的了熟于心，才能給參審人員描繪出一個簡單、合理、有價值、沒有問題的產品功能，否則，進行評審完全是浪費大家時間。
人員提前邀請協商時間
一般來說每次產品評審都會涉及到領導、產品、開發（前端/Android/iOS、后端）、設計、測試、運營、客服這幾類人，但也看具體情況。這里的協商時間首先要提前1到3天聯系相干人員，尤其領導，看大家是否有出差或者其他會議的安排，協調好一致的時間區，通常盡量照顧領導與核心技術人員的時間安排。
會議室提前預約
提前兩到三天預約會議室，提前對投影儀、電腦放映試用確認，桌椅數量、燈、筆、電插板等確認可用，以防萬一。一般公司的會議室永遠是稀缺資源，投影儀電腦更是頻繁出現不可預料的問題。
相關文檔資料準備
產品文檔，原型鏈接地址、評審講解稿（寫下來，多練幾遍，把講解思路背下來）。
郵件通知各與會人員
以郵件的方式邀請將要參審人員，內附評審文檔、評審內容、時間、地點，另外將本次評審的核心動能點簡要在郵件中羅列，以方便接收郵件的人能夠迅速掃一眼了解相關情況。
3.2 評審中
講解需要注意的地方
盡量站著講，讓你的氣場出來，能夠一眼掃清全場人員；
語言+手勢+馬克筆，特殊情況用特殊語言表達；
采用適當停頓、抑揚頓挫的聲音和眼神來把控議場氛圍；
較大爭議不當堂辯論，留作私下交流；
電腦上清理掉私人的信息，如QQ、微信、桌面上其他雜項、瀏覽器上其他雜頁，一方面保證你的“安全”，另一方面也減少影響參審人員的注意力。
開場白
歡迎大家云云開頭；
本次我們評什么？
項目背景是什么？
我們為什么要做這個功能或迭代？
這版迭代解決了什么問題和需求？
我們產品的解決方案是什么？
基本就上面這些，主要一方面是對大家的尊重，同時讓大家先緩一下腦子，有些人剛進來會議室還是懵的；另一方是也是需要通過一個簡單的概括說明讓大家先大致了解我們今天評審的內容，腦子里先有一個框架結構。
評審講解思路
按照金字塔結構由總到分的方式講解；
先過產品架構和信息結構，簡要描述各功能模塊，然后以流程圖聊一下產品的業務流程；
對功能模塊進行組織分類，提取公有模塊，以舉例其中之一典型講解，不要過全部的功能；
將每個功能點重要的關鍵功能點領出來著重強調，或是功能流程、或是特殊限制、或是邏輯設計等；
最后對特殊的不同功能點做單獨講解，整體拒絕流水賬；
開始講解
按照上面的講解思路下來基本沒什么問題，快的話半個小時結束，內容多的話也最多兩個小時結束。
如果評審內容過多，建議拆分開幾次評審，如果想一次講解完，提前給大家打好招呼，或是帶電腦，或是帶水或是提前上廁所等。另外中間需要再一個多小時左右中場休息，一方面你自己需要喝點水潤潤喉，另一方面大家可能也需要上廁所喝水之類的，別把大家憋死……
項目時間規劃
提前跟領導主管以及項目各相關方主管溝通，以確定大概的時間周期。功能模塊講解完之后現場與大家溝通，確認設計、技術給出時間評估，有些可能當場就能給出來，有些可能你要求多久就是多久，有些可能需要回去詳細看了文檔才能給出時間周期，這個過程每個人每個公司情況不同，做好后續的跟蹤以盡快完成完整的項目周期規劃安排。
問題、建議詢問收集，并結會
具體講解結束，項目時間規格也基本結束，最后再詢問一遍大家是否還有什么問題或建議，如果有立即解釋，如果沒有（一般情況下都沒有……），最后簡要總結一下今天的評審，主要是發現了哪些問題，后續我們產品怎么跟進，怎么和大家溝通協作。完了結束會議的時候說聲謝謝大家（基本禮貌），希望合作愉快。
3.3 評審后
評審會議結論總結
評審的結束并沒有意味著產品評審已經結束，反而應該在評審結束后是帶著參審人員給出的建議和問題來重新審視產品設計，搞清楚明白他們為什么會有那樣的疑惑，為什么會反對這種設計，為什么覺得那個功能不合理，為什么他們從技術、銷售、客服、運營角度提出了大大小小的自己看法。
評審是一個產品設計的升級，從一個人的悶頭設計走出到各種利益相關方，接受大家的質疑，協調各方需求，最終拿出一個合理的、有效的、滿足大部分用戶的產品設計來。
這是對一個產品人最大的要求，能夠靜得下心來，思考別人的建議和提問，總結產品設計的方方面面。
評審結果郵件通知各方人員
另外評審結束后還有一件重要的事要做，那就是整理評審會議記錄，然后郵件發送boss，并抄送給各個與會參加評審的相關人員，一方面是讓boss了解到評審都干了些啥，產品設計是怎樣的，有哪些問題，后續的安排是怎樣的等，另一方面是確保參加到會以及因為各種原因沒來參會的人還能夠在評審結束后有的回顧產品設計和評審會議，這一點對項目推進有比較大的幫助，因為評審會上都是在聽，聽完之后挑刺，評審結束后反而是大家都靜下心來思考該如何實現這個產品設計，項目周期、人員配備等心里都有數。最后還有一點小套路，評審結束后郵件發送大家也是把評審人講的話留下證據，方便后面產品推進。
后續問題跟進方案
有些問題不是能夠立馬解決的，但也不允許拖若干天，盡快解決，然后根據實際情況評估是否還需要再次評審或是只跟單獨人員私下溝通。
因為評審后基本算是一個產品設計已經交付出去了，因此這時的功能或交互文檔等變動都需要詳細的修訂記錄，每一個更新后需要郵件通知每個相關人員，郵件中附帶原型地址、更新的問題、更新時間等，郵件后最好能在QQ群或者微信群再吼一聲，保證大家都能夠及時了解產品更新。
#專欄作家#
紫沐渲葉，人人都是產品經理專欄作家，一只有點小驕傲小文藝的產品菜鳥，喜歡倒騰產品和設計，看好O2O、教育和人工智能。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
感謝分享，非常受用。
很好的工作方式的介紹