需求評審是需求分析過程中的最后一個階段，可以分為組內(nèi)需求評審、技術需求評審、客戶需求評審等。本文作者根據(jù)自己的工作經(jīng)驗，對需求評審的過程進行了拆解，希望能給你帶來一些幫助。

需求評審是需求分析過程中的最后一個階段，本文結合自己的經(jīng)驗對評審過程進行拆解，希望能讓我們的評審更順利，同時及時發(fā)現(xiàn)自己在評審前工作的不足之處，持續(xù)精進。

之前的文章中寫過需求洞察（從收到需求到明確需求——需求洞察）、需求變更（頻繁的需求變更讓你痛苦過嗎？）、需求蔓延（需求蔓延的復盤與思考）、需求講解（如何做好一場需求講解），再加上今天的需求評審，和需求相關的幾大重要節(jié)點就整理完了，后續(xù)我會繼續(xù)補充其他和需求相關的內(nèi)容，歡迎持續(xù)關注~

言歸正傳，需求評審基于參與的人員不同、評審的目標不同、所處的階段不同，也可以再細分為組內(nèi)需求評審、技術需求評審、客戶需求評審等，當然有些關鍵需求可能還會涉及與公司領導層進行評審。不同的情景下，我們評審的側(cè)重點和注意事項也會有很多差異。

雖然有很多差異，我還是盡量以標準化的形式進行拆解，再針對部分差異單獨說明。

全文概覽：

1. 評審是評什么
2. 評審的目標
3. 評審前的準備
4. 評審中的講解
5. 評審中的討論
6. 評審后的結論
7. 評審后的完善

01 評審是評什么？

1）評審業(yè)務方案是否滿足原始需求

最基礎的目標，就是確認本次解決方案和原始需求是否貼切，通過我們深入的需求洞察和方案整理后，是否能夠滿足業(yè)務提出方的要求。

2）評審工作量是否可控

尤其對于有技術團隊參與的需求評審，他們需要對本方案的開發(fā)工作量進行預估，可能一句很簡單的方案但在執(zhí)行時卻很復雜。

同時如果涉及到關聯(lián)方的改造，對方是否愿意配合，對方對我們的進度計劃是否接受，也是需要在評審過程中最終確認的（當然有些情況不需要在需求評審會確認，這里不再單獨羅列）。

3）評審方案是否滿足業(yè)務規(guī)劃

本次方案除了滿足原始需求之外，可能需要領導或者業(yè)務相關的其他負責人評估本次的方案是否支持后續(xù)的場景拓展，是否支持系統(tǒng)的中遠期規(guī)劃。我們也會遇到即便方案滿足原始需求，但有些業(yè)務規(guī)則的制定存在局限性的情況，這時為了后續(xù)業(yè)務的拓展，本次規(guī)則也需要同步修改。

不知道你是否聽到過客戶或者領導這樣的話：“這塊后續(xù)打算XXXX做，還要和XX系統(tǒng)對接上，你們要留個口子”。

這里與技術側(cè)的設計評審有相通之處，即便本次只是做MVP流程，但為了滿足后續(xù)的版本迭代，在設計時功能結構上也要對應滿足拓展性。

4）評審可行性是否合理

同樣的場景，會存在多種實現(xiàn)方式，需求人員在制定方案時可能只站在業(yè)務角度或個人經(jīng)驗角度進行分析，但其他角色可能會有更優(yōu)的、更貼合現(xiàn)狀的解決方案。

所以對于方案細節(jié)的合理性評估，也是本次評審的重點內(nèi)容。

5）評審邏輯結構是否嚴謹

最后，對于很多評審而言，針對關鍵業(yè)務的邏輯規(guī)則嚴謹性也需要詳細確認。此時可能需要技術負責人、測試負責人發(fā)表自己的意見，對關鍵細節(jié)提出質(zhì)疑并形成多方認可的解決方案。

以上提到的評審內(nèi)容，不同團隊、不同業(yè)務模式，都會存在差異，每個參與評審的人員出發(fā)點不同，關注點不同。

雖然不能一概而論，但既然做評審，我們就是要圈定一個范疇，讓多方角色對這件事達成共識。

02 評審的目標

雖然說評審都是為了讓大家達成共識，但不同的參與人，不同的背景下，評審的目標也是不一樣的。而且不同的目標也會影響我們在具體評審過程中的流程和側(cè)重點。

1. 內(nèi)部評審

屬于產(chǎn)品組內(nèi)部的評審，會涉及其他產(chǎn)品同事、產(chǎn)品總監(jiān)，當然也可能會邀請一些其他組的相關成員提前參與。

這一步的目標更偏向于整體方案的合理性、完整性以及和版本的規(guī)劃、市場反饋的優(yōu)先級等綜合商討，具體功能的實現(xiàn)方法是否滿足當下訴求。

其中方案撰寫人可能在某個問題上有多個方案，或者無法權衡具體優(yōu)劣，都可以在內(nèi)部評審時先由產(chǎn)品團隊內(nèi)部討論進行初步抉擇。同時要向組內(nèi)的伙伴們講解關鍵功能的設計思路、背景原因等。

因為產(chǎn)品組內(nèi)同事，都是你“最親密”的戰(zhàn)友，我們面對相同的合作環(huán)境，工作方法論也是相互貼近的，他們也是最能理解你的。所以在內(nèi)部評審時，只要時間允許，我更傾向于【細致】。

對于產(chǎn)品組內(nèi)評審，我認為的關鍵詞是：盡量完整。

2. 技術評審

技術評審是和開發(fā)團隊進行評審，更側(cè)重于方案的落地性分析、工作量初步評估，疑難雜癥的解決方案商討，同時需要技術團隊幫我們查漏補缺。

尤其是涉及功能迭代的需求，可能我們認為一個很簡單的功能，在實現(xiàn)時需要傷筋動骨。

技術評審則需要我們把需求講明白，不要遺漏，同時結合開發(fā)人員提出的工作量、工期等問題進行權衡、補充或刪減。

同時我們可以通過他們的關注點更加理解技術思維，在后續(xù)的版本迭代過程中，合理的融入一部分技術思維來制定方案（當然這里面也有一個“尺度”問題，具體可查看歷史文章：辯證難題 | 產(chǎn)品經(jīng)理要不要懂技術？）

對于和技術團隊進行的需求評審，我認為的關鍵詞是：工作量。

3. 客戶評審

對于外包類項目等需要客戶方參與的需求評審，很多情況下評審會變成一個不可裁剪的流程節(jié)點。雖然有些可能是走個過場，但我們要認識到這次評審的重要性。

在評審時盡量解決之前因為協(xié)調(diào)困難等原因而遺留的需求問題，需要趁著領導在場時“拍板”或者“授權”或者“推進”。

客戶評審時除了我們的需求人員、項目經(jīng)理，客戶方的領導，還可能有其他關聯(lián)方的配合人、其他業(yè)務部門的協(xié)作人等等。因為涉及成員比較復雜多變，所以通用的方法論也不像另外兩個評審標準，但更能體現(xiàn)需求人員的真實水平。

評審已經(jīng)是最后一個階段了，如果前期工作到位，評審過程會很順利。一旦在評審時狀況百出，困難重重，那一定要回顧自己之前的階段是否有不到位的工作。

對于和客戶進行需求評審，我認為的關鍵詞是：簽字。

4. 領導評審

其實和公司領導進行需求評審，會摻雜更多“匯報”的意味。如果前期匯報及時，最終的評審也會比較簡單順利。

如果前期領導比較忙，或者你們溝通的不及時，那也可能會在評審時對方案產(chǎn)生戰(zhàn)略性轉(zhuǎn)變。

而且對于領導的評審，可能更需要的是言簡意賅，挑重點，畢竟領導的時間也不會很多（這里和客戶評審在時間上的要求也比較類似）。

對于和領導進行需求評審，我認為的關鍵詞是：支持、授權。

雖說每種評審形式有各自的側(cè)重點，但我認為最基礎的目標依然是為了形成多方之間的“執(zhí)行對齊”。

03 評審前的準備

組織起一場正式的需求評審不太容易，所以為了讓評審的目標更容易達到，讓評審的價值更好的體現(xiàn)，我們在評審之前一定要做一些準備。

首先，主講人要對本次評審的需求和方案很熟悉，對一些具體的實現(xiàn)步驟產(chǎn)生的原因很了解（因為可能涉及工作交接、人員變動等情況，有些功能不一定出自自己的思考。延伸閱讀：工作交接中的“交”與“接”）。

這樣既能保證講解過程的連貫和全面，也能確保在提問、討論環(huán)節(jié)的“穩(wěn)定性”（包含情緒的穩(wěn)定、思路的穩(wěn)定、溝通表達的穩(wěn)定）。

其次，我們要盡量讓參與人在會前對整個文檔，或涉及到自己工作的內(nèi)容進行提前閱讀。雖然我們無法保障閱讀的質(zhì)量，但是這一步的要求不能省去。因為屆時我們無法保證臨時性的理解能否真正到位，能否對此功能有全面考量。同時預防一些“漫無邊際”的想法影響評審的正常進行。

而且，對于客戶評審來說，我們在評審之前，絕大多數(shù)問題都應該已經(jīng)提前溝通完成，該確認的問題也確認清楚，需要關聯(lián)方配合的內(nèi)容也已經(jīng)私下確認，此時不應該遺留太多的問題準備在評審會上討論（特殊情況除外），從而提前保證評審的連續(xù)性和目標感。

最后，我們需要協(xié)調(diào)好時間，發(fā)會議通知（形式不限），并且準備好講解過程中需要用到的文檔、物料等。還要單獨準備一個文件或記事本，將討論過程中的遺留問題記錄下來，把待確認的問題列清楚，免得遺漏關鍵內(nèi)容。

04 評審中的講解

這里又涉及到需求講解的很多方法和細節(jié)，我在之前的文章中雖然總結了需求講解的注意事項，但是針對需求評審中的講解還有一些特殊的情況。

1. 針對評審內(nèi)容和參與者，適當調(diào)整講解的細致程度

• 我們以客戶評審為例，如果有大領導參加，而且需求的內(nèi)容很多，那我們需要挑重點的功能來講解，并且不需要講解具體的規(guī)則；
• 如果有很多關聯(lián)方參與，則側(cè)重點在這些關聯(lián)方如何配合，關聯(lián)方在整個平臺中扮演怎樣的角色；
• 或者某些功能屬于產(chǎn)品的標準化流程，則也可以加快進度，重點講解特色化功能的邏輯關系。

總之一句話，同樣的內(nèi)容根據(jù)不同的聽眾一定有不同的講解套路，我們要知道對方更關心什么，同時時刻提醒自己本次評審的目的是什么。

我們所有的講解、討論，都要基于目標而來。

2. 針對評審參與者與背景，適當調(diào)整宏觀場景的描述

• 比如功能的迭代評審，宏觀場景描述更多側(cè)重于本次為什么要迭代這些新功能；
• 如果是0-1的新系統(tǒng)評審，則要把需求的背景，整體的參與角色、場景通過流程圖或其他形式表達清楚；
• 如果內(nèi)部評審或技術評審大家對這部分內(nèi)容很了解，則可以更快的直奔主題。

3. 搭配更易懂的表現(xiàn)形式

文字的表現(xiàn)力一定不如圖形、動畫。為了讓聽眾能夠更快的理解，或者避免對方和自己思路不同頻，我們可以搭配流程圖、原型圖、UI圖等物料來輔助自己的講解。尤其是相對復雜的處理邏輯，基于流程圖的講解能讓結果事半功倍。

如果條件允許，在講的過程中在白板上寫寫畫畫，不僅能更抓住聽眾的注意力，讓對方更好的理解，還能對講解人的水平有充足的認可，后續(xù)討論過程也會更信服你給出的方案。

去年有一個新系統(tǒng)的建設，客戶評審一共進行了兩個半小時，我針對系統(tǒng)的核心流程圖的講解、討論就占了一個多小時。而這些關鍵內(nèi)容真正梳理清楚并讓大家理解后，后續(xù)的細節(jié)其實就沒有那么重要了。

而且通過這次評審，讓幾位關聯(lián)方負責人很認可我們的方案，后續(xù)推進執(zhí)行過程也很順利。

05 評審中的討論

這一步其實是最不可控的，也是最容易產(chǎn)生風險的。因為我們無法預估對方的思維會對整個方案提出怎樣的影響。

但換個角度來考量，這個過程又是一個學習進步的時機，我們通過不斷的吸收對方的意見，并快速甄別篩選，想出應對策略，本質(zhì)對自己的能力也是一個很高的要求。

同時還可以以同理心站在對方的角度深入考慮，他為什么如此關注這個問題？他為什么會想在這里加這個功能？他為什么對我的方案產(chǎn)生質(zhì)疑？

這一系列的過程，最終都能夠讓我們通過本次評審“成指數(shù)型”成長。

具體問題和應對策略不再深入分析，這里總結幾點小建議供大家參考：

1. 關注核心目標，不要讓發(fā)散性問題影響整體的評審進展；
2. 關注問題根源，不要讓臨時性的方案為后續(xù)埋雷；
3. 合理控制討論時間，不要讓評審變得“又臭又長”；
4. 關注領導關注的內(nèi)容，優(yōu)先解決領導的問題；
5. 及時甄別問題，不要因為小問題引申出大問題；
6. 客戶評審時，討論的過程很容易引起需求變更和需求蔓延，要提前和自己團隊的人，或者關聯(lián)方的人提前溝通好，屆時一起“打打配合”；
7. 討論的內(nèi)容無論結果與否，都記下來，用于會后自己的復盤總結。

06 評審后的結論

評審即將結束時，一定要進行現(xiàn)場的總結。

總結依然要與本次評審會的目標相結合，并將遺留問題、或會中討論的結論進行復述，一是為了再次強調(diào)這些內(nèi)容以免遺漏，二是避免大家仍然對這些討論結果沒達成共識，后續(xù)推進時又要重新掰扯。

同時對于遺留問題要列好推進周期、關聯(lián)人，并且對下一步的工作進行初步確認。

比如客戶需求評審完成后，遺留了5個問題，兩個需要完善方案，兩個需要找關聯(lián)方協(xié)調(diào)確認，一個屬于遺留問題，要等到某個階段再來決定。

• 這時我們需要向參會者表達新的方案什么時間能夠完成，屆時會再更新一版供大家查閱；
• 確認兩個關聯(lián)方的協(xié)調(diào)時間和人員，由誰負責主導，什么時間能夠確認下來；
• 還要把遺留問題的風險提出來，而且等到可以做決定時不要遺忘，并且不能對項目的整體進展，上線驗收等產(chǎn)生影響。如果存在類似的風險，則要提前確認折中方案或置換方案。

最后確認本次評審是否需要二評。

07 評審后的完善

評審結束不是終點，也可能是新階段的起點，也可能是終點前的最后一步。

我沒有見過評審后不需要完善方案的評審會，所以無論是否需要二次評審，本次的待修改點一定是必做的。

同時像上文提及的復盤、同理心思考對方的問題，并從中引申出自己業(yè)務的新思路，或者拓展自己的認知盲區(qū)，從盲區(qū)中尋找業(yè)務風險點，這些都是在評審之后，或者說方案完善后，需要持續(xù)思考的內(nèi)容。

這些思考要趁熱打鐵，盡量不要擱置，因為當下的感受是最真實的，自己的思路也是更全面、更發(fā)散的。即便有些優(yōu)先級低的遺留問題，也千萬不要不了了之。

即便某個功能擱置不做，作為業(yè)務人員，我們也不能不想，否則怎么更進一步呢？

當然，復盤時我們依然要把握核心目標，不僅在本次需求評審會上提到的問題需要復盤，很多問題背后反映的前期工作問題，更要能意識到。

• 比如張三當時為什么提了這樣一個驢唇不對馬嘴的問題？——很有可能是因為你開始的講解沒有讓他聽明白；
• 比如李四為什么把上周確認的方案又拿出來討論？——可能當時的方案沒有得到他的認可，或者他原本就沒有明白這個方案的內(nèi)容；
• 比如王五為什么昨天說好幫我推進這個方案，結果今天“反水”了？——可能是因為他發(fā)現(xiàn)領導并不支持這個方法，或者他突然發(fā)現(xiàn)了此方案的邏輯漏洞；
• 比如趙六今天提的這個問題為什么我之前沒有想過呢？——可能是之前工作交接時沒有把此功能當做重點，也可能自己本身對業(yè)務的理解還不全面，也可能……

所以，評審雖然結束了，但我們的工作沒有結束，個人的成長也遠沒有結束。

08 寫在最后

不同的目標，不同的環(huán)境，不同的對接人，不同的業(yè)務場景，需求評審過程中需要注意的內(nèi)容都會有很多差異，篇幅有限，不能把更多的例子逐一拆解，但上述所整理的關鍵節(jié)點和方法論，希望能夠給有緣讀到這里的你，帶來一些幫助。

上述的內(nèi)容并不絕對，比如評審時間的控制，對于客戶評審盡量不要搞的太久。但是我也遇到有些客戶會和我們一條一條過規(guī)則，戰(zhàn)線拉的很長?？傊覀円耙蛉硕悺焙侠磉m當?shù)恼{(diào)整我們的評審節(jié)奏、內(nèi)容。

更不能因為客戶問的細而不耐煩，也不能因為客戶什么都不問而沾沾自喜。畢竟最終這些沒有確認的細節(jié)，都可能是后期需求變更、系統(tǒng)缺陷、生產(chǎn)事故的一個個“伏筆”。

需求是系統(tǒng)的源頭，在需求階段每多確認一個細節(jié)，每多達成一個共識，每多識別一個風險，都能為后續(xù)的開發(fā)、測試、投產(chǎn)、運維等各個階段節(jié)省很多時間。

雖然需求的好與壞很難客觀評估，但作為一個負責任的需求分析、作為一個有職業(yè)素養(yǎng)的產(chǎn)品經(jīng)理，讓需求更完整，更合理，更切合實際，應是我們持久的追求。