編輯導(dǎo)語：令很多產(chǎn)品新人非常頭疼的會議就是需求評審，害怕在會上“懟”不過研發(fā)，也害怕被“懟”的“體無完膚”。本篇文章里，作者圍繞需求評審會議的五個方面為我們?nèi)轿唤庾x要如何才能不被“懟”，一起來看看吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、需求評審流程

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

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

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

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

1. 范圍評審

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

（Axure頁面列表）

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

2. 低保真評審

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

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

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

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

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

第二部分就來看看需求評審相關(guān)的會議管理內(nèi)容。

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

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

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

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

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

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

1. 會前準備

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

2. 會中把控

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

節(jié)奏把控：

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

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

如果你剛剛?cè)腴T，還不知道怎樣能夠很好地把控節(jié)奏，那么可以嘗試提前根據(jù)評審內(nèi)容進行時間和會議內(nèi)容規(guī)劃。

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

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

爭論處理和情緒管理：

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

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

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

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

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

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

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

3. 會后同步和跟進

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

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

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

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

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

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

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

四、評審時，前后端/測試都關(guān)注什么？

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

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

后端：

• 關(guān)注方案可行性的評估，重點在需求邏輯可行性、技術(shù)難度、工作量和改動成本上；
• 關(guān)注需求邏輯的覆蓋度，幫助產(chǎn)品經(jīng)理做好邏輯的查漏補缺
• 關(guān)注研發(fā)過程中的實現(xiàn)風(fēng)險

前端：

• 關(guān)注需求場景及業(yè)務(wù)合理性
• 關(guān)注頁面樣式交互，為產(chǎn)品經(jīng)理提出一些更合理的樣式交互建議
• 關(guān)注技術(shù)方案和成本評估，尤其關(guān)注新頁面中交互與已有統(tǒng)一標準組件的評估

測試：

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

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

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

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

1. 先零售溝通，再批發(fā)溝通

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

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

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

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

2. 識別并搞定關(guān)鍵人

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

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

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

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

3. 適當放權(quán)，避免太過獨斷

不知道大家有沒有做過DISC性格測試，筆者身邊大多數(shù)產(chǎn)品經(jīng)理都是D型居多，即支配型/控制者Dominance。

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

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

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

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

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

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

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

本文由 @冰冰醬 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議