AAA教育

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

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

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

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

 

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

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

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

 

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

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

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

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

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

 

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

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

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