产品经理怎样更好的和开发人员沟通？

诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论，可能会对各不同角色的人之间进行换位起到一定的帮助作用，无疑，这是一件对各方都有积极意义的事情。产品经理作为贯通各环节的中心节点，避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中，我将这些可能成为臭毛病的行为归纳为以下几种情况：短时间内可以完全避免的：需求不清晰，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。干预纯技术问题，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。交付的方案不确定，开发人员讨厌其实这样也可以，要不就这样吧的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。没有必要的预留时间,这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。不能完全避免但短期内可以改善的：需求变更，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少；另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案B。口交次数太多：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口（头）交（流）可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。需要长期积累或锻炼才能改善的：缺乏个人魅力：是的，缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西，确实很难在短期内得到改善。甚至，对于个人魅力的判断，不同的工程师会有不同的标准。经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。以上 ，以自勉。

我写这篇文章被开发人员看到，会不会想打我？狗日的产品经理天天游手好闲，还想着怎么“折磨”我们，而且还是“就应该折磨”。

这个是“我”做了这么多产品后的“心声”，我并不想隐瞒。

一款产品是怎么来的？

一般来说是部分人看见了某处商机，找来一个开发团队把商机具象成产品，然后让用户为此付费。

也就是说每一款产品出来一定有三类人群围绕着它：企图用产品赚钱的公司（提需求者）、开发团队、付费人群（用户）

产品经理是这三类人群的中转站，企图赚钱的公司把这个使命（商机具象化）交给产品经理；开发团队合作把产品经理的原型具象化；用户为这个具象化的产品付钱。

表面看起来这个事情顺风顺水，每个人各安其职做好分内的事就行了，但是实际情况却不是这样，开发过程中充满了各种痛苦。

产品在具象化过程中充满着各种困难，这些困难的最终承受者基本都是开发者团队。整个产品开发中抱怨最多的永远是开发者，他们会觉得产品经理思维不全面/或者功能意向天开，不可能实现。

因为在产品开发中，产品经理接触最多的永远是开发者，听到最多的也是开发者的抱怨，所以产品经理会不自觉的同情开发者（也有可能是受不了抱怨的压力进而妥协），想办法为开发者降低技术难度，为同事造福。

比如需要使用原生语言开发的页面，允许开发者使用了H5开发，开发者难度是降低了，但是用户体验就大大折扣。

但是我想说，这种同情心真是大错特错。

拥有这种同情心的产品经理都是弄不清楚具体形势，没有合理判断围绕产品的三类人群的重要程度。

市场上肯定很多人说用户最重要，巴拉巴拉用户体验之类的的，为用户负责之类的。

出钱的老板最重要，无论是产品经理还是开发团队，为了这件事牺牲都没有老板大，他拿出真金白银上赌桌了，请心疼老板的钱。

开发人员辛苦是应该的，这么说也许不好听，但是我是真的这么想的。在这个社会上大家都是跪着赚钱的，希望开发人员理解下产品经理（产品经理需要经常跪老板。跪客户、跪开发、跪美工、跪对接）。做出盈利可观的产品，我们所有人都收益（老板、开发团队、用户、产品经理），参与了伟大产品的开发本身就是一种傲人的资历。

比起用户满意，老板赚钱，开发者的抱怨，重要性的确是往后移的。

好的产品经理就应该学会权衡利弊，为老板做出最能赚钱的产品才是我们的终极目标。

而且老板利益和用户的利益也是一致的，老板希望做出好的产品，才能打动更多的用户（对不起，不自觉的想到了携程和同程机票事件）。

无论开发团队怎么抱怨，请不要对产品打折扣，“折磨”开发本来就是我们的本职之一，一切为了产品。

这里的“折磨”主要是指：不要因为直接接触开发人员的抱怨，而改变我们做好产品的初衷。不是为了折磨而折磨，相信也没人会为了折磨而折磨，所有为这个产品出力的人，我们是一个团队。

另外我们偶尔要换下其他的“折磨”开发团队的方式，比如发红包呀，请吃饭呀、为开发者戴戴高帽子呀。让他们知道我们其实也很同情他们的，哪怕我们私人出钱补贴他们都行，产品的事请他们多多包涵。

产品经理一定要知道，哪些可能妥协哪些不能妥协，以及什么是真-最重要。

Ps：这些是我真的遇到过，走错过的路，希望其他人能避免

开始实施之前

说不清需求价值，技术问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”，成为了传话筒，是最Low的，相反，能有理有据的顶老板的产品经理，通常会在大家的眼中逼格满满；

没想到功能细节，表现为技术问细节（当然，是涉及业务的细节，不是技术实现细节）的时候，自己还没想过，现场想，被发现了，或者因为是接二手需求，并不知道、也没有去追溯这个需求的初衷；

帮技术评估工作量，特别是技术出身的产品经理容易犯这个错，潜台词就是“希望加活”，我评估过了，这些都能做掉的，不要给我偷懒；

逼着技术团队承诺，产品经理想的是，如果技术承诺了，但却做不到，这样自己就没责任了，但很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别；

实施过程中

做了一半改需求，scrum里的表现就是sprint内的非受迫需求变更，大家很难忍受的是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，当然，如果是外部市场变了，大家都可以理解；

开发过程中消失，你可以出差、可以开会，但是要能及时响应技术的问题，要不然，为了进度大家照着自己的想法做下去，验收的时候产品经理跑出来说“这不是我要的”，可不要怪没人理你；

过度关注实现细节，帮技术决定技术方案，也是技术出身的产品经理容易犯的错，越俎代庖了，会降低技术同学的积极性，渐渐的就完全打工心态了；

产品发布之后

发布后没有反馈，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，做完发布，石沉大海，大家是不可能有owner感的；

无节奏感，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，让技术人员在干死干活的高强度之后突然不知道做什么，几天后又开始要赶进度；

全过程都有

优柔寡断无决断，是产品经理最要不得的品质，就是在已经讨论完毕后，大家都等着你拍板的时候“你说吧，往哪儿走我们就跟着办”，这时候你说“啊，那个，各种方案各有利弊啊，我也不知道怎么办啊，你们有什么好想法……”，你就完蛋了；

报喜不报忧，产品经理总想藏着掖着一些信息，比如“老板在考虑干掉这个项目”这类信息，出发点可能是好的，但，当大家通过其他途径知道了以后，互信就完全打破了，大家会觉得“你还是把我们当资源”；