編輯導(dǎo)語：需求評審是產(chǎn)品經(jīng)理非常“害怕”但是又不得不做的一個會議 ，因為在評審會中，產(chǎn)品經(jīng)理往往是被大家“攻擊”的對象。做好評審會，對于產(chǎn)品經(jīng)理的專業(yè)能力也是一個非常大的考驗。產(chǎn)品經(jīng)理如何才能在需求評審中少挨打呢？

作為一個產(chǎn)品經(jīng)理，需求評審是產(chǎn)品設(shè)計開發(fā)的一個重要環(huán)節(jié)。只要工作在進行，產(chǎn)品在迭代，新需求在不斷產(chǎn)生，就會有需求評審。

在需求評審會議上，產(chǎn)品經(jīng)理將面對前端、后端、測試、UI設(shè)計師、你的領(lǐng)導(dǎo)、甚至老板可能都會過來，不同角色聚在一個會議室聽你講解需求內(nèi)容，簡直妙不可言。在會議中，不同角色提出不同意見，出現(xiàn)無法預(yù)測問題等，產(chǎn)品經(jīng)理又該如何游刃有余的化險為夷，高效完成需求評審呢？

本文作者基于自身工作經(jīng)驗，和大家一起聊聊需求評審相關(guān)的內(nèi)容，希望對你們有幫助。

一、原型準(zhǔn)備階段

在評審前，是產(chǎn)品經(jīng)理收集需求、分析需求、提煉需求、輸出原型等文檔的過程，在此階段提幾點自己總結(jié)的愚見，如果能做到以下幾點的話，可能對你開展工作會有很大的幫助。

1. 需求細(xì)節(jié)盡量描述詳細(xì)

詳細(xì)即邏輯清晰、無遺漏、頁面整潔、表達(dá)清晰等，圖1、圖2是作者平時寫需求文檔的一些習(xí)慣，僅供大家參考。這里說一個有趣現(xiàn)象，不知道大家有沒有遇到過：就是不管你需求說明寫得如何詳細(xì)，有些技術(shù)就是不看，次次都來問。

(圖1：審核狀態(tài)需求說明)

(圖2：字段需求說明)

圖1是我做的B端項目某個審核狀態(tài)的需求說明，將書寫需求說明可以分為三部分：要描述功能或者動作、分狀態(tài)或場景、細(xì)節(jié)描述，大家可對照圖1自行理解，一看就懂。

2. 以前有的功能，現(xiàn)在項目涉及到要不要把以前的功能需求再寫一下

關(guān)于這個問題，也有好幾個小伙伴問過我。如果是該功能迭代優(yōu)化，那涉及其相關(guān)的需求要在會上說明：原先功能整套流程是怎么樣的，現(xiàn)在針對哪個環(huán)節(jié)進行升級迭代。

其實多寫總歸沒毛病的，畢竟上一版的開發(fā)人員不一定繼續(xù)負(fù)責(zé)以后的相關(guān)迭代工作，我的做法一般會加上這句話 “現(xiàn)有邏輯：若代碼發(fā)生修改，應(yīng)及時和產(chǎn)品、測試說明情況”。

因為在技術(shù)實際開發(fā)過程，可能會現(xiàn)有邏輯的代碼進行增刪，這種情況肯定需要測試人員重新測試；即使現(xiàn)有邏輯未動，測試人員可能也需要回歸一下，走一下流程，都是有必要做的。

總之呢，關(guān)于涉及到現(xiàn)有邏輯會不會被改動，會議上還要重點提一下的。

3. 設(shè)計功能或者邏輯一定要有理有據(jù)

邏輯不通，形成不了閉環(huán)，大忌；設(shè)計功能的時候，自己認(rèn)為這樣就是這樣，也是大忌；一起看下簽到功能的例子，一說到簽到功能想必大家腦海中連UI畫面都想好了，常見的前臺頁面可能如下圖這幾種。

（圖3：簽到畫面一）

（圖4：簽到畫面二）

這兩種簽到布局展示的方式，在座的各位應(yīng)該都見過吧，兩者布局差異基本不大。從技術(shù)角度來看，圖4的日期顯示效果肯定比圖3按天數(shù)方式實現(xiàn)要復(fù)雜一些。

假如你選擇圖4方案時，技術(shù)人員有可能會問：你為什么要采用這種日期顯示方式，而不選擇圖3方式？各種小伙伴遇到這種問題，自己心里有答案嗎？

如果你支支吾吾的，說不出個子丑寅卯，那么技術(shù)人員分分鐘鐘教你做人，我們可以這么回答：之所以按照日期的方式顯示，可以使簽到功能參與營銷活動；比如5月20號這天，運營可以在后臺設(shè)置那天簽到獎勵是情人節(jié)大額優(yōu)惠券等等，這樣按日期方式顯示就很有意義了。

記住我們設(shè)計的每個功能都要有理有據(jù)。

4. 設(shè)計過程中遇到技術(shù)難點、技術(shù)知識盲區(qū)，一定要和技術(shù)去溝通

相信大多數(shù)的產(chǎn)品是沒有技術(shù)背景的，在產(chǎn)品設(shè)計過程中，經(jīng)常遇到需要實現(xiàn)某些復(fù)雜的操作交互、炫酷特效、營銷游戲等。要實現(xiàn)這些功能，估計需要技術(shù)人員有比較扎實的代碼能力。

因此，當(dāng)你遇到把握不準(zhǔn)自家技術(shù)能不能實現(xiàn)自己功能，可以找到技術(shù)負(fù)責(zé)人把自己的想法提前說給他聽，提前一起討論實現(xiàn)過程，或許讓他們評估且及時制定方案。

最好在會議前雙方把方案制定，達(dá)成共識，而不是把所有問題放在會議上討論，這樣做好處是避免了：在評審過程中就某一特效或功能實現(xiàn)難易程度，雙方花費太多的時間討論，而導(dǎo)致評審時間被拉長。

二、評審前的準(zhǔn)備

1. 產(chǎn)品內(nèi)部評審

如果是比較大的項目，可能是多個產(chǎn)品經(jīng)理一起負(fù)責(zé)，那么最好是產(chǎn)品部門內(nèi)部開一個小評審會，把大致邏輯、功能統(tǒng)統(tǒng)講一遍，看看有沒有遺留的，有沒有補充的。

2. 業(yè)務(wù)部門會議

還是屬于比較大的項目，跟業(yè)務(wù)部門開會主要目的是讓他們了解產(chǎn)品部門做的東西是不是符合他們預(yù)期效果。我們只要跟他們大致講解項目操作流程即可，無需太細(xì)致。小范圍的需求預(yù)評審主要還是為了保證需求的質(zhì)量，以保證正式評審的時候，不會出現(xiàn)大的紕漏。

3. 提前把原型或者需求文檔發(fā)給技術(shù)人員

在需求評審會議的前一天，可以把原型和需求文檔發(fā)送給參會的相關(guān)人員，目的是讓他們提前熟悉需求。若有問題及時收集，在需求評審之前向提問者解答，能大大提高需求評審會的效率。

三、評審中 – 控制節(jié)奏、應(yīng)萬變

需求評審的過程，本質(zhì)上就是溝通，用語言配合原型文檔的方式，將需求、邏輯清晰的表述出來，然后和所有人基本達(dá)成一致意見。但講解之前一定要先向大家介紹一下本次項目的背景，大致可以朝這兩個大個方向進行說明：

1. 需求來自哪個人或者哪個部門等，他們遇到什么問題了？【現(xiàn)狀】
2. 針對這些問題，采用什么方案或者增加什么功能，來解決他們遇到的問題或提升什么體驗及指標(biāo)等；【預(yù)期】

需求評審原則上就是產(chǎn)品經(jīng)理的“主場”，所要保持主場的氣勢，穩(wěn)住場面。人人都是產(chǎn)品經(jīng)理，正是因為人人針對某一個功能都會有自己的想法和意見，那么產(chǎn)品經(jīng)理該怎么應(yīng)付呢？

1. 合理的意見、想法

針對于這種意見，可能會給我們后續(xù)迭代有一定的啟發(fā)，但是不一定要放在本次需求內(nèi)。需求總有優(yōu)先級排序的，應(yīng)當(dāng)先解決眼前緊急的問題。我們大可不必針對每個意見一一作出解釋，你們可以保留自己的意見，我負(fù)責(zé)記錄，提高會議效率。

2. 不要過度糾結(jié)細(xì)節(jié)討論

很多同學(xué)應(yīng)該遇到過這種情況：你每一句話需求，總有人會打斷你并和你扣細(xì)節(jié)，打破砂鍋問到底，這不是什么好現(xiàn)象。細(xì)節(jié)是永遠(yuǎn)都扣不完的，如果在會議上陷入細(xì)節(jié)的討論，不僅浪費大家時間，而且對于產(chǎn)品經(jīng)理來說也會非常痛苦。

這時候你可以制止那人，讓你把這塊功能講完，再讓大家提問題，實在有人要聊細(xì)節(jié)，建議在會后和他單獨好好討論，產(chǎn)品經(jīng)理始終要記住把控會議時間和節(jié)奏。

3. 邏輯漏洞、功能遺漏

如果對業(yè)務(wù)了解不夠深入，思考不周全，很容易被其他人發(fā)現(xiàn)邏輯或功能遺漏等問題，這對產(chǎn)品經(jīng)理來說是屬于比較嚴(yán)重的評審事故了，錯了就要挨打。一般不是較大的邏輯問題，評審會議還是能繼續(xù)開下去的，會后應(yīng)當(dāng)及時補充內(nèi)容。

4. 不要把會評審成技術(shù)方案討論會議

每當(dāng)遇到某些功能，對于技術(shù)來說實現(xiàn)比較有挑戰(zhàn)性或者很感興趣的時候，他們就會不知不覺的開始討論用什么方法實現(xiàn)好，該如何如何去操作，留下一臉懵逼的你。這時候你要打住他們，如果邏輯沒問題，怎么實現(xiàn)是技術(shù)的問題，不允許在會議上占用太多時間來討論具體方案。

5. 這個實現(xiàn)不了

技術(shù)們這樣的回應(yīng)時，想必大家也遇到過，不要慌，之所以這么回應(yīng)，絕大情況下是背后有一個巨大的開發(fā)量，或者是時間緊張。

這種情況，千萬不能傻乎乎的直接反駁“這個有那么麻煩嘛？”、“很簡單的啊，這樣搞搞就好了啊”，這種很容易被技術(shù)認(rèn)為是傻bi的表現(xiàn)，嚴(yán)重的話會激化矛盾。

首先呢，我們要確認(rèn)技術(shù)們的難點在哪里，是需要更多的開發(fā)時間呢，還是真的有一定開發(fā)難度。綜合各方面因素，考慮是否值得這樣的投入？如果真的是一個很重要的功能點，可以說清楚該功能對整個業(yè)務(wù)的重要性，就算開發(fā)復(fù)雜、難度高，需要較多的時間也可以接受。

如果還是爭論不止，那把這問題暫時放一下，會后叫上技術(shù)負(fù)責(zé)人和該項目開發(fā)人員一起在討論，切記也不能占用要多時間。

四、評審后 – 查缺補漏、保持跟進

需求評審會議結(jié)果后，我們還不能如釋重負(fù)，還有事情要做呢！

1. 及時修改問題

小功能評審基本上可以百分百過，但是大項目基本上很少全票通過的情況，都會有一些小修改小調(diào)整的。該修改的地方修改，該落實細(xì)節(jié)地方落實好細(xì)節(jié)，最終通過郵件等方式告知大家。

2. 督促排期，跟蹤進度

督促各個崗位負(fù)責(zé)人針對此次項任務(wù)周期，最后確認(rèn)預(yù)估的整個開發(fā)周期。后續(xù)要持續(xù)跟進開發(fā)進度，直至完成上線。在跟進過程中，很有可能出現(xiàn)未考慮到的問題，這時候需要產(chǎn)品經(jīng)理要和開發(fā)緊密合作，討論新的解決方案，并同步修改原型和需求說明。

3. 需求評審復(fù)盤

會議上，大家都會各抒己見，對產(chǎn)品經(jīng)理來說很多意見和想法對自己很有啟發(fā)，我們可以一一收集起來，也可以找同事幫自己記錄下。會議結(jié)束后，我們就要針對這些想法進行篩選分析，合理的進行后續(xù)的迭代工作。

還有一點也要反思自己會議中，哪幾個點做的還不夠好的，及時改善不足之處，快速成長。

五、總結(jié)

在會議中，產(chǎn)品經(jīng)理被針對是很正常的情況，通過以上內(nèi)容的介紹，大多數(shù)情況下可以幫助大家避免一些問題。當(dāng)遇到反對觀點，我們常常會不自覺產(chǎn)生自我保護意識，一味的進行反駁，卻忘了需求評審的目的，決不妥協(xié)和輕易妥協(xié)似乎都不是好辦法。

最后，祝大家順利的渡過每一次需求評審，也可在留言區(qū)分享會議中出現(xiàn)有趣的事情！

#專欄作家#

道三，微信公眾號：產(chǎn)品大秘籍，人人都是產(chǎn)品經(jīng)理專欄作家。以前寫過代碼，現(xiàn)在產(chǎn)品圈摸爬滾打，專注于電商領(lǐng)域產(chǎn)品設(shè)計、主要分享電商和供應(yīng)鏈領(lǐng)域知識點。

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

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