不做让开发人员讨厌的产品经理

首先,没有人会无端讨厌一个人,除非你身上有让人讨厌的臭毛病。而有些臭毛病,自己是可能不认为很严重。这是由于人类自我认知的障碍造成的,无法避免。不做让开发人员讨厌的产品经理,需要首先弄清开发人员究竟讨厌的是什么?于是,我在知乎上问了一个问题:开发人员最讨厌产品经理的哪些臭毛病?

让人意外的是,这个问题引起了业界很多认识的讨论和关注,并跟风产生了设计师最讨厌产品经理的哪些臭毛病?、产品经理最讨厌开发人员的哪些臭毛病?、产品经理最讨厌设计师的那些臭毛病?等问题。不难推测,在互联网公司,不同角色的人员在共同完成项目的过程中,实现天衣无缝的合作总是很有挑战的事情。

诚然,这些挑战可能是由于参与人员的能力问题,这无可避免。但我更愿意相信,沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论,可能会对各不同角色的人之间进行换位起到一定的帮助作用,无疑,这是一件对各方都有积极意义的事情。

产品经理作为贯通各环节的中心节点,避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中,我将这些可能成为臭毛病的行为归纳为以下几种情况:

短时间内可以完全避免的:

需求不清晰,当开发人员问PM需求的时候,发现PM也弄不清楚,这样的问题是一定要杜绝也完全可以杜绝的,如果PM自己都不清楚需求,的考虑这样的工作是否适合自己了。

干预纯技术问题,例如:这个code应该这么写。避免之道:对于纯技术的问题不要干预,如果他的技术实现真的有问题,自有相关的人去负责,产品只需关注他最终是否实现了预期的功能。

交付的方案不确定,开发人员讨厌“其实这样也可以”,“要不就这样吧”的言论,他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候,PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时,再将备选方说出来。

没有必要的预留时间,”这个我们修改一下,明天提交新的版本,一看,列了一大堆增加的功能,并不是仅仅是修改。coder真的不是神,增加的功能是需要测试的。pm给自己留时间同时,可怜可怜攻城湿,留点时间思考吧。”这是一位工程师的原话。Pm要对进度负责,压力很大,但是预留时间是一定要的。

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

需求变更,这是回答中出现平率最高的一个词汇。但是,要让开发人员失望的是,因为种种原因,这个问题并不能完全避免,PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到,使可能发生改变的需求讲到最少;另外一个就是要杜绝需求的往复性变更,不要让从方案A改为方案B之后觉得不行,又改回方案A。

口头交流次数太多:要避免口头交流交代,显然不现实,再完美的文档也无法代替口头上的直接交流。但频繁的口头交流可能会打断工程师的思路,延缓进度。PM可以做一是尽量完善你的文档,第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情,从而减少次数。

需要长期积累或锻炼才能改善的:

相关推荐