好久沒(méi)有寫文章了，因?yàn)樽罱鼡Q工作了，正在拼命學(xué)習(xí)新東西中...
上周連續(xù)針對(duì)同一個(gè)版本進(jìn)行了三次需求評(píng)審，第一次進(jìn)行了全范圍的評(píng)審，涉及到各方相關(guān)人員，包含：產(chǎn)品、設(shè)計(jì)、開(kāi)發(fā)（客戶端和服務(wù)端）、測(cè)試；第二次產(chǎn)品團(tuán)隊(duì)內(nèi)部小范圍的評(píng)審，主要是為了確定第一次評(píng)審中部分不太確定的/沒(méi)考慮到實(shí)際可能遇到的問(wèn)題的需求，涉及人員：產(chǎn)品（iOS端和Android端）和運(yùn)營(yíng)；第三次針對(duì)那些不太確定的/沒(méi)考慮到實(shí)際可能遇到的問(wèn)題的需求進(jìn)行確認(rèn)，涉及人員：開(kāi)發(fā)和測(cè)試。等三場(chǎng)評(píng)審下來(lái)，就累成了狗。
一場(chǎng)需求評(píng)審會(huì)議變成了三場(chǎng)，這肯定是有問(wèn)題的，是該好好檢討下了。
之前一直在創(chuàng)業(yè)公司，需求評(píng)審會(huì)基本很隨意，叫上開(kāi)發(fā)、設(shè)計(jì)和老板就可以直接開(kāi)始了，評(píng)審會(huì)上也會(huì)遇到一些問(wèn)題，但涉及的人比較少，且一個(gè)人從頭到尾都只負(fù)責(zé)一個(gè)項(xiàng)目，事后基本上只要口頭確認(rèn)下評(píng)審時(shí)的問(wèn)題就行了。但流程較復(fù)雜的公司情況就有些不一樣了，需求評(píng)審會(huì)參會(huì)人數(shù)比較多，并且一個(gè)人可能會(huì)負(fù)責(zé)多個(gè)項(xiàng)目，需要重新調(diào)配資源，一旦評(píng)審中需求不確定/沒(méi)考慮周全的問(wèn)題，就會(huì)出現(xiàn)多次需求評(píng)審的情況，這就極大的降低了工作效率。
需求評(píng)審時(shí)常發(fā)生的情況：
1、與會(huì)人員對(duì)需求的目標(biāo)不明確，易發(fā)散思維，最終偏離方向。
2、對(duì)某個(gè)需求點(diǎn)相持不下，認(rèn)為該需求不合理/開(kāi)發(fā)周期長(zhǎng)不劃算，從而導(dǎo)致場(chǎng)面混亂，長(zhǎng)時(shí)間僵持下去。
3、對(duì)技術(shù)方案探討不定，對(duì)問(wèn)題點(diǎn)無(wú)限引申。
4、遺漏評(píng)審時(shí)的待改動(dòng)的需求點(diǎn)，會(huì)后找相關(guān)人員再次確認(rèn)。
基本上遇到上面情況中的任意一種，都會(huì)將需求評(píng)審時(shí)間拉長(zhǎng)，導(dǎo)致效率低下，輕則需求產(chǎn)生變更，重則需求功能無(wú)法實(shí)現(xiàn)，產(chǎn)品人員在評(píng)審過(guò)程中也容易產(chǎn)生渾身燥熱、體乏無(wú)力和頭昏腦漲的感覺(jué)_|￣|○...
那如何進(jìn)行有效的需求評(píng)審呢？
我結(jié)合我自己上周做的需求評(píng)審作了一些總結(jié)，天熱了給自己拔拔罐，希望能做到更規(guī)范，減少評(píng)審時(shí)會(huì)出現(xiàn)的問(wèn)題，少踩點(diǎn)坑。
將需求評(píng)審分為三階段：
1、評(píng)審前
相關(guān)資料準(zhǔn)備（確保人身安全）
1）產(chǎn)品需求文檔
我的需求文檔里一般包含四塊：項(xiàng)目背景、項(xiàng)目目標(biāo)、需求概述和需求詳細(xì)描述，必要的時(shí)候可以帶上項(xiàng)目風(fēng)險(xiǎn)（說(shuō)明此次版本可能帶來(lái)的問(wèn)題或考慮不夠完善的地方）和業(yè)務(wù)流程圖（對(duì)某些復(fù)雜功能/邏輯的分解）。
產(chǎn)品需求文檔主要是要把需求的邏輯表達(dá)清楚沒(méi)歧義，對(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)然不能事無(wú)巨細(xì)都通通一股腦寫進(jìn)去，不然開(kāi)發(fā)和測(cè)試的朋友會(huì)看的很辛苦，小心被打...
舉一個(gè)活生生的反例，上周寫文檔時(shí)有一個(gè)計(jì)算規(guī)則比較想當(dāng)然了，要算“累計(jì)閱讀時(shí)長(zhǎng)”，閱讀時(shí)長(zhǎng)嘛就是閱讀時(shí)長(zhǎng)嘛，一句話就帶過(guò)了，然后在需求評(píng)審時(shí)就比較慘了，該如何統(tǒng)計(jì)這個(gè)閱讀時(shí)長(zhǎng)？直接用定時(shí)器嗎？還是使用本地時(shí)間？用定時(shí)器比用本地時(shí)間相比既復(fù)雜又低效，但如果用本地時(shí)間，那用戶直接修改手機(jī)上的時(shí)間給不給累計(jì)閱讀時(shí)長(zhǎng)？還有用戶如果一直停留在當(dāng)前閱讀頁(yè)還給不給算閱讀時(shí)長(zhǎng)？...后面對(duì)這個(gè)功能的計(jì)算規(guī)則討論了好久，最終評(píng)審會(huì)上也沒(méi)確定下來(lái)。所以說(shuō)，做好細(xì)節(jié)是多么的重要！/(ㄒoㄒ)/~~
產(chǎn)品需求文檔的準(zhǔn)確和詳細(xì)可以有效減少需求評(píng)審時(shí)的花費(fèi)的時(shí)間，也能讓參會(huì)人員更清楚地了解需求。
2）線框圖
帶上線框圖而不是比如這樣或那樣，配合線框圖有利于對(duì)需求點(diǎn)的梳理。需求文檔里可以簡(jiǎn)要配些線框圖方便文字的理解，不過(guò)需求評(píng)審時(shí)還是另外打包一份線框圖單獨(dú)帶著吧，可以詳細(xì)點(diǎn)，把交互稿也帶上。
第一次評(píng)審的時(shí)候，我忘了帶，而需求文檔里也剛好沒(méi)放那個(gè)頁(yè)面的線框圖...于是我只能讓大家跟著我一起在腦海中繪制一副圖，能不能繪出來(lái)我就不清楚了Orz...反正不要學(xué)我！
3）相關(guān)數(shù)據(jù)
帶上數(shù)據(jù)而不是我認(rèn)為，一些需要數(shù)據(jù)支撐的需求點(diǎn)要帶上相關(guān)的數(shù)據(jù)，用數(shù)據(jù)說(shuō)話。
小范圍的溝通（確認(rèn)方案）
產(chǎn)品需求文檔寫好了，這個(gè)時(shí)候就可以去找涉及到本次改版的同事們?nèi)チ牧牧?，不要有寫好產(chǎn)品需求文檔就萬(wàn)事大吉，接下來(lái)只要等需求評(píng)審會(huì)就可以了這樣的想法。提前小范圍溝通可以避免很多不必要的撕逼，將一些不確定的方案給確定下來(lái)，探討方案實(shí)現(xiàn)的難易程度，確保某些需求的可行性，還可以發(fā)現(xiàn)可能與原有產(chǎn)品邏輯相沖突的地方等，把這些坑都填好，這樣在需求評(píng)審的時(shí)候就可以快速走過(guò)了。
上周我連開(kāi)了兩個(gè)項(xiàng)目的需求評(píng)審會(huì)，一個(gè)是改版還有一個(gè)是新應(yīng)用的上線，改版的需求評(píng)審總共開(kāi)了三次，就是最開(kāi)始說(shuō)的那種情況，而新應(yīng)用上線的評(píng)審只開(kāi)了一次而且只用了不到半小時(shí)，需求評(píng)審前和開(kāi)發(fā)溝通就基本上已經(jīng)將我不太確定的方案給確定了下來(lái)，并且確保了部分不確定需求的可行性，在評(píng)審會(huì)上是一次就過(guò)。有對(duì)比才會(huì)有真相，多么痛的領(lǐng)悟，不要什么都等到需求評(píng)審會(huì)議上才去確認(rèn)/解決，提前做好溝通工作，能大大提高需求評(píng)審的效率。但不是說(shuō)提前把所有的需求都溝通一遍啦！大家都很忙，動(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ù)的情況，說(shuō)白點(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ì)的信任感，以后辦起事來(lái)就比較方便了你懂得\(^o^)/。之前在創(chuàng)業(yè)公司就沒(méi)有碰到過(guò)這種情況，因?yàn)锳ndroid端和iOS端都是我負(fù)責(zé)的，功能是一致的，所以就沒(méi)這種情況，也就可以省去這一步產(chǎn)品內(nèi)部評(píng)審了...如果功能邏輯涉及到多個(gè)產(chǎn)品負(fù)責(zé)人，這一步還是很有必要的！
提前把需求文檔發(fā)出來(lái)（有備無(wú)患）
根據(jù)以上步驟確認(rèn)好需求后就可以把需求文檔發(fā)出來(lái)了，以郵件/群聊的方式發(fā)出來(lái)，讓與會(huì)者提前查看產(chǎn)品需求文檔，不求他們能夠把需求文檔從頭到尾看一遍，但求大家能知道下個(gè)版本要做的需求有哪些，這樣前期的服務(wù)工作才算到位。
以上工作都做好了基本上就可以進(jìn)行需求評(píng)審了，預(yù)約好會(huì)議室后通知相關(guān)參會(huì)人員參加。
2、評(píng)審中
正式需求評(píng)審時(shí)，帶好必備品，就可以開(kāi)始了，基本上只要前期準(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)度（兵來(lái)將擋水來(lái)土掩）
1）有清晰的目標(biāo)
相比其他參與者，產(chǎn)品經(jīng)理要對(duì)此次需求評(píng)審更有方向性和目標(biāo)性，這次改版所要解決的問(wèn)題以及所要達(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)并不是為了要說(shuō)服誰(shuí)！召開(kāi)評(píng)審會(huì)，就是為了讓大家對(duì)你提出的方案進(jìn)行批評(píng)指正或提出疑問(wèn)點(diǎn)，從而能及時(shí)地解決并發(fā)現(xiàn)方案中的問(wèn)題，保持各團(tuán)隊(duì)目標(biāo)一致，將產(chǎn)品做好。
2）把控好時(shí)間
需求評(píng)審時(shí)很容易會(huì)對(duì)某個(gè)需求/方案僵持不下，常一討論起來(lái)就是半個(gè)小時(shí)，多遇到這么幾個(gè)僵持情況，一場(chǎng)需求評(píng)審下來(lái)就好幾個(gè)小時(shí)，不僅會(huì)慢慢耗盡大家的精力，而且需求評(píng)審的效果也不好，得不償失！所以產(chǎn)品經(jīng)理要嚴(yán)格把控好時(shí)間，由于前期工作準(zhǔn)備不充分而導(dǎo)致一些需求/方案模棱兩可，且暫時(shí)無(wú)法立馬提出解決方案的可以會(huì)后確認(rèn)好后再溝通，必要時(shí)可以進(jìn)行第二次評(píng)審。
3）認(rèn)真傾聽(tīng)
可能別人一上來(lái)就開(kāi)始對(duì)你的方案提出不認(rèn)可，這個(gè)時(shí)候就得認(rèn)真傾聽(tīng)；開(kāi)發(fā)在探討技術(shù)方案的時(shí)候你也要認(rèn)真傾聽(tīng)；先在大腦梳理好他們?cè)谡f(shuō)什么，傾聽(tīng)后才能對(duì)癥下藥，而不是打斷然后陳述自己的觀點(diǎn)。
傾聽(tīng)后再陳述而不是直接打斷，可以讓人覺(jué)得你在認(rèn)真思考后才說(shuō)出這番陳述的，更有說(shuō)服力，并且不跟其他團(tuán)隊(duì)硬碰硬，先了解他們的問(wèn)題再提出解決方案，不是顯得更理智么？
4）保持清醒的頭腦
在需求評(píng)審會(huì)議中，很有可能會(huì)發(fā)生爭(zhēng)論，產(chǎn)品經(jīng)理一定要保持理性，切不可讓怒氣或膽怯沖昏了頭腦，失去理智。對(duì)會(huì)議上提出的每一個(gè)問(wèn)題都應(yīng)該記錄下來(lái)并作出解答，要冷靜客觀的把自己的觀點(diǎn)給陳述出來(lái)。
小范圍的討論（見(jiàn)仁見(jiàn)智）
在需求評(píng)審講需求點(diǎn)時(shí)，開(kāi)發(fā)會(huì)針對(duì)某個(gè)點(diǎn)進(jìn)行技術(shù)方案探討，這樣有利于及早發(fā)現(xiàn)需求點(diǎn)與現(xiàn)有邏輯相沖突或由于硬件問(wèn)題而導(dǎo)致需求變更或夭折的問(wèn)題，避免到開(kāi)發(fā)時(shí)才發(fā)現(xiàn)需求沒(méi)法做...但也要控制好時(shí)間，引導(dǎo)大概討論下技術(shù)實(shí)現(xiàn)方案，具體的細(xì)節(jié)之后再討論。
除了開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部小范圍的討論外，還有設(shè)計(jì)團(tuán)隊(duì)，不過(guò)設(shè)計(jì)一般不在需求評(píng)審會(huì)上討論了，畢竟，設(shè)計(jì)基本上不會(huì)影響到產(chǎn)品需求的變更。
定下開(kāi)發(fā)周期（誕辰）
如果評(píng)審順利的話，就可以直接定下開(kāi)發(fā)周期了；如果不順利，那就放在評(píng)審后吧~上周評(píng)審時(shí)就各種不順利，三場(chǎng)評(píng)審后還加了一場(chǎng)開(kāi)發(fā)周期的確定...祝愿以后一切順利吧！
3、評(píng)審后
會(huì)后及時(shí)輸出會(huì)議紀(jì)要，羅列出會(huì)議中有爭(zhēng)議仍待解決的問(wèn)題、改動(dòng)的部分和結(jié)論，將完善后最終更新過(guò)的需求文檔發(fā)送給參會(huì)人員，通知需求評(píng)審已完成。之后對(duì)問(wèn)題進(jìn)行跟蹤，保證評(píng)審結(jié)果的落實(shí)。
總結(jié)
能否在產(chǎn)品需求評(píng)審會(huì)議中如魚得水，提高需求評(píng)審的效率，我覺(jué)得前期的準(zhǔn)備工作很關(guān)鍵！
