1. 程式人生 > >技術團隊管理:需求之殤——你大媽不是你以前的大媽了,你大爺永遠是你大爺

技術團隊管理:需求之殤——你大媽不是你以前的大媽了,你大爺永遠是你大爺

        在軟體界來說,好像產品經理天然就是程式設計師的頭號公敵。原因基本上就是需求的變更。產品經理有時候會覺得自己很委屈,因為有些東西是客戶要求變更的。對程式設計師來說,技術只是實現需求的一種手段,需求的實現才是終極目標;站在產品經理的角度來說,需求只是一個手段而已,而客戶才是終極目標。因為兩者在對需求的看待問題的不一致,導致後續戰爭頻發.............

十年專案之現狀。

我們經過的專案關係很多是這樣的:1、領導拍腦袋提出一個需求(是否合理不管);2、拉著產品經人員,拍拍肩膀,說這個很重要之類的(總之非你莫屬了);3、產品經理一聽說很重要,立馬拍胸脯保證完成任務(有的產品經理這個時候開始給客戶完成時間了);4、然後各種噩夢開始了.....產品在和開發對需求的時候,基本上都是拍桌子。基本上這個時候在程式設計師眼睛裡,產品經理就是個傻缺了,產品經理眼睛裡,程式設計師就是個二貨了;5、後來實在談不攏了,就開始拉到上面去了,上面公權一壓。程式設計師基本上是那種在非專業上沒話說的(逗比的程式設計師不在此列)。6、程式設計師估算開發時間,這個時候又是各種撕逼。產品經理總是站在自己的專業角度上來考慮問題,覺得一個小小的頁面憑啥要個1-2周(產品經理是不是用畫原型的時間在評估需求開發時間呢?)然後開始壓時間。

產品經理:“這個要多長時間才能完成?”

程式設計師:“兩週”

產品經理:“(二貨,欺負我不懂是吧?)時間太長了,最多一週時間?” 

程式設計師:“(這個傻缺)可以吧”

7、開發時間進入一半後,客戶提出需求變更。同時表示需求很急,希望能按原定時間完成。

8、然後產品和開發各種撕逼中..........用程式猿的話來說,這個才應該是年度最大的宮廷劇

9、然後的然後..........就沒有然後了。要麼需求延期,要麼需求斃掉,要麼散夥走人。

產品經理為什麼會經常接到來自客戶的需求變更?

(其實我覺得很多產品經理不能夠很好的理解客戶的要求或者需求痛點)。很多產品經理都是因需求而需求,而不是去想為什麼。大家都明白專案都是逐漸明細的,為什麼是這樣,因為需求到後期會越來越細,所以專案會越來越清晰(你確定你說的這不是廢話?)。很多產品經理接到來自客戶方的需求就是一段話或者一個想法。對於中間的需求相關性和實現的可能性以及優先順序,其實都沒有經過論證的。客戶給過來的需求80%都是拍腦袋決定的,拍腦袋的決定,往往伴隨著拍大腿的懊惱和拍桌子的需求變更。因產品經理的目標是客戶,在客戶面前,產品經理就是個渣渣。所以後續需求變更無法避免,接下來的巴以衝突在程式設計師和產品經理中間就不斷的上演著.......

怎麼解決這個問題?

聰明的人士都會將這個問題拋給客戶,讓客戶自己來提真正的需求。聰明的產品經理在接到客戶是需求後,往往不會立即拍胸口承諾。而是先提出先做個需求調研並且和程式設計師開個會確認下需求實現的可能性。然後屁顛屁顛的跑回來和程式設計師溝通一下。免得到時候後院起火。

其實這個問題最主要的是來自兩個方面。一、客戶不是大爺;二、程式設計師應該享有平等的知情權。

我們先聊下為什麼不能把客戶當作大爺吧?

需求不一定真的是需求

“你大爺永遠是你大爺”黑土大爺的話還在不少人耳邊響起。很多產品經理的需求往往就是來自客戶的一句話,一個想法,一時興起。其實提出的很多需求都是偽需求。然後就丟給產品經理,然產品實現。很多初級產品經理也是拿著雞毛當令箭。開始認真的分析起來。其實這個時候產品經理最應該做的事情思考:為什麼要這個功能,這個功能有什麼作用,它會不會令產品的主要方向出現偏差,會不會影響到其它的功能使用,有沒有用現有功能替代的方法?..........產品經理最應該做的事情是思考,而不是想著怎麼實現原型圖。

產品經理不要自己添磚加瓦

"你大爺永遠是你大爺,你大媽已經不是你以前的大媽了"。我以前碰到過一個需求,產品經理從客戶那裡得到一個統計需求,然後要求實現,首先產品經理要求按照其給出來的需求實現,因為歷史遺留的問題,部分資料是有問題的,在經歷過開發的實現之後發現實際預計有偏差,然後拍著腦袋把需求再按照自己的腦袋進行二次加工,要求實現,這個時候又對需求進行加工....然後,這個需求直接反饋給使用者實現不了。其實這個問題的解決方法不是不斷的去修改需求。而是去想著,那資料有問題,能否進行修復?明知道以前的資料有問題了,而不去修改資料,反而不斷的去調整需求,其實這個在實現的方向上就錯了。因為無論你怎麼改,錯誤的資料還是在裡面。你都不可能避免錯誤資料的問題,正確的解決思路應該是先如何把錯誤的資料修復過來。南轅北轍,在錯誤的路上,越努力離成功越遠。很多產品經理在功能的實現方向上一旦出現問題,往往習慣想當然的去改變需求然後繞過去,而不是直接面對。這就導致了問題還是問題,當前的需求已經不是當年的白雲大媽了....產品經理不要總是自己拍個腦袋就把需求改了.........

要準備上班了,程式設計師的那塊下次補上