程序员和产品经理协作、沟通矛盾是一个永恒的话题。因为两者的知识体系和思维结构不一样， 我认为，程序员和产品经理之间的健康关系应该是基于信任、尊重和理解以及同一利益共同体的，脱离了这一前提，高效的协作就成了空谈。
那产品经理在日常的工作过程中，与程序员要保持高度默契，形成健康的协作关系，需要注意哪些方面呢?今天结合我曾经在两个角色之间完成过转换的经历，谈谈自己的理解，一家之言，欢迎拍砖。
平等、尊重与理解是第一前提。
首先，产品经理应该明确知晓项目/团队的目标，与程序员是同一利益共同体，所有的讨论、分歧、摩擦、思想碰撞都是对事不对人的，也不存在必然的领导和被领导、上级和下级的关系。产品经理跟程序员之间是平等的协作关系，双方的命运与产品息息相关。有时候程序员对产品倾注的情感，付出的努力，并不比产品经理少;程序员对产品的期望和思考，也不比产品经理低，有时候甚至高于产品经理。
不打扰，多给程序员时间和空间。
程序员非常讨厌的一点(即使你做了，可能他们也不会明说)是当他思维在高度集中、效率奇高构建思维、飞快码字的时候，产品经理不断地跑过来说一些无关痛痒的“点”打断他的思维。
是的，断了的思维有时候会延续不上，甚至有时候会让产品实现逻辑上少掉一个关键的分支。不用在产品实现的时候频繁出现刷存在感，当他(程序员)需要你的时候，他会自己找你。即便你自己发现了产品问题或者bug，如果不是核心的、致命的问题，请先记在一个列表里，集中给他。
产品经理要学会在大多数时候，让程序员忘了你的存在，但在最需要你的时候你才挺身而出。
有担当，敢担当，不贪功。
所有产品经理都绕不过去的一个坎是“老板需求”。什么是老板需求?说白了就是：老板需要一个这样的东西，老板想要这样做。但老板不接触程序员，他接触产品经理。如果你只是老板需求的转发者，而不是产品需求的过滤者、把关者，可能会被视为“无担当”。
老板需求跟用户需求、产品基础需求应该是平等的，也有合理、不合理之分，也有优先级。当产品经理发现老板需求不是太合理时，产品经理要冒着丢掉饭碗的风险与老板据理力争，动之以理，晓之以情。
曾经有一次老板提了一个几乎是颠覆当前产品架构以及技术架构设计的想法，他觉得非常重要，必须要尽快实现。我认为当前产品第一要务是解决基础功能问题，打好产品根基。跟他PK的时候双方情绪激动，就差没有拍桌子，老板在途中也说了一句，我觉得你非常聪明，也非常适合做产品经理，但是你有点固执，你看得没我清楚，但最后证明产品根基对于产品的可持续发展是非常重要的，也给产品后续的迭代提供了非常好的基础。
一日三省吾身，产品经理的工作性质决定了产品经理是容易犯错的。一旦产品的设计上出了问题，作为产品的决策者，你不能把责任往外推，要有承担责任的态度和表率。但对于有价值的产品方向近乎固执的坚持，不轻易推翻、变更需求，是产品经理敢担当、有担当的表现，则是最程序员劳动最基本的尊重。
产品设计/实现出现问题时，担当而不推诿;需要资源支持时，巧取而不豪夺(这里的“豪夺”是指动不动搬上下级关系施压);在产品有成绩和突破时，表达而不贪功。
在协作、磨合过程中，有担当，敢担当，不贪功，善良比聪明更重要。
点到即止，不越俎代庖。
许多产品经理喜欢想当然，特别是技术出身的产品经理，很难去把握点到即止的度，经常说“这个应该很简单吧”、“这个应该这样去实现”，更有甚至在聊需求的时候会深入聊到技术上如何去实现。
懂点技术有利于在跟程序员沟通的时候换位思考，评估需求落地风险，但又很容易让产品经理越俎代庖，对技术实现方案过多介入。
在提需求之前先跟程序员有线下沟通能够提升你的需求合理度和风险控制能力，但不要讨论技术实现细节。技术是程序员们所擅长的东西，信任他们，你要做的就是，倾听、欣赏他们的方案，不推翻，只提建议。
产品经理不是光鲜亮丽的角色，也只是团队中的一员，跟大家荣辱与共，同享成败。所以，你们互相承担彼此变化带来的后果，你们是同事、是队友、更是朋友。
福利大放送，送送送不停：