起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何讓PM完成需求評審而不被打？
編輯導讀：需求評審是每個產品經理都躲不過的一項工作，如何做好這項工作可大有學問。本文將從三個方面展開分析，對需求評審感興趣的童鞋不要錯過哦。
如果說產品經理的生涯是一條修煉之路，那么需求評審就是產品汪躲不過的劫。
做不好需求評審的產品經理，很可能會對產品生涯產生陰影，因為每一次需求評審都是對產品經理的多人毒打。
心態好的產品經理能每次爬起來完成蛻變，而心態不好的產品經理，很可能會被實力勸退。
尤其是對于新手產品經理，或者是新加入一個團隊的產品經理來說，第一次需求評審將決定你在團隊中的印象，也將決定你日后的日子是苦是甜。
如何讓產品汪完成需求評審而不群毆，本文從需求評審前，中，后三步來談一下我工作中得到的經驗。
一、需求評審前
正式需求評審前，一定要進行一次需求預審。
大事都是在小會上決定的，而大會只是做一個詳細通知和布置具體的任務。
需求預審的參加對象，是產品經理、前端主管、后臺主管，一般三個人即可，或者是前后臺的開發主力。
預審的目的有兩個：
- 明確需求能不能實現
- 驗證需求文檔的主要邏輯沒有問題
明確需求是否可以實現。有時候一些想偷懶的開發，面對一些復雜的需求，就會以“這個做不了”來推脫。
這個時候，你把預評審的結論說出來，他也就熄火了，就不至于陷入扯皮的尷尬。
驗證需求文檔的主要邏輯。大會評審的時候，如果主要邏輯出現了問題，那基本上可以確定要再進行一輪評審，這樣不僅浪費了大家的時間，還可能讓自己被貼上不靠譜的標簽。
需求評審前，一定要提前發評審邀請?？梢允青]件，也可以直接在工作群邀約。
但是一定要有提前量，這樣可以讓開發預習一下，提前把問題準備好，提高大會評審效率。
評審邀請，如果是寫郵件，發送郵件前，也最好在群里跟大家約一下時間，免得出現時間沖突的情況。
邀請郵件的內容一般包括：
- 需求的背景，便于理解
- 需求的功能列表（不需要太細）
- 需求文檔鏈接，看團隊習慣
- 會議主體、會議時間、地點和參與人員
郵件發完以后，記得在群里和大家同步一聲，免得有人漏掉郵件。
二、需求評審中
需求評審的步驟大致如下：
并不是每次需求評審都需要完全按照這個流程，比如是迭代型的需求，就不需要走第二步。
需求評審，本質上就是溝通，用語言配合原型文檔的方式，將需求清晰的表述出來。所以，一定要明白我們和其他人之間，肯定存在知識詛咒。
所以，不要一開始就講細節，不要一開始就講細節，不要一開始就講細節。
細節是永遠都扣不完的，如果在會議上陷入細節的討論，不僅浪費時間，而且對于產品經理來說也會非常痛苦。
因為總有一些細節是你沒有想到的，而且你會發現，一到這種時候，大家都非常興奮。
因為誰都會挑毛病，而且大家都非常樂意挑別人的毛病。所以不要找不自在。
而且陷入細節的需求評審，會顯得毫無邏輯。大家很容易一臉懵逼，特別是對于沒有提前看過文檔的同學（不幸的是，大部分同學都不會提前看文檔）。
在正式講解需求之前，一定要先明確本次會議的主題，會議需要完成達成哪些目的。主要事項有哪些，讓大家心里有底。這也是串起整個會議的主線。
正式開始需求評審后，首先要做的，就是要和大家達成一項共識：為什么要做本次迭代。也就是這些需求能帶來哪些價值。
而不是說那句表面上讓大家無法拒絕，但是實際會非常掉底子的一句話：這是老板的需求。
一般的需求價值包括：
- 需求符合公司的戰略目標嗎？
- 需求能帶來直接的收益嗎？
- 需求能提升用戶體驗嗎？
- 需求能提高效率或節省成本嗎？
和團隊成員達成共識的目的，是為了防止大家出工不出力。和大家就這些需求的價值達成一致，有助于更好的完成需求開發。
畢竟一個人從內心認可一件事的動力，和因為外力強迫不得不做的動力，那是天壤之別。
講解需求要從整體到局部。不要一開始就扎到細節里，否則大家也會跟著你去摳細節。
而需求評審并不是摳細節的，需求評審的主要目的是：
- 傳遞需求的價值，讓大家認可這個需求可以做，而不是被強迫
- 傳遞功能的場景，讓大家理解功能所覆蓋的用戶和使用的場景
- 明確需求實現的方式，劃分大致的任務和排期
我們要先從整體對需求的流程做一個梳理。一般都是從用戶的角度，對用戶使用這個功能的流程進行一個整體的梳理。
就像你在看一本書時，當讀到一半的時候，就忘記之前是講什么的了。
我們會發現很難將書中的知識串起來，這個時候往往都會選擇打開目錄，通過看目錄來幫我們回憶起之前的章節內容，從而將這些內容都串聯起來。
需求評審如何從整體開始？我們以優惠券需求為例。
評審優惠券相關的需求，就可以從優惠券的創建、優惠券發布、優惠券領取、優惠券消費。
這四個大的步驟進行整體的概況說明。以此為需求評審的主線，這樣大家在聽你講解具體需求的時候，不至于迷失在細節之中。
接下來，描述該功能的使用場景。我認為產品經理，最強大的軟實力，就是講故事的能力。
如何用一個故事把自己的想法表達清晰，讓大家易懂，并且得到大家的一致認可，是產品經理最難能可貴的能力。
在講解具體功能邏輯之前，可以先描述下具體的功能使用場景。
這樣有利于大家理解這個功能：
- 功能的用戶是誰？
- 用戶通常在什么場景下使用這個功能？
- 用戶當前在這個場景下遇到了什么困難？
- 我們的功能是怎樣幫助用戶解決問題的？
以場景的角度來描述功能，同時也是進一步讓大家理解做這個功能的價值所在。
而且產品經理在思考功能的使用場景時，也是進一步思考是否有必要做這個功能？怎么做這個功能才更好的機會？
而且，讓大家明確該功能的場景，有時候會有驚喜。有時候對于一些你認為比較復雜的功能，大家在明確背景的情況下，有可能可以想到更簡單的方案。
詳略得當，不要毫無重點地長篇大論。哪些該講？哪些不該講？
這個要看團隊之間的默契。如果是初期合作，大家都不太了解彼此的時候，建議要盡量詳細。
不要自以為某些功能很常見，例如輸入框的一些交互，就省略不講，到最后開發沒做，就只能自己背鍋。
對于配合默契的團隊，可以根據團隊的習慣，忽略掉一些以前做過的東西，或者一些常見的東西，比如輸入框的校驗規則等。
回答并記錄問題。需求評審大家肯定會提出很多問題，有的是質疑需求的必要性，有的是指出需求的不完整，或邏輯的缺失，有的是討論需求的實現方式等。
有的問題可以直接回答，例如需求的邏輯問題，實現問題，必要性問題等。
而有的問題則可以不回答，例如自己沒有想清楚的問題，一些比較細節的問題，而且這些細節不涉及其他同學，會后單獨私聊就可以解決的。
自己沒有想清楚的問題，千萬不要因為要面子強答，那只會讓自己更丟臉。
如果是簡單的問題，可以直接想一下然后回答。
如果是稍微復雜的問題，或者被問住了的問題，要及時認慫，承認自己事先沒有想好，先記錄下來，會后考慮清楚以后再同步給大家。
在評審過程中，作為會議的主講人，不僅要傳達完整清晰的傳達需求，還要控制會議的節奏，不要讓會議陷入摳細節的狀況，更不要讓會議跑偏。
發現有的同學喜歡摳細節，要及時制止，并建議在會后和他詳細討論。如果是跑偏，要及時將大家的注意力拉回來。
會議最后要形成會議結論。
會議結果無非兩種，成功和失敗。若會議成功，那大家就分配下一步工作。
若會議不成功，有一些需求邏輯待進一步梳理，那就約定由誰來梳理，什么時候完成并重新組織評審。
一定要有結論，誰干什么，什么時候交付，交付物是什么，都要定義清楚。
如果只定義了負責人，但是沒有定義交付時間，就會造成拖延，大學生綜合征就是典型。
如果沒有定義負責人，到最后，這件事大家都不會去做，三個和尚沒水喝。
如果沒有定義交付物，那他到底做還是沒做，就沒有一個可以衡量的結果，容易變成嘴炮。
三、需求評審后
需求評審后還不是結束，需要做兩件事：
1. 將會議上記錄的問題，一個一個落實
需求該修改的地方修改，該找人落實細節的找人落實細節，并且修改好以后，要以郵件的形式及時同步給大家，并且在群里進行簡要提醒和說明。
必要的話，可以組織小范圍的二次需求評審。
2. 需求評審復盤
記錄每次需求評審，大家提出來的問題。將這些問題進行分類統計。
哪些是自己經常忽略的問題，哪些是自己經常被問到的問題，哪些自己明明說了，但是大家還是會問的問題等。
對自己的每次需求評審都做一次復盤，總結自己沒有講好的地方，講的好的地方，下次該如何改進等。
有的同學說，需求評審的時候忙著回答問題，哪有時間進行記錄。
辦法總比困難多，你可以每次找一位產品同事幫忙記錄（他評審的時候，你幫他記錄），或者買一只錄音筆錄音，這都是好方法。
最后，總結一下：
需求評審前，盡量先進行一次預評審，并提前發出會議邀請，將需求文檔等資料提前發給大家熟悉。
需求評審中，會議一開始就要明確本次會議的主題和目的，需求講解，要從整體到局部，具體的功能講解從背景開始。
最后，會議一定要形成結論。另外，謹記：一定不要陷入細節！
需求評審后，將會議上的問題一個一個解決，將分配給或需要自己配合的任務一項一項推動。
另外，堅持對每一次需求評審進行復盤，明白自己的問題和優勢，有針對性的改進和提高。
本文由 @Jarvan 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
寫的真好！
學習了