需求評審，是每一個產品經理幾乎每周都會經歷的過程。只要工作在進行，產品在迭代，新需求在不斷產生，就會有需求評審。

在需求評審會議上，前端、后端、測試、UI、你的老板可能都會過來，不同的角色聚在一起，聽產品經理講需求內容。這不是一件容易的事情，如何高效完成需求評審，對每一個產品經理來說，都需要去仔細琢磨，也是必須得掌握的基本功。今天我就跟大家聊聊這個話題。

01

先說下背景故事。

春節后因為疫情的影響，我在家辦公差不多有三周左右。因為是遠程，導致日常很多需要組會溝通的事情，現在都通過文檔的離線溝通完成。

因此，對于我來說，也有了非常完整的時間去思考和設計Q1計劃完成的一個大項目。在之前的文章里也提高過，是贈品系統。

這個系統最終的產品原型，包括兩個后臺模塊和兩個C端頁面，非常復雜。PRD完成之后，連我自己都驚呆了，快趕上一篇小論文了。

但就是這么多內容，需要在1個小時左右的時間內，跟相關團隊講清楚，將需求完成地交付到研發階段。幸運的是，我完成得還算可以，尤其在遠程辦公的情況下。

今天我就以這個項目為例子，給大家說說，如何高效完成需求評審。

02

關于需求評審要傳遞的信息，其實包含了非常簡單的一套邏輯：價值、功能、實現。

• 價值：為什么要做這個需求，上線之后的價值是什么。
• 功能：為了支撐這個價值，需求包含了哪些功能呢。
• 實現：針對每一個功能，該怎么實現。

比如說我做一個給老板用的數據看板，價值就是使得老板可以隨時了解項目進度，功能是需要呈現A、B、C等三個維度的數據，實現就是每個數據的口徑是什么，數據在看板上如何分布，以什么樣的圖表形式呈現。

而關于需求本身，又大致可以分為：功能優化，功能拓展，新項目。不同類別的需求，在評審會上傳遞的信息重點不太一樣。

1. 功能優化：重點在講清楚如何做，往往評審時間較短，不會單獨組會，跟著其他需求一起評審。
2. 功能拓展：重點在講清楚是什么，與原有功能的聯系是什么，可能要單獨組會。
3. 新項目：重點在講清楚為什么要立這個項目，項目包括哪些模塊，模塊間的聯系是什么，每個模塊的功能及實現。

所以從信息量上來說，新項目的評審是密度最高的，也是最考驗表達邏輯及評審效率的。我理解的高效評審，是向協作團隊傳達出了統一的項目價值，能夠讓他們理解彼此的角色，任務及需要落地的行動，最關鍵的，彼此角色之間的關聯是什么。

我們都能理解，人對新事物的信任感是相對低的。產品經理在需求評審會上最重要的任務，是幫助大家建立這種信任感，傳遞兩個信號：這個事兒值得做；這個事兒能做。

下面我重點說說新項目在做需求評審時，如何可以更高效。

03

第一，用最直接的方式說明需求價值

產品經理是了解需求價值的，但這遠遠不夠，你需要讓協作團隊也了解需求價值。但協作團隊往往沒有像你一樣，對需求背景做過很多調研。

怎么樣在最短的時間內傳遞清楚需求的價值呢？量化指標，數字切入。

比如說贈品系統，這個系統的價值也很多種描述方式：效率提升啦，解決了以前的某個行業問題啦，老板很關注啦等等，但這些不夠直接。

想在最短時間內說明這個系統很重要，你得知道這是多大規模的盤子。什么意思，你得調研清楚，一家零售超市一年的贈品營銷規模是多少，你的項目，直接關聯多大規模的盤子。把這個數字擺出來，需求的價值就一目了然了。

第二，說明為需求設計方案之前的準備工作

這是我以前工作中容易忽略的一步，但最近一段時間以來很重視的一點。前面說過，人對新事物的信任感是相對低的。同理，協作團隊對新項目的信任感也是相對低的，他們會經常懷疑產品經理——

1. 這是不是老板需求，而你只是一個執行者的角色；
2. 這是一個確定的需求，還是你拍腦門想出來的；
3. 最關鍵的，這件事情，你作為產品經理有沒有想清楚或者為此做過一些準備。

所以，準備工作及相關的核心結論，有必要在評審會上同步。例如做過哪些競品調研；公司戰略層有一些什么指示；跑過的一些測試case，有沒有什么核心結論。

這一步的重點不在于讓需求變得更清晰，而在于提升協作團隊對新需求的信任感——我，產品經理，在組織今天的評審會之前，已經做了不少相關準備工作，這件事情，我是想清楚了的。

第三，邏輯+模塊的表達方式

我聽過一些產品講需求評審，或是對著PRD講，或者對著原型一張圖一張圖地講。但老實說，這種方式不適合新項目的評審。

新項目因其內容密度大，往往會產生“聽不懂+不知道現在講到哪一步了”這樣的負面效果。本質上都是因為，沒有在聽眾腦中建立起邏輯主線。

我自己在設計贈品系統的時候，會有一個邏輯鏈，鏈上每個關鍵節點便是一個產品模塊，所以先講清楚邏輯鏈，再講每個鏈上的產品模塊，是比較好的表達方式。

就好比我自己看論文的時候，先看目錄，再看每個章節，看到難懂的地方，時不時回到目錄來，看看現在到哪一步，漸漸地就搞懂了。

同樣的，新項目的需求評審就是你帶著協作團隊一起看論文的過程。先介紹目錄，再介紹每一章的具體內容，遇到卡點，回顧一下目錄，告訴大家我們現在在講的內容處于什么位置。這樣反復強調，邏輯鏈立住了，需求評審就成功了一大半。

第四，上帝視角與用戶視角的結合

我們知道，關于產品有兩個常用的視角，上帝視角和用戶視角。前者是產品經理在設計方案時常用到的，后者是用戶從進入產品的一剎那，到最終退出，所經歷的完整過程。

就拿開車舉例，上帝視角是我出發之前，在地圖上看到的線路，我大概知道整段路程多遠，大概要多久，在哪些路段可能會堵。用戶視角，就是我出發后所看到的每一個路口，斑馬線，紅綠燈等，直到最終我到達了目的地。

開車的時候，司機會聽導航，但也會看路。所以介紹需求的時候，我建議產品經理也結合上帝視角和用戶視角穿插來講。

比如我在介紹贈品系統的時候，既要說明邏輯、模塊、功能等上帝視角的概念，也會從一個具體配置人員的角度，或者門店執行人員的角度，講一講他們該如何使用這個系統。

只說上帝視角，不容易理解，別人理解起來困難；只說用戶視角，太零碎，不容易記住主線。結合起來，就能最快幫助協作團隊理解，這個事兒是什么，該怎么做。

最后一點，學會區分聽眾的提問

我們要明白，在一個小時的時間里，完全講清楚一個新項目，幾乎是不可能的，即使你講得完，聽眾也一定消化不了。這必然會導致，當你講完之后，一堆問題接踵而至。

這時候產品經理需要學會判斷，什么樣的問題該當場解答，什么樣的問題下來私聊。

我個人的建議是，如果一個問題滿足以下若干條件之一，你得當場解決了：

1. 關乎價值，關乎為什么做；
2. 關乎完整性，這個問題不解決，整個產品邏輯跑不通；
3. 會帶來聯動效應。

比如一個問題，如果跟前端、后端、UI都有關系，那你得當場確認了，因為把大家湊在一起不容易。而那些各個團隊自己的問題，比如前端細節，交互細節，后端邏輯細節，或者是你還不確定的點，可以下來了慢慢私聊。

我們要記住，高效的需求評審不是解決100%的問題，而是在1個小時的時間里解決最重要的問題。

為什么要在一個小時內，因為時間長了，我們的精力和注意力都會打折扣，相信大家都有這樣的體會，一切方法論都不管用了。

最后的最后，有朋友可能會問，你不是要講需求評審么，為什么重點都在講新項目的評審。因為當你可以搞定一個新項目的需求評審時，我相信其他類型的需求，你也都可以應對自如了。

#專欄作家#

大力哥呀；微信公眾號：大力哥求職，人人都是產品經理專欄作家。正年輕的產品經理，關注新零售、用戶體系，擅長問題抽象及拆解。

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

題圖來自Unsplash，基于CC0協議