如何開好需求評審會？

當你在和開發進行需求評審時，你會發現原本規劃半個小時的會議往往被各種各樣的問題拖入無止境的小會中，結果會議時長一下子延伸了2~3個小時。這篇文章分享的內容就是如何規避類似這樣的問題。

產品經理在和開發進行需求評審時，經常剛開個頭，就被各種問題拖入無止境的解釋、爭辯、開小會中，結果通常就是會議幾個小時無結論，強行推進開發，後期各種需求變更，搞得大家都很疲憊。今天思考的話題就是如何避免這樣的情況。

就結論而言，就是四個字：做足準備！

首先，我們在寫需求畫原型時，要做足準備

第一，產品經理在做原型時，不要一開始就畫交互界面，而是單獨列一個區域，把這個版本需求的來龍去脈說清楚。包括為什麼要做這個版本，要滿足哪些人的哪些需求，做了這些後有什麼價值，如何證明，以及大概要做的模塊都有哪些，時間估算等等，讓每個來開會的人一上來就有宏觀意識。

第二，涉及業務流程的需求，也要單獨列一個區域，專門繪製流程圖，並把流程圖中的「概念」解釋清楚，然後才是針對概念的交互界面，這樣也能方便開發迅速理解業務，再和交互稿對照查看，印象更深刻。

第三，在繪製交互界面時，也要盡量按目的、按邏輯分組歸類。比如將「提升用戶活躍」作為大分類，在這個分類下，「推送功能優化」作為小分類，在這個小分類下，我們要做哪些子模塊，層層分解。

其次，我們在

，也要做足準備

第一，在和全體開發開會前，盡量提前和開發各業務負責人召開一個小會，進行需求初評，目的是提前收集問題，溝通是否有技術難點，確認需求的開發成本，並從技術的角度看是否有考慮不全的邏輯漏洞等等。如果存在需求不足的地方儘快修改。當然還可讓開發負責人向下簡單傳達要做哪些需求，讓大家心裡有數。

第二，在會議召開前，一定先通過郵件形式發布會議召開邀請，同時附上即將要講解的原型文檔，至少提前1天讓所有參會人員了解需求。當然最好在發完郵件後到每個開發座位上再提醒一下，督促大家去閱讀文檔，有較大分歧的反饋儘早收集處理。

最後，

，更要有備而來

第一，每一個需求點，產品經理自己要有充足的理由說服大家，無論是數據證明，還是市場調研，還是用戶心理分析等等，盡量避免說出「我覺得應該XXX」這樣的話，而是講客觀依據。

第二，每一種交互設計，都盡量有幾套方案備選，如果大家對已畫出的交互意見較大，就再擺出幾種備選，讓大家有目的地展開討論。

第三，產品經理講解交互稿時，可以先講總體，再講重要細節，再講次重要細節，並層層確認。比如訂單支付流程，先講解支付順利的主流程，再講解支付失敗的異常流程，最後再講解支付成功、失敗的交互效果。這樣做的好處是限制討論邊界，避免理解偏差。

第四，對於會議上爭議較大的問題點，有個「5分鐘」原則，5分鐘后還沒有結論，就記錄下來，會後再單獨討論。如果問題點太多，就說明產品經理還沒考慮清楚，那就儘早結束會議，再重新修改原型，再召開一次會議，當然我們還是希望這樣的情況不要發生，因為非常浪費時間和精力。

最後的最後，再介紹一個小經驗

就是建議將PRD、需求FeatureList和原型都畫在一起，統一講解，這樣能提高效率，減少理解成本。如下圖所示：

當然這是我個人經驗，不同公司可以根據情況調整~

以上是我的思考，你們公司是如何做需求評審的呢？期待你的留言~

#專欄作家#

申悅，人人都是產品經理專欄作家，36氪產品總監，（ID：pmbox）

本文原創發佈於人人都是產品經理。未經許可，禁止轉載。