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

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

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

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

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

第二，涉及業(yè)務流程的需求，也要單獨列一個區(qū)域，專門繪制流程圖，并把流程圖中的“概念”解釋清楚，然后才是針對概念的交互界面，這樣也能方便開發(fā)迅速理解業(yè)務，再和交互稿對照查看，印象更深刻。

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

其次，我們在會議召開前期，也要做足準備

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

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

最后，在召開會議時，更要有備而來

第一，每一個需求點，產(chǎn)品經(jīng)理自己要有充足的理由說服大家，無論是數(shù)據(jù)證明，還是市場調(diào)研，還是用戶心理分析等等，盡量避免說出“我覺得應該XXX”這樣的話，而是講客觀依據(jù)。

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

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

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

最后的最后，再介紹一個小經(jīng)驗

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

當然這是我個人經(jīng)驗，不同公司可以根據(jù)情況調(diào)整~

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

#專欄作家#

申悅，人人都是產(chǎn)品經(jīng)理專欄作家，36氪產(chǎn)品總監(jiān)，微信公眾號：互聯(lián)網(wǎng)悅讀筆記（ID：pmbox）

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。