不做讓開發人員討厭的產品經理
不做讓開發人員討厭的產品經理-移動閱讀二維碼

不做讓開發人員討厭的產品經理,互聯網的一些事

首先,沒有人會無端討厭一個人,除非你身上有讓人討厭的臭毛病。而有些臭毛病,自己是可能不認為很嚴重。這是由于人類自我認知的障礙造成的,無法避免。不做讓開發人員討厭的產品經理,需要首先弄清開發人員究竟討厭的是什么?于是,我在知乎上問了一個問題:開發人員最討厭產品經理的哪些臭毛病?

讓人意外的是,這個問題引起了業界很多認識的討論和關注,并跟風產生了設計師最討厭產品經理的哪些臭毛病?、產品經理最討厭開發人員的哪些臭毛病?、產品經理最討厭設計師的那些臭毛病?等問題。不難推測,在互聯網公司,不同角色的人員在共同完成項目的過程中,實現天衣無縫的合作總是很有挑戰的事情。

誠然,這些挑戰可能是由于參與人員的能力問題,這無可避免。但我更愿意相信,溝通不暢、習慣不佳、缺乏換位思考等因素才是最常見的。知乎上的幾個問題的討論,可能會對各不同角色的人之間進行換位起到一定的幫助作用,無疑,這是一件對各方都有積極意義的事情。

產品經理作為貫通各環節的中心節點,避免一些讓人討厭的臭毛病顯得尤為重要。從知乎的回答中,我將這些可能成為臭毛病的行為歸納為以下幾種情況:

短時間內可以完全避免的:

需求不清晰,當開發人員問PM需求的時候,發現PM也弄不清楚,這樣的問題是一定要杜絕也完全可以杜絕的,如果PM自己都不清楚需求,的考慮這樣的工作是否適合自己了。

干預純技術問題,例如:這個code應該這么寫。避免之道:對于純技術的問題不要干預,如果他的技術實現真的有問題,自有相關的人去負責,產品只需關注他最終是否實現了預期的功能。

交付的方案不確定,開發人員討厭“其實這樣也可以”,“要不就這樣吧”的言論,他們需要的是一個明確的方案。在多種方案猶豫不決需要思考的時候,PM最好只是將這樣的猶豫不決體現在自己的思考中。除非工程師無力實現你的第一種方案時,再將備選方說出來。

沒有必要的預留時間,”這個我們修改一下,明天提交新的版本,一看,列了一大堆增加的功能,并不是僅僅是修改。coder真的不是神,增加的功能是需要測試的。pm給自己留時間同時,可憐可憐攻城濕,留點時間思考吧?!边@是一位工程師的原話。Pm要對進度負責,壓力很大,但是預留時間是一定要的。

不能完全避免但短期內可以改善的:

需求變更,這是回答中出現平率最高的一個詞匯。但是,要讓開發人員失望的是,因為種種原因,這個問題并不能完全避免,PM能做的就是盡量在交付開發之前將盡可能多的問題都考慮到,使可能發生改變的需求講到最少;另外一個就是要杜絕需求的往復性變更,不要讓從方案A改為方案B之后覺得不行,又改回方案A。

口交次數太多:要避免口頭交代,顯然不現實,再完美的文檔也無法代替頭上的直接流。但頻繁的口(頭)交(流)可能會打斷工程師的思路,延緩進度。PM可以做一是盡量完善你的文檔,第二個就是盡量在一次口頭交流中集中講完盡可能能多的事情,從而減少次數。

需要長期積累或鍛煉才能改善的:

缺乏個人魅力:是的,缺乏個人魅力也成為工程師討厭PM的一個原因了。但是個人魅力這個東西,確實很難在短期內得到改善。甚至,對于個人魅力的判斷,不同的工程師會有不同的標準。

經驗不足:或者說資歷不深,要改變這樣的現狀,恐怕也非可立竿見影的。

以上 ,以自勉。

本文鏈接:http://www.casaleticia.com/not-pm-to-developers-hate.html
本文標簽: , , ,