起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理怎么做才能在需求評審中少挨打？
編輯導語：需求評審是產品經理非常“害怕”但是又不得不做的一個會議 ，因為在評審會中，產品經理往往是被大家“攻擊”的對象。做好評審會，對于產品經理的專業能力也是一個非常大的考驗。產品經理如何才能在需求評審中少挨打呢？
作為一個產品經理，需求評審是產品設計開發的一個重要環節。只要工作在進行，產品在迭代，新需求在不斷產生，就會有需求評審。
在需求評審會議上，產品經理將面對前端、后端、測試、UI設計師、你的領導、甚至老板可能都會過來，不同角色聚在一個會議室聽你講解需求內容，簡直妙不可言。在會議中，不同角色提出不同意見，出現無法預測問題等，產品經理又該如何游刃有余的化險為夷，高效完成需求評審呢？
本文作者基于自身工作經驗，和大家一起聊聊需求評審相關的內容，希望對你們有幫助。
一、原型準備階段
在評審前，是產品經理收集需求、分析需求、提煉需求、輸出原型等文檔的過程，在此階段提幾點自己總結的愚見，如果能做到以下幾點的話，可能對你開展工作會有很大的幫助。
1. 需求細節盡量描述詳細
詳細即邏輯清晰、無遺漏、頁面整潔、表達清晰等，圖1、圖2是作者平時寫需求文檔的一些習慣，僅供大家參考。這里說一個有趣現象，不知道大家有沒有遇到過：就是不管你需求說明寫得如何詳細，有些技術就是不看，次次都來問。
(圖1：審核狀態需求說明)
(圖2：字段需求說明)
圖1是我做的B端項目某個審核狀態的需求說明，將書寫需求說明可以分為三部分：要描述功能或者動作、分狀態或場景、細節描述，大家可對照圖1自行理解，一看就懂。
2. 以前有的功能，現在項目涉及到要不要把以前的功能需求再寫一下
關于這個問題，也有好幾個小伙伴問過我。如果是該功能迭代優化，那涉及其相關的需求要在會上說明：原先功能整套流程是怎么樣的，現在針對哪個環節進行升級迭代。
其實多寫總歸沒毛病的，畢竟上一版的開發人員不一定繼續負責以后的相關迭代工作，我的做法一般會加上這句話 “現有邏輯：若代碼發生修改，應及時和產品、測試說明情況”。
因為在技術實際開發過程，可能會現有邏輯的代碼進行增刪，這種情況肯定需要測試人員重新測試；即使現有邏輯未動，測試人員可能也需要回歸一下，走一下流程，都是有必要做的。
總之呢，關于涉及到現有邏輯會不會被改動，會議上還要重點提一下的。
3. 設計功能或者邏輯一定要有理有據
邏輯不通，形成不了閉環，大忌；設計功能的時候，自己認為這樣就是這樣，也是大忌；一起看下簽到功能的例子，一說到簽到功能想必大家腦海中連UI畫面都想好了，常見的前臺頁面可能如下圖這幾種。
（圖3：簽到畫面一）
（圖4：簽到畫面二）
這兩種簽到布局展示的方式，在座的各位應該都見過吧，兩者布局差異基本不大。從技術角度來看，圖4的日期顯示效果肯定比圖3按天數方式實現要復雜一些。
假如你選擇圖4方案時，技術人員有可能會問：你為什么要采用這種日期顯示方式，而不選擇圖3方式？各種小伙伴遇到這種問題，自己心里有答案嗎？
如果你支支吾吾的，說不出個子丑寅卯，那么技術人員分分鐘鐘教你做人，我們可以這么回答：之所以按照日期的方式顯示，可以使簽到功能參與營銷活動；比如5月20號這天，運營可以在后臺設置那天簽到獎勵是情人節大額優惠券等等，這樣按日期方式顯示就很有意義了。
記住我們設計的每個功能都要有理有據。
4. 設計過程中遇到技術難點、技術知識盲區，一定要和技術去溝通
相信大多數的產品是沒有技術背景的，在產品設計過程中，經常遇到需要實現某些復雜的操作交互、炫酷特效、營銷游戲等。要實現這些功能，估計需要技術人員有比較扎實的代碼能力。
因此，當你遇到把握不準自家技術能不能實現自己功能，可以找到技術負責人把自己的想法提前說給他聽，提前一起討論實現過程，或許讓他們評估且及時制定方案。
最好在會議前雙方把方案制定，達成共識，而不是把所有問題放在會議上討論，這樣做好處是避免了：在評審過程中就某一特效或功能實現難易程度，雙方花費太多的時間討論，而導致評審時間被拉長。
二、評審前的準備
1. 產品內部評審
如果是比較大的項目，可能是多個產品經理一起負責，那么最好是產品部門內部開一個小評審會，把大致邏輯、功能統統講一遍，看看有沒有遺留的，有沒有補充的。
2. 業務部門會議
還是屬于比較大的項目，跟業務部門開會主要目的是讓他們了解產品部門做的東西是不是符合他們預期效果。我們只要跟他們大致講解項目操作流程即可，無需太細致。小范圍的需求預評審主要還是為了保證需求的質量，以保證正式評審的時候，不會出現大的紕漏。
3. 提前把原型或者需求文檔發給技術人員
在需求評審會議的前一天，可以把原型和需求文檔發送給參會的相關人員，目的是讓他們提前熟悉需求。若有問題及時收集，在需求評審之前向提問者解答，能大大提高需求評審會的效率。
三、評審中 – 控制節奏、應萬變
需求評審的過程，本質上就是溝通，用語言配合原型文檔的方式，將需求、邏輯清晰的表述出來，然后和所有人基本達成一致意見。但講解之前一定要先向大家介紹一下本次項目的背景，大致可以朝這兩個大個方向進行說明：
- 需求來自哪個人或者哪個部門等，他們遇到什么問題了？【現狀】
- 針對這些問題，采用什么方案或者增加什么功能，來解決他們遇到的問題或提升什么體驗及指標等；【預期】
需求評審原則上就是產品經理的“主場”，所要保持主場的氣勢，穩住場面。人人都是產品經理，正是因為人人針對某一個功能都會有自己的想法和意見，那么產品經理該怎么應付呢？
1. 合理的意見、想法
針對于這種意見，可能會給我們后續迭代有一定的啟發，但是不一定要放在本次需求內。需求總有優先級排序的，應當先解決眼前緊急的問題。我們大可不必針對每個意見一一作出解釋，你們可以保留自己的意見，我負責記錄，提高會議效率。
2. 不要過度糾結細節討論
很多同學應該遇到過這種情況：你每一句話需求，總有人會打斷你并和你扣細節，打破砂鍋問到底，這不是什么好現象。細節是永遠都扣不完的，如果在會議上陷入細節的討論，不僅浪費大家時間，而且對于產品經理來說也會非常痛苦。
這時候你可以制止那人，讓你把這塊功能講完，再讓大家提問題，實在有人要聊細節，建議在會后和他單獨好好討論，產品經理始終要記住把控會議時間和節奏。
3. 邏輯漏洞、功能遺漏
如果對業務了解不夠深入，思考不周全，很容易被其他人發現邏輯或功能遺漏等問題，這對產品經理來說是屬于比較嚴重的評審事故了，錯了就要挨打。一般不是較大的邏輯問題，評審會議還是能繼續開下去的，會后應當及時補充內容。
4. 不要把會評審成技術方案討論會議
每當遇到某些功能，對于技術來說實現比較有挑戰性或者很感興趣的時候，他們就會不知不覺的開始討論用什么方法實現好，該如何如何去操作，留下一臉懵逼的你。這時候你要打住他們，如果邏輯沒問題，怎么實現是技術的問題，不允許在會議上占用太多時間來討論具體方案。
5. 這個實現不了
技術們這樣的回應時，想必大家也遇到過，不要慌，之所以這么回應，絕大情況下是背后有一個巨大的開發量，或者是時間緊張。
這種情況，千萬不能傻乎乎的直接反駁“這個有那么麻煩嘛？”、“很簡單的啊，這樣搞搞就好了啊”，這種很容易被技術認為是傻bi的表現，嚴重的話會激化矛盾。
首先呢，我們要確認技術們的難點在哪里，是需要更多的開發時間呢，還是真的有一定開發難度。綜合各方面因素，考慮是否值得這樣的投入？如果真的是一個很重要的功能點，可以說清楚該功能對整個業務的重要性，就算開發復雜、難度高，需要較多的時間也可以接受。
如果還是爭論不止，那把這問題暫時放一下，會后叫上技術負責人和該項目開發人員一起在討論，切記也不能占用要多時間。
四、評審后 – 查缺補漏、保持跟進
需求評審會議結果后，我們還不能如釋重負，還有事情要做呢！
1. 及時修改問題
小功能評審基本上可以百分百過，但是大項目基本上很少全票通過的情況，都會有一些小修改小調整的。該修改的地方修改，該落實細節地方落實好細節，最終通過郵件等方式告知大家。
2. 督促排期，跟蹤進度
督促各個崗位負責人針對此次項任務周期，最后確認預估的整個開發周期。后續要持續跟進開發進度，直至完成上線。在跟進過程中，很有可能出現未考慮到的問題，這時候需要產品經理要和開發緊密合作，討論新的解決方案，并同步修改原型和需求說明。
3. 需求評審復盤
會議上，大家都會各抒己見，對產品經理來說很多意見和想法對自己很有啟發，我們可以一一收集起來，也可以找同事幫自己記錄下。會議結束后，我們就要針對這些想法進行篩選分析，合理的進行后續的迭代工作。
還有一點也要反思自己會議中，哪幾個點做的還不夠好的，及時改善不足之處，快速成長。
五、總結
在會議中，產品經理被針對是很正常的情況，通過以上內容的介紹，大多數情況下可以幫助大家避免一些問題。當遇到反對觀點，我們常常會不自覺產生自我保護意識，一味的進行反駁，卻忘了需求評審的目的，決不妥協和輕易妥協似乎都不是好辦法。
最后，祝大家順利的渡過每一次需求評審，也可在留言區分享會議中出現有趣的事情！
#專欄作家#
道三，微信公眾號：產品大秘籍，人人都是產品經理專欄作家。以前寫過代碼，現在產品圈摸爬滾打，專注于電商領域產品設計、主要分享電商和供應鏈領域知識點。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
hen diao
很受用啊
感謝，產品小白受益匪淺～
哈哈，關注交流~