上篇文章《產(chǎn)品功能調(diào)研，需要注意的3個要點》我們討論了產(chǎn)品功能調(diào)研的相關(guān)知識，這一次我們來談?wù)劗a(chǎn)品經(jīng)理如何打好“需求評審”這場仗。

在產(chǎn)品經(jīng)理崗位的能力要求中，其中兩項是強大的心理抗壓能力和良好的溝通能力。

因為產(chǎn)品經(jīng)理很重要的一個職責就是與公司的各個部門協(xié)調(diào)溝通，保證項目進展的有效性。工作中接觸的場景和同事涉獵面越廣，就越容易被懟，在各部門同事云集的需求評審會中更是如此。

需求評審是產(chǎn)品經(jīng)理工作中非常重要的一環(huán)，它決定著我們的想法是否能夠落地實現(xiàn)，也是產(chǎn)品經(jīng)理被懟可能性最大的時候。

若準備不夠充分，需求評審會可能演變成群起而攻之的批斗大會，而被掛在十字架的對象就是產(chǎn)品經(jīng)理和原型圖。

以下列舉了一些本人被懟的血和淚：

• “在XX情況下，你沒有做條件限制呀，能不能考慮的全面點？”
• “你這個流程太麻煩了，用戶能被你繞暈，能不能簡單點？”
• “現(xiàn)有的數(shù)據(jù)庫結(jié)構(gòu)不支持，要實現(xiàn)只能重構(gòu)，太麻煩了！有時候你產(chǎn)品的一句話，開發(fā)要做一個月呀，兄嘚！”
• “這樣開發(fā)難度很大，最好基于現(xiàn)有的數(shù)據(jù)庫結(jié)構(gòu)考慮業(yè)務(wù)拓展性，”
• “這個功能操作好奇葩，哪有產(chǎn)品像你這么設(shè)計的”

需求評審的目的是讓相關(guān)人員（開發(fā)、設(shè)計、測試、運營、老板等）理解需求背景、需求目的以及具體的需求描述，并認可原型設(shè)計和解決方案。

在需求評審中多多少少會碰到被懟的情況，那么作為產(chǎn)品經(jīng)理，怎么才能使需求評審會保持高效，并在評審會中降低被懟的可能性呢？

一、需求評審前

俗話說“臺上一分鐘，臺下十年功”，想要在需求評審會的有限時間內(nèi)，保持高效且不被懟，必須做好充分的提前準備工作。

1. 充分準備原型和PRD

首先充分理解自己所負責的需求，不要一拿到需求，頭腦一熱就開始畫原型。

先做需求分析和產(chǎn)品調(diào)研，梳理出功能架構(gòu)和業(yè)務(wù)邏輯，最好輸出“業(yè)務(wù)流程圖”和“功能結(jié)構(gòu)圖”，圖表比文字更容易讓人理解需求。

另外盡可能輸出邏輯嚴密，表達清晰的原型和文檔，盡量考慮到所有的邊界場景，并提前和開發(fā)人員溝通，就需求的實現(xiàn)方案達成一致。

如果評審會中被挑出各種疏漏問題，不僅影響會議的效率，而且會讓同事質(zhì)疑自己的專業(yè)能力，也會成為以后工作中同事不積極配合的誘因。

針對同一問題給出多個解決方案，這樣在評審中，哪怕開發(fā)表示方案A不能實現(xiàn)，還可以補充提出方案B。

需求文檔的表達要簡潔，邏輯要嚴謹。有的公司需求文檔和原型是分開各一份；而有的公司是需求文檔直接寫在Axure里面，直接備注在原型頁面旁邊（我目前用的后者）。

很多產(chǎn)品新人都會問哪種方式更好，其實不管哪種形式，要學(xué)會因地制宜。

說到底需求文檔是給開發(fā)和測試人員看的，他們是需求文檔的核心用戶，產(chǎn)品經(jīng)理要傾聽用戶的訴求，多詢問他們的意見，如何能讓他們更有效率的閱讀需求文檔，以及更容易理解需求文檔中的表述。

2. 產(chǎn)品組內(nèi)評審

在真正的需求評審會之前，一般情況下，要先對原型初版進行組內(nèi)評審，原型初版一般不需要完整的需求文檔，只需要標注出重點的交互和功能邏輯。

組內(nèi)評審的目的是讓組內(nèi)產(chǎn)品同僚幫自己擦漏補缺，提前檢查出疏漏和不合理之處。

另外產(chǎn)品組內(nèi)評審是基于用戶體驗5層要素（戰(zhàn)略、范圍、結(jié)構(gòu)、框架、表現(xiàn)層）來審視原型和PRD，檢視產(chǎn)品設(shè)計的合理性。

比如有時候在組內(nèi)評審時，判斷需求不符合當前產(chǎn)品的戰(zhàn)略方向，應(yīng)該暫緩或不實現(xiàn)。這是開發(fā)、設(shè)計、測試、運營都不太重視的維度。

3. 提前告知

在通過組內(nèi)評審之后，接下來就應(yīng)該修改并完善原型和prd。

在需求評審會的前一天把原型和prd發(fā)送給參會的相關(guān)人員，目的是讓其提前熟悉需求，達成目標上的一致性。

如果有問題及時收集，在需求評審之前向提問者解答，能大大提高需求評審會的效率。

二、需求評審中

需求評審會是一個極度頻繁的場景，除了早上晨會，應(yīng)該是初級產(chǎn)品經(jīng)理開過最多的會議。

只要我們提前做好了充分準備，就可以當作是個人的小型“產(chǎn)品分享會”。只有放松了，在講解原型時也不會因為太緊張出現(xiàn)磕巴的狀況。

1. 切記闡明背景和緣由

會議首先要向大家闡明需求背景、需求目的，讓他們了解這個需求是怎么產(chǎn)生的，需求是為了解決什么問題，讓參會者了解并達成目標上的一致性，有助于理解業(yè)務(wù)。

切忌一上來就講功能、講交互，導(dǎo)致參會者一臉懵逼，知其然不知其所以然，會影響會議的效率和后續(xù)的項目進展過程。

2. 產(chǎn)生互動

目的是為了讓參會者更專注的聽評審，減少會議室玩手機的情況。

分享一個不成熟的小技巧，原型中的名稱和內(nèi)容示例，可以使用周遭同事的名字（他們不介意的前提下），并在講解中念出名字，這樣被Q到的的同事會放下手機專心看投影儀，提高互動性和趣味性。

比如評論模塊中的評論示例，可以這樣在原型中標注：

運營廖小驪：昨晚吳亦凡被爆戀情了，你們看新聞了么？

開發(fā)楊因：誰？

測試朱序：聽說了，好大一個瓜，不過很快爆了另一個瓜！

設(shè)計雪琳：吳亦凡被套路了，好可憐

開發(fā)蘇馳：誰……？

另外當講到某個開發(fā)同事負責的功能時，可以與其產(chǎn)生互動，一個眼神示意或提及名字。

比如評審時可以這樣說：

• “后端同學(xué)楊因注意一下，CMS后臺新增了2個字段。需要配合前端超哥調(diào)你的接口?！?/li>
• “UI同學(xué)瓜瓜注意下，這個抽獎頁面要有酷炫吊炸天的動效，足夠吸引用戶的眼球”
• “任務(wù)系統(tǒng)新增1個觸發(fā)操作，需要后端同學(xué)蘇馳在數(shù)據(jù)庫加一下?！?/li>

這樣互動可以很自然的打斷玩手機的同事，使其更專注，畢竟我們不能禁止評審中玩手機，萬一別人是在回復(fù)領(lǐng)導(dǎo)消息呢~

溝通協(xié)調(diào)本就是產(chǎn)品經(jīng)理工作中的常態(tài)，如果善用溝通技巧，可以提高我們的工作效率。

3. 權(quán)衡輕重

講解具體的頁面、功能點和交互時，可以按照大綱結(jié)構(gòu)依次講解，事無巨細，不要有任何遺漏。

但由于評審會的時間有限，遇到不重要的點可以一句話概括，比如某個頁面怎么排版，顯示哪些字段。遇到重點的功能和業(yè)務(wù)邏輯時就需要詳細講解。

注意！每講解完一個模塊，都要停頓下讓大家提問，全部講完時，也要簡單回顧所有頁面，讓大家提問。

有的話當場提出當場解決，盡量讓所有參會者在會上理清大致的業(yè)務(wù)流程?？梢源蟾怕时苊庠陂_發(fā)、測試過程中，他們再來問自己講過的邏輯，導(dǎo)致過多的打擾自己正常的工作。

想象一個場景，某天自己正在梳理思路，畫原型時，一會兒開發(fā)A來確認某個會上講過的邏輯，一會兒測試B來確認另一個問題。

如此一來，不僅我們要做很多次打斷思路再連接的額外操作。結(jié)果可能是一天感覺原型沒什么進展，時間基本都花在和開發(fā)測試確認問題了。

至于一些排版、交互的細節(jié)問題，如該頁面內(nèi)容最多顯示幾行?？梢詴笤俅_認。

4. 把控時間節(jié)奏

評審中，有一種不幸，是參會人員對產(chǎn)品經(jīng)理的解決方案提出質(zhì)疑，就會進入“需求的討論期”，沒參與討論的人員可能就會玩手機。

若討論期過久（建議最多不超過10分鐘）仍沒有達成一致，說明自己的解決方案多少是有問題的。這時候要主動提出停止討論，會后考慮是否有更好的解決方案，同時與對應(yīng)人員進行溝通。

另外，開發(fā)都會在評審會上討論技術(shù)實現(xiàn)方案，我們要允許開發(fā)人員展開討論，因為要確保需求是可以實現(xiàn)的。

有時候開發(fā)會下意識的將討論延伸到具體開發(fā)細節(jié)，比如用H5，還是原生開發(fā)。從而導(dǎo)致討論時間過長，我們要審時度勢，及時制止，提醒開發(fā)可以會后再討論。不要讓需求評審會變成了技術(shù)研討會！

最后，需求評審涉及的人比較多，討論經(jīng)常會“跑題”，有時候話匣子一打開關(guān)不上，又扯到其他業(yè)務(wù)上去，導(dǎo)致評審的效率很低。產(chǎn)品經(jīng)理應(yīng)該適當制止，把大家的思維拉回來。

5. 需求是領(lǐng)導(dǎo)提的

在評審中，產(chǎn)品經(jīng)理的內(nèi)心活動幾乎都是“希望一切順利，沒有人唱反調(diào)就完美了”。但往往事與愿違，產(chǎn)品經(jīng)理時常會遇到有人唱反調(diào)的情況（對事不對人）。

比如，技術(shù)人員發(fā)出“這個實現(xiàn)起來太麻煩了”、“開發(fā)難度很大”的聲音，這種情況一般都代表著巨大的開發(fā)量。

因為需求評審前都會先通過領(lǐng)導(dǎo)或老板的審核，但也不建議直接丟出一句“這個需求是老板提的”，用老板這個靠山來反駁。這是不充分理解需求的表現(xiàn)，不做需求分析，拿到需求就埋頭畫原型。雖然這句話如尚方寶劍般，效果可能很好，但是不能讓開發(fā)信服。

首先我們要權(quán)衡會否值得這么大的開發(fā)量。如果確實值得，可以給開發(fā)人員“洗腦”，強調(diào)需求的重要程度，實現(xiàn)這個需求可以創(chuàng)造什么用戶價值，給產(chǎn)品帶來什么收益。

以理服人，讓開發(fā)人員沒有理由拒絕?；蛘呖梢宰鲞m當?shù)淖尣剑砻餍枨蟊仨殞崿F(xiàn)，但可以接受較長的開發(fā)周期。

最好的結(jié)果就是需求沒被砍，開發(fā)人員無奈的丟出一句：“可以實現(xiàn)，只是要排期……”。

6. 做好會議記錄

敲黑板啦，這里是重點，在會議中一定一定一定要記錄下爭論的遺留問題。

或者讓同事幫自己記錄也可以。不然過后靠自己回憶或者找別人問，會很麻煩。有可能別人也想不起來就尷尬了。

三、需求評審后

1. 整理遺留問題，給出解決方案

評審結(jié)束后，整理并解決會議中的遺留問題，若遺留問題太多，有必要進行二次評審。

檢視并修改原型和PRD，然后把最終版發(fā)送給相關(guān)人員。

2. 督促排期，跟蹤進度

督促項目經(jīng)理進行排期，確認預(yù)估的開發(fā)周期和測試周期。

接下來不要以為就沒事了，都說產(chǎn)品是產(chǎn)品經(jīng)理的孩子，我們這些當?shù)鶍尩模y道我們懷了ta，給ta做了體檢，就不負責把ta健康的生下來嗎？

后續(xù)要持續(xù)跟進開發(fā)測試進度，直到上線。在跟進過程中，大概率上還有未考慮到的問題逐一浮現(xiàn)出來，產(chǎn)品要和開發(fā)測試緊密合作，討論新的解決方案，并同步修改原型和PRD。

四、反思

人類在很多時候分不清自己是“堅持真理”還是“固執(zhí)己見”，產(chǎn)品經(jīng)理亦是如此。

在需求評審中遇到反對觀點，我們常常會不自覺產(chǎn)生自我保護意識，一味的進行反駁，卻忘了需求評審的目的，決不妥協(xié)和輕易妥協(xié)似乎都不是好辦法。

產(chǎn)品經(jīng)理應(yīng)當具備同理心，用我爸常教育我的話就是“換個板凳坐”，學(xué)會在他人立場思考同一個問題，或許會有額外的收獲。

需求評審對產(chǎn)品經(jīng)理樹立威信很有幫助，想要打好這場仗，就踏踏實實做好每一步。希望自己能在每一次需求評審后，都有一點點的進步。

感謝你的閱讀！如果有不同想法，歡迎交流討論。

作者：Zss；微信公眾號：Zss的寫字屋

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

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