在实际工作当中，产品经理是经常需要和开发人员打交道的，而人际交往的前提是相互之间有一个良好的感观，甚或是已经建立起来的友情，这样沟通或交流起来会非常的顺畅。产品经理和开发人员之间，属于工作范畴的关系，一般来讲还分属于不同的部门，如果再加上所背负的考核KPI是不一样的话，两者之间很难说能够为了一个共同的目标而无间的配合。从正常情况来说，产品经理要从大局出发，所考虑的要更加全面，某个设计可能包含了后续运营以及数据收集的前瞻性东西在里面，而开发人员更多考虑的是如何去实现，实现的难易程度以及代码量的多少，不同的角度做同一件事，比然会引发很多的讨论，所以产品经理所要参加的会议一直都是很多的。如何能够和开发人员保持良好且高效的沟通交流，一直是产品经理们所需要解决的问题。
按说，产品经理和开发人员之间也是可以建立起很深的友谊的，这个需要工作之外的沟通和多次愉快的合作之后才能慢慢建立起来。已经在一个环境下工作了较长时间的产品经理和刚入职进入一个新环境的产品经理，都得和产品线所对应的开发人员搞好关系，否则会影响到后面的工作开展。经常听到一些同行抱怨在公司里与团队成员之间如何如何沟通不畅，导致对产品失去信心之类的，我想说的是，无论是和UED、设计、开发等整个团队都沟通不畅还是只和开发人员有沟通问题，产品经理都是要自我反思的，问题都出在你自己的身上，因为人际交往的宗旨就是在面对不同性格不同背景的人要采取迥异的方式来营造良好的人际交往环境。要想做一个让开发人员喜欢的产品经理，排除一些个人魅力因素，还是有一些方法的。个人在这方面做的还比较好，两家公司待下来都能与整个团队打成一片，还与一些开发人员建立了深厚的友谊，下面就讲讲一些个人的经验。
讲道理式的沟通
沟通是人际交往过程当中的必要手段，良好的人际关系从沟通开始。单从沟通的角度来说，面对不同性格的开发人员时，是要采取不同的沟通方式的，这点上需要一些阅历才能做到，因此刚从学校出来打拼的同行们可能有点吃亏，不过如果你在学校里参与了足够多的社交团体活动，相信也应该能从中学到一些方式。简单点来说就是，学会换位思考，从他人的角度出发去沟通。对性格沉闷的开发人员，在沟通的时候逻辑尽量严谨，语言尽量带些专业术语；对性格开朗的开发人员，还可以适当的有一些口头禅啊，插科打诨之类的；对待年长的（相差三岁以上吧），一定要谦卑有礼貌，同辈之间可以随意一点，但也不能肆无忌惮，对待开发新人，要一视同仁，不要带任何的轻视。人与人之间的关系相处是最为复杂的，需要慢慢积累和学习，个人现在也不敢说自己能应对所有的情况，只能尽量去做到最好，总之，保持谦逊有礼貌总是没错的，任何人都喜欢和有礼貌的人打交道，低调行天下啊。
有了良好的沟通开端，就能打开话茬开始沟通了，但要达到沟通的目的，只有这一点还不够。人和人之间的相处最讲究平等，因此在沟通的时候要特别注意不要拿老大的命令啊，KPI啊之类的去压人，要讲道理。你不仅要告诉开发人员他们应该做什么，还告诉他们为什么这样做，这样做的目的在哪里，最好还能告诉他们这样做的价值点。谁都希望自己所做的事情是有价值有意义的，而不是无用功，因此明确的目的和价值有很好的说服力。当沟通遇到分歧的时候，要努力的去说服他们，而不是简单说领导要求或者上面就要这么干，这会引起开发人员的反感。虽然有些时候确实会做一些领导要求的说不出价值的功能，产品经理也要尽力让这件事看起来是正确的，让开发人员认识到现状，认同你的无奈。在这点上，个人的做法是相互之间讲道理，谁能说服对方就听谁的，产品经理也会犯错，有时开发人员说的反而是对的，毕竟从不同的角度思考问题会有不一样的结构，且旁观者清嘛。
专业的文档撰写能力
一份好的PRD的要求是正确清楚的描述了产品的所有功能点，功能描述无二义性，功能点之间描述是一致的，各个功能对产品而言都是必要且完备的，所有功能的设计都是可验证和可实现的，所阐述的是要做什么而不是怎么做。其他的都较好理解，好的文档让人看起来非常的顺畅，可以一目了然，而不必去逐字逐句的深究，这样也会节省开发人员看文档的时间和精力。不过最后一点要稍微注意一下，怎么做一般是要有开发人员来决定的，产品经理最多指定一下数据源，组织逻辑，所要实现的展示效果即可，不需要告诉开发人员怎么实现。只有在一种情况下可以，那就是你设计的东西你认为可以实现，而开发人员认为实现不了，在保证这个功能在业务上是非常有必要而且有价值的前提下，你可以通过举例或者委婉的描述实现方法的方式来告诉开发人员，尽量不要让开发人员觉得自身能力不足，总之要引导成为这是一件有挑战的事情。文档撰写能力在开发人员的角度看不是必要的，但却是加分项，这个能力也是产品经理的必备能力，如果不够强的话，还是好好修炼一下吧。
基础的技术知识
首先强调这点也不是必备项，但是加分项。有些产品经理是有研发背景的，即在转行做产品经理之前，有从事过开发工作的，这样就非常的有优势，如果之前的开发工作与现在产品所需的是一样的话，就完美了，可以在设计的时候就进行一定程度的实现性和可行性考虑，评估所设计的功能是否可以在现有条件和资源下实现，也能在开发人员写的系统设计说明书评审会上听懂，可以大致了解是否符合要求。开发人员都是喜欢和同行交流的，就像我们自己喜欢和产品经理同行交流一下，因此做过开发的产品经理在和开发人员的沟通上有优势，但需要注意的是，千万不能装大佬，不要以为自己做过开发了不起，就指手画脚的参与系统设计，这样反而会令人反感，要记住你的技术背景只能停留在产品设计阶段和PRD沟通阶段，不要过多的给出技术方面的意见或建议，况且你都转行了，说不定你所知道的东西已经过时了。
没有研发背景的产品经理就需要修炼了，其实也不需要去学习开发技术，但是要知道一些专业术语，比如要知道JS脚本、Ajax、数据库、存储过程、BI等等名词到底是什么东西，否则你会发现你在和开发人员沟通的时候会一愣一愣的，因为他们说的你听不懂。学习的时候要有针对性，比如公司产品都是采用JAVA开发的，那就去了解一下JAVA相关的基础知识，数据都都是采用MYSQL的，那就去简单了解一下这个数据库相关的知识，我们的目标是能听懂开发人员说的话，以免陷于被动。如果让开发人员发现他说了半天，你都没有听明白，如果要他讲第二遍或者一一解释一下，估计首先要有点不耐烦，其次会有点嫌弃你了，呵呵。
听得进去建议
前面也提到，有时候开发人员是会提一些意见或者建议的，虽然大家都很专业，经验都很丰富，但大家都是很忙的，很多时候都无法考虑的那么细那么完美，总有纰漏的时候，而开发人员有时候会适时的给出一些关于细节的建议与修改，这个时候你要评估一下，看是否是有价值的，如果是改变需求的，是要认真评估一下的；如果不改变需求，你要评估一下哪种更好，两种方案实现起来的难易程度，是否可以折中等等，这种时候要尽量站在开发人员的角度去考虑。能听的进去建议的人也是受了欢迎的，就像曹操，下面的谋士都是对其忠心耿耿的，因为曹操善于采纳建议。
最后，其实开发人员也是很可爱的，只不过外面很多人会给程序员们冠以各种帽子，那都是有失偏颇的，要注意的是，不是所有的开发人员都会有类似的行为，你要是先入为主了，往往会做出错误的判断。前面讲到有研发背景的产品经理，就是从开发人员转行过来的，这证明开发人员当中是有很多与大家类似的人群的，况且还时不时有一两个美女开发嘛。以上只是个人的一些工作经验总结，前面两点个人觉得在和团队成员协作时都适用。
