上篇文章《產品功能調研，需要注意的3個要點》我們討論了產品功能調研的相關知識，這一次我們來談談產品經理如何打好“需求評審”這場仗。

在產品經理崗位的能力要求中，其中兩項是強大的心理抗壓能力和良好的溝通能力。

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

需求評審是產品經理工作中非常重要的一環，它決定著我們的想法是否能夠落地實現，也是產品經理被懟可能性最大的時候。

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

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

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

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

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

一、需求評審前

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

1. 充分準備原型和PRD

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

先做需求分析和產品調研，梳理出功能架構和業務邏輯，最好輸出“業務流程圖”和“功能結構圖”，圖表比文字更容易讓人理解需求。

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

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

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

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

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

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

2. 產品組內評審

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

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

另外產品組內評審是基于用戶體驗5層要素（戰略、范圍、結構、框架、表現層）來審視原型和PRD，檢視產品設計的合理性。

比如有時候在組內評審時，判斷需求不符合當前產品的戰略方向，應該暫緩或不實現。這是開發、設計、測試、運營都不太重視的維度。

3. 提前告知

在通過組內評審之后，接下來就應該修改并完善原型和prd。

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

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

二、需求評審中

需求評審會是一個極度頻繁的場景，除了早上晨會，應該是初級產品經理開過最多的會議。

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

1. 切記闡明背景和緣由

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

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

2. 產生互動

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

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

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

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

開發楊因：誰？

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

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

開發蘇馳：誰……？

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

比如評審時可以這樣說：

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

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

溝通協調本就是產品經理工作中的常態，如果善用溝通技巧，可以提高我們的工作效率。

3. 權衡輕重

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

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

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

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

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

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

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

4. 把控時間節奏

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

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

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

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

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

5. 需求是領導提的

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

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

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

首先我們要權衡會否值得這么大的開發量。如果確實值得，可以給開發人員“洗腦”，強調需求的重要程度，實現這個需求可以創造什么用戶價值，給產品帶來什么收益。

以理服人，讓開發人員沒有理由拒絕?；蛘呖梢宰鲞m當的讓步，表明需求必須實現，但可以接受較長的開發周期。

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

6. 做好會議記錄

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

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

三、需求評審后

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

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

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

2. 督促排期，跟蹤進度

督促項目經理進行排期，確認預估的開發周期和測試周期。

接下來不要以為就沒事了，都說產品是產品經理的孩子，我們這些當爹媽的，難道我們懷了ta，給ta做了體檢，就不負責把ta健康的生下來嗎？

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

四、反思

人類在很多時候分不清自己是“堅持真理”還是“固執己見”，產品經理亦是如此。

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

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

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

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

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

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

題圖來自Unsplash，基于CC0協議。