產(chǎn)品經(jīng)理在需求評審會上必定被問過的7個問題!
編輯導(dǎo)語:在需求評審過程中,產(chǎn)品經(jīng)理往往需要跟多方進行解釋和溝通,其中,與技術(shù)小伙伴的溝通過程中,有可能會就功能、方案設(shè)計等方面提出相應(yīng)問題。本篇文章里,作者就總結(jié)了產(chǎn)品經(jīng)理在需求評審過程中可能會遇到的七個問題和對應(yīng)解決方法,一起來看一下。
有一句玩笑話:產(chǎn)品經(jīng)理不是在吵架就是在去吵架的路上,生動地刻畫了我們產(chǎn)品經(jīng)理在溝通上需要花的時間。
而需求評審會是所有的溝通場景里面比較重要的一個,所以今天就分享一下在需求評審會上經(jīng)常會遇到的幾個需要特別注重溝通的問題,希望會對大家有所啟發(fā)。
做為一個產(chǎn)品經(jīng)理經(jīng)常會在需求評審會上遇到技術(shù)的吐槽,常見的大概是以下幾個問題:
- 感覺這個功能沒什么用啊,我們?yōu)槭裁匆觯?/li>
- 你這個方案設(shè)計得不合理,應(yīng)該這樣這樣設(shè)計。
- 你設(shè)計的時候有沒有考慮過XXX的情況?
- 你的需求不夠完整,缺了很多東西。
- 這個需求改動太大了,真的要改嗎?
- 你這個需求又改回去了,那你們當時為什么要改呢?
我們一個個來解析一下。
01
第一問:感覺這個功能沒什么用啊,我們?yōu)槭裁匆觯?/strong>
技術(shù)這么問的潛臺詞是:我們不知道需求的目的和背景,無法判斷這么做合不合理,產(chǎn)品經(jīng)理趕緊講一下。
大部分時候技術(shù)并不是真的覺得這個功能沒有用,這是一種吐槽和詢問。
你要是聽到這句話,你趕緊把這個需求產(chǎn)生的背景、需求的目的說清楚,讓技術(shù)清晰地知道為什么要做這個需求,這個需求是解決什么問題的。這樣就能和技術(shù)在信息層面保持一致,能更好地達成共識。
這種情況就是在需求評審會的最開始沒有把關(guān)鍵信息交代清楚,這是一個新人在入行的時候常犯的一個問題。
新人很多時候都會以為大家的信息是一致的,所以我不需要解釋為什么。但其實不是的,技術(shù)部門需要產(chǎn)品部門去傳達這些背景信息,產(chǎn)品是一個關(guān)鍵節(jié)點。
在整個研發(fā)流程里面,大部分信息都是產(chǎn)品負責(zé)傳遞的,一般不會出現(xiàn)其他部門直接和技術(shù)部門對接的情況,這樣一來雖然產(chǎn)品經(jīng)理已經(jīng)和業(yè)務(wù)部門討論過好幾輪了,但是技術(shù)部門是第一次介入,所以必須認真地從頭開始講。
當然極少數(shù)情況下是技術(shù)真的覺得沒什么用,我遇過這種情況,技術(shù)覺得根據(jù)自己的經(jīng)驗上這個功能沒必要,然后就一直不做。
這是比較麻煩的一種情況,而且通常是技術(shù)比較強勢的情況下會出現(xiàn)的。這個時候就擱置爭議,會后拉上他和領(lǐng)導(dǎo)去討論一下這個問題,雙方各自陳述一下理由,然后由領(lǐng)導(dǎo)來給一個建議。這種情況下如果領(lǐng)導(dǎo)決定要做的話技術(shù)也不會說什么。
引入第三方能夠有效的避免和技術(shù)直接發(fā)生沖突,但是弊端也很明顯,有些技術(shù)可能會持續(xù)用這個方式,你不可能一直找第三方來解決類似的問題,這個時候就要抓大放小,在小地方就按技術(shù)的處理,大的方向還是要說服技術(shù)按照你的走,說服不了的話按制度處理。
02
第二問:你這個方案設(shè)計得不合理,應(yīng)該這樣這樣設(shè)計。
這也是很常見的一個情況,技術(shù)覺得產(chǎn)品經(jīng)理的方案不好,他的方案好。
這倒沒什么潛臺詞,純粹技術(shù)覺得產(chǎn)品太菜,所以當場把自己的想法說出來,免得做一個坑的方案,后面還要填坑。
這個情況有兩種可能,一個是產(chǎn)品和技術(shù)對整體業(yè)務(wù)的掌握程度不同,所以大家的想法就不同;另一個是方案的偏好性不同,效果差不多,一個選A一個選B。
第一種情況如果是產(chǎn)品經(jīng)理掌握的不夠,那么是比較麻煩的,因為這表示你還不熟悉公司的業(yè)務(wù),對你的信任度會產(chǎn)生負面的影響。你要做的是馬上在會上把相關(guān)的細節(jié)問清楚,然后中止評審會去調(diào)整方案,準備充分再來。一定要盡量避免產(chǎn)生這樣的情況。
新人在這個時候常犯的一個錯誤是知道有問題還是強行推進這個方案,怕自己受到質(zhì)疑,其實不可取,只有把事情做對了做好了才會沒有人質(zhì)疑,不然即便不當場質(zhì)疑你會后也可以找領(lǐng)導(dǎo)反饋,這樣更不好。
如果是技術(shù)掌握的不夠,那么你需要說清楚這么設(shè)計的原因,他的方案在哪些方面存在問題,通常是和其他模塊的聯(lián)動上存在問題。就事論事,你把事情講清楚了一般就不會有啥問題,大家心里都是有數(shù)的。技術(shù)提其他方案也僅僅是因為信息掌握的不夠全面。
第二種就是一個偏好性的問題,你可以說一下你這么設(shè)計的原因,也可以說一下技術(shù)的方案也是可行的,兩個方案其實沒有好壞之分,只是你傾向于這個方案,和業(yè)務(wù)部門達成共識的也是這個方案。
技術(shù)在這種情況下一般也不會堅持,因為沒必要,他提方案是希望表達出自己的想法,你對他的方案認可了這就可以了。
03
第三問:你設(shè)計的時候有沒有考慮過XXX的情況?
或許是善意的提醒,或許是惡意的挑刺,不重要,一律當成善意的提醒。你怎么看待這個問題就決定了你怎么處理這個問題,善意的回應(yīng)比較好。
如果你考慮到了這個情況,那么你可以說考慮到了,等下會具體說一下,現(xiàn)在先按順序把前面的講清楚。
把節(jié)奏控制在自己手里,不要跳著去講,一個會議的會議節(jié)奏要掌握在會議主持手里,需求評審會的節(jié)奏就要把握在產(chǎn)品經(jīng)理手里,你要是打亂節(jié)奏回答問題,那整個會的節(jié)奏就會很亂,時間就會長,你雖然成功地回答了大家的問題,但是效率不夠,會有點亂糟糟的,這樣也不好。
如果沒有考慮到,你可以說這個情況之前不清楚,等下集中討論下。注意,不要打擾既定的會議節(jié)奏,在需求評審會上把能確定的都先確定下來,把漏掉的部分在后面花時間討論一下。
一般來說不超過15分的討論可以當場討論,然后定一個方向,如果是時間比較長的,那么會后討論,然后再定方案,弄完之后再做二次評審。
二次評審不是一個可怕的事情,也不是一個不光彩的事情,二次評審你可以理解為一個必要的流程,重點是把事情處理好。
04
第四問:你的需求不夠完整,缺了很多東西。
這也是會遇到的,一般來說新人的時候遇到的比較多,后面其實應(yīng)該還好。
出現(xiàn)這種情況的話有兩種情況:一種是產(chǎn)品的方案真的不完整,一種是技術(shù)覺得你的方案不完整。
不管是哪一種情況,如果聽到這個首先需要做的是讓提出這個問題的技術(shù),具體說一下缺哪些東西,然后一一地對一下。
有的時候技術(shù)說的是對的,有的時候技術(shù)也就是說一下,不一定。就事論事地把這個事情弄清楚,技術(shù)如果說的是真的那就都記下來,然后去改,回去自己加強技能,如果就這么一說那么這個確認的動作能夠有效的減少那些無效的干擾,同時能夠讓這種情況以后少發(fā)生,省很多事。
一般來說其實也不會缺很多東西,一個產(chǎn)品拿出來的方案不會是千瘡百孔的,因為在評審之前通常都會有其他人看過、討論過,不會是產(chǎn)品經(jīng)理一個人弄完就拿出來評審的。
但是可能真的有地方?jīng)]寫到,不多,也就有一兩個地方,技術(shù)就正好想到了,在會上讓技術(shù)指出來,然后簡單地給一個方案,定下來就行,會后把方案不上去。
所以這句話很多時候有點夸張,不需要太緊張,確認一下就行。
05
第五問:這個需求改動太大了,真的要改嗎?
這句話是有潛臺詞的,技術(shù)的意思是開發(fā)的工作量有點大,你們這么改有沒有想清楚。
技術(shù)說這句話的時候多少有點不情愿或者有點擔心,因為這種情況下通常意味著大量原來的代碼都沒有用了,過去的工作可能都白費了,這是技術(shù)不愿意看到的,所以技術(shù)會確認一下也是人之常情。
還有一種可能是需要改動的這塊代碼過去比較亂或者用到的地方比較多,所以技術(shù)有點擔心改了之后出各種問題,他們會說這句話,希望業(yè)務(wù)部門和產(chǎn)品再考慮一下。
如果是前面那種好處理,產(chǎn)品盡可能地把修改的目的和背景講清楚就行,一般來說如果確實需要改的話技術(shù)也不會多說什么。
但如果是后面那種情況,那么最好和技術(shù)溝通一下,然后盡可能地多留一點時間給技術(shù)和測試,確保上線之后不出問題。
這種情況在小公司其實比較容易出問題,經(jīng)常會出現(xiàn)業(yè)務(wù)的領(lǐng)導(dǎo)說不行,必須在多少天內(nèi)把這個需求實現(xiàn)了,可能是業(yè)務(wù)那邊已經(jīng)答應(yīng)大領(lǐng)導(dǎo)或者答應(yīng)客戶了,也可能是外行指揮內(nèi)行,不管是哪個都比較坑。
這種情況的話建議拉上技術(shù)部門的負責(zé)人和業(yè)務(wù)方具體溝通一下,看看是不是能夠調(diào)整研發(fā)周期或者搞一個折中的方案,我絕對建議調(diào)整研發(fā)周期。因為搞折中方案意味著后續(xù)需要花更多的時間去補救這個問題。
06
第六問:你這個需求又改回去了,那你們當時為什么要改呢?
這種情況經(jīng)常出現(xiàn)在產(chǎn)品的初創(chuàng)期,因為方向不確定,需要不停地調(diào)整和摸索,所以有可能會出現(xiàn)反復(fù)修改的情況。
會問這個問題的技術(shù)一般來說是習(xí)慣了做成熟產(chǎn)品的研發(fā),但是初創(chuàng)型的產(chǎn)品必然是會經(jīng)常調(diào)整的。
我也遇到過這種情況,技術(shù)經(jīng)常強調(diào)的就是你們想清楚再開發(fā),盡量規(guī)劃得遠一點,這樣后面就不用經(jīng)常改來改去。
講這個話的技術(shù)還是一個資深的技術(shù),我覺得講這個話就有點外行了。改不改的看階段,并不是產(chǎn)品想改,而是業(yè)務(wù)需要。
如果遇到這種情況的話就說一下為什么會發(fā)生改回去的這個情況,客觀地說就行,不需要額外的去解釋。技術(shù)只是有點煩改回去,但是其實也知道做還是要做的,你需要做的是安撫他們,然后給臺階。
07
第七問:這個地方能不能改成XXX?
在這個需求評審會上除了研發(fā)部門的同事以外,通常還會有對應(yīng)的業(yè)務(wù)部門的同事,業(yè)務(wù)部門有時候也會在會議上提出一些東西,通常是追加需求或者修改方案。
如果是追加需求的話其實還行,你可以評估一下改動的大小,比較小的話當場溝通一下加進去就行,如果比較大的話你就建議下個版本和其他內(nèi)容一起搞個優(yōu)化,當前這個版本就先不要加了,因為方案都已經(jīng)確定了,加需求的話這個會就沒法開了。一般業(yè)務(wù)部門是會同意的。
如果是改方案的話就比較坑了,通常是臨時想到一個方案,然后說能不能這么這么改。這種的話其實就說明運營的經(jīng)驗也不是很豐富,所以才會出現(xiàn)當場改方案的拆臺情況。
如果出現(xiàn)這種情況那你就可以問一下說,是不是新的方案比原來的方案好很多,如果答案是否定的那么建議用已經(jīng)整理好的方案,這樣可以盡快上線,如果是確實新方案好很多那么就需要重新整理方案并重新開需求評審會,盡量不要讓這種情況發(fā)生,比較浪費時間,盡可能在開會前和業(yè)務(wù)部門多討論。
以上就是我關(guān)于在需求評審會上會遇到的常見問題的一些觀察和總結(jié),希望對你有所啟發(fā)。
一個產(chǎn)品經(jīng)理,如果沒有經(jīng)歷過無數(shù)需求評審會的洗禮是不能成長為一個真正的產(chǎn)品經(jīng)理的,真的勇士就需要直面技術(shù)的怒懟和業(yè)務(wù)的拆臺,而且大概率是需要反復(fù)直面。
不重要,只要成功挺過去,你就是最強嘴炮王者。
如果你選擇做產(chǎn)品經(jīng)理,那么祝你好運。
本文由 @代號道長 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自?Unsplash,基于 CC0 協(xié)議
哈哈,那個場景簡直了
冒昧的問一下,第六問中的“改不改看階段”是什么意思啊,一般是不同階段的需求數(shù)量或深度不同,這樣確實是“改不改看階段”,但第六問中說的是“改回去”,什么樣的情況才會這樣反復(fù)橫跳呢(職場新人,單純請教)
個人觀點,也是在職場中確實遇到了,主要有以下幾個方面的原因:第一點,用戶需求不明確并且抱著試試看的態(tài)度,或者說不同的領(lǐng)導(dǎo)有不同的需求見解;第二點,客戶提出該需求時態(tài)度強硬,不容質(zhì)疑以及不允許有其他方案代替;第三點,產(chǎn)品順應(yīng)客戶需求,沒有引導(dǎo)用戶往規(guī)劃方向上調(diào)整;這些都會導(dǎo)致出現(xiàn)改需求并適用一段時間后再次修改回去的問題
產(chǎn)品新人認為寫的真的不錯,學(xué)習(xí)了
感謝
好文
感謝
這里不能這么做,用戶肯定不會這么操作。全部把“站在用戶的角度”掛嘴邊。。。
你說的對,這兩個沒放進去,想的時候沒想到。
深有體會
哈哈哈哈,大家都是一路這么過來的。