最近參與了一場需求評審會，我是參會人。會議中，產(chǎn)品小兄弟總是被打斷、被質(zhì)問、被挑戰(zhàn)，一場評審會下來，他依次脫了羽絨衣、毛衣，只剩一件格子襯衫，整個人滿面通紅，像是沖刺了一公里，而我卻在角落凍的瑟瑟發(fā)抖。

你有經(jīng)歷過在評審會中被問的面紅耳赤、大汗淋漓嗎？我有過，但現(xiàn)在淡定多了，可能是臉（不）皮（要）厚（臉）了，也可能是摸清了評審會中的常見問題。我總結(jié)了評審會中的4類典型問題與應對方案，如果你還害怕開需求評審，希望本文能幫你提前做好“戰(zhàn)斗”準備，讓你在評審時少出點汗。

問題清單

01?如果XXX情況，怎么辦？

類似的問題還有：你有沒有考慮過這種情況？你這流程有問題啊？

問題本質(zhì)：場景是否考慮完善；業(yè)務流程是否完整；

解決方式：利用各方意見反饋，完善產(chǎn)品方案；

有小伙伴提這類問題，是個好事！一是證明大家跟著節(jié)奏在對評審內(nèi)容進行思考，二是這些問題能幫助完善產(chǎn)品方案。我們需要去傾聽大家意見，不要感覺被挑戰(zhàn)進而產(chǎn)生抵觸心里。

如果所提的問題是已經(jīng)思考并規(guī)劃過，只是還沒介紹到，我們可以直接反饋：你說的我有考慮，將在后面說；如果確實未提前準備，那也無需隱藏，虛心請教對方，也給出自己意見。多數(shù)情況下，這類問題并不涉及流程主體，比較容易快速給出判斷與結(jié)論。如果一時間拿捏不準，建議會后討論，不在會上展開。

需注意，這類問題都不應涉及核心業(yè)務場景與主體流程。如果主線都沒考慮清楚，這評審會就不該開。

02?這個功能做了沒意義啊！為啥要做？

類似的問題還有：這功能做出來干什么都不曉得？

問題本質(zhì)：需求背景描述不清晰。

解決方式：描述需求背景、用戶故事

團隊成員在參與評審過程前，很少會主動了解需求背景，查閱原型內(nèi)容。即便產(chǎn)品經(jīng)理已將原型等內(nèi)容丟群里，提醒大家提前查閱，但懂的都懂。而在評審會期間，開發(fā)人員很容易鉆入到某一具體功能如何實現(xiàn)、這個功能是否和原有矛盾等思考中，忽略了需求的背景與目的。

因此，產(chǎn)品經(jīng)理務必在評審會剛開始時，明確需求場景，描述版本包含哪些功能、解決哪類用戶的什么問題；在具體功能點評審前，強調(diào)該功能點的業(yè)務場景，說明用戶故事。

產(chǎn)品經(jīng)理給團隊描述需求背景與用戶故事的同時，也給團隊“畫了一張大餅”，讓大伙知道了需求的重要性與意義。我們需要重視在“畫餅”過程團隊提出的意見，這時候的反饋很可能暴露了大方向的問題。建議在大家意見一致、目標一致后，再進行后續(xù)細節(jié)的評審。

03?這么搞我們又要重構(gòu)了。

類似的問題還有：你根本沒考慮系統(tǒng)現(xiàn)在情況！

問題本質(zhì)：產(chǎn)品思維與開發(fā)思維的差異。

解決方式：辨別“真假重構(gòu)”

重構(gòu)是大事，往往在需求評審會前就已決定，并以一個獨立版本來進行管理，評審會中的“重構(gòu)”，更多的是原有產(chǎn)品功能的調(diào)整，是需求的變更。我們所主張的“需求是不斷變化”開發(fā)不認，當有需求要調(diào)整時，他們更相信“重構(gòu)”。你回想下，在評全新功能時，是不是聽不到“重構(gòu)”一詞？

當開發(fā)會中提出“需要重構(gòu)”時，我們無須慌張，以一個低姿態(tài)，去了解“重構(gòu)”涉及哪些范圍，為什么說要“重構(gòu)”。通常情況下，“重構(gòu)”是因為需求的實現(xiàn)要去查閱并修改原有不熟悉的代碼或者已經(jīng)知道涉及到的代碼有坑難維護，開發(fā)希望產(chǎn)品經(jīng)理不要動輕易改動，用“重構(gòu)”一詞提出抗議。我們需要向團隊闡明，是用戶在不同的時期對平臺有著不一樣的訴求，導致了需求的變更，并不是產(chǎn)品經(jīng)理想改就改。當然，我們也要去理解、安撫可愛的開發(fā)，尊重他們的反饋，體諒他們的不爽。

另外，“重構(gòu)”這一詞在公司里有一定的敏感性，當老板聽到某某某產(chǎn)品要重構(gòu)、又要重構(gòu)時，第一反應是之前的投入打了水漂，這將對整個團隊帶來潛在的影響。如果可以，請不要把“重構(gòu)”一詞掛嘴邊。

04?你這么設(shè)計還不如這樣。

類似的問題還有：你直接把XXXXX；

本質(zhì)問題：當前方案是否是最優(yōu)實現(xiàn)方式

解決方式：闡明采用當前產(chǎn)品方案原因，吸取各方意見進行優(yōu)化

這類問題也意味著，大家認同這個功能的預期成效，只是在實現(xiàn)方式上仍有分歧。

對于一個需求，因切入的角度不同，對應的最優(yōu)方案也將不同。例如開發(fā)會從實現(xiàn)難度給出最優(yōu)解，項目經(jīng)理會從實現(xiàn)成本給出最優(yōu)解，而我們需要牢記，我們是產(chǎn)品經(jīng)理，需從用戶角度，圍繞業(yè)務目標思考最佳方案。

當然在多數(shù)情況下，產(chǎn)品經(jīng)理需根據(jù)系統(tǒng)現(xiàn)狀、資源現(xiàn)狀、交付要求等進行權(quán)衡，但我仍然建議能有個理想化的產(chǎn)品實現(xiàn)方式，哪怕只是一個模糊的輪廓。在需求評審會中，我們可以簡要說明理想方案，讓大家對產(chǎn)品最終形態(tài)有一定認識。有心的開發(fā)會在實現(xiàn)過程中預留一些設(shè)計，便于后續(xù)擴展，待日后時機成熟，快速豐富產(chǎn)品形態(tài)。

在具體介紹當前方案時，我們需闡述當前方案所做的權(quán)衡，說明方案優(yōu)勢。當大家提出不同意見，去引導他們說出“為什么”，進而去評估是否需要調(diào)整當前方案。調(diào)整后的產(chǎn)品方案可能仍然無法滿足所有人，但產(chǎn)品經(jīng)理需要拍板明確最終實現(xiàn)方式，并讓大家向著共同目標努力。

我們組織需求評審，為的是讓團隊明確產(chǎn)品目標與實現(xiàn)方式，暴露潛在問題。我們唯有直面團隊的提問，并且逐一擊破，才能完善產(chǎn)品形態(tài)，提升自我能力。

會議技巧

上面我們講了4類需求評審會中常見問題，現(xiàn)在我們再來擴展說下開需求評審會的技巧與套路。我們需要高效的會議，避免一場會議持續(xù)好幾小時，結(jié)束后發(fā)現(xiàn)毫無重點毫無主題，團隊怨聲不斷。

01?把控會議節(jié)奏

關(guān)于一場評審會的時間，我建議不超過一小時。超過一小時，大家的精神開始渙散，會議效率直線下降。回憶下高中的數(shù)學課，你能多長時間緊跟老師思路？對于我，超過半節(jié)課已屬于超水平發(fā)揮。

而在這一小時的時間里，前半小時效率最高，因此我建議率先闡明用戶故事，讓大家從宏觀層面對需求內(nèi)容有所認知；率先描述重點內(nèi)容，避免因死摳細節(jié)而忽略的主線內(nèi)容。至于那些細節(jié)，我們需要在原型及PRD中清晰標注，當研發(fā)人員在編碼對應功能時，自然會看到這塊內(nèi)容（也有很多不看文檔直接開發(fā)的，那至少我們在后續(xù)撕逼中有了證據(jù)~）。

關(guān)于會議中的討論，我建議控制在10分鐘。如果提前做好了產(chǎn)品方案的溝通與確認，評審會期間的討論不太會涉及核心問題。若討論超出10分鐘且沒有結(jié)果，我們可以先將問題記錄，會后和專人討論確定結(jié)果后，再同步給大家。

有小伙伴問，在評審一個功能的時，是讓開發(fā)隨時提問，還是匯總到一個功能評審完成后集中反饋。我更傾向前者，特別是你對會議節(jié)奏有很強的掌控力，并且對產(chǎn)品方案十分自信的情況下，開發(fā)的提問通常都能快速解答，不會破壞會議進度。此外，你游刃有余的解答還會在團隊心中樹立不錯的“威望”。但如果你還處于新手上路階段，建議采用統(tǒng)一提問的形式，這能更好避免因頻繁打斷而造成的緊張、過程失控。

02?提前溝通與確認

有時候需求評審會更多是走個形式，“逢場作戲”。會議中需要同步的信息、需要討論的點已經(jīng)提前和團隊成員，或者團隊各板塊負責人達成共識。與其說是需求“評審會”，不如用“宣講會”來的確切。

在需求評審會前，我會組織兩次“小會”。一場是在確定業(yè)務流程，明確實現(xiàn)方式后，與服務端負責人溝通整體思路，如果有可預見的前端難點，也可拉上相關(guān)人員。第一場溝通，為的是暴露當前實現(xiàn)方式中的不合理點，并讓研發(fā)團隊對技術(shù)難點預研；另一場是在完成原型頁面（非PRD，不包含完整規(guī)則）后，拉上各端負責人及測試，結(jié)合業(yè)務流程圖，以一個較為具象的形式，同步最新的產(chǎn)品方案，再次審視之前認為欠妥的點，反饋研發(fā)小伙伴預研意見。

這兩次溝通，不用講很細致，因此也太長時間，每次控制在30分鐘內(nèi)。

03?重要事情說三遍

在評審中，一定要把你認為重點的內(nèi)容“敲黑板、劃重點”，確保大家均已知曉，且沒有異議。重復闡述要點便是一個不錯的方式。這種看似簡單粗暴的嘮叨確實能起到不錯的效果。舉個例子，大家恒源祥的廣告還記得嗎？廣告內(nèi)容簡單粗暴，一個靜態(tài)logo加上“恒源祥，羊羊羊”的MBG，重復三遍，十分洗腦，以至于我在小時候考試題目做不出時，腦子里都會放循環(huán)播放“恒源祥，羊羊羊”。

04?會后紀要

需求評審會的紀要不必復雜，主要說明以下三塊內(nèi)容：

結(jié)論：

評審是否通過。有的團隊還會在評審會中確定該版本具體做哪些內(nèi)容，我通常在評審會中側(cè)重需求本身，對于版本具體包含范圍，會在后續(xù)工時預估后再進行判斷。

需調(diào)整、完善（至原型、PRD中）：

圍繞著原型及prd，記錄在評審會期間提出的需要補充說明的、討論后要修改的點。

待確認：

記錄會議中未討論出結(jié)果或者有其他人需繼續(xù)配合完善的點，并明確負責人員及時間要求。這是團隊目前的待辦事項，是會議紀要的重點。

會后及時輸出會議紀要并同步給團隊，便于后續(xù)問題的跟進。

最后

簡單的說了下評審會常見的問題，也分享了下開會的經(jīng)驗。說實話，能幫到多少，我心里并沒有一個譜。每個公司的制度不同、每個團隊的能力不同，我們需“因地制宜、因材施教”，最終形成一套自己的方法論。

↘好文推薦：

把偽需求扼制在搖籃里-B端產(chǎn)品需求方法論

8000字講清楚從0到1搭建電商商品中心

五千字詳解消息通知！

👇歡迎關(guān)注：

點個“在看”

總結(jié)

以上是生活随笔為你收集整理的开需求评审会，你会出汗吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。