產品經理需要發問，需求評審就沒有一次就過的時候嗎？答案是沒有，為什么？

有一則故事：在一個需求評審的現場，參加的人有產品線的產品總監、產品經理、設計負責人、技術總監以及老板，產品經理伴著低保真的交互演示，開始介紹產品的需求、功能和交互。

產品總監說，還有一種情況你沒有考慮到。

技術總監說，這樣做太麻煩了，開發成本很高。

設計負責人說，這個地方的交互你確定是這樣的嗎？

老板說，我們的用戶是不是還有另一種需求，像我自己…

之后，他們又對此爭論了一番，才說服老板突然的想法。這時候產品經理心理五味雜陳，一方面覺得他們有的地方說得確實有改進的空間，另一方面面對領導和上級，有些地方他又沒有辦法很好去公開表達自己的想法。

最后，產品經理只好乖乖地回去一通改，而忘記了最初的需求和思考。

這是大多數產品經理的真實寫照，那么如何進行高效地需求評審？

首先，產品經理需要發問，需求評審就沒有一次就過的時候嗎？

答案是沒有，為什么？

有一點觀點需要明確，影響產品最終走向成功或者失敗的原因有很多，包括真實的需求、良好的用戶體驗、美觀的界面、可預期的開發成本等等。需求評審就是為了發現問題，保證產品能夠一直走在正確的方向。從宏觀上來講，需求評審需要傾聽。

那么從需求評審的外部來看，需求評審又分為哪幾個階段呢？

需求評審分為不同的階段，一般分為內部評審、預評審、正式評審和終評審四個階段。內部評審、預評審、正式評審和終評審的目的不同，參加的人員也有所不同。 同時，每一個階段也并不一定每次都一次通過。

內部評審的主要目的是：產品出了低保真原型之后，先進行內部的評審。即產品經理同事之間的相互評審，尤其是同一產品線有關聯的不同項目，如不同客戶端或者產品邏輯上有聯系。

產品經理同事坐在一起相互提建議、梳理邏輯、找坑，根據需求出發，發現產品邏輯問題。同時內部評審的又一個重要的目的是為了保證在更大范圍的需求評審會議上，產品經理同事之間可以保持立場的一致性。

預評審階段的主要目的是：產品出了低保真原型之后，先小范圍的進行溝通，提前滅掉大問題，從需求開始審視，確保方向正確之后，才能夠進入高保真設計階段，減少后續需求推翻帶來的人力資源浪費。

一般參加的人員有產品自己、產品線的同仁（包括產品總監）、UE和UI設計負責人、技術總監等。人員范圍不宜過大，主要是產品的前半階段的核心人員。

正式評審階段的主要目的是：設計根據完善后的低保真設計出高保真頁面，產品做好高保真交互原型，此時基本上可以還原產品90%的需求和交互場景，代表著產品的最終形態，除了基本的物料和數據交互之外。也就是說對高保真交互原型質量要求比較高，產品的核心人員會在一起看一下高保真的整體效果。

一般參加的人員有產品自己、產品線的同仁（包括產品總監）、UE和UI設計負責人、技術總監等。主要是在高保真環境下瀏覽產品的需求、功能、交互以及界面樣式，強調高保真的整體感受。

終評審階段的主要目的是：根據最終完善的高保真交互原型，產品提供產品說明文檔，提交給研發，讓研發理解需求、統一思想、確認實現方法和數據處理、評估研發周期，最終進入研發階段。

一般參加的人員主要有產品自己、產品線的同仁、相關研發工程師、測試工程師、運營等。涉及的人員主要是產品的后半階段的相關人員。

以上便是需求評審的4個不同階段，依照評審的不同目的來劃分。當然在實際的執行過程中，并不一定是4個階段都需要分別走一遍，可以根據實際情況適當地改變策略。

套路是死的，人是活的，具體看所在公司工作方式。對于初級產品經理來說，尤其要注意不同的需求評審階段的目的。

下一期我們講講需求評審的關鍵流程。

作者：吳翰中，微信公眾號：翰中的產品思考（ID：hanzhongPM）。寧思一時進，莫思一時停。

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

題圖來自PEXELS，基于CC0協議