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

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

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

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

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

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

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

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

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

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

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

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

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

缺乏团体魅力：是的，缺乏团体魅力也成为工程师讨厌PM的一个缘由了。但是团体魅力这个东西，确实很难在短期内得到改善。甚至，对于团体魅力的判断，不同的工程师会有不同的标准。

经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。

以上 ，以自勉。