產品經理，如何進行有效的需求評審 | 人人都是產品經理

好久沒有寫文章了，因為最近換工作了，正在拚命學習新東西中...

上周連續針對同一個版本進行了三次需求評審，第一次進行了全範圍的評審，涉及到各方相關人員，包含：產品、設計、開發（客戶端和服務端）、測試；第二次產品團隊內部小範圍的評審，主要是為了確定第一次評審中部分不太確定的/沒考慮到實際可能遇到的問題的需求，涉及人員：產品（iOS端和Android端）和運營；第三次針對那些不太確定的/沒考慮到實際可能遇到的問題的需求進行確認，涉及人員：開發和測試。等三場評審下來，就累成了狗。

一場需求評審會議變成了三場，這肯定是有問題的，是該好好檢討下了。

之前一直在創業公司，需求評審會基本很隨意，叫上開發、設計和老闆就可以直接開始了，評審會上也會遇到一些問題，但涉及的人比較少，且一個人從頭到尾都只負責一個項目，事後基本上只要口頭確認下評審時的問題就行了。但流程較複雜的公司情況就有些不一樣了，需求評審會參會人數比較多，並且一個人可能會負責多個項目，需要重新調配資源，一旦評審中需求不確定/沒考慮周全的問題，就會出現多次需求評審的情況，這就極大的降低了工作效率。

1. 與會人員對需求的目標不明確，易發散思維，最終偏離方向。
2. 對某個需求點相持不下，認為該需求不合理/開發周期長不划算，從而導致場面混亂，長時間僵持下去。
3. 對技術方案探討不定，對問題點無限引申。
4. 遺漏評審時的待改動的需求點，會後找相關人員再次確認。

基本上遇到上面情況中的任意一種，都會將需求評審時間拉長，導致效率低下，輕則需求產生變更，重則需求功能無法實現，產品人員在評審過程中也容易產生渾身燥熱、體乏無力和頭昏腦漲的感覺_|￣|○...

那如何進行有效的需求評審呢？

我結合我自己上周做的需求評審作了一些總結，天熱了給自己拔拔罐，希望能做到更規範，減少評審時會出現的問題，少踩點坑。

將需求評審分為三階段：

相關資料準備（確保人身安全）

1）產品需求文檔

我的需求文檔里一般包含四塊：項目背景、項目目標、需求概述和需求詳細描述，必要的時候可以帶上項目風險（說明此次版本可能帶來的問題或考慮不夠完善的地方）和業務流程圖（對某些複雜功能/邏輯的分解）。

（需求文檔結構）

產品需求文檔主要是要把需求的邏輯表達清楚沒歧義，對各個細節描述清晰，各輸入輸出項（涉及到表單/數據的輸入輸出）、業務流程（功能的交互步驟和數據的流轉）、計算規則（某些特定須計算的規則）、判斷邏輯 （業務流程中出現的一些判斷邏輯及各種判斷下的反饋情況，賬號的許可權範圍也屬於這種）和一些特殊情況（如是否支持橫屏啊之類的）都要寫清楚，如果實在記不住太多，每次寫需求文檔時都會這裡漏個流程那裡漏個判斷的，可以整理一份適合自己的需求文檔自查清單，每次寫完後從頭到尾對照一遍。當然不能事無巨細都通通一股腦寫進去，不然開發和測試的朋友會看的很辛苦，小心被打...

舉一個活生生的反例：上周寫文檔時有一個計算規則比較想當然了，要算「累計閱讀時長」，閱讀時長嘛就是閱讀時長嘛，一句話就帶過了，然後在需求評審時就比較慘了，該如何統計這個閱讀時長？直接用定時器嗎？還是使用本地時間？用定時器比用本地時間相比既複雜又低效，但如果用本地時間，那用戶直接修改手機上的時間給不給累計閱讀時長？還有用戶如果一直停留在當前閱讀頁還給不給算閱讀時長？...後面對這個功能的計算規則討論了好久，最終評審會上也沒確定下來。所以說，做好細節是多麼的重要！/(ㄒoㄒ)/~~

產品需求文檔的準確和詳細可以有效減少需求評審時的花費的時間，也能讓參會人員更清楚地了解需求。

2）線框圖

帶上線框圖而不是比如這樣或那樣，配合線框圖有利於對需求點的梳理。需求文檔里可以簡要配些線框圖方便文字的理解，不過需求評審時還是另外打包一份線框圖單獨帶著吧，可以詳細點，把交互稿也帶上。

第一次評審的時候，我忘了帶，而需求文檔里也剛好沒放那個頁面的線框圖...於是我只能讓大家跟著我一起在腦海中繪製一副圖，能不能繪出來我就不清楚了Orz...反正不要學我！

3）相關數據

帶上數據而不是我認為，一些需要數據支撐的需求點要帶上相關的數據，用數據說話。

小範圍的溝通（確認方案）

產品需求文檔寫好了，這個時候就可以去找涉及到本次改版的同事們去聊聊了，不要有寫好產品需求文檔就萬事大吉，接下來只要等需求評審會就可以了這樣的想法。提前小範圍溝通可以避免很多不必要的撕逼，將一些不確定的方案給確定下來，探討方案實現的難易程度，確保某些需求的可行性，還可以發現可能與原有產品邏輯相衝突的地方等，把這些坑都填好，這樣在需求評審的時候就可以快速走過了。

上周我連開了兩個項目的需求評審會，一個是改版還有一個是新應用的上線，改版的需求評審總共開了三次，就是最開始說的那種情況，而新應用上線的評審只開了一次而且只用了不到半小時，需求評審前和開發溝通就基本上已經將我不太確定的方案給確定了下來，並且確保了部分不確定需求的可行性，在評審會上是一次就過。有對比才會有真相，多麼痛的領悟，不要什麼都等到需求評審會議上才去確認/解決，提前做好溝通工作，能大大提高需求評審的效率。但不是說提前把所有的需求都溝通一遍啦！大家都很忙，動好腦子帶好方案再去溝通！

產品內部評審（確認需求）

產品內部評審就是在產品團隊內部進行小範圍評審，確保需求邏輯的一致性。在確定好各種方案後，最好在產品內部先進行評審，特別是當有兩個產品經理分別負責Android客戶端和iOS客戶端但是兩種終端數據又是用的同一個介面數據的情況，說白點，就是Android客戶端和iOS客戶端要求在大體上保持一致的情況下，為了保證邏輯的一致性，最好先進行產品團隊內部的小範圍評審。

一次內部的小範圍評審可以規避大部分需求不合理的地方，可以直接有效的提升需求評審的效率，同時也能增加其他團隊對產品團隊的信任感，以後辦起事來就比較方便了你懂得(^o^)/。之前在創業公司就沒有碰到過這種情況，因為Android端和iOS端都是我負責的，功能是一致的，所以就沒這種情況，也就可以省去這一步產品內部評審了...如果功能邏輯涉及到多個產品負責人，這一步還是很有必要的！

提前把需求文檔發出來（有備無患）

根據以上步驟確認好需求後就可以把需求文檔發出來了，以郵件/群聊的方式發出來，讓與會者提前查看產品需求文檔，不求他們能夠把需求文檔從頭到尾看一遍，但求大家能知道下個版本要做的需求有哪些，這樣前期的服務工作才算到位。

以上工作都做好了基本上就可以進行需求評審了，預約好會議室後通知相關參會人員參加。

正式需求評審時，帶好必備品，就可以開始了，基本上只要前期準備工作做得好，需求評審時出現的幺蛾子就不會太多，稍微拍拍就能滅掉，所以評審時狀況百出，多半是準備工作不到位。但除了前期的準備工作，在評審時還有幾個需要注意的地方，能夠幫助提升需求評審的效率。

產品經理應有的態度（兵來將擋水來土掩）

1）有清晰的目標

相比其他參與者，產品經理要對此次需求評審更有方向性和目標性，這次改版所要解決的問題以及所要達成的目標都應銘記於心，只有產品經理自己有清晰的目標才能做到即使同時被多人撕也不發生動搖，才可能確保參會的其他團隊能理解並認同該版本所要達成的目標以及要做的功能點。

即使有著明確的目標，也別想著要把自己的想法強加到別人的腦子裡，很容易發生：目標很明確，所以大家要按我的想法走的這種情況。需求評審目標並不是為了要說服誰！召開評審會，就是為了讓大家對你提出的方案進行批評指正或提出疑問點，從而能及時地解決並發現方案中的問題，保持各團隊目標一致，將產品做好。

2）把控好時間

需求評審時很容易會對某個需求/方案僵持不下，常一討論起來就是半個小時，多遇到這麼幾個僵持情況，一場需求評審下來就好幾個小時，不僅會慢慢耗盡大家的精力，而且需求評審的效果也不好，得不償失！所以產品經理要嚴格把控好時間，由於前期工作準備不充分而導致一些需求/方案模稜兩可，且暫時無法立馬提出解決方案的可以會後確認好後再溝通，必要時可以進行第二次評審。

3）認真傾聽

可能別人一上來就開始對你的方案提出不認可，這個時候就得認真傾聽；開發在探討技術方案的時候你也要認真傾聽；先在大腦梳理好他們在說什麼，傾聽後才能對症下藥，而不是打斷然後陳述自己的觀點。

傾聽後再陳述而不是直接打斷，可以讓人覺得你在認真思考後才說出這番陳述的，更有說服力，並且不跟其他團隊硬碰硬，先了解他們的問題再提出解決方案，不是顯得更理智么？

4）保持清醒的頭腦

在需求評審會議中，很有可能會發生爭論，產品經理一定要保持理性，切不可讓怒氣或膽怯沖昏了頭腦，失去理智。對會議上提出的每一個問題都應該記錄下來並作出解答，要冷靜客觀的把自己的觀點給陳述出來。

小範圍的討論（見仁見智）

在需求評審講需求點時，開發會針對某個點進行技術方案探討，這樣有利於及早發現需求點與現有邏輯相衝突或由於硬體問題而導致需求變更或夭折的問題，避免到開發時才發現需求沒法做...但也要控制好時間，引導大概討論下技術實現方案，具體的細節之後再討論。

除了開發團隊內部小範圍的討論外，還有設計團隊，不過設計一般不在需求評審會上討論了，畢竟，設計基本上不會影響到產品需求的變更。

定下開發周期（誕辰）

如果評審順利的話，就可以直接定下開發周期了；如果不順利，那就放在評審後吧~上周評審時就各種不順利，三場評審後還加了一場開發周期的確定...祝願以後一切順利吧！

評審後

會後及時輸出會議紀要，羅列出會議中有爭議仍待解決的問題、改動的部分和結論，將完善後最終更新過的需求文檔發送給參會人員，通知需求評審已完成。之後對問題進行跟蹤，保證評審結果的落實。

能否在產品需求評審會議中如魚得水，提高需求評審的效率，我覺得前期的準備工作很關鍵！

作者：小聖，個人微信公眾號：hi_xiaosheng，簡書賬號：小聖。歡迎戳我小窗一起探討產品！

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