好久沒有寫文章了，因?yàn)樽罱鼡Q工作了，正在拼命學(xué)習(xí)新東西中…

上周連續(xù)針對(duì)同一個(gè)版本進(jìn)行了三次需求評(píng)審，第一次進(jìn)行了全范圍的評(píng)審，涉及到各方相關(guān)人員，包含：產(chǎn)品、設(shè)計(jì)、開發(fā)（客戶端和服務(wù)端）、測試；第二次產(chǎn)品團(tuán)隊(duì)內(nèi)部小范圍的評(píng)審，主要是為了確定第一次評(píng)審中部分不太確定的/沒考慮到實(shí)際可能遇到的問題的需求，涉及人員：產(chǎn)品（iOS端和Android端）和運(yùn)營；第三次針對(duì)那些不太確定的/沒考慮到實(shí)際可能遇到的問題的需求進(jìn)行確認(rèn)，涉及人員：開發(fā)和測試。等三場評(píng)審下來，就累成了狗。

一場需求評(píng)審會(huì)議變成了三場，這肯定是有問題的，是該好好檢討下了。

之前一直在創(chuàng)業(yè)公司，需求評(píng)審會(huì)基本很隨意，叫上開發(fā)、設(shè)計(jì)和老板就可以直接開始了，評(píng)審會(huì)上也會(huì)遇到一些問題，但涉及的人比較少，且一個(gè)人從頭到尾都只負(fù)責(zé)一個(gè)項(xiàng)目，事后基本上只要口頭確認(rèn)下評(píng)審時(shí)的問題就行了。但流程較復(fù)雜的公司情況就有些不一樣了，需求評(píng)審會(huì)參會(huì)人數(shù)比較多，并且一個(gè)人可能會(huì)負(fù)責(zé)多個(gè)項(xiàng)目，需要重新調(diào)配資源，一旦評(píng)審中需求不確定/沒考慮周全的問題，就會(huì)出現(xiàn)多次需求評(píng)審的情況，這就極大的降低了工作效率。

需求評(píng)審時(shí)常發(fā)生的情況：

1. 與會(huì)人員對(duì)需求的目標(biāo)不明確，易發(fā)散思維，最終偏離方向。
2. 對(duì)某個(gè)需求點(diǎn)相持不下，認(rèn)為該需求不合理/開發(fā)周期長不劃算，從而導(dǎo)致場面混亂，長時(shí)間僵持下去。
3. 對(duì)技術(shù)方案探討不定，對(duì)問題點(diǎn)無限引申。
4. 遺漏評(píng)審時(shí)的待改動(dòng)的需求點(diǎn)，會(huì)后找相關(guān)人員再次確認(rèn)。

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

那如何進(jìn)行有效的需求評(píng)審呢？

我結(jié)合我自己上周做的需求評(píng)審作了一些總結(jié)，天熱了給自己拔拔罐，希望能做到更規(guī)范，減少評(píng)審時(shí)會(huì)出現(xiàn)的問題，少踩點(diǎn)坑。

將需求評(píng)審分為三階段：

評(píng)審前

相關(guān)資料準(zhǔn)備（確保人身安全）

1）產(chǎn)品需求文檔

我的需求文檔里一般包含四塊：項(xiàng)目背景、項(xiàng)目目標(biāo)、需求概述和需求詳細(xì)描述，必要的時(shí)候可以帶上項(xiàng)目風(fēng)險(xiǎn)（說明此次版本可能帶來的問題或考慮不夠完善的地方）和業(yè)務(wù)流程圖（對(duì)某些復(fù)雜功能/邏輯的分解）。

（需求文檔結(jié)構(gòu)）

產(chǎn)品需求文檔主要是要把需求的邏輯表達(dá)清楚沒歧義，對(duì)各個(gè)細(xì)節(jié)描述清晰，各輸入輸出項(xiàng)（涉及到表單/數(shù)據(jù)的輸入輸出）、業(yè)務(wù)流程（功能的交互步驟和數(shù)據(jù)的流轉(zhuǎn)）、計(jì)算規(guī)則（某些特定須計(jì)算的規(guī)則）、判斷邏輯 （業(yè)務(wù)流程中出現(xiàn)的一些判斷邏輯及各種判斷下的反饋情況，賬號(hào)的權(quán)限范圍也屬于這種）和一些特殊情況（如是否支持橫屏啊之類的）都要寫清楚，如果實(shí)在記不住太多，每次寫需求文檔時(shí)都會(huì)這里漏個(gè)流程那里漏個(gè)判斷的，可以整理一份適合自己的需求文檔自查清單，每次寫完后從頭到尾對(duì)照一遍。當(dāng)然不能事無巨細(xì)都通通一股腦寫進(jìn)去，不然開發(fā)和測試的朋友會(huì)看的很辛苦，小心被打…

舉一個(gè)活生生的反例：上周寫文檔時(shí)有一個(gè)計(jì)算規(guī)則比較想當(dāng)然了，要算“累計(jì)閱讀時(shí)長”，閱讀時(shí)長嘛就是閱讀時(shí)長嘛，一句話就帶過了，然后在需求評(píng)審時(shí)就比較慘了，該如何統(tǒng)計(jì)這個(gè)閱讀時(shí)長？直接用定時(shí)器嗎？還是使用本地時(shí)間？用定時(shí)器比用本地時(shí)間相比既復(fù)雜又低效，但如果用本地時(shí)間，那用戶直接修改手機(jī)上的時(shí)間給不給累計(jì)閱讀時(shí)長？還有用戶如果一直停留在當(dāng)前閱讀頁還給不給算閱讀時(shí)長？…后面對(duì)這個(gè)功能的計(jì)算規(guī)則討論了好久，最終評(píng)審會(huì)上也沒確定下來。所以說，做好細(xì)節(jié)是多么的重要！/(ㄒoㄒ)/~~

產(chǎn)品需求文檔的準(zhǔn)確和詳細(xì)可以有效減少需求評(píng)審時(shí)的花費(fèi)的時(shí)間，也能讓參會(huì)人員更清楚地了解需求。

2）線框圖

帶上線框圖而不是比如這樣或那樣，配合線框圖有利于對(duì)需求點(diǎn)的梳理。需求文檔里可以簡要配些線框圖方便文字的理解，不過需求評(píng)審時(shí)還是另外打包一份線框圖單獨(dú)帶著吧，可以詳細(xì)點(diǎn)，把交互稿也帶上。

第一次評(píng)審的時(shí)候，我忘了帶，而需求文檔里也剛好沒放那個(gè)頁面的線框圖…于是我只能讓大家跟著我一起在腦海中繪制一副圖，能不能繪出來我就不清楚了Orz…反正不要學(xué)我！

3）相關(guān)數(shù)據(jù)

帶上數(shù)據(jù)而不是我認(rèn)為，一些需要數(shù)據(jù)支撐的需求點(diǎn)要帶上相關(guān)的數(shù)據(jù)，用數(shù)據(jù)說話。

小范圍的溝通（確認(rèn)方案）

產(chǎn)品需求文檔寫好了，這個(gè)時(shí)候就可以去找涉及到本次改版的同事們?nèi)チ牧牧?，不要有寫好產(chǎn)品需求文檔就萬事大吉，接下來只要等需求評(píng)審會(huì)就可以了這樣的想法。提前小范圍溝通可以避免很多不必要的撕逼，將一些不確定的方案給確定下來，探討方案實(shí)現(xiàn)的難易程度，確保某些需求的可行性，還可以發(fā)現(xiàn)可能與原有產(chǎn)品邏輯相沖突的地方等，把這些坑都填好，這樣在需求評(píng)審的時(shí)候就可以快速走過了。

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

產(chǎn)品內(nèi)部評(píng)審（確認(rèn)需求）

產(chǎn)品內(nèi)部評(píng)審就是在產(chǎn)品團(tuán)隊(duì)內(nèi)部進(jìn)行小范圍評(píng)審，確保需求邏輯的一致性。在確定好各種方案后，最好在產(chǎn)品內(nèi)部先進(jìn)行評(píng)審，特別是當(dāng)有兩個(gè)產(chǎn)品經(jīng)理分別負(fù)責(zé)Android客戶端和iOS客戶端但是兩種終端數(shù)據(jù)又是用的同一個(gè)接口數(shù)據(jù)的情況，說白點(diǎn)，就是Android客戶端和iOS客戶端要求在大體上保持一致的情況下，為了保證邏輯的一致性，最好先進(jìn)行產(chǎn)品團(tuán)隊(duì)內(nèi)部的小范圍評(píng)審。

一次內(nèi)部的小范圍評(píng)審可以規(guī)避大部分需求不合理的地方，可以直接有效的提升需求評(píng)審的效率，同時(shí)也能增加其他團(tuán)隊(duì)對(duì)產(chǎn)品團(tuán)隊(duì)的信任感，以后辦起事來就比較方便了你懂得\(^o^)/。之前在創(chuàng)業(yè)公司就沒有碰到過這種情況，因?yàn)锳ndroid端和iOS端都是我負(fù)責(zé)的，功能是一致的，所以就沒這種情況，也就可以省去這一步產(chǎn)品內(nèi)部評(píng)審了…如果功能邏輯涉及到多個(gè)產(chǎn)品負(fù)責(zé)人，這一步還是很有必要的！

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

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

以上工作都做好了基本上就可以進(jìn)行需求評(píng)審了，預(yù)約好會(huì)議室后通知相關(guān)參會(huì)人員參加。

評(píng)審中

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

產(chǎn)品經(jīng)理應(yīng)有的態(tài)度（兵來將擋水來土掩）

1）有清晰的目標(biāo)

相比其他參與者，產(chǎn)品經(jīng)理要對(duì)此次需求評(píng)審更有方向性和目標(biāo)性，這次改版所要解決的問題以及所要達(dá)成的目標(biāo)都應(yīng)銘記于心，只有產(chǎn)品經(jīng)理自己有清晰的目標(biāo)才能做到即使同時(shí)被多人撕也不發(fā)生動(dòng)搖，才可能確保參會(huì)的其他團(tuán)隊(duì)能理解并認(rèn)同該版本所要達(dá)成的目標(biāo)以及要做的功能點(diǎn)。

即使有著明確的目標(biāo)，也別想著要把自己的想法強(qiáng)加到別人的腦子里，很容易發(fā)生：目標(biāo)很明確，所以大家要按我的想法走的這種情況。需求評(píng)審目標(biāo)并不是為了要說服誰！召開評(píng)審會(huì)，就是為了讓大家對(duì)你提出的方案進(jìn)行批評(píng)指正或提出疑問點(diǎn)，從而能及時(shí)地解決并發(fā)現(xiàn)方案中的問題，保持各團(tuán)隊(duì)目標(biāo)一致，將產(chǎn)品做好。

2）把控好時(shí)間

需求評(píng)審時(shí)很容易會(huì)對(duì)某個(gè)需求/方案僵持不下，常一討論起來就是半個(gè)小時(shí)，多遇到這么幾個(gè)僵持情況，一場需求評(píng)審下來就好幾個(gè)小時(shí)，不僅會(huì)慢慢耗盡大家的精力，而且需求評(píng)審的效果也不好，得不償失！所以產(chǎn)品經(jīng)理要嚴(yán)格把控好時(shí)間，由于前期工作準(zhǔn)備不充分而導(dǎo)致一些需求/方案模棱兩可，且暫時(shí)無法立馬提出解決方案的可以會(huì)后確認(rèn)好后再溝通，必要時(shí)可以進(jìn)行第二次評(píng)審。

3）認(rèn)真傾聽

可能別人一上來就開始對(duì)你的方案提出不認(rèn)可，這個(gè)時(shí)候就得認(rèn)真傾聽；開發(fā)在探討技術(shù)方案的時(shí)候你也要認(rèn)真傾聽；先在大腦梳理好他們?cè)谡f什么，傾聽后才能對(duì)癥下藥，而不是打斷然后陳述自己的觀點(diǎn)。

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

4）保持清醒的頭腦

在需求評(píng)審會(huì)議中，很有可能會(huì)發(fā)生爭論，產(chǎn)品經(jīng)理一定要保持理性，切不可讓怒氣或膽怯沖昏了頭腦，失去理智。對(duì)會(huì)議上提出的每一個(gè)問題都應(yīng)該記錄下來并作出解答，要冷靜客觀的把自己的觀點(diǎn)給陳述出來。

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

在需求評(píng)審講需求點(diǎn)時(shí)，開發(fā)會(huì)針對(duì)某個(gè)點(diǎn)進(jìn)行技術(shù)方案探討，這樣有利于及早發(fā)現(xiàn)需求點(diǎn)與現(xiàn)有邏輯相沖突或由于硬件問題而導(dǎo)致需求變更或夭折的問題，避免到開發(fā)時(shí)才發(fā)現(xiàn)需求沒法做…但也要控制好時(shí)間，引導(dǎo)大概討論下技術(shù)實(shí)現(xiàn)方案，具體的細(xì)節(jié)之后再討論。

除了開發(fā)團(tuán)隊(duì)內(nèi)部小范圍的討論外，還有設(shè)計(jì)團(tuán)隊(duì)，不過設(shè)計(jì)一般不在需求評(píng)審會(huì)上討論了，畢竟，設(shè)計(jì)基本上不會(huì)影響到產(chǎn)品需求的變更。

定下開發(fā)周期（誕辰）

如果評(píng)審順利的話，就可以直接定下開發(fā)周期了；如果不順利，那就放在評(píng)審后吧~上周評(píng)審時(shí)就各種不順利，三場評(píng)審后還加了一場開發(fā)周期的確定…祝愿以后一切順利吧！

評(píng)審后

會(huì)后及時(shí)輸出會(huì)議紀(jì)要，羅列出會(huì)議中有爭議仍待解決的問題、改動(dòng)的部分和結(jié)論，將完善后最終更新過的需求文檔發(fā)送給參會(huì)人員，通知需求評(píng)審已完成。之后對(duì)問題進(jìn)行跟蹤，保證評(píng)審結(jié)果的落實(shí)。

總結(jié)

能否在產(chǎn)品需求評(píng)審會(huì)議中如魚得水，提高需求評(píng)審的效率，我覺得前期的準(zhǔn)備工作很關(guān)鍵！

作者：小圣，個(gè)人微信公眾號(hào)：hi_xiaosheng，簡書賬號(hào)：小圣。歡迎戳我小窗一起探討產(chǎn)品！

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