編輯導語：令很多產品新人非常頭疼的會議就是需求評審，害怕在會上“懟”不過研發，也害怕被“懟”的“體無完膚”。本篇文章里，作者圍繞需求評審會議的五個方面為我們全方位解讀要如何才能不被“懟”，一起來看看吧。

對于產品新人而言，日常最頭疼的會議就是需求評審。

在做產品的這幾年，筆者開過上百場需求評審會，曾經被研發在會上懟哭過一次，也遇到過研發和產品大吵半小時、最終有一方摔門而出的情況。

但這都是剛開始一段時間的慘案了，那時一想到要一個人面對近10個研發就戰戰兢兢瑟瑟發抖。而如今，幾乎每一次的需求評審都變得相當順利，時間和結果都能達到預期，甚至都不需要太多額外的準備。

很多產品新人擔心自己懟不過研發，但事實上，「懟」這個詞就把自己和研發置于了對立面。很多需求評審中的爭吵和爭論在會后看來是沒必要的，大多都源自于信息差和溝通能力的問題。

因此，今天想和大家分享下如何做好需求評審、不再怕被懟。本文將從產品、研發和團隊等多個角度來談，以下為目錄，希望大家能提前在心里有一個框架：

• 需求評審的意義到底在哪？
• 一次標準需求評審的階段和流程
• 如何很好地進行需求評審的會議管理
• 需求評審會上，前端、后端和測試分別都關注什么？
• 3個壓箱底的需求評審技巧！

一、需求評審的意義到底在哪？

直接用一堆正確的話來告訴大家需求評審的意義，可能并不會有太深刻的體會。所以我們不妨另辟蹊徑，一起來試想一下：如果一次迭代沒有任何需求評審、研發完全按照產品需求文檔進行開發，會有什么樣的結果？

看起來貌似節約了大量的溝通時間，也避免了團隊內的爭論和爭吵，但實際開工之后呢？

一方面，在開發過程中，研發發現出現了部分需求遺漏、有些看似一句話的需求實現起來成本反而非常高、有些需求未考慮到數據修復、數據查詢量過載的風險等，這時候，經驗豐富一些的研發會主動找到產品進行討論并要求進行需求變更，而另外一些研發新人可能就埋頭照做了，到真正上線后才發現實際有一大堆問題，甚至可能造成不可挽回的損失。

另一方面，產品上線之后，銷售和售后部門的同事發現需求是滿足了，但卻一點都沒法用，這時候，客戶也接二連三的反饋系統怎么越改越難用了，根本沒法解決他們的問題！

這樣看來，省去了需求評審之后，產品經理的工作雖然「單純」了很多，但卻很難兼顧全局，也無形中將所有的風險和壓力擔在了自己一個人身上，浪費了團隊的智慧和經驗。

因此，一場好的需求評審能夠幫助我們很好地管理需求方（業務/銷售/售后部門）的預期，同時也能通過一次次評審和糾偏，幫助整個產研團隊就需求場景和優先級達成一致，及早進行風險評估及查缺補漏，有效提升團隊開發效率和產品可用性。

那么，接下來我們就來看看一次完整的需求評審是怎樣的？

需求評審的本質分為2個維度：其內容是用于需求評審，其性質則是有組織的連續性會議。因此我們把需求評審拆解為：需求評審+會，即需求評審流程和會議管理2個方面來講。

二、需求評審流程

不同公司不同業務不同客戶的需求評審流程都有所不同，有些只有1次，有些要開3、4次。但是，無論開幾次，其本質都是在主要和2類人開會：需求方和研發。

B端產品經理的需求方一般是老板、甲方爸爸、業務部門、銷售部門和售后部門等，無論你們公司具體業務如何，需求評審的第一步都是要和需求方確定5W1H中的為什么做（why）、什么時候做（when）以及大致做什么（what）。

第二步則是先和研發部門同步前面討論好的why、when和what，再和大家一起討論具體做什么（what）、誰來做（who）和怎么做（how）。

那么，下面提供一個較為通用的標準評審模板，分為范圍評審、低保真評審和方案評審3次。

1. 范圍評審

• 評審目標：明確需求范圍，難點在于明確不做什么
• 文檔準備：內容需要包含需求場景、需求清單、客戶調研報告、競品調研報告等
• 參會人員：產品、需求方（業務、銷售、售后、老板等）
• 評審產出：達成一致的需求范圍清單

（Axure頁面列表）

（通過用例圖描述需求場景）

2. 低保真評審

• 評審目標：初步明確大致的樣式交互及業務邏輯方案，難點在于做好需求和成本間的衡量
• 文檔準備：低保真稿（包含核心業務邏輯說明及核心頁面交互）
• 參會人員：產品、需求方、研發（前端、后端）、UI/UE
• 評審產出：就核心業務邏輯及核心頁面交互達成一致

3. 方案評審（或稱高保真評審）

• 評審目標：關注粒度更細的方案細節，難點在于邏輯覆蓋的全面程度
• 文檔準備：高保真稿（包含全部業務邏輯說明和頁面樣式交互說明），是可以直接開始研發的終稿
• 參會人員：產品、研發（前端、測試）、UI/UE
• 評審產出：理想狀態下，就全部業務邏輯和頁面交互達成一致

以上就是較為常見的3次需求評審流程。但是需求評審只是一個里程碑，產品經理大部分的時間都花在每兩次會議之間的文檔準備中，要不是在和需求方掰頭，要不就是在和研發掰頭。

三、如何很好地進行會議管理？

第二部分就來看看需求評審相關的會議管理內容。

大部分人在做產品經理之前，極少有會議組織的機會和經驗，更多都是在被動參會。而一旦入行產品，就需要開始頻繁組織各種各樣的會議，而需求評審就是其中最不可避免的一類會議。

曾經有同事分享過羅伯特議事規則，也有一類專門做會議組織研究的咨詢公司。由此可見，會議組織其實是一門非常高深的學問。

《羅伯特議事規則》（Robert’s Rules of Order，RONR）是一本由美國將領亨利·馬丁·羅伯特于1876年出版的手冊，搜集并改編美國國會的議事程序，使之普及于美國民間組織，也是目前美國最廣為使用的議事規范。

作品內容非常詳細，包羅萬象，有專門講主持會議的主席的規則，有針對會議秘書的規則，當然大量是有關普通與會者的規則，有針對不同意見的提出和表達的規則，有關辯論的規則，還有非常重要的、不同情況下的表決規則。

但這里不展開來講（筆者自己也沒有掌握那么深），就只和大家分享一些較為基礎的會議管理方法，只要能夠很好地服務于需求評審和日常工作即可。

從時間角度來看，一場會議可以分為會前、會中和會后3個階段。那么每個階段我們都需要做什么呢？

1. 會前準備

• 準備會議資料：需求評審則需要按照評審內容提前準備好文檔，并根據實際情況提醒大家提前閱讀并做好問題整理
• 創建會議：盡量提前2-3天拉會，給參會人留有充足時間調整其他日程和準備本次會議；并在日程中提前告知會議目標、會議資料地址等信息

2. 會中把控

需求評審過程中，最主要的3個點就在于節奏把控、爭論處理和情緒管理。

節奏把控：

一般而言，產品是會議主持人，那么自然就擔當著會議節奏把控和主持的角色。當角色眾多時，其實是比較容易出現討論內容溢出的問題，大家一聊開就上頭了，結果導致會議開了足足幾個小時都還沒有產生定論。

所以，需求評審中產品要做的第一件事就是把控整個會議的節奏，既要及時把聊得起興的大家拉回評審中，還要盡量按照參會人的精力去做好節奏的規劃，讓整場會議高效而輕松。

如果你剛剛入門，還不知道怎樣能夠很好地把控節奏，那么可以嘗試提前根據評審內容進行時間和會議內容規劃。

例如，前10分鐘同步信息和背景，中間10分鐘講權限業務邏輯模塊，然后預留5分鐘時間討論，接下來繼續講權限配置的頁面交互，再預留5分鐘時間討論等。全程盡量嚴格按照自己的議程來，看看實際情況和自己規劃是否相符，如果出現不符合，那么問題出在哪里？后續怎么進行改進？

多來幾次，你就會有不錯的節奏把控能力了，甚至于整個會議實際開完的時間和你預期的時間相差不了幾分鐘。

爭論處理和情緒管理：

需求評審中出現爭吵的原因常見于以下幾點：

• 表達或理解不準確，導致出現了信息差
• 情緒管理不佳，一上頭就開始對人不對事
• 會前就需求溝通不足，導致會上出現較大分歧

既然是團隊中很多角色坐一起評審，每個角色的視角和關注點不同，那么自然會出現很多討論點甚至于爭論點。那么，當會上有2個人產生了爭論時（通常是產品經理和其他人），怎樣處理才比較妥善呢？

首先最重要的一點，做好自己的情緒管理。

在一場需求評審過程中，產品經理既是會議主持人，又是參會人。如果你自己都亂了，那么整個會就尬在那里沒人收場了。所以，一個成熟的產品經理需要盡量顧全大局、擺正自己的心態，盡量以結果為導向、對事不對人。

其次，換位思考，嘗試先根據對方表達的看法去梳理他的思路，然后用自己的理解復述一遍，看對方是否認可你的理解。接下來，再根據你的理解去進行判斷并闡述自己的觀點，看是否能夠得到對方的認可。

最后，如果實在在會上沒法溝通，那就告知大家：自己會先記錄下待討論的問題，會后再進行討論，后續的議程繼續。「下來再討論」真的是一句解決會上沖突的萬能金句。

3. 會后同步和跟進

會議結束之后，確實可以長舒一口氣，開始準備下一階段的工作了，但注意：會后還是需要做好會議紀要、會議同步和后續問題的跟進。

筆者的需求評審會議紀要一般分為3部分：待討論、待完善、已確認。

• 待討論：指會上的遺留問題
• 待完善：指會上確認要改的問題，后續自己要完善在文檔中
• 已確認：指會上討論得出要做/不做的結論的點

整理好會議紀要后，及時將內容同步好發給參會同事，如果后續還有待討論的問題，則與相關人員定一個討論的待辦，避免大家忘記。

這里其實想分享一個筆者和UI小姐姐之間蠻有意思的小故事。

低保真評審時，我們還會順路確認好UI出圖的范圍。因為大多數都是產品帶電腦投屏，所以自己會順手記錄下UI出圖的范圍并發給UI小姐姐。本意是為了更好地把控會議后續質量，沒想到這個順手的行為得到了UI小姐姐的肯定。

從這個小故事中，筆者發現，如果日常能夠在需求評審中的灰色地帶稍微多做一些、多為對方思考一些，那么，整個團隊互相之間的信任和協作會越來越nice～

四、評審時，前后端/測試都關注什么？

前面和大家分享了完整的需求評審流程，現在就來帶大家換個思路，看看前端、后端、測試在一次需求評審中都關注什么？

以下素材來源于筆者和研發同事們的親身采訪：

后端：

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

前端：

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

測試：

• 關注需求的邏輯性及合理性
• 關注需求描述的準確程度、是否排除二義性等（認為好的需求文檔應該是一把標準的尺子）
• 關注整個迭代的質量風險及進度，保證交付的穩定性

從上面的回答中能夠很明顯的看出不同角色看待需求的視角。當我們要將需求講給不同的人聽時，就要提前站在他們的視角和關注點去思考問題，獲得更多溝通的前提信息，從而更順暢地進行溝通。

五、3個壓箱底的需求評審技巧！

從被懟到在現場止不住的哭，再到現在可以輕輕松松開玩笑回懟研發，筆者踩了很多坑、也積累了一些經驗。所以，最后就和大家分享3個壓箱底的需求評審技巧！

1. 先零售溝通，再批發溝通

此處標題來自邱岳《產品訓練營》中的內容，指我們在做需求評審的時候，不能把各式各樣的問題全部都堆到1-2h的需求評審會上來解決，而是應當先和相關人私下進行討論（零售溝通），取得共識后再和相關角色統一進行討論（批發溝通）。

因為，一場需求評審中往往會出現來自不同部門的不同崗位和角色，每個人的關注點都有所不同。如果，所有問題都在會上一并討論，那么不僅容易范圍溢出、干擾討論，也容易耽誤他人時間、讓聽眾失去了耐心。

例如，本次迭代中課次和班級的關系到底應該如何設計？班級和課次是1對n還是n對n的關系？這明顯是與后端直接相關的問題，那么，在需求評審前，這類問題就需要提前與后端同學溝通確認好，會上只討論大家公共關注和需要共同確認的問題。

這樣一來，整個會議中大部分時間都在做同步，小部分時間在討論一些公共問題及小問題，整個會議的效率會得到極大的提升。

2. 識別并搞定關鍵人

項目管理中有一類管理叫做「干系人管理」，指的是我們需要識別項目中的干系人stakeholders，并對他們進行一定的管理。

而我們則可以把需求評審當作一次小型的項目，項目如果要順利推進，就需要對其中的干系人做好管理。而干系人中，又可以根據話語權及意見影響程度分為關鍵人和追隨者，用一句互聯網黑話來形容就是找到關系人中的「抓手」人物。

因為，需求評審中不僅角色眾多，人員也很復雜，很難兼顧和滿足每一個人的想法。因此，在大方向上，我們就需要提前去搞定關鍵人，因為他們擁有更多的視野和做決策的信息，某種程度上，也是意見領袖。

如果你的想法和大部分人都不一致，那可以先嘗試和關鍵人進行溝通。在取得關鍵人認可后，再去推進那些想法搖擺不定或者沒有太多主觀想法的人，整個過程相對就會順利一些。

3. 適當放權，避免太過獨斷

不知道大家有沒有做過DISC性格測試，筆者身邊大多數產品經理都是D型居多，即支配型/控制者Dominance。

D型行為風格的關鍵詞是：積極進取、爭強好勝、強勢、愛追根究底、直截了當、主動的開拓者、堅持意見、自信和直率。

但是這類人也往往具有以下這些缺點：

不知道你有沒有躺槍，D型人格的產品經理在需求評審中一些問題的討論上難免會有些過于強勢。當然，大家都知道天才產品經理喬布斯就是一個極度強勢和獨斷專行的人，但我們大部分人都難以達到那樣的高度，如果真的像喬幫主那樣處事，可能最后就只能被迫做一個全棧產品了吧。

因此，在需求評審中我們需要對自己的決策做出一些取舍。大方向上一定要堅持自己的想法和意見，而一些優先級低的需求和細節可以適當放權，給予團隊一些發揮空間，這也算能夠堅持自我想法的一種迂回之策吧。

綜上，筆者從價值、需求評審流程、會議管理、研發視角和實用技巧這5個方面給大家分享了一份較為全面的需求評審指南。從戰戰兢兢到相對游刃有余，經歷了上百次的磨練。

當然，有人可能不屑于去認真對待需求評審，認為這是小題大作，但筆者一直是非常欣賞有好的工作習慣和基礎扎實的人。越日常的工作，越能日積月累地沉淀出一個人認真做事的能力和態度，而認真和踏實的人必將擁有源源不斷的潛力和空間。

作者：冰冰醬；公眾號：setmefree

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

題圖來自Unsplash，基于CC0協議