開需求評審是產(chǎn)品經(jīng)理的工作內(nèi)容之一，那么如何做好這項(xiàng)工作呢？梳理自己在工作中的實(shí)踐和感悟，希望能找到更適合的最佳實(shí)踐方法。

需求評審的作用

1. 向他人傳達(dá)自己設(shè)計(jì)理念

如何在會議上講解清楚自己的設(shè)計(jì)思路并得到大家認(rèn)可，是需求評審前應(yīng)準(zhǔn)備和考慮的問題。

2. 發(fā)現(xiàn)自己設(shè)計(jì)的不足，查漏補(bǔ)缺

一個人的思維畢竟是有限的，通過評審，讓不同角色的人員站在不同的角度審視方案，是很好地補(bǔ)充自己思維不足和發(fā)現(xiàn)方案缺陷的方式。所以，沒有評審，沒有交流，沒有討論，是一件多么可怕的事情。

3. 推動研發(fā)工作的重要節(jié)點(diǎn)

每次的需求評審都意味著產(chǎn)品研發(fā)進(jìn)度又前進(jìn)了一步，說明各項(xiàng)工作在慢慢不斷完善和向前推進(jìn)。

4. 凝結(jié)團(tuán)隊(duì)成員的力量

通過開會交流、討論，團(tuán)隊(duì)成員對自己的工作有更清晰的認(rèn)知和責(zé)任感，也是無形中團(tuán)結(jié)大家向同一目標(biāo)努力的一股力量。

需求評審的流程

1、版本范圍評審會

當(dāng)一個版本開啟時，需要先界定此次迭代的范圍。產(chǎn)品經(jīng)理先根據(jù)需求優(yōu)先級，確定一些需要做的需求點(diǎn)，并對這些需求點(diǎn)的業(yè)務(wù)邏輯和功能設(shè)置可進(jìn)行清晰地闡述。迭代需求點(diǎn)確認(rèn)后，召集需求方（如tob系統(tǒng)的業(yè)務(wù)部門、運(yùn)營部門等）、后端、前端、UI等干系人參加評審會議。此次會議更像是一個版本啟動會（類似項(xiàng)目啟動會），目的在于：

• 正式告知需求方，接下來我們打算做這些功能，若他們有更緊急的需求，可及時提出，保證每次迭代都在做最緊急重要的需求（當(dāng)然，不同的部門會從自身角度出發(fā)提出要求，此時，需要產(chǎn)品經(jīng)理進(jìn)行綜合考量）
• 使團(tuán)隊(duì)每個人對接下來將要做的事情有一個初步的概念和認(rèn)知，使團(tuán)隊(duì)就此事達(dá)成共識；
• 使每個人對自己接下來的工作做到心里有數(shù)，接下來有這些活等著我；
• 技術(shù)人員（尤其是后端）評估功能實(shí)現(xiàn)的技術(shù)難點(diǎn)及可行性，避免原型、交互等前期工作做完后，交到技術(shù)人員手上才知道有技術(shù)瓶頸造成前期工作和資源的浪費(fèi)。

此次評審需特別注意：需求點(diǎn)講解的粒度不應(yīng)過細(xì)，產(chǎn)品經(jīng)理只要講清楚，接下來我們將要做XXX這幾條需求，每個需求大概實(shí)現(xiàn)的是一個什么功能即可，避免陷在業(yè)務(wù)細(xì)節(jié)中，偏離會議的主旨。

2、功能方案業(yè)務(wù)確認(rèn)評審會

產(chǎn)品經(jīng)理根據(jù)確定后的需求列表，初步完成設(shè)計(jì)原型方案后，召集業(yè)務(wù)或需求方（若無需求方，應(yīng)在產(chǎn)品組內(nèi)部進(jìn)行評審）對功能設(shè)計(jì)進(jìn)行評審確認(rèn)。此次評審相當(dāng)于方案確認(rèn)會，目的在于：

• 從不同的視角審視方案是否符合需求，是否合理；
• 查漏補(bǔ)缺，通過評審，可以及早發(fā)現(xiàn)問題并及時補(bǔ)充完善；
• 通過業(yè)務(wù)需求方的審核，使得產(chǎn)品設(shè)計(jì)更貼近實(shí)際需求

此次評審，講解的重點(diǎn)在于，每個需求點(diǎn)是如何轉(zhuǎn)換為頁面上的功能結(jié)構(gòu)的？這樣的功能結(jié)構(gòu)是如何滿足需求的？為什么是這樣的結(jié)構(gòu)，設(shè)計(jì)的思路是什么？有人說，產(chǎn)品經(jīng)理最難的是，說服別人肯定自己的設(shè)計(jì)，此次會議要達(dá)到的就是這個目的。

3、UI交互需求講解評審會

方案經(jīng)過評審后，完善修改問題，無誤后，即可開啟UI設(shè)計(jì)。此時，召集UI人員講解和溝通需求。此次評審會的目的在于，讓UI理解每個頁面，為什么這個頁面上有這些功能點(diǎn)？這些功能點(diǎn)之間的聯(lián)系是什么？在講解的過程中，應(yīng)著重于頁面交互和功能說明，避免過多的業(yè)務(wù)細(xì)節(jié)困擾UI。

4、前端交互需求講解會

待UI出具了交互和設(shè)計(jì)規(guī)范后，需想前端宣講細(xì)節(jié)。此次會議主要由UI負(fù)責(zé)人講解，產(chǎn)品經(jīng)理輔助解釋。以前端人員理解規(guī)范、交互和功能設(shè)計(jì)初衷為目的。當(dāng)然在開會前，產(chǎn)品經(jīng)理應(yīng)該對交互設(shè)計(jì)稿先進(jìn)行審核，發(fā)現(xiàn)與需求不滿足的地方，并進(jìn)行討論修改。

5、后端技術(shù)需求評審

業(yè)務(wù)細(xì)節(jié)規(guī)則、功能設(shè)計(jì)符合需要，需求方通過評審后，可交由后端技術(shù)設(shè)計(jì)數(shù)據(jù)表等準(zhǔn)備工作。此時召集所有技術(shù)人員，一個個功能點(diǎn)進(jìn)行詳細(xì)的業(yè)務(wù)邏輯介紹，旨在幫助研發(fā)人員理解業(yè)務(wù)細(xì)節(jié)，幫助他們更好地進(jìn)行架構(gòu)規(guī)劃和代碼編寫。

6、評審路線圖

大致可以總結(jié)成下圖，當(dāng)然各項(xiàng)評審之間沒有固定的前后順序，不同職能間若不是強(qiáng)關(guān)聯(lián)，往往是并期進(jìn)行的：

（在新標(biāo)簽頁中打開，即可查看大圖）

需求評審的注意點(diǎn)

除了細(xì)節(jié)功能的講解，宏觀大框架的交代也必不可少：

1. 交代產(chǎn)品定位和目標(biāo)：不要一開會就馬上進(jìn)入細(xì)節(jié)功能，balaba講一通，別人還沒反應(yīng)過來，你給講完了。應(yīng)該先交代你要做的是個什么產(chǎn)品？PC端、移動端？APP、H5？為什們打算做這個產(chǎn)品？若是后期迭代，此處交代此次迭代的目標(biāo)即可。
2. 交代產(chǎn)品的面向用戶：產(chǎn)品是做給誰用的呀？產(chǎn)品給這些人提供什么樣的功能呀？此次迭代的功能主要是面向哪一些用戶的呀？
3. 交代產(chǎn)品的功能架構(gòu)：這么多功能，他們之間的層級關(guān)系是什么樣的？是用什么樣的線索和結(jié)構(gòu)組織起來的？
4. 交代功能設(shè)計(jì)的思路：一個產(chǎn)品肯定有一套統(tǒng)一的設(shè)計(jì)思路，比如統(tǒng)一的信息展示、統(tǒng)一的頁面流轉(zhuǎn)路勁。

總結(jié)一下，大概下面這些內(nèi)容是都應(yīng)該講解的：

誠然，不同的項(xiàng)目、產(chǎn)品、團(tuán)隊(duì)，實(shí)際的操作方式不同，但想要達(dá)到的效果一致，關(guān)鍵在于找到一個清晰的標(biāo)準(zhǔn)又靈活的適合自己的操作方式。

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

題圖來自 Unsplash，基于 CC0 協(xié)議