編輯導讀：需求評審是產品經理的一項基礎工作，和技術人員、UI設計師等人員一起探討需求落地的可行性。在需求評審會議中，不單單只是講解，還需要把握要點，讓需求評審會議發揮出它最大的價值。本文作者對此進行了分析，與你分享。

需求評審是產品經理工作的重要環節，是團隊成員間銜接需求的重要橋梁，產品經理的方案能準確落地的重要保障。幾乎每個產品經理，工作中都經歷并主持過需求評審。無疑，產品經理是需求評審的主角，主導整個過程。

需求評審的主要內容，其實就是講解需求。很多次剛入行的產品經理會疑惑，為什么有了PRD和原型，還要進行需求評審？因為，有很多信息是圖和文字不能完全表達清楚的。需要大家進行溝通，打破信息的孤單島。

當然，需求評審也不完全是講解，還要與干細人員一起審驗需求的方案和業務細節。因此，需求評審在需求落地的過程中的也有很積極的作用。同時，還能夠促進需求方案的完善，探索方案的合理性。在這基礎上，優秀的需求評審，甚至能影響團隊的凝聚力，達成方向與目標的一致性。

需求評審的參與人員，幾乎涵蓋團隊的所有人員。最直接的人員，就是技術人員和UI設計師。他們是負責產需求落地為產品功能的第一把手。他們在業務的可行性上，會提供最具參考價值的意見和反饋。當然，也需要運營和市場的人員參與。他們能為方案和細節提供一些參考和建議，同時也為了減少后續的重復溝通。特別是B端產品，運營和市場人員可能會直接對接客戶。那么他們的很多意見就代表著客戶的反饋。

可能很多產品經理會覺得需求評審，是一件很簡單的事情，只是講一講需求，與大家一起探討一下需求的正確性。但要做好需求評審，卻是一件非常困難的事情。特別是要在保證效率和質量的情況下。這其中有很多的細節和方法，能夠幫助產品經理改善需求評審。這些方法大都是對細節的把控和經驗的總結。

一次失敗的需求評審會，在技術及其他團隊成員之間，容易造成對需求理解的歧義，進而導致更大的項目風險。失敗的需求評審，極端情況下可能導致團隊的裂痕，項目的開發進度延誤，甚至于項目的失敗。

如果在需求評審的過程中，與會人員對于業務的設計上存在較大的歧義，對方案有較多的負面反饋。那就需要反思產品經理的需求設計，是不是準備的不夠充分。

一、準備工作

在正式開始需求評審之前，我們需要先做好的相關的準備工作。畢竟，需求評審涉及到的內容通常都是比較多的。而且，需要我們及時流暢的進行講解。產品經理不能打沒有準備的仗，一定要準備足夠充分。

既然要進行需求評審，第一步必須完成原型設計、UML圖和PRD文檔的準備。這是需求評審的前提。需求評審評的就是這些東西所承載的內容。

在需求評審前，產品經理還需要先進行方案和技術的可行性評審。

第二步產品經理需要梳理一下評審的流程，并進行粗略的預演。

第三步則是需要準備好相關的資料。比如，相關的背景資料、技術人員研發過程中用到的對接文檔等。如果在評審的過程中，我們需要進行演示，那還要準備好演示的相關資料和環境。如果有爭議的需求，我們可以提前準備好數據等內容，以提升我們方案設計的說服力。

最后，做好以上準備后，我們就可以準備會議室并通知相關的參會人員。通知參會人員時，我們需要將準備好的資料提前發放給他們，并告知他會議的日期和注意事項。如果有遠程參會的人員，需要進行特別提醒，并設置好提前通知他們參會的備忘事項。

在進行準備工作時，一定一定要提醒相關人員在參會前預習發放的資料和相關的PRD、原型、UML圖等。如果參會人員不提前了解需求的相關方案，在會上再來思考的話，一方面會降低會議整體的效率，另一方面也不能充分的吸收和理解需求評審的內容。

二、正式會議

在正式開始需求評審會之前1~2個小時內，產品經理一定要對會議的流程和評審的需求進行回顧和熟悉。

需求評審的進行過程，我個人比較喜歡采用，經典的總分總的模式來開展。整體的總分總，在細化到每個功能點和細節的總分總。第一個「總」代表著整體性的介紹和說明；「分」代表著分點說明；第二個「總」代表討論提問和總結環節。在這基礎上，我將我的需求評審過程，分為五個步驟。第一步是背景介紹；第二步整體介紹；第三步功能細節評審；第四步提問討論環節；第五步總結環節。下面，我們就來講講，每一步是怎么做和對應的一些方法。

正式開始需求評審之前，我們還需要確認一下人員的到場情況。如果，有一些關鍵人員沒有到場的話，我們可能要確定一下是否需要延遲需求評審或者改期。

正式開始需求評審之后，第一步是背景介紹。首先我們要介紹需求的背景以及相關的行業背景。通?？梢源┎逯榻B一下用戶的情況或者說客戶的情況。在背景介紹的環節，通常我還會進行一些暖場。簡單介紹一下我們這個需求解決的問題，以及完成這個需求之后，我們產品可能達到的目標或帶來的增長。

第二步則是，需求方案的整體介紹。包括我們設計方案的整體結構，整體的業務流程，涵蓋了哪些功能，涉及那些系統，以及系統間如何進行交付。還有整個業務的角色構成，甚至于我們給到的文檔的構成情況。

第三步是正式進行功能的評審。功能評審，可以按照功能的關聯性，串起來按模塊進行評審。這樣會使整個條理清晰。對于業務有關聯性的，也可以按照業務流程來進行評審。對于單個功能的評審，也可以按照總分總的原則來展開。

在實際進行評審時，通常是根據原型圖來進行講解。一邊以原型的交互來演示，一面配合邏輯上的講解。在講解的過程中，如果有UML圖的話，可以穿插UML圖到講解的過程中。比如，在講解某個功能的業務流程時，先講解流程圖。在講解的過程中，應該按照用戶的交互過程來進行展開。

在講解原型的過程中，需要對細節進行補充。主要涉及到的內容，包含限制條件異常處理；UI需求的一些要點；可動態修改數據；某些業務包含的明細規則。明細規則，應該一條一條的給大家捋清楚，并且詳細說明這些規則的說明在文檔的那個部分。

在功能的講解過程中，應該包含系統性的要求。比如說安全性、穩定性、響應時長、數據需求等。

在進行業務和功能講解時，如果一場需求評審會，有多個產品經理參與，那么就需要在產品經理間穿插進行需求評審。通常以我需求評審的經驗，進行產品經理間的穿插評審，我會保證業務的流程的完整性和順序。同時，要求產品經理保持評審的風格一致。

當完成功能評審后，就進入到提問和討論環節。提問和討論環節，可以分為兩個部分。一部分是在現場完成的?，F場進行提問，并解答和討論。另一部分則是在會后，相關人員進行更細致的消化之后的提問和討論。在提問和討論環節，盡量避免長時間的爭議。以提高會議的效率。盡量把存在爭議的環節，放在會后仔細研討后再做定奪。對于提問和討論，產品經理需要及時的記錄相關的要點，以便會后對相關的文檔和方案進行更新。

提問和討論環節，并不是嚴格的放在所有功能評審完成之后再進行的。應該在功能評審的適當環節進行。比如，完成一個功能板塊的評審之后，就可以乘熱乎，對于這個功能板塊的內容提問和討論。特別是，當評審的內容較為龐大時，最后進入提問和討論環節，可能并不效率并不高。因為相互人員想到的問題，已經被他們忘記了。但是，也并不建議在評審環節中隨時提問。因為評審整個過程是存在關聯性的，可能現在提出的問題，是后面的評審內容。再者，隨時的打斷不僅會打斷產品經理的思維，還會降低整體的評審效率。

最后是總結環節?？偨Y環節，主要是將大家提出的疑問和討論的結果，進行總結提煉。最后還要和參會人員確定一下反饋的內容。比如，相關的研發人員給出節點的時間的時間，某些待明確問題的確認時間等。以及，討論一下具體的后續計劃安排。

以上，就完成了一場需求評審會。雖然會議完成了，但不代表著需求評審的工作完結，還有一些后續的環節。評審會完之后，產品經理需要對設計的需求方案和收到的一些意見反饋進行優化，會上待明確的內容進行明確，并且確定相關的時間節點。如果評審完之后，還要進行二次評審，那需要盡快確定二次評審的時間，盡快進行二次評審。需求評審也只是需求落地的萬里長征的第三步。

已經沒有待確認項并需求評審通過后，產品經理需要和相關人員，盡快確定好后續節點的時間。比如，UI的評審時間，研發的時間節點，上線節點等。最后，將時間節點整理成計劃表。

三、要求和方法

在評審會時，產品經理要保證會議良好的氛圍。盡可能，調動與會人員參與討論。但是，盡量不要陷入到無窮的爭議當中，避免抬杠。我有一個訣竅，就是當大家產生爭議，如果能給出佐證爭議的相關證據，那我們就繼續深入討論。如果，沒有給出有說服力的證據，那我們就留待會后，再深入研究和小范圍討論。

在需求評審會上，建議大家多使用白板。不僅是自己用，也督促參會人員使用。特別是在討論一些較為復雜的內容時，白板上勾畫的內容比單純的言語更令人易于理解。

前文已經提到過，這里再強調一下。要提高需求評審會的效率，一定一定是相關參會人員要提前閱讀需求相關的文檔和資料。

要開好需求評審會，不是一個快速的過程，而是一個逐漸形成標準化的流程的過程。對于每個產品經理都是這樣，即使是很多年工作經驗的產品經理，換了一個工作環境和團隊，也需要重新形成需求評審的標準化流程。因為不同的團隊，環境和文化氛圍不同，需求評審會議最優的方式也不一定相同。

有些產品經理在評審時，特別是提問和討論環節，喜歡全程錄音，來會后進行回顧。我個人并不建議這樣做，因為一般評審會的信息密度都達不到錄音來保存信息的底部。對核心要點，記筆記，就足以應付大多數問題。除非你記性實在是太差了。

要開好一場需求評審會，雖然對于大家來說方法可能各有不同，但是有一些要求。一些要求是相同的，只有達到這些要求，基本上才能做一場良好的需求評審會。

產品經理一定要成為需求評審會的主導者，一定要帶領大家去參與需求評審。而不能被其它牽著鼻子走。特別是在，有上級領導參與的過程中。

既然需求評審會，要求產品經理進行講解，那么產品經理最基礎應該保證自己發言的簡潔明了通俗易懂。但是，切記不要去追求語言上的技巧。直白的語言，是最容易傳遞信息的。另一方面，在溝通和講解的技巧上，產品經理還是要花點心思學習的。怎么與人溝通，怎么把一個東西簡單明了的講清楚，還是有一定技巧的。多練，也能熟能生巧。

需求評審會，產品經理要精確的控制好節奏和時間。計劃多久完成需求評審，盡可能按時完成。多人會議通常拖的時間越久效率就越低?？刂茣h的節奏，也是產品經理的基礎需求功力的體現。說白了就是自己對自己業務的熟悉程度。

在需求評審會上，盡量不要陷入到UI和交互的主觀討論甚至于扯皮上。產品經理一定要明確需求和產品的核心價值是什么。UI和交互是個人傾向很重的內容。這部分能容應該是群體的認同占主題，而不是陷入到個人執拗當中。

需求評審會上，盡可能的保證某個人都不被打斷完整的發言。會議室不是菜市場，嚴禁多人產生哄搶式的爭論。會議上的爭論并不可怕，可怕的是走偏了方向，去討論無關緊要的內容。菜市場式已經是被證實最容易帶偏方向的。如果討論的方向走偏了，作為評審會的掌舵人，產品經理要及時把大家帶回正軌。

需求評審會不是挑刺大會。盡可能控制，任何人不要以為別人找出問題為目的來討論問題。大家的核心目的一定要專注在理解到整個需求，討論問題并找到最優的解決方案上。

四、小思考

在某些情況下，需求評審會可能要遠程進行。遠程評審的難度比在會議室高了很多很多。遠程評審的硬件環境，要更復雜一些，需求投屏、語音之類的設備。而且，語音溝通肯定不如現場溝通來的直接。所以，我個人覺得能夠現場評審，盡量不要做遠程評審。如果一定要遠程評審，那么盡可能的準備充分的文檔，并且讓與會人員詳細詳細再詳細的閱讀。

需求需不需要評審，其實主要由兩點決定的。一是文檔能不能詳細的闡明清楚需求的設計方案。另一點是有沒有容易導致大家產生歧義的點。也與團隊的協作模式有關系。如果團隊協調的已經很高效，而且非常樂于用文檔傳遞信息，并且已經在高效的通過文檔來傳遞信息，那么可以考慮不進行需求評審。有時候一個過于簡單的需要，其實也是沒有必要進行評審的。

需求評審是不是一種高效的傳遞信息的方式？顯然不是的。因為一群人聚在一起通過講解和討論的形式，短時間內吸收大量的信息，并不高效。通過文檔來傳遞信息是最高效的。但是，對于同一個內容，不同的人可能會產生截然不同的理解。因此，需求評審是需求文檔的有效補充。需求評審能夠「更準確」的傳遞信息。

我個人覺得一場會議，無論是什么類型的會議，盡可能的都要簡短。超過兩個小時的會議，會議的效率會非常非常低。我個人參加一個會議，超過半小時，待在一個密閉空間里，就有些受不了。更別說專心的吸取龐大的信息。

需求評審會上還需要注意，誰有決策權。是與會的領導有決策權？還是民主的方式來進行決策？這決定了需求評審會的進行過程和討論氛圍。強勢的上級領導，在需求會上做決策，通常是一場需求評審會的災難的開始。所以我通常在需求評審會前和后，與上級領導和后進行溝通，而不是其直接參與需求評審會議?！盖啊故谴_認，「后」是反饋。

最后，不同的產品經理有各自習慣的評審方法，不同的團隊有不同的工作方式，不同的公司有不同的企業文化，不同的需求有恰當的評審方式，產品經理應該因地制宜。

#專欄作家#

產品小思考，微信公眾號：產品小思考，人人都是產品經理專欄作家。擅長行業業務分析，設計行業方案，設計B端產品架構。主要關注醫美、醫療行業，涉及HIS、CRM和各類業務系統產品。

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

題圖來自Unsplash，基于CC0協議