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

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

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

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

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

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

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

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

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

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

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

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

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

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