开需求评审会,你会出汗吗?
最近參與了一場需求評審會,我是參會人。會議中,產(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 8000字讲清楚从0到1搭建电商商品中心
- 下一篇: 2022年初,给5年内还想做产品经理的提