產品經理在需求評審會上必定被問過的7個問題!

8 評論 4359 瀏覽 28 收藏 16 分鐘

編輯導語:在需求評審過程中,產品經理往往需要跟多方進行解釋和溝通,其中,與技術小伙伴的溝通過程中,有可能會就功能、方案設計等方面提出相應問題。本篇文章里,作者就總結了產品經理在需求評審過程中可能會遇到的七個問題和對應解決方法,一起來看一下。

有一句玩笑話:產品經理不是在吵架就是在去吵架的路上,生動地刻畫了我們產品經理在溝通上需要花的時間。

而需求評審會是所有的溝通場景里面比較重要的一個,所以今天就分享一下在需求評審會上經常會遇到的幾個需要特別注重溝通的問題,希望會對大家有所啟發。

做為一個產品經理經常會在需求評審會上遇到技術的吐槽,常見的大概是以下幾個問題:

  • 感覺這個功能沒什么用啊,我們為什么要做?
  • 你這個方案設計得不合理,應該這樣這樣設計。
  • 你設計的時候有沒有考慮過XXX的情況?
  • 你的需求不夠完整,缺了很多東西。
  • 這個需求改動太大了,真的要改嗎?
  • 你這個需求又改回去了,那你們當時為什么要改呢?

我們一個個來解析一下。

01

第一問:感覺這個功能沒什么用啊,我們為什么要做?

技術這么問的潛臺詞是:我們不知道需求的目的和背景,無法判斷這么做合不合理,產品經理趕緊講一下。

大部分時候技術并不是真的覺得這個功能沒有用,這是一種吐槽和詢問。

你要是聽到這句話,你趕緊把這個需求產生的背景、需求的目的說清楚,讓技術清晰地知道為什么要做這個需求,這個需求是解決什么問題的。這樣就能和技術在信息層面保持一致,能更好地達成共識。

這種情況就是在需求評審會的最開始沒有把關鍵信息交代清楚,這是一個新人在入行的時候常犯的一個問題。

新人很多時候都會以為大家的信息是一致的,所以我不需要解釋為什么。但其實不是的,技術部門需要產品部門去傳達這些背景信息,產品是一個關鍵節點。

在整個研發流程里面,大部分信息都是產品負責傳遞的,一般不會出現其他部門直接和技術部門對接的情況,這樣一來雖然產品經理已經和業務部門討論過好幾輪了,但是技術部門是第一次介入,所以必須認真地從頭開始講。

當然極少數情況下是技術真的覺得沒什么用,我遇過這種情況,技術覺得根據自己的經驗上這個功能沒必要,然后就一直不做。

這是比較麻煩的一種情況,而且通常是技術比較強勢的情況下會出現的。這個時候就擱置爭議,會后拉上他和領導去討論一下這個問題,雙方各自陳述一下理由,然后由領導來給一個建議。這種情況下如果領導決定要做的話技術也不會說什么。

引入第三方能夠有效的避免和技術直接發生沖突,但是弊端也很明顯,有些技術可能會持續用這個方式,你不可能一直找第三方來解決類似的問題,這個時候就要抓大放小,在小地方就按技術的處理,大的方向還是要說服技術按照你的走,說服不了的話按制度處理。

02

第二問:你這個方案設計得不合理,應該這樣這樣設計。

這也是很常見的一個情況,技術覺得產品經理的方案不好,他的方案好。

這倒沒什么潛臺詞,純粹技術覺得產品太菜,所以當場把自己的想法說出來,免得做一個坑的方案,后面還要填坑。

這個情況有兩種可能,一個是產品和技術對整體業務的掌握程度不同,所以大家的想法就不同;另一個是方案的偏好性不同,效果差不多,一個選A一個選B。

第一種情況如果是產品經理掌握的不夠,那么是比較麻煩的,因為這表示你還不熟悉公司的業務,對你的信任度會產生負面的影響。你要做的是馬上在會上把相關的細節問清楚,然后中止評審會去調整方案,準備充分再來。一定要盡量避免產生這樣的情況。

新人在這個時候常犯的一個錯誤是知道有問題還是強行推進這個方案,怕自己受到質疑,其實不可取,只有把事情做對了做好了才會沒有人質疑,不然即便不當場質疑你會后也可以找領導反饋,這樣更不好。

如果是技術掌握的不夠,那么你需要說清楚這么設計的原因,他的方案在哪些方面存在問題,通常是和其他模塊的聯動上存在問題。就事論事,你把事情講清楚了一般就不會有啥問題,大家心里都是有數的。技術提其他方案也僅僅是因為信息掌握的不夠全面。

第二種就是一個偏好性的問題,你可以說一下你這么設計的原因,也可以說一下技術的方案也是可行的,兩個方案其實沒有好壞之分,只是你傾向于這個方案,和業務部門達成共識的也是這個方案。

技術在這種情況下一般也不會堅持,因為沒必要,他提方案是希望表達出自己的想法,你對他的方案認可了這就可以了。

03

第三問:你設計的時候有沒有考慮過XXX的情況?

或許是善意的提醒,或許是惡意的挑刺,不重要,一律當成善意的提醒。你怎么看待這個問題就決定了你怎么處理這個問題,善意的回應比較好。

如果你考慮到了這個情況,那么你可以說考慮到了,等下會具體說一下,現在先按順序把前面的講清楚。

把節奏控制在自己手里,不要跳著去講,一個會議的會議節奏要掌握在會議主持手里,需求評審會的節奏就要把握在產品經理手里,你要是打亂節奏回答問題,那整個會的節奏就會很亂,時間就會長,你雖然成功地回答了大家的問題,但是效率不夠,會有點亂糟糟的,這樣也不好。

如果沒有考慮到,你可以說這個情況之前不清楚,等下集中討論下。注意,不要打擾既定的會議節奏,在需求評審會上把能確定的都先確定下來,把漏掉的部分在后面花時間討論一下。

一般來說不超過15分的討論可以當場討論,然后定一個方向,如果是時間比較長的,那么會后討論,然后再定方案,弄完之后再做二次評審。

二次評審不是一個可怕的事情,也不是一個不光彩的事情,二次評審你可以理解為一個必要的流程,重點是把事情處理好。

04

第四問:你的需求不夠完整,缺了很多東西。

這也是會遇到的,一般來說新人的時候遇到的比較多,后面其實應該還好。

出現這種情況的話有兩種情況:一種是產品的方案真的不完整,一種是技術覺得你的方案不完整。

不管是哪一種情況,如果聽到這個首先需要做的是讓提出這個問題的技術,具體說一下缺哪些東西,然后一一地對一下。

有的時候技術說的是對的,有的時候技術也就是說一下,不一定。就事論事地把這個事情弄清楚,技術如果說的是真的那就都記下來,然后去改,回去自己加強技能,如果就這么一說那么這個確認的動作能夠有效的減少那些無效的干擾,同時能夠讓這種情況以后少發生,省很多事。

一般來說其實也不會缺很多東西,一個產品拿出來的方案不會是千瘡百孔的,因為在評審之前通常都會有其他人看過、討論過,不會是產品經理一個人弄完就拿出來評審的。

但是可能真的有地方沒寫到,不多,也就有一兩個地方,技術就正好想到了,在會上讓技術指出來,然后簡單地給一個方案,定下來就行,會后把方案不上去。

所以這句話很多時候有點夸張,不需要太緊張,確認一下就行。

05

第五問:這個需求改動太大了,真的要改嗎?

這句話是有潛臺詞的,技術的意思是開發的工作量有點大,你們這么改有沒有想清楚。

技術說這句話的時候多少有點不情愿或者有點擔心,因為這種情況下通常意味著大量原來的代碼都沒有用了,過去的工作可能都白費了,這是技術不愿意看到的,所以技術會確認一下也是人之常情。

還有一種可能是需要改動的這塊代碼過去比較亂或者用到的地方比較多,所以技術有點擔心改了之后出各種問題,他們會說這句話,希望業務部門和產品再考慮一下。

如果是前面那種好處理,產品盡可能地把修改的目的和背景講清楚就行,一般來說如果確實需要改的話技術也不會多說什么。

但如果是后面那種情況,那么最好和技術溝通一下,然后盡可能地多留一點時間給技術和測試,確保上線之后不出問題。

這種情況在小公司其實比較容易出問題,經常會出現業務的領導說不行,必須在多少天內把這個需求實現了,可能是業務那邊已經答應大領導或者答應客戶了,也可能是外行指揮內行,不管是哪個都比較坑。

這種情況的話建議拉上技術部門的負責人和業務方具體溝通一下,看看是不是能夠調整研發周期或者搞一個折中的方案,我絕對建議調整研發周期。因為搞折中方案意味著后續需要花更多的時間去補救這個問題。

06

第六問:你這個需求又改回去了,那你們當時為什么要改呢?

這種情況經常出現在產品的初創期,因為方向不確定,需要不停地調整和摸索,所以有可能會出現反復修改的情況。

會問這個問題的技術一般來說是習慣了做成熟產品的研發,但是初創型的產品必然是會經常調整的。

我也遇到過這種情況,技術經常強調的就是你們想清楚再開發,盡量規劃得遠一點,這樣后面就不用經常改來改去。

講這個話的技術還是一個資深的技術,我覺得講這個話就有點外行了。改不改的看階段,并不是產品想改,而是業務需要。

如果遇到這種情況的話就說一下為什么會發生改回去的這個情況,客觀地說就行,不需要額外的去解釋。技術只是有點煩改回去,但是其實也知道做還是要做的,你需要做的是安撫他們,然后給臺階。

07

第七問:這個地方能不能改成XXX?

在這個需求評審會上除了研發部門的同事以外,通常還會有對應的業務部門的同事,業務部門有時候也會在會議上提出一些東西,通常是追加需求或者修改方案。

如果是追加需求的話其實還行,你可以評估一下改動的大小,比較小的話當場溝通一下加進去就行,如果比較大的話你就建議下個版本和其他內容一起搞個優化,當前這個版本就先不要加了,因為方案都已經確定了,加需求的話這個會就沒法開了。一般業務部門是會同意的。

如果是改方案的話就比較坑了,通常是臨時想到一個方案,然后說能不能這么這么改。這種的話其實就說明運營的經驗也不是很豐富,所以才會出現當場改方案的拆臺情況。

如果出現這種情況那你就可以問一下說,是不是新的方案比原來的方案好很多,如果答案是否定的那么建議用已經整理好的方案,這樣可以盡快上線,如果是確實新方案好很多那么就需要重新整理方案并重新開需求評審會,盡量不要讓這種情況發生,比較浪費時間,盡可能在開會前和業務部門多討論。

以上就是我關于在需求評審會上會遇到的常見問題的一些觀察和總結,希望對你有所啟發。

一個產品經理,如果沒有經歷過無數需求評審會的洗禮是不能成長為一個真正的產品經理的,真的勇士就需要直面技術的怒懟和業務的拆臺,而且大概率是需要反復直面。

不重要,只要成功挺過去,你就是最強嘴炮王者。

如果你選擇做產品經理,那么祝你好運。

 

本文由 @代號道長 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自?Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 產品新人認為寫的真的不錯,學習了

    回復
    1. 感謝

      回復
  2. 好文

    回復
    1. 感謝

      回復
  3. 這里不能這么做,用戶肯定不會這么操作。全部把“站在用戶的角度”掛嘴邊。。。

    回復
    1. 你說的對,這兩個沒放進去,想的時候沒想到。

      回復
  4. 深有體會

    回復
    1. 哈哈哈哈,大家都是一路這么過來的。

      回復