作为程序员，工作中除了测试，项目管理，可能最多的就是和产品经理打交道了，工作这么久，合作了很多产品经理。我从一个程序开发人员角度，总结了五点产品经理和开发人员沟通的注意事项：
点到为止，不越俎代庖；
不打扰，多给程序员时间和空间；
对问题要有自己的判断；
沟通需求要详细明确；
平等、尊重与理解；
点到为止，不越俎代庖
许多产品经理喜欢想当然，特别是技术出身的产品经理，很难去把握点到为止的度，经常说“这个应该很简单吧”、“这个应该这样去实现”，甚至在聊需求的时候会深入聊到技术上如何实现。
懂点技术有利于在跟程序员沟通的时候换位思考，评估需求落地风险，对产品经理来讲这是优势，但如果产品经理无法把握尺度，特别在讨论技术相关问题出现分歧的时候，产品经理很容易越俎代庖，对技术细节，实现方案过多介入。而产品经理的判断往往是建立在自己以往的一点技术知识与之上的，很容易判断失误，开发人员才是真正了解功能实现的人，对技术细节更清楚，考虑的更全面。所以带来的后果就是常常引起开发人员反感，最终双方不欢而散。既浪费时间有浪费情绪。这就相当于产品经理站在技术角度和开发人员站在技术角度看技术问题，当然是开发人员更有说服力。
在提需求之前先跟程序员有线下沟通能够提升你的需求合理度和风险控制能力，但不要讨论技术实现细节。技术是程序员们所擅长的东西，信任他们，你要做的就是，倾听、欣赏他们的方案，不推翻，只提建议。
不打扰，多给程序员时间和空间
作为程序员，非常反感思维在高度集中、效率奇高，构建思维、飞快码字的时候，产品经理不断地跑过来说一些无关痛痒的“点”打断我的思维
做开发的人可能知道，当你很高亢很有感觉的时候，一旦被打断很容易延续不上之前的思路，甚至有时候会让产品实现逻辑上少掉一个关键的判断。一般上午是处理复杂，重要问题的最好时间，这个时候精力比较旺盛，头脑比较清晰，如果上午产品经理找你两次，基本上一个上午做不了什么事情。
建议产品经理沟通不要想到什么问题就立即去沟通，最好把需要沟通的问题汇总到列表，对问题尽量描述的清晰一些。不是核心的、致命的问题可以和相关人员约定时间，邮件发送问题内容。这样沟通之前大家对问题有个预先的了解，沟通的时候可以更高效。需要注意的是，沟通的时候一定要明确沟通主题，沟通后一定要有结论。我亲身经历过无数次产品经理把评审会开成茶话会，反思会，抱怨会的例子。
对问题要有自己的判断
我们公司是做物联网医疗的，患者使用我们公司的产品的同时会实时上传患者数据，经常有产品经理反馈数据不上传问题，由于数据无法上传，记录的log也无法传到服务器分析问题原因，所以只能去患者家里，现场解决问题，很多次去了患者家里发现数据上传都是正常的，原来是产品经理把患者产品编号弄错了，没有经过确认筛选直接反馈给了开发人员。
所以产品经理得到问题反馈或者需求的时候，一定要确认问题，能筛选的筛选，能自己处理的自己处理，并尝试去解决。要有自己的判断，不要做问题或需求的搬运工。
沟通需求要详细明确
产品经理是需求的收集者，分类者，排序者。目前我们公司的工作流程是，产品经理拿到需求，首先会把需求发给项目组组长，然后组长下发任务，我们接到任务之后如果有问题会和产品经理沟通，明确需求。工作中经常会遇到这种情况，需求完成以后拿给产品经理看，产品经理说：咦，我要的不是这样的效果啊，这个字体不对，需要改一下。开发人员就会说：你需求里也没要求需要什么字体，我就按默认字体实现的。然后产品经理又说：不确定的你可以问啊，重新改一下吧，反正改个字体也不难。程序员：。。。；当然出现这种问题程序员也有责任。
总结如下：
1. 需求收集的时候一定要明确需求，如果需求从最开始就模棱两可，后续需求实现的时候一定会出问题。
2.产品和程序员沟通的时候，需求一定要描述详细，特别是复杂的需求最好能有需求说明书之类的文档说明，并且要尽量全面。
3.在开发过程中遇到不清楚的问题一定要及时沟通。
4.需求变更的时候一定及时通知开发人员，确认是当前版本修改还是下一个版本迭代。
平等、尊重与理解
首先，产品经理应该明确知晓项目/团队的目标，与程序员是同一利益共同体，所有的讨论、分歧、摩擦、思想碰撞都是对事不对人的，也不存在必然的领导和被领导、上级和下级的关系。产品经理跟程序员之间是平等的协作关系，双方的命运与产品息息相关。有时候程序员对产品倾注的情感，付出的努力，并不比产品经理少;程序员对产品的期望和思考，也不比产品经理低，有时候甚至高于产品经理。
举个例子，大部分的产品经理在设计新房时可能考虑了电梯、逃生通道、水电、电器接入，但程序员想得会更多，他们会关注停电停水之后房间里需不需要备蜡烛、紧急照明灯以及储备用水。
程序员是产品/项目的实际实施者和创造者，产品经理是帮助产品创造的设计者和连接者，是团队中的一员，而不是突出的个人。放弃你改变世界的想法，以平等、尊重彼此的心态，沟通。
