作者在创业型公司负责产品工作，因为没有设置单独的产品部门，所以被暂时安置在了技术研发部。从我被调到技术部的第一天起，老大就告诉我“你和开发永远成不了一类人”。
用“相爱相杀”形容产品经理和程序员的关系未免有些严重，但PM和研发确实是两种完全不同的生物，无论从思维方式还是工作目标上，存在一定的利益冲突，但大部分时间需要相互信任、求同存异、合作共赢。
我想过这个问题，程序员对话产品经理，存在先天上的优势——编程工作的技能值非常高，大部分人无法通过短暂的学习就能获得，这是让程序员们非常自豪的事。而且这种优越感也扩展到了由研发转过来的产品经理身上。马化腾说过“我认为所有的产品经理都应该具备技术背景”。当然作为一个没有技术背景的产品经理来说，我从内心是不愿意认同这句话的，但普遍的认识确实是：产品经理难以从事研发，但研发可以轻松地转为产品经理。（这又引出了一个比较大的、一直在争论中的话题“产品经理到底需不需要懂技术”）
扯远了，说到和程序员的沟通，确实要区分一下PM和研发不同的思维习惯。
以我自己为例吧，作为产品经理，我在做事情的时候会考虑：
这个是不是真正需要的？
有没有更好的、性价比更高的替代方案？
怎么做体验更好？
怎么才能少给后续的运营挖坑？
技术的实现难度有多大？
而程序员在做事情时会思考：
这个怎么实现？
怎样才能降低开发难度？
会不会对之前的系统造成负面影响？
是不是可扩展和易维护？
虽然PM也会考虑（可能大部分时间是自以为考虑）技术研发的成本，但毕竟不是自己做的工作，所以这方面的思考难免浅显和主观。其实，作者在跟公司的程序员GG、MM们沟通时（补充：他们人真的挺不错~工作不忙的时候大家每天中午玩狼人杀），也着过急，吵过架。但冷静下来想，真的是因为缺乏对编程的了解和对程序员的理解，才会造成这些问题。所以作者要在这些负面的事件中承担主要责任。
我估计和我本人一样，大多情况下，非研发出身的PM在和研发沟通时，困扰的问题有两个：
“看起来很简单啊，为什么告诉我不能做？”（“看起来很简单啊，为什么工期这么长”）
“本来已经沟通好的需求，为什么写代码的时候又跟我商量不这么做了？”
根据作者现有的工作经验，非研发出身PM可尝试用以下方法加强与研发人员的沟通。
把握好需求评审的流程，一定要把涉及到的所有研发人员都拉过来，并且有重点的对产品需求进行讲解。大方面的事情要尽量在会上沟通好，细节性的工作可以会下单独沟通。
一定要改变观念，程序员是与你合作的同事，并非是你的下属，产品经理是个职位并非头衔。有些刚入行的产品人员还有“以我为大”的观念，这种想法是很幼稚的。
如果你不了解技术，切莫有太多的“我认为这个很简单啊”的想法，当你对实现难度、工期没有概念时，要虚心请教架构师或主程序员。如果他们能为你普及些技术概念，说明你遇到好同事了。
每个人都有偷懒的想法，程序员们也是。如果你发现确实是因想单纯减少工作量而提出修改需求或质疑需求。一定要运用两个法宝来说服他们：用场景感染，用数据立足。增强体验的需求在研发眼里，属于可做可不做（“有那么重要吗？在我看来只是增加工作量的”），这时候就要搬出用户场景，就是给研发讲故事，这个做了用户是什么感受，没有的话用户又是什么感受。数据就不用说了，因为程序员本来就是一种理性思维的动物，如果有数据支撑你的观点，那再好不过。PM虽在技能方面不是最精专的，但一定要有全局观点，当你提前考虑到了别人的质疑，才能有备而战。
相信你的研发同事和你目标一致，相信程序员们从内心是非常想做好这些工作的，就像他们会信任你，相信你做的需求并努力实现它。同理心，真的是沟通中的三字金言。
我问过北京的同行，和研发有冲突时你该怎么做，他回复了一句“没有什么问题是一顿撸串解决不了的！”
