編輯導讀：需求評審是每個產品經理都躲不過的一項工作，如何做好這項工作可大有學問。本文將從三個方面展開分析，對需求評審感興趣的童鞋不要錯過哦。

如果說產品經理的生涯是一條修煉之路，那么需求評審就是產品汪躲不過的劫。

做不好需求評審的產品經理，很可能會對產品生涯產生陰影，因為每一次需求評審都是對產品經理的多人毒打。

心態好的產品經理能每次爬起來完成蛻變，而心態不好的產品經理，很可能會被實力勸退。

尤其是對于新手產品經理，或者是新加入一個團隊的產品經理來說，第一次需求評審將決定你在團隊中的印象，也將決定你日后的日子是苦是甜。

如何讓產品汪完成需求評審而不群毆，本文從需求評審前，中，后三步來談一下我工作中得到的經驗。

一、需求評審前

正式需求評審前，一定要進行一次需求預審。

大事都是在小會上決定的，而大會只是做一個詳細通知和布置具體的任務。

需求預審的參加對象，是產品經理、前端主管、后臺主管，一般三個人即可，或者是前后臺的開發主力。

預審的目的有兩個：

1. 明確需求能不能實現
2. 驗證需求文檔的主要邏輯沒有問題

明確需求是否可以實現。有時候一些想偷懶的開發，面對一些復雜的需求，就會以“這個做不了”來推脫。

這個時候，你把預評審的結論說出來，他也就熄火了，就不至于陷入扯皮的尷尬。

驗證需求文檔的主要邏輯。大會評審的時候，如果主要邏輯出現了問題，那基本上可以確定要再進行一輪評審，這樣不僅浪費了大家的時間，還可能讓自己被貼上不靠譜的標簽。

需求評審前，一定要提前發評審邀請?？梢允青]件，也可以直接在工作群邀約。

但是一定要有提前量，這樣可以讓開發預習一下，提前把問題準備好，提高大會評審效率。

評審邀請，如果是寫郵件，發送郵件前，也最好在群里跟大家約一下時間，免得出現時間沖突的情況。

邀請郵件的內容一般包括：

• 需求的背景，便于理解
• 需求的功能列表（不需要太細）
• 需求文檔鏈接，看團隊習慣
• 會議主體、會議時間、地點和參與人員

郵件發完以后，記得在群里和大家同步一聲，免得有人漏掉郵件。

二、需求評審中

需求評審的步驟大致如下：

并不是每次需求評審都需要完全按照這個流程，比如是迭代型的需求，就不需要走第二步。

需求評審，本質上就是溝通，用語言配合原型文檔的方式，將需求清晰的表述出來。所以，一定要明白我們和其他人之間，肯定存在知識詛咒。

所以，不要一開始就講細節，不要一開始就講細節，不要一開始就講細節。

細節是永遠都扣不完的，如果在會議上陷入細節的討論，不僅浪費時間，而且對于產品經理來說也會非常痛苦。

因為總有一些細節是你沒有想到的，而且你會發現，一到這種時候，大家都非常興奮。

因為誰都會挑毛病，而且大家都非常樂意挑別人的毛病。所以不要找不自在。

而且陷入細節的需求評審，會顯得毫無邏輯。大家很容易一臉懵逼，特別是對于沒有提前看過文檔的同學（不幸的是，大部分同學都不會提前看文檔）。

在正式講解需求之前，一定要先明確本次會議的主題，會議需要完成達成哪些目的。主要事項有哪些，讓大家心里有底。這也是串起整個會議的主線。

正式開始需求評審后，首先要做的，就是要和大家達成一項共識：為什么要做本次迭代。也就是這些需求能帶來哪些價值。

而不是說那句表面上讓大家無法拒絕，但是實際會非常掉底子的一句話：這是老板的需求。

一般的需求價值包括：

• 需求符合公司的戰略目標嗎？
• 需求能帶來直接的收益嗎？
• 需求能提升用戶體驗嗎？
• 需求能提高效率或節省成本嗎？

和團隊成員達成共識的目的，是為了防止大家出工不出力。和大家就這些需求的價值達成一致，有助于更好的完成需求開發。

畢竟一個人從內心認可一件事的動力，和因為外力強迫不得不做的動力，那是天壤之別。

講解需求要從整體到局部。不要一開始就扎到細節里，否則大家也會跟著你去摳細節。

而需求評審并不是摳細節的，需求評審的主要目的是：

• 傳遞需求的價值，讓大家認可這個需求可以做，而不是被強迫
• 傳遞功能的場景，讓大家理解功能所覆蓋的用戶和使用的場景
• 明確需求實現的方式，劃分大致的任務和排期

我們要先從整體對需求的流程做一個梳理。一般都是從用戶的角度，對用戶使用這個功能的流程進行一個整體的梳理。

就像你在看一本書時，當讀到一半的時候，就忘記之前是講什么的了。

我們會發現很難將書中的知識串起來，這個時候往往都會選擇打開目錄，通過看目錄來幫我們回憶起之前的章節內容，從而將這些內容都串聯起來。

需求評審如何從整體開始？我們以優惠券需求為例。

評審優惠券相關的需求，就可以從優惠券的創建、優惠券發布、優惠券領取、優惠券消費。

這四個大的步驟進行整體的概況說明。以此為需求評審的主線，這樣大家在聽你講解具體需求的時候，不至于迷失在細節之中。

接下來，描述該功能的使用場景。我認為產品經理，最強大的軟實力，就是講故事的能力。

如何用一個故事把自己的想法表達清晰，讓大家易懂，并且得到大家的一致認可，是產品經理最難能可貴的能力。

在講解具體功能邏輯之前，可以先描述下具體的功能使用場景。

這樣有利于大家理解這個功能：

• 功能的用戶是誰？
• 用戶通常在什么場景下使用這個功能？
• 用戶當前在這個場景下遇到了什么困難？
• 我們的功能是怎樣幫助用戶解決問題的？

以場景的角度來描述功能，同時也是進一步讓大家理解做這個功能的價值所在。

而且產品經理在思考功能的使用場景時，也是進一步思考是否有必要做這個功能？怎么做這個功能才更好的機會？

而且，讓大家明確該功能的場景，有時候會有驚喜。有時候對于一些你認為比較復雜的功能，大家在明確背景的情況下，有可能可以想到更簡單的方案。

詳略得當，不要毫無重點地長篇大論。哪些該講？哪些不該講？

這個要看團隊之間的默契。如果是初期合作，大家都不太了解彼此的時候，建議要盡量詳細。

不要自以為某些功能很常見，例如輸入框的一些交互，就省略不講，到最后開發沒做，就只能自己背鍋。

對于配合默契的團隊，可以根據團隊的習慣，忽略掉一些以前做過的東西，或者一些常見的東西，比如輸入框的校驗規則等。

回答并記錄問題。需求評審大家肯定會提出很多問題，有的是質疑需求的必要性，有的是指出需求的不完整，或邏輯的缺失，有的是討論需求的實現方式等。

有的問題可以直接回答，例如需求的邏輯問題，實現問題，必要性問題等。

而有的問題則可以不回答，例如自己沒有想清楚的問題，一些比較細節的問題，而且這些細節不涉及其他同學，會后單獨私聊就可以解決的。

自己沒有想清楚的問題，千萬不要因為要面子強答，那只會讓自己更丟臉。

如果是簡單的問題，可以直接想一下然后回答。

如果是稍微復雜的問題，或者被問住了的問題，要及時認慫，承認自己事先沒有想好，先記錄下來，會后考慮清楚以后再同步給大家。

在評審過程中，作為會議的主講人，不僅要傳達完整清晰的傳達需求，還要控制會議的節奏，不要讓會議陷入摳細節的狀況，更不要讓會議跑偏。

發現有的同學喜歡摳細節，要及時制止，并建議在會后和他詳細討論。如果是跑偏，要及時將大家的注意力拉回來。

會議最后要形成會議結論。

會議結果無非兩種，成功和失敗。若會議成功，那大家就分配下一步工作。

若會議不成功，有一些需求邏輯待進一步梳理，那就約定由誰來梳理，什么時候完成并重新組織評審。

一定要有結論，誰干什么，什么時候交付，交付物是什么，都要定義清楚。

如果只定義了負責人，但是沒有定義交付時間，就會造成拖延，大學生綜合征就是典型。

如果沒有定義負責人，到最后，這件事大家都不會去做，三個和尚沒水喝。

如果沒有定義交付物，那他到底做還是沒做，就沒有一個可以衡量的結果，容易變成嘴炮。

三、需求評審后

需求評審后還不是結束，需要做兩件事：

1. 將會議上記錄的問題，一個一個落實

需求該修改的地方修改，該找人落實細節的找人落實細節，并且修改好以后，要以郵件的形式及時同步給大家，并且在群里進行簡要提醒和說明。

必要的話，可以組織小范圍的二次需求評審。

2. 需求評審復盤

記錄每次需求評審，大家提出來的問題。將這些問題進行分類統計。

哪些是自己經常忽略的問題，哪些是自己經常被問到的問題，哪些自己明明說了，但是大家還是會問的問題等。

對自己的每次需求評審都做一次復盤，總結自己沒有講好的地方，講的好的地方，下次該如何改進等。

有的同學說，需求評審的時候忙著回答問題，哪有時間進行記錄。

辦法總比困難多，你可以每次找一位產品同事幫忙記錄（他評審的時候，你幫他記錄），或者買一只錄音筆錄音，這都是好方法。

最后，總結一下：

需求評審前，盡量先進行一次預評審，并提前發出會議邀請，將需求文檔等資料提前發給大家熟悉。

需求評審中，會議一開始就要明確本次會議的主題和目的，需求講解，要從整體到局部，具體的功能講解從背景開始。

最后，會議一定要形成結論。另外，謹記：一定不要陷入細節！

需求評審后，將會議上的問題一個一個解決，將分配給或需要自己配合的任務一項一項推動。

另外，堅持對每一次需求評審進行復盤，明白自己的問題和優勢，有針對性的改進和提高。

本文由 @Jarvan 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議