剛加入現(xiàn)在的創(chuàng)業(yè)團(tuán)隊(duì)的那段時(shí)間，需要組織大家進(jìn)行需求評審，團(tuán)隊(duì)內(nèi)部沒有固有流程，加上自己本身經(jīng)驗(yàn)不足，我將原型文檔及標(biāo)注準(zhǔn)備的差不多之后，就『膽大妄為』的拿著這些內(nèi)容組織大家進(jìn)行需求評審。

評審會上，拿出原型稿，開始抑揚(yáng)頓挫的直奔主題，跟大家講流程、功能和規(guī)則。講完后大家一臉懵逼的看著我的演講終于要落下帷幕了，然后『聽講的人』開始毫不留情的把各種問題仍過來。比如：

你確定考慮清楚要這樣做了嗎？
這里為什么要這樣設(shè)計(jì)？
高保真設(shè)計(jì)稿還會在原型稿基礎(chǔ)上大改嗎？
你這里是啥意思，說的太籠統(tǒng)了
這樣做會有xx問題，老版本怎么考慮？

那時(shí)候才去公司沒多久，大家都比較客氣，不會直接噴過來。偶爾也被吐槽一下，那段時(shí)間還寫了篇文章：每個產(chǎn)品大概都被技術(shù)吐槽過吧。而更大的問題是，因?yàn)橛袝r(shí)對需求的拿捏不夠準(zhǔn)，或很多特殊情況未考慮到，需求評審期間跟大家溝通不夠清晰詳細(xì)，等開發(fā)進(jìn)行到一半后又拉著技術(shù)改需求，設(shè)計(jì)師改頁面，然后導(dǎo)致項(xiàng)目延期。

那段時(shí)間感覺很糟糕，尤其是需求評審前人很焦慮，擔(dān)心哪里沒準(zhǔn)備充分，哪里又沒思考清楚，怕被問到問題時(shí)回答補(bǔ)上來。。。

我意識到這個問題很嚴(yán)重，陸續(xù)找研發(fā)同學(xué)溝通，讓他們提出問題并給出建議，比如文檔需要準(zhǔn)備多詳細(xì)；拿捏不住的需求在初期可以跟他們先討論可行性；他們在開發(fā)過程中，不確定的地方會直接跟我討論，確定方案，不按照自己想的做等。之后也找了一些資料和書籍閱讀。經(jīng)過幾個月的磨合，一直在調(diào)整各種評審會姿勢，到現(xiàn)在為止，最明顯的感知是：
<b>1.臨時(shí)改需求的情況顯著減少；2.項(xiàng)目延期有減少；3.大大減少了技術(shù)的吐槽機(jī)會~</b>

這期間大概半年時(shí)間左右，也終于能比較坦然的組織需求評審了。然后趁著周末，我又完整梳理了一遍需求評審的流程和細(xì)節(jié)，也找了一些外部資料，整合了一篇關(guān)于需求評審的說明文。

1、為什么要需求評審？

需求到產(chǎn)品經(jīng)理那兒之后，經(jīng)過對需求的調(diào)研、分析，到確定要做之后，需要多個部門的同事配合才能完成，比如設(shè)計(jì)師、開發(fā)使得整個需求上線，而運(yùn)營負(fù)責(zé)對其進(jìn)行推廣、包裝給用戶使用等。那么，產(chǎn)品經(jīng)理完成他前期工作之后，需要讓大家周知整個需求的『來龍去脈』。所以<b>需求評審的目的</b>基本如下：

<b>-讓團(tuán)隊(duì)所有人（相關(guān)成員）明確需求背景和目的；
-確認(rèn)需求的規(guī)則及實(shí)現(xiàn)方案；
-確定整個項(xiàng)目的周期和內(nèi)容；
-讓相關(guān)人員了解自己所需負(fù)責(zé)的內(nèi)容；
-確定需求上線時(shí)間規(guī)劃；</b>

2、哪些人需參加？

一般情況下，一次需求評審中，參與的人包括：<b>產(chǎn)品、設(shè)計(jì)、研發(fā)、運(yùn)營</b>，大團(tuán)隊(duì)可能還有<b>測試、客服</b>等其他崗位的人。為什么這些人要參加？

<b>產(chǎn)品。</b>這里的產(chǎn)品是除了需求負(fù)責(zé)人外，可能還有該業(yè)務(wù)的其他產(chǎn)品經(jīng)理或公司內(nèi)部上下游產(chǎn)品同事，他們一般是為了解業(yè)務(wù)變更情況，甚至要配合做一些調(diào)整。比如，前臺業(yè)務(wù)變更時(shí)，后臺產(chǎn)品經(jīng)理可能需配合調(diào)整后臺的邏輯及設(shè)計(jì)。

<b>設(shè)計(jì)。</b>設(shè)計(jì)師通過需求評審，了解需求邏輯和規(guī)則，尤其是原型設(shè)計(jì)邏輯，并提出問題，方便后續(xù)產(chǎn)出設(shè)計(jì)稿。

<b>研發(fā)。</b>前后端、客戶端的研發(fā)等成員通過需求評審，了解需求的流程和規(guī)則，提出問題，溝通好細(xì)節(jié)方案，以便后續(xù)開發(fā)。

<b>運(yùn)營。</b>運(yùn)營同學(xué)通過需求評審，了解需求的背景、目的及流程，方便后續(xù)準(zhǔn)備運(yùn)營方案。

3、如何組織需求評審？

把整合需求評審會分為3個周期，一共有<b>3個階段：1）前期準(zhǔn)備2）評審會期間3）評審之后</b>

1）前期準(zhǔn)備

準(zhǔn)備越充分，評審效果越好，被吐槽的機(jī)會也越小。幾個小技巧如下：
<b>-完成需求文檔撰寫。</b>包括流程圖、原型、標(biāo)注等。然后反復(fù)多次推演，看是否有漏洞，盡量把能考慮到的問題都準(zhǔn)備好。

<b>-同核心人員小范圍溝通，確保沒有大問題。</b>這一招效果很好，提前溝通好，有大問題提前找出來并解決，避免在評審會期間出現(xiàn)大問題，甚至可能導(dǎo)致整個方案都無法執(zhí)行。

<b>-提前同相關(guān)參與同學(xué)協(xié)調(diào)好評審時(shí)間。</b>不要臨時(shí)組織評審，不僅可能人無法到齊，大家手頭有其他工作也會受到影響，心里也不爽。

<b>-提前將需求文檔發(fā)給大家。</b>讓大家有時(shí)間提前了解基本信息，提高評審會效率。當(dāng)然，提前發(fā)了可能也有人不會看，想辦法引導(dǎo)一下唄~

3.2 評審會期間

不要一上來就講功能，大致按照以下流程一步步說明需求信息：

<b>-先講需求背景。</b>讓大家知道為什么要，做了對用戶和我們自身有什么價(jià)值。這樣大家心里才明白參與到這個項(xiàng)目的價(jià)值，后面才有動力聽下去。

<b>-講功能模塊。</b>說明這個需求本身需要哪些功能來滿足，其中這一期先做哪些，后續(xù)迭代的時(shí)候再做哪些。

<b>-講業(yè)務(wù)流程。</b>說明整個需求的業(yè)務(wù)流程和數(shù)據(jù)流轉(zhuǎn)。

<b>-講原型和交互。</b>這一步終于可以拿出原型稿了，詳細(xì)的說明頁面布局、交互邏輯及規(guī)則等詳細(xì)信息；

<b>-講數(shù)據(jù)指標(biāo)。</b>溝通清楚需要哪些數(shù)據(jù)，在哪些地方埋點(diǎn)，數(shù)據(jù)如何可視化；

<b>-需要誰支持。</b>有哪些人需要投入到這個需求的項(xiàng)目中，以及負(fù)責(zé)的內(nèi)容是什么，上下游配合的人員是誰等；

<b>-預(yù)計(jì)上線時(shí)間。</b>需求排期，可以讓每個功能對應(yīng)的負(fù)責(zé)人估時(shí)，確定測試時(shí)間及預(yù)計(jì)上線時(shí)間。

基本上到這一步為止，需求評審會就結(jié)束了。另外，期間可能會有拋出一些問題，需要記錄下來。

3.3 評審會后

評審結(jié)束后，大家回去開始干活了，這時(shí)候最核心的是要push整個項(xiàng)目的進(jìn)度，保證在預(yù)期時(shí)間上線。

<b>-確認(rèn)排期，追進(jìn)度。</b>固定周期組織大家開會同步進(jìn)度，其他時(shí)間可私下追問進(jìn)度。確保一切順利進(jìn)展，若有問題也能提前了解。

<b>-整理遺留問題，并盡快給出解決方案。</b>評審會期間的問題及時(shí)解決，并將方案同步到相關(guān)的人員。

<b>-若需求有調(diào)整，更新需求文檔并發(fā)給大家。</b>

以上是這半年多來的一些親身經(jīng)歷和總結(jié)，晚安~