害怕需求評審的產(chǎn)品經(jīng)理，該如何跨越這個產(chǎn)品經(jīng)理的第一關(guān)呢？
害怕需求評審的產(chǎn)品經(jīng)理，該如何跨越這個產(chǎn)品經(jīng)理的第一關(guān)呢？
你害怕需求評審嗎？
我怕過，回想起剛開始做需求評審，仍心有余悸。
就像是一個小孩子，做了一件事，也不知道對錯，周圍有一堆的人旁觀，質(zhì)疑，指責(zé)。常常一句話沒說完，開發(fā)就說你這樣設(shè)計我很難實現(xiàn)，幾個人嘰嘰喳喳開始吐槽。測試說當出現(xiàn)某種異常的時候，怎么辦，不考慮的嗎？我有時答不上來，越緊張越容易出錯，也就越害怕。
我以為這是我個人原因，本來就害怕當眾講話，更何況是講需求。
直到有一次，一個產(chǎn)品助理問我：我剛轉(zhuǎn)產(chǎn)品經(jīng)理，需求評審很緊張，覺得自己很糟糕，感覺你講得很好，有什么方法嗎？
我意識到，需求評審恐怕是大部分產(chǎn)品經(jīng)理要闖的第一關(guān)。
如今，也經(jīng)歷了幾十上百次的需求評審，已經(jīng)能夠自如應(yīng)對了，分享一些技巧給大家，希望能幫助害怕的伙伴們輕松闖過這一關(guān)。
平和的心態(tài)
為什么要在講技巧前，首先強調(diào)心態(tài)呢？
我們客觀地分析下，害怕是因為別人在挑刺，而我們希望自己交出的答卷是完美的，當心里預(yù)期被現(xiàn)實打臉了，就會很失落。
所以，我們首先要降低自己的心里預(yù)期，任何產(chǎn)品經(jīng)理都有考慮不周的時候，這不是考試，沒有標準答案，也沒有完美。
何況，開發(fā)有bug是正常的，測試也有測試用例覆蓋不全的理直氣壯的理由，為什么不準產(chǎn)品經(jīng)理有錯誤呢？
不要把需求評審看成是一場對產(chǎn)品經(jīng)理的批判會，也不要覺得這是一個走流程的事情，是別人故意在為難我們，我們在這個會上是有明確任務(wù)和目標的：
- 向開發(fā)、測試傳達清楚要做的需求，保證大家能配合你實現(xiàn)想要的功能。
- 提前讓大家?guī)湍阏页雎┒矗瑴p少開發(fā)過程可能存在的問題。
- 發(fā)現(xiàn)不同角色考慮問題的角度，提高自己的產(chǎn)品設(shè)計能力。
我們不妨在需求評審會前多暗示下自己：就算這次評審被批的一無是處，那又怎樣呢，改好了再評一遍就是了。
雖說心態(tài)要好，但前期準備也是要做足的，不然被批可不能算是無辜。接下來我用一個積分商城的實例來帶大家走一遍需求評審的流程。
一般來說，大功能的需求評審要經(jīng)歷2步：
- 初評：將項目背景，用戶痛點和整體解決方案告訴相關(guān)人員，請大家評估方案是否合理。
- 詳評：將需求細節(jié)、重要規(guī)則給相關(guān)人員講解，讓大家對功能有一個更深入的了解，并解答大家的疑問，讓開發(fā)測試能快速上手。
既然初評的目的是講清功能目的，看整體方案是否合適，那我們的資料需要包含這幾方面：
這些內(nèi)容要準備到什么程度呢？
我們來看下積分商城的例子。
項目概要
我們明確積分商城的目的是增強營銷環(huán)節(jié)，增加客戶粘性，那常見的積分兌換就是電子券和商品，考慮到商品涉及訂單和物流，相對比較復(fù)雜，可以先做電子券的兌換，此次需求評審就是針對積分兌換電子券的方案。
流程圖
總業(yè)務(wù)流程圖
先畫出一個多方角色的完整流程圖，就像是在講述一個完整的故事：商家在后臺創(chuàng)建積分兌換活動，投放到C端積分商城上面，客戶在商城上面找到自己想要兌換的電子券，發(fā)起兌換，扣減積分的同時獲得電子券，獲得后可在購物時直接抵扣。
這樣其他相關(guān)人員就有一個整體的概念了。這個圖重在理清角色間的使用流程，所以不用畫出創(chuàng)建，兌換時的細節(jié)，這2個方面可以另外畫2個分支流程圖來清晰地講述。
分支業(yè)務(wù)流程圖
比如說積分規(guī)則設(shè)置的流程圖：活動設(shè)置的時候需要考慮兌換價格，總數(shù)量，每人兌換上限，上下架等情況。如下面的流程圖就能比較清晰地看出重要的業(yè)務(wù)規(guī)則點。
積分兌換頁面的流程圖也是同理來畫。如果把這2張細節(jié)流程圖和整體流程圖畫在一起，會非常復(fù)雜，不利于評審時講述，也不利于其他人理解。
可能有人會有這個誤區(qū)：流程圖越復(fù)雜，產(chǎn)品經(jīng)理水平越高。其實不是的，產(chǎn)品經(jīng)理的目的是讓人更容易理解。
結(jié)構(gòu)圖
為什么初評的時候不直接拿著原型圖去講呢？
因為原型圖畫起來比較費時間，萬一方案不合理，改動較大，那豈不是之前畫的原型都需要重畫了嗎？這對于產(chǎn)品經(jīng)理來說，是性價比非常低的事情。
所以，我們會先理出結(jié)構(gòu)圖來，覆蓋相關(guān)的功能點，可能碰到的頁面，頁面里面的關(guān)鍵字段和規(guī)則。雖然沒有原型圖來的直觀，但大家腦海中對功能的雛形都有了了解，能做出方案的評估，這就達到了我們此次評審的目的了。
比如說這是部分積分商城的結(jié)構(gòu)圖：按照終端-模塊-頁面-字段-規(guī)則的層級來梳理。
問題反饋表
這個表主要是用來記錄評審過程中的問題，以及對應(yīng)給出的解決方案，做到有據(jù)可循。相關(guān)人員在查看這張表的時候，能夠找到自己提出問題的答案。對于產(chǎn)品經(jīng)理而言，也便于總結(jié)回顧，認知到哪幾個方面還考慮不周，下次能注意陷阱。
怎么講
就按照項目概要-總流程圖-分支流程圖-結(jié)構(gòu)圖的順序來講，從背景到功能，從整體到局部，帶領(lǐng)大家來了解即將要做的事情。
詳評技巧 資料準備
經(jīng)過了初評的方案確認，就可以開始準備原型圖了，詳評時給出的是一份完整的PRD文檔了，主要包含這幾個方面的內(nèi)容：
我們可以看到，除了初評包含的內(nèi)容，還加入了全局說明和原型圖。
全局說明
全局說明主要是針對重要規(guī)則、通用規(guī)則和一些交互規(guī)范的說明。
為什么要把他們單獨拎出來呢？
為了引起大家的高度重視。
就重要規(guī)則而言，流程圖和結(jié)構(gòu)圖里面很難寫全面，而原型圖里面散落各頁，容易顧此失彼，整個功能的實現(xiàn)，都是在這些規(guī)則的前提下，后面每一頁原型的規(guī)則能不能與之相沖突。
通用性規(guī)則就不必說了，特別是交互規(guī)范，就是為了后面不要重復(fù)書寫，節(jié)省時間。
比如積分商城的某個全局說明：
原型圖
除了交互規(guī)范，前面的步驟都要由產(chǎn)品經(jīng)理來完成，至于原型圖，有條件的情況下可以交由交互來完成。
原型圖上會包含頁面布局，業(yè)務(wù)規(guī)則標注，交互規(guī)則標注，比如說這是積分規(guī)則設(shè)置的原型圖：
怎么講
既然初評的時候已經(jīng)講過了項目背景，流程圖和結(jié)構(gòu)圖，那是不是詳評的時候不要講了，直接一頁頁過原型？
不是的。
還是要按照項目概要-總流程圖-分支流程圖-結(jié)構(gòu)圖-全局重要規(guī)則-原型圖的順序來講。原因是：
- 聽的人未必是同一撥。初評的時候去的是前后端負責(zé)人，設(shè)計也不會參加，但詳評的時候有關(guān)系的開發(fā)都會去，設(shè)計也會去。而他們其實之前并不了解需求。
- 就算是同一撥人，隔了幾天去聽，難免就忘了，為了避免講述過程中提出一些很基礎(chǔ)的問題，不妨先做個回顧。
- 初評時肯定是有一些疑問的，先把調(diào)整后的完整方案講述一遍，大家先達成基本的共識，后面評審也會更順利一點。
講原型圖的時候要注意這幾點技巧：
- 講業(yè)務(wù)規(guī)則，不要講交互規(guī)則。有的產(chǎn)品經(jīng)理會把規(guī)則從頭到尾地念一遍，以為講的很細致，殊不知大家已經(jīng)過于疲倦，聽不進去了。交互規(guī)則對前端有用，但對后端來說，用處不大，沒有必要占用所有人的時間來講，可以私下溝通。
- 講重點業(yè)務(wù)規(guī)則，不要沒有側(cè)重。有一些常規(guī)的業(yè)務(wù)規(guī)則，比如說限制字段長度，數(shù)值范圍，這種即便是講了也記不住，開發(fā)的時候看下文檔就行，不需要講解。但像設(shè)置積分兌換規(guī)則時，選取的電子券不能是運費券，贈品券，這種規(guī)則需要重點強調(diào)。
- 前后臺聯(lián)動來講。比如說講完設(shè)置積分規(guī)則的頁面，緊接著講C端兌換的頁面，大家就知道設(shè)置項對C端的影響在哪里。不要把積分兌換統(tǒng)計，積分訂單等都講完了再去講C端兌換頁面，大家對應(yīng)不起來前后的字段和規(guī)則，會覺得很懵。
評審過程中難免會遇到提問，當然別人的提問不一定是你的設(shè)計不合理。
有時是因為別人沒有理解為什么要這么做。這種情況下，最好的方式就是從用戶實際場景出發(fā)，來講述你這么設(shè)計的理由和依據(jù)。
有時是別人提出了一個更好的解決方式，確實毫無疑問的比你的方式更加合理，那就記下來，會后優(yōu)化需求。
有時確實是令我們害怕的情況發(fā)生了，別人赤裸裸的指出了邏輯漏洞，我們在沒有想清楚之前，不要去回答，記錄下問題，會后想清楚，或者和開發(fā)溝通后再給出解決方案。切勿在會上花費過長的時間去爭論，甚至偏離主題。
記住這句萬能的話： 你說的我記下來了，我會后再考慮一下，給出答復(fù)，到時會以郵件形式通知大家，時間有限，會上先不討論了，我們繼續(xù)吧。
提高技巧
經(jīng)驗越來越多以后，我們會前可以試想一下， 不同角色的人可能會提出什么樣的問題，我們要怎么回答。這也是給自己查漏補缺的機會。
比如說開發(fā)，非常關(guān)注這個功能能不能實現(xiàn)，更確切的說，是容易地實現(xiàn)。如果我們把兌換規(guī)則設(shè)置放在電子券模塊，開發(fā)會覺得這兩者耦合太大，不利于后期的維護，更希望做成一個獨立的活動設(shè)置模塊。那我們就可以往這方面去考慮。
測試更關(guān)心反例，我們需要去排查，每一步可能會遇到什么異常情況，遇到了要怎樣去處理：提示什么？以什么樣的形式去提示？提示后怎么辦？比如說兌換電子券的時候，數(shù)量不足了，提示該電子券已搶光，并推薦他兌換其他的電子券。
總結(jié)
細細想來，跟著初評、詳評，這樣一步步地準備、評審，也沒有什么可怕的。
需求評審會是產(chǎn)品經(jīng)理主導(dǎo)的會議，需要由產(chǎn)品經(jīng)理來掌控節(jié)奏，遇到一時解決不了的問題，會后去考慮，會上先把自己的產(chǎn)品方案傳達清楚。這樣就不會發(fā)生混亂、多人指責(zé)、吐槽的場景了。
恭喜你，過了這一關(guān)，就可以送口氣了，開發(fā)過程中的問題都是逐個浮出水面，各個擊破的，不會有這么大的精神壓力了。
作者：司馬特小隊，丁香園高級產(chǎn)品經(jīng)理。微信公眾號：司馬特小分隊
本文由 @司馬特小隊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
