淺談如何更好的進行需求評審

1 前言

面對需求評審，無論是發起人產品經理，還是參與人研發、測試都是有苦難言：

1. 在會議上，產品直接被研發工程師懟方案不合理，技術無法實現。
2. 參與人員沒有圍繞評審會的目標去討論而是衍生到其他問題，導致效率不高。
3. 需求評審會議順利結束，但在實際開發中卻不斷髮現需求漏洞，導致不能按照計劃順利執行。

怎樣能夠讓需求評審更高效、保質呢？作為測試人員又如何在其中發揮價值呢？根據自己的工作經驗，下文介紹如何在需求評審中做到更規範，來減少評審過程出現的問題，以此提高需求評審效率、提升需求評審會議質量，來營造一個比較輕鬆的產研合作氛圍。

2 什麼是需求評審

通過將需求規約檔案釋出給利益相關者進行檢查，發現需求規約中存在缺陷（如錯誤、不完整性、二義性等）的過程。簡單點來說，就是在產品規劃完之後，把團隊人員聚集一起討論並評審方案的會議。如方案通過，則按規劃的方案，繼續往下實施；如方案不通過，根據意見進行改善。

2.1 需求評審的參與人員

每個公司的團隊結構不一致，但通常包括：產品經理、開發工程師（前端、後端）、測試工程師、設計（UI、UE）、需求提出方。

2.2 為什麼要做需求評審

產品眼中的需求，互動眼中的需求，視覺眼中的需求，開發眼中的需求，測試眼中的需求大相徑庭,需要讓團隊中每位人員對需求有統一的瞭解，通過需求評審來拉齊大家的認知。主要作用是：

1. 有助於團隊中每個角色瞭解使用者需求，理解產品需求的由來，考慮需求合理性及使用者體驗感。
2. 對需求檔案進行評審，儘早發現需求中的問題，減少後期修改缺陷的成本。
3. 使開發團隊中每個角色對需求的理解保持一致，減少了後期的溝通成本。
4. 溝通需求細節，確認需求是否可以實現以及實現方式，有利於測試人員對功能實現邏輯的理解，完善測試用例。
5. 確認交付內容和預期時間。

3 如何進行需求評審

做好一場需求評審，大致分為三個階段：評審前、評審中、評審後。

3.1 評審前

3.1.1 做好產品基本功

角色：產品經理

1. 和業務方認真推演產品要解決的問題，深挖業務述求，相信自己的產品設計能力，業務方提供的產品方案可以作為參考，不能作為指南。
2. 充分準備需求原型和PRD，反覆推敲產品方案，確保所有的功能點都能實現閉環，正常和異常場景都要考慮。任何一個遺漏的場景，都可能成為評審會上的「雷點」，產品們需要提前掃雷。
3. 提前找到此專案對應的技術負責人，認真的和他們溝通你的方案和想法，技術的小夥伴們不是被動的執行者，讓他們參與到你的前期設計中來，驅動技術前置。
4. 提前將完整的原型和PRD發給相關人員，以便他們提前閱讀相關檔案，深刻理解需求，有疑問的點提前標註出來，方便在開會的過程中積極地去參與這個會議，丟擲疑問點。

3.1.2 技術人員提前介入

角色：研發、測試，建議提前2天

1. 團隊制定好規範，利用各自碎片化時間，提前介入進來理解需求。前期瞭解過程中除了關注功能要求，還需要關注資料型別、介面定義、效能要求、安全性等，這個根據具體業務進行評估，例如高並行場景，頻繁請求的場景等。同時還需要考慮一些隱性需求。
2. 技術負責人可以前置到需求溝通和設計階段，給產品經理提供必要的技術支援，協助評估產品方案的可行性。

3.1.3 提前進行會議邀請

角色：產品經理，建議提前1天

給出會議時間、地點、預計需要時間。一方面，這樣可以讓參與人員得知你對整個需求評審會議內容的掌控；另一方面，參與人員能根據時間安排手頭上的其他任務，以致於節奏不被打亂。

3.2 評審中

3.2.1 節奏把控

角色：產品經理

產品是會議主持人，那麼自然就擔當著會議節奏把控和主持的角色。當角色眾多時，其實是比較容易出現討論內容溢位的問題，大家一聊開就上頭了，結果導致會議開了足足幾個小時都還沒有產生定論。需求評審中產品要做的第一件事就是把控整個會議的節奏，既要及時把聊得起興的大家拉回評審中，還要儘量按照參會人的精力去做好節奏的規劃，讓整場會議高效而輕鬆。

3.2.2 情緒管理和爭論處理

角色：全員

很多產品都懼怕需求評審，感覺研發、測試在找茬，有針對自己的感覺。這個時候最重要的一點，首先，做好自己的情緒管理，有問題丟擲是好事，說明大家都聽了並且在思考。其次，換位思考，嘗試先根據對方表達的看法去梳理他的思路，然後用自己的理解複述一遍，看對方是否認可你的理解。接下來，再根據你的理解去進行判斷並闡述自己的觀點，看是否能夠得到對方的認可。最後，如果實在在會上沒法溝通，那就告知大家：自己會先記錄下待討論的問題，會後再進行討論，後續的議程繼續。「下來再討論」真的是一句解決會上衝突的萬能金句。

3.2.3 關注講解方法和策略

角色：產品經理

不要上來就講方案，大家一定會懵圈，個人總結下來，可以按照以下的步驟推進：

1. 需求背景：傳達本次需求的背景，為什麼有這樣的需求，解決了什麼問題。
2. 需求價值：為什麼要做本次需求，做完後會給產品帶來哪些價值（例如：提高使用者留存、提高轉化率或者是提升使用者體驗等)。
3. 需求概述：需求提出方想實現什麼，描述該產品方案如何解決業務述求。
4. 方案詳解：詳細的進行產品方案講解，讓與會人員都充分的瞭解產品方案，判斷是否會牽一髮而動全身。建議分模組講解，一個模組講解完後，可以稍微停頓一會，詢問大家是否有疑問，並進行答疑（如果是一個比較複雜的問題，講解的時間比較長，可以考慮會議後單獨和相關的人員進行溝通）；會議中如果出現一些自己未考慮到的點，一定要記錄下來，會後進行完善。

3.2.4 刻意關注、沉浸式參與到評審中

角色：研發、測試

需求評審的時候不要在會議上面玩手機或者幹其他事情，因為如果需求理解不深刻，後面相關的工作就很難開展。需求中產品設計不合理、很難理解、邏輯有問題、以及可能影響原功能的地方，對於這些點我們要丟擲疑問進行澄清，從而推動產品進行修改，最終達成一致。
需求評審會上，前端、後端和測試分別都關注什麼？

後端：

• 關注方案可行性的評估，重點在需求邏輯可行性、技術難度、工作量和改動成本上
• 關注需求邏輯的覆蓋度，幫助產品經理做好邏輯的查漏補缺
• 關注研發過程中的實現風險

前端：

• 關注需求場景及業務合理性
• 關注頁面樣式互動，為產品經理提出一些更合理的樣式互動建議
• 關注技術方案和成本評估，尤其關注新頁面中互動與已有統一標準元件的評估

測試：

• 關注需求的邏輯性及合理性
• 關注需求描述的準確程度、是否排除二義性等
• 關注整個迭代的質量風險及進度，保證交付的穩定性

3.3 評審後

3.3.1 評審會議紀要

角色：產品

會議結束之後，確實可以長舒一口氣，開始準備下一階段的工作了，但注意：會後還是需要做好

會議紀要、會議同步和後續問題的跟進。會議紀要主要分為三個部分：

1. 待討論：指會上的遺留問題
2. 待完善：指會上確認要改的問題，後續要完善在檔案中
3. 已確認：指會上討論得出要做/不做的結論的點

3.3.2 待辦項跟進

角色：產品+相關人員

1. 整理會議中記錄的問題，在原型和PRD中進行調整和補充，有需要的話，可以拉上相關的人員針對這些問題，進行二次評審。
2. 好的產品一定得有專案管理能力，在整個開發過程中，一定要定期跟進開發進度，避免需求延期或者需求缺失。
3. 另外，開發過程中，如果涉及到需求的調整.一定要在原型和 PRD中標記修改記錄，並且及時通知相關的人員，確保理解一致

4 總結

如何高效、保質、愉悅的進行需求評審，各角色專業能力是基礎，但更需要大家相互配合，互相尊重，通力合作才能打造更好的產品。

作者：京東物流 王敏

來源：京東雲開發者社群 自猿其說Tech