起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識好的需求評審流程該怎么走？
在產品落地開疆擴土前進上，需求評審就是產品人開荒的第一步！
搞產品的人都會經歷過無數次的挑刺，無數次的評審！
當大家對于產品提出一道道質疑時，這時候就要以專業的只是說服溝通他們！
很多產品人更多層面是在會議之前準備的不夠充分，從而導致會議效率低下，甚至于需要好幾次才能通過！
（需求評審會議的意義再次就不做討論了，你們懂得！）
在召開會議前，內心要清楚的知道本次會議參與的人員類型，各自大概的需求點？
好了，開始直奔主題內容，說說好的需求評審流程該怎么走？
按照會議的流程來說，可以劃分為 “會議前”，“會議中”，“會議后”這三大環節。
一、會議前
會議召開前
在會議召開之前，應提前準備好相關的內容，以及常見問題的應對措施。
1、了解會議目的
- 統一思想，了解需求意義
- 明確需求具體涉及范圍
- 確定事項落實工期與責任
- 確定開展工作
你要清晰的知道為什么要召開這次會議。
2、提前準備好資料
需準備好相關的原型，交互設計稿，流程圖，功能概要列表，PTT，PRD等，并在提前發送到環節涉及所有人。
3、提前通知責任人
- 除了正式渠道（如郵件，群等），還需再次口頭告知確認，
- 通知內容需包含：需求資料，參會人員，會議內容主題，需要配合資源內容
等
4、備好問題速救藥
產品內部自行檢查好：一般保證這幾方面：（確定性，完整性，復雜性，熟悉性，穩定性，交互性）
- 確定要這么做？這么做會*，考慮清楚要這么做？
- 還有這種情況你沒考慮到？
- 這個搞的話，太復雜了，能簡單點不？
- 你要動這一塊，有沒有考慮到現有的流程？
- 確定定稿這些內容了，會不會再出現變化？
- 這個交互為什么要這樣，主要的是這樣？
劃重點來了，在對接研發人員，他們要的不是你懂技術，要的是你不要改需求！
二、會議中
會議召開中
準備好相關的資料后，也提前通知責任人了，終于可以開始了。
1、召集小伙伴開會咯
時間點到了后，要及時拉上所有相關人員，由于人都有拖延懶惰的特點，記得在開會10分鐘就要喊上他們，保證會議準時進行！
2、講解前應先說說本次會議的內容范圍
相關涉及責任人到會議室后，應在開會前明確表明確認：
本次會議目的，會議涉及內容，會議所需結果；
（不要一上來就直接講原型?。?/p>
3、記得做好會議記錄
除了記錄常規的會議內容之外，還需要重點記錄核心爭議討論點，以及討論結果！
4、有爭論不可怕，可怕的是方向偏，無效率
- 在討論需求之前，要明確爭論基點，不能無休止討論，也不能啥也不說
- 出現爭論是好事，證明哪些人有在看，有在聽
- 會前一定要保證主流程，主方向，主內容OK沒問題
- 非常細的內容，不涉及主流程環節下，建議會后解決
- 主流程環節出現爭論，一定要在會議解決掉
- 不宜在會議爭論太長時間在工期環節
- 明確本次開會目標，不宜偏題討論
5、終于可以開始好好的講解需求了
講解答疑環節中應講究條理性與節奏。
- 需求背景：概述需求從哪來，為何要做這塊，
- 用戶與需求概述：描述需求應該要做成什么樣，
- 功能模塊：需求涉及相關的重點大的功能點，
- 簡要優先級：描述下當前的最重點內容，
- 流程講解：講解本次需求涉及主要流程，
- 原型與交互：開始講解原型內容和交互，
- 數據指標：講解本次需要哪些關鍵性的指標；
6、需要各各環節的配合
明確落實本次需求需要哪些人，哪些資源進行配合！
比如：需要運營協助處理文案；需要開發協助技術實現，需要行政協助開設激勵獎等
7、總結概括本次會議內容
- 講解溝通完成之后，應再次復述總體需求內容
- 咨詢確認是否了解當前整個需求內容
8、責任人復述確認
- 讓相關責任人簡要復述確認理解層面是否一致
- 以明確了解需求內容為判斷依據
- 是否簽字畫押確認由各自環境決定
9、爭吵時間節點（工期與上線）
講解溝通完畢后，就進行相關的初步定稿評估工期時間，以及告知計劃上線時間；（會議定稿初步工期，部分爭議則私下解決！）
三、會議后
會議召開后
終于熬過挑刺環節了，距離落地執行沒多遠了，可工作還有這些：
1、整理會議紀要內容
會議結束后，應當天總結處理會議上所有討論的爭議點，以及討論的結果內容！
2、是否需要進行調整
立馬處理在會議上未能討論解決的內容：
- 應盡快確認是否應該調整？調整的范圍是多少？
- 并且及時反饋告知處理結果。
3、是否需要再次召開
會議結束后，是否需要再次召開會議，討論內容，
以落地責任人了解程度為判斷依據！
4、發送會議記錄
會議結束后，當天內應及時通過正式渠道發布會議紀要。
- 會議討論設計內容
- 爭議點及其處理內容
- 初步定稿時間與責任人
5、落實明確行動計劃
會議定稿后，應推動落實需求前進！
再次確定定稿內容時間節點！
6、任務排期
內容/節點定稿后，則落實到具體的排期，開始項目跟進！
7、定稿內容發送
定稿確認之后，應正式發布通知相關責任人：
- 會議最終結果（排期，時間節點等）
- 本次涉及內容（有哪些內容，做到啥程度等）
- 需要誰進行配合，感謝哪些支持等等
溫馨提示：至始至終，要明確你開會是為了什么，想要什么結果！
終于可以安心了，任務開始徐徐前進了，可接下來的工作還不少，還要繼續開撕！
——來自永遠不定期斷更的 youketao
==（關于需求評審質疑，如何有效的溝通，再說了?。?=
作者：youketao
來源：http://www.jianshu.com/p/fda0c4887f4d
本文由 @youketao 授權發布于人人都是產品經理，未經作者許可，禁止轉載。
低保真流程
收藏了！
不錯不錯。挺齊全，收藏了。
文中的圖片內容是用什么工具做的，
visio 跨職能流程圖可以畫
錯別字太多+1
寫的很全面也寫的很理想
以后開會就按這個流程走，先把主線的工作處理完，其他的再開細會決定。
調理清楚，但實施起來有點惱火
剛開完會，正好！
然后我再個人中心里查看我的評論時，別人給我的評論怎么看不到了？我自己的評論也只是顯示一條別的去哪了?雖然能評論“評論”但是怎么看不見了？這是BUG嘛？能蓋樓但是我看不見怎么回事?
評論的字數沒有限制嗎？
這個APP做的不錯，哪個產品經理？??
整體還不錯，收藏了
錯別字太多！
好
好
我自己評論自己怎么不能顯示呢?
大沙發發散度
寫的挺全的！
挺全的，攢
很全面，一般都是按照這個流程走，有的會更簡化一些
需求評審就需要 原型、prd這些了？
請教下，您覺得還需要什么內容？
【原型，交互稿，流程圖，功能列表，流程圖，PPT，PRD等，這些不能滿足會議的溝通需要！】
點贊
非常完整的工作流程以及細節解剖。但是如果把需求評審作為一個產品，我建議砍掉5成以上的功能點。
說的沒錯，其實自始至終貫徹主線：【1、真的需要開會？ 2、開會是為了什么？ 3、會議想要達到什么結果】！
這應該是項目原型評審了。如果是部分功能的需求評審，是應該在會前就應該各方先前就討論并達成一致的，可以節約很多沒必要的討論時間。
說的沒錯，會議之前 就應該明確 “真的需要進行開會？”，“哪些不清晰不明確的的？”！接下來才會在評審這一步！
我覺得即使需求評審階段，你把什么原型都做好了。萬一這個需求是不符合或者是推遲做的，感覺就有點浪費時間。個人認為流程以及原型是在評審通過過后，進去需求打包的時候再去做比較合理。
說的沒錯，不同的團隊會有不同的業務模式，
這時候，還是要回歸到基點上
【真的需要開會才能解決嘛】【需求真的清晰明確，方向正確嘛？】
項目經理在哪里，產品兼任了嗎？
往小的說：
小公司，一般來說是產品兼顧項目來的！
大公司，才有這方面的，這時候，產品只需要關注時間節點跟優先級即可！
往大的說：
心中定調一個基點：從需求的產生到落地，產品應該進行推進！
Voilà c‘est ?a
思維清晰，不錯，支持下
如果是大的功能或產品，在第一次評審研發就能當場評估初步的工期？
1、其實這塊跟團隊合作密切相關，責任人對自己負責的環節是否有個清晰的認知了解！以及愿意真正投入進去！
2、第一次評估不準，項目有延期，那下一次的評估呢？再下一次呢？ 那能否結合以往的經歷加上對需求的理解進行評估
3、以前我在一本書看到有這種預估方式： 最好，最差，最適中
（這個點最好的話需要多久，最差的需要多久，一般情況下的需要多久，然后三者相加，再乘以 三分之二）
得出來的數值基本上相差無幾！
【不過還是推薦第一點】
確定是乘以三分之二嗎？
邏輯整理得非常清晰，不過我覺得，在會議前其實就應該跟與會各方就需求達成一致了，不是全部都要在會上去討論，會上只是做最后的確認工作，這樣會更高效~
說的沒錯，回歸到基點上
【真的需要開會才能解決嘛】【需求真的清晰明確，方向正確嘛？】
這樣才能找到一個適合自己團隊的流程作風！
非常贊同。否則需求評審會的持續時間將會十分恐怖
ptt是什么？
hh，我就是來看看有沒有和我有一樣疑問的
應該是打錯了
看的過程沒發現，當成PPT
沒錯，真的是打錯了，是PPT來的！