"上篇文章《產品功能調研，需要注意的3個要點》我們討論了產品功能調研的相關知識，這一次我們來談談產品經理如何打好“需求評審”這場仗。
上篇文章《產品功能調研，需要注意的3個要點》我們討論了產品功能調研的相關知識，這一次我們來談談產品經理如何打好“需求評審”這場仗。
在產品經理崗位的能力要求中，其中兩項是強大的心理抗壓能力和良好的溝通能力。
因為產品經理很重要的一個職責就是與公司的各個部門協調溝通，保證項目進展的有效性。工作中接觸的場景和同事涉獵面越廣，就越容易被懟，在各部門同事雲集的需求評審會中更是如此。
需求評審是產品經理工作中非常重要的一環，它決定著我們的想法是否能夠落地實現，也是產品經理被懟可能性最大的時候。
若準備不夠充分，需求評審會可能演變成群起而攻之的批鬥大會，而被掛在十字架的對象就是產品經理和原型圖。
以下列舉了一些本人被懟的血和淚：
- “在XX情況下，你沒有做條件限制呀，能不能考慮的全面點？”
- “你這個流程太麻煩了，用戶能被你繞暈，能不能簡單點？”
- “現有的數據庫結構不支持，要實現只能重構，太麻煩了！有時候你產品的一句話，開發要做一個月呀，兄嘚！”
- “這樣開發難度很大，最好基於現有的數據庫結構考慮業務拓展性，”
- “這個功能操作好奇葩，哪有產品像你這麼設計的”
需求評審的目的是讓相關人員（開發、設計、測試、運營、老闆等）理解需求背景、需求目的以及具體的需求描述，並認可原型設計和解決方案。
在需求評審中多多少少會碰到被懟的情況，那麼作為產品經理，怎麼才能使需求評審會保持高效，並在評審會中降低被懟的可能性呢？
一、需求評審前
俗話說“臺上一分鐘，臺下十年功”，想要在需求評審會的有限時間內，保持高效且不被懟，必須做好充分的提前準備工作。
1. 充分準備原型和PRD
首先充分理解自己所負責的需求，不要一拿到需求，頭腦一熱就開始畫原型。
先做需求分析和產品調研，梳理出功能架構和業務邏輯，最好輸出“業務流程圖”和“功能結構圖”，圖表比文字更容易讓人理解需求。
另外儘可能輸出邏輯嚴密，表達清晰的原型和文檔，儘量考慮到所有的邊界場景，並提前和開發人員溝通，就需求的實現方案達成一致。
如果評審會中被挑出各種疏漏問題，不僅影響會議的效率，而且會讓同事質疑自己的專業能力，也會成為以後工作中同事不積極配合的誘因。
針對同一問題給出多個解決方案，這樣在評審中，哪怕開發表示方案A不能實現，還可以補充提出方案B。
需求文檔的表達要簡潔，邏輯要嚴謹。有的公司需求文檔和原型是分開各一份；而有的公司是需求文檔直接寫在Axure裡面，直接備註在原型頁面旁邊（我目前用的後者）。
很多產品新人都會問哪種方式更好，其實不管哪種形式，要學會因地制宜。
說到底需求文檔是給開發和測試人員看的，他們是需求文檔的核心用戶，產品經理要傾聽用戶的訴求，多詢問他們的意見，如何能讓他們更有效率的閱讀需求文檔，以及更容易理解需求文檔中的表述。
2. 產品組內評審
在真正的需求評審會之前，一般情況下，要先對原型初版進行組內評審，原型初版一般不需要完整的需求文檔，只需要標註出重點的交互和功能邏輯。
組內評審的目的是讓組內產品同僚幫自己擦漏補缺，提前檢查出疏漏和不合理之處。
另外產品組內評審是基於用戶體驗5層要素（戰略、範圍、結構、框架、表現層）來審視原型和PRD，檢視產品設計的合理性。
比如有時候在組內評審時，判斷需求不符合當前產品的戰略方向，應該暫緩或不實現。這是開發、設計、測試、運營都不太重視的維度。
3. 提前告知
在通過組內評審之後，接下來就應該修改並完善原型和prd。
在需求評審會的前一天把原型和prd發送給參會的相關人員，目的是讓其提前熟悉需求，達成目標上的一致性。
如果有問題及時收集，在需求評審之前向提問者解答，能大大提高需求評審會的效率。
二、需求評審中
需求評審會是一個極度頻繁的場景，除了早上晨會，應該是初級產品經理開過最多的會議。
只要我們提前做好了充分準備，就可以當作是個人的小型“產品分享會”。只有放鬆了，在講解原型時也不會因為太緊張出現磕巴的狀況。
1. 切記闡明背景和緣由
會議首先要向大家闡明需求背景、需求目的，讓他們瞭解這個需求是怎麼產生的，需求是為了解決什麼問題，讓參會者瞭解並達成目標上的一致性，有助於理解業務。
切忌一上來就講功能、講交互，導致參會者一臉懵逼，知其然不知其所以然，會影響會議的效率和後續的項目進展過程。
2. 產生互動
目的是為了讓參會者更專注的聽評審，減少會議室玩手機的情況。
分享一個不成熟的小技巧，原型中的名稱和內容示例，可以使用周遭同事的名字（他們不介意的前提下），並在講解中念出名字，這樣被Q到的的同事會放下手機專心看投影儀，提高互動性和趣味性。
比如評論模塊中的評論示例，可以這樣在原型中標註：
運營廖小驪：昨晚吳亦凡被爆戀情了，你們看新聞了麼？
開發楊因：誰？
測試朱序：聽說了，好大一個瓜，不過很快爆了另一個瓜！
設計雪琳：吳亦凡被套路了，好可憐
開發蘇馳：誰……？
另外當講到某個開發同事負責的功能時，可以與其產生互動，一個眼神示意或提及名字。
比如評審時可以這樣說：
- “後端同學楊因注意一下，CMS後臺新增了2個字段。需要配合前端超哥調你的接口。”
- “UI同學瓜瓜注意下，這個抽獎頁面要有酷炫吊炸天的動效，足夠吸引用戶的眼球”
- “任務系統新增1個觸發操作，需要後端同學蘇馳在數據庫加一下。”
這樣互動可以很自然的打斷玩手機的同事，使其更專注，畢竟我們不能禁止評審中玩手機，萬一別人是在回覆領導消息呢~
溝通協調本就是產品經理工作中的常態，如果善用溝通技巧，可以提高我們的工作效率。
3. 權衡輕重
講解具體的頁面、功能點和交互時，可以按照大綱結構依次講解，事無鉅細，不要有任何遺漏。
但由於評審會的時間有限，遇到不重要的點可以一句話概括，比如某個頁面怎麼排版，顯示哪些字段。遇到重點的功能和業務邏輯時就需要詳細講解。
注意！每講解完一個模塊，都要停頓下讓大家提問，全部講完時，也要簡單回顧所有頁面，讓大家提問。
有的話當場提出當場解決，儘量讓所有參會者在會上理清大致的業務流程。可以大概率避免在開發、測試過程中，他們再來問自己講過的邏輯，導致過多的打擾自己正常的工作。
想象一個場景，某天自己正在梳理思路，畫原型時，一會兒開發A來確認某個會上講過的邏輯，一會兒測試B來確認另一個問題。
如此一來，不僅我們要做很多次打斷思路再連接的額外操作。結果可能是一天感覺原型沒什麼進展，時間基本都花在和開發測試確認問題了。
至於一些排版、交互的細節問題，如該頁面內容最多顯示幾行。可以會後再確認。
4. 把控時間節奏
評審中，有一種不幸，是參會人員對產品經理的解決方案提出質疑，就會進入“需求的討論期”，沒參與討論的人員可能就會玩手機。
若討論期過久（建議最多不超過10分鐘）仍沒有達成一致，說明自己的解決方案多少是有問題的。這時候要主動提出停止討論，會後考慮是否有更好的解決方案，同時與對應人員進行溝通。
另外，開發都會在評審會上討論技術實現方案，我們要允許開發人員展開討論，因為要確保需求是可以實現的。
有時候開發會下意識的將討論延伸到具體開發細節，比如用H5，還是原生開發。從而導致討論時間過長，我們要審時度勢，及時制止，提醒開發可以會後再討論。不要讓需求評審會變成了技術研討會！
最後，需求評審涉及的人比較多，討論經常會“跑題”，有時候話匣子一打開關不上，又扯到其他業務上去，導致評審的效率很低。產品經理應該適當制止，把大家的思維拉回來。
5. 需求是領導提的
在評審中，產品經理的內心活動幾乎都是“希望一切順利，沒有人唱反調就完美了”。但往往事與願違，產品經理時常會遇到有人唱反調的情況（對事不對人）。
比如，技術人員發出“這個實現起來太麻煩了”、“開發難度很大”的聲音，這種情況一般都代表著巨大的開發量。
因為需求評審前都會先通過領導或老闆的審核，但也不建議直接丟出一句“這個需求是老闆提的”，用老闆這個靠山來反駁。這是不充分理解需求的表現，不做需求分析，拿到需求就埋頭畫原型。雖然這句話如尚方寶劍般，效果可能很好，但是不能讓開發信服。
首先我們要權衡會否值得這麼大的開發量。如果確實值得，可以給開發人員“洗腦”，強調需求的重要程度，實現這個需求可以創造什麼用戶價值，給產品帶來什麼收益。
以理服人，讓開發人員沒有理由拒絕。或者可以做適當的讓步，表明需求必須實現，但可以接受較長的開發週期。
最好的結果就是需求沒被砍，開發人員無奈的丟出一句：“可以實現，只是要排期……”。
6. 做好會議記錄
敲黑板啦，這裡是重點，在會議中一定一定一定要記錄下爭論的遺留問題。
或者讓同事幫自己記錄也可以。不然過後靠自己回憶或者找別人問，會很麻煩。有可能別人也想不起來就尷尬了。
三、需求評審後
1. 整理遺留問題，給出解決方案
評審結束後，整理並解決會議中的遺留問題，若遺留問題太多，有必要進行二次評審。
檢視並修改原型和PRD，然後把最終版發送給相關人員。
2. 督促排期，跟蹤進度
督促項目經理進行排期，確認預估的開發週期和測試周期。
接下來不要以為就沒事了，都說產品是產品經理的孩子，我們這些當爹媽的，難道我們懷了ta，給ta做了體檢，就不負責把ta健康的生下來嗎？
後續要持續跟進開發測試進度，直到上線。在跟進過程中，大概率上還有未考慮到的問題逐一浮現出來，產品要和開發測試緊密合作，討論新的解決方案，並同步修改原型和PRD。
四、反思
人類在很多時候分不清自己是“堅持真理”還是“固執己見”，產品經理亦是如此。
在需求評審中遇到反對觀點，我們常常會不自覺產生自我保護意識，一味的進行反駁，卻忘了需求評審的目的，決不妥協和輕易妥協似乎都不是好辦法。
產品經理應當具備同理心，用我爸常教育我的話就是“換個板凳坐”，學會在他人立場思考同一個問題，或許會有額外的收穫。
需求評審對產品經理樹立威信很有幫助，想要打好這場仗，就踏踏實實做好每一步。希望自己能在每一次需求評審後，都有一點點的進步。
感謝你的閱讀！如果有不同想法，歡迎交流討論。
作者：Zss；微信公眾號：產品自省
本文由 @Zss 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
"