-
1 # 滾滾糰子
-
2 # java架構設計
我是做技術的,如果一個產品經理不懂技術,我真的沒法溝通。。。事實上還就得和他溝通。
彷佛網際網路公司裡大多數產品經理不懂技術,這也就造成了大量產品經理和程式設計師玩命的段子。例如:
就在前天,我們的產品經理就提出了一個需求並給出了原型,然而當我看完原型以後,我就不想說話了,沒有溝通的慾望了。本來就是一個後臺需求,增刪改查的玩意,我半個小時就寫好了,然而你非得讓我修改的時候把列表資料給帶到修改頁面我就忍不了了,我是可以實現,但是你不能侮辱我的智商。。。最後做完了給我來一句:“你怎麼沒有按照我的原型做”。。。太難了。。。
說歸說,還是得站在產品經理的角度考慮的,畢竟產品經理也是人,程式設計師天天面對的不是程式碼就是產品經理了。需求不滿意可以慢慢聊,今天咱們就一起聊聊產品經理的溝通能力。
需求的可行性和產品目標我們都知道產品經理的需求來自於各個業務部門,業務部門都會從自身業務出發提出IT研發需求,這個時候還不能叫IT研發需求,就是我要做這麼個事,怎麼實現我們not care。產品經理就需要梳理需求,並分析這個需求的可行性,到底能不能做,做成什麼樣的。
另外產品經理需要承接多個部門五花八門的需求,合理的、不合理的、有用的、看似有用的,技術部門則需要排期研發,那麼產品經理就需要對各類需求的重要性以及產品目標來決定研發優先順序、投入成本以及收益佔比等等。
和研發同學闡述需求的必要性以及具體互動路徑幾個問題需要考慮清楚:
為什麼要開發這個需求?
這個需求能解決什麼問題 ?
能給我帶來多大的收益?
怎樣的一個實現方式?
將這些問題和研發同學溝通清楚,我相信一定能得到研發部門的支援。剩下的就是需求細節的打磨了,不要一上來就是“老闆要實現這個需求”、“怎麼實現我不管”、“這個需求馬上就要實現”這類的話和語氣。
需求文件很重要產品經理出的需求,我遇見過的問題有:
沒有需求文件,後期無盡扯皮中。。。
UE和UI不一樣,互動不一樣,顯示哪些欄位不一樣,服務端先行之後等UI出來了,發現設計的資料結構和介面根本行不通;
需求文件裡就一個圖,沒有需求描述性文字在圖的左右,研發同學靠猜?我見過細心的產品經理,一個需求寫了十萬字的需求描述,大到整理敘述,小到每一個需求點的注意事項;
需求不閉環,研發做著做著,做不下去了,或者剛發完這版本功能,下版本就開始查缺補漏,然後你發現功能改的不像樣子,程式碼改的慘不忍睹。
前期改需求、中期改需求、上線前改需求,憑什麼你的問題讓開發背鍋?
回覆列表
作為產品經理需要對客戶有準確的把握,產品經理需要懂些技術但不是需要懂很多細節的東西。
在研發眼裡,產品經理應該是客戶的代表,而不是技術帶頭人,如果研發覺得你必須懂技術細節,那麼告訴他產品經理是做什麼的。
跟研發溝通,要多問問題,你要講清楚你需要做成什麼,你需要有強烈的遠景和眼界去推廣你的思路,如果你講不清楚,這個是你的問題,要你解決,要你思考,針對技術細節,你需要反覆詢問研發問題,比如可行性怎麼樣,工作量怎麼樣,帶來收益怎麼樣,可以舉行小組討論,可以充分爭論,最終拿出經得起考驗的產品。
想找到一個又懂技術又懂創意,又瞭解客戶的人很難,即使有,這樣的人也早早身居高位了,越是大公司,越是不可能一個人面面俱到,所以勇敢面對,培養自己的能力,補強弱項,你總會可以的