一边是需求提供方，一边是需求实现方，产品经理和程序员仿佛是「天敌」的关系。
有沟通就会有问题，有问题就可能会有矛盾。由于工作方式、工作内容、实际经验、个性等多种因素上都存在差异，每个产品经理的职业生涯中都会遇到与程序员产生沟通上的问题。
一、产品经理和程序员之间到底有什么沟通上的问题？
比如：有些产品经理没有产品的决策权，往往是需求的传话筒，是个需求转达者的角色，开发在质疑需求的合理性时，产品经理直接将锅甩给了需求的来源者，用“这是某某确定要做的需求”这类话去回复开发，由于产品经理没有产品的决策权。这也会需求者的需求多次变更，导致开发硬着头皮反复反工，甚至带着情绪去编码，这无疑会加深两者的矛盾。
比如：有些产品经理没有将自己以为的常识性产品功能细节告诉开发，也没有在产品原型中明确说明。开发以自己的经验去编码，由于两者对同一个功能的认知并不一致，导致开发出来的产品功能与产品经理预期的并不一致，导致双方互相扯皮。
再比如：产品经理往往在开发阶段和程序员去讨论具体方案的实现细节问题，产品经理自己觉得很基础的功能或改动，在开发眼里往往就是系统的大改造。
……
产品经理和程序员在沟通上的问题不胜枚举，但核心冲突是“有限的开发资源”与“无限的产品需求”之间的矛盾。
要解决这个问题，要么提供更多的开发资源，也就是招更多更合格的工程师；要么就让产品经理对自己的行为做更多限制，让产品决策和产品设计方案尽量符合市场和用户需求，尽量合理。
但显然这条路绝大部分企业并不行得通。对于开发者，提供更多的开发资源意味着企业要开发成本；对于产品经理，对其行为的限制有太多不可控因素，一个决策的很可能是涉及多方、多种因素的结果；产品经理的个人经验、认知水平、风格等因素也各不相同。
而且，显然实际工作中，情况还要比这复杂的多。
二、站在程序员的角度，看产品经理应如何和开发沟通
双方的矛盾不可能消除，但站在程序员的角度，产品经理如果能做到以下几点，一定能够减少和程序员之间的沟通问题甚至是矛盾。
（1）产品经理要点到为止，不越俎代庖。
产品经理尽量不要与开发讨论具体的实现方案上的细节问题，专业的事情交给专业的人去做，给与充分的信任。
一些技术出身的产品经理经常会与程序员讨论需求的具体实现方式的问题，产品经理认为自己的技术方案更适用，导致讨论结果不欢而散。程序员对技术发展的认知，个人技术经验、技术专业程度等方面大概率比技术出身的产品经理更专业。
要相信，每个程序员都是自己代码的「产品经理」。
（2）产品经理要多了解技术基础知识。
对于一些非技术出身或没有技术背景的产品经理而言，由于对技术知识的缺乏，很可能陷入学习技术知识的细节中。产品经理需要了解基础知识，并不需要知道实现细节。产品经理学习技术知识的目的是为了为更合理的设计产品服务，为更好的团队沟通服务。
对于一些非技术出身或者需要学习技术的产品经理，非常推荐唐韧的《产品经理必懂的技术那点事儿》，这本书详细介绍了产品经理工作需要用到的技术知识，非常全面且简单易懂。
（3）没有程序员希望经常被打扰。
专注的时候工作效率一般是最高效的。在程序开发阶段，产品经理一定要尽可能少的打扰编码中的程序员。除了一些紧急且重要的需求，需要及时与开发沟通。其他的需求产品经理可以适当划分优先级后，跟开发约定时间后，集中时间去讨论。
（4）多给程序员时间和空间。
具体到细节，程序员与产品经理的目标很可能是迥异的，甚至可能是相反的。如产品经理要求先做一个功能，尽快上线，这一需求即使普通人也能理解。
但程序员考虑的不仅仅是需求本身，还要考虑上线后的维护、升级等，而这部分不懂技术的产品经理是难以理解的，即使是懂技术的产品经理，可能也会觉得实现起来是简单的，其中的艰辛和沉重就只有程序员能够体会了。
产品经理要给程序员预留出合理的修整时间。一定不要把研发时间就当作完成时间。研发功能只是一部分，测试、改 BUG 以及处理意外情况的时间都要预留出来。
有两种情况要多预留出修整的时间。
一种是研发团队自己对功能没有把握，可能是全新的功能，可能是比较难做的功能，可能出现许多 BUG 和功能实现糟糕的情况，那就要多预留出时间。
另一种是产品团队表示对功能也有疑虑，比如在提供需求时表示这个功能很有可能要调整，或者对功能本身信心不足，那也要多留时间做调整。
（5）注意沟通的问题方式和方法。
程序员喜欢按照既定的需求优先级和产品方案有序的工作。产品经理给到开发的需求一定要是合理划分优先级的，版本需求的提供与团队的开发节奏尽量保持一致；遇到问题先分析、定位问题，而不是遇到问题先把问题直接退给开发，然后催着开发短期内加急处理。
（6）产品需求变动及时告知，最好给与变更的背景说明。
我见过太多的产品需求文档更改之后没有及时告知开发，导致测试验收阶段的需求与产品预期需求不一致的情况。产品经理不要想当然的以为改动的需求开发一定会看，产品经理的需求变动一定要及时告知相关开发相应的改动，有时候需求的变动可能就是简单的一句话，及时的沟通可以避免后期的大改动和双方推诿扯皮。
（7）对问题要有自己的判断。
产品经理接收到的需求一定要有自己的清晰判断，哪怕是很小的需求，到产品经理这里必须经过理性分析后，再安排开发进行处理。
以bug为例，很多时候一线或者客户反馈的“bug”极有可能是对系统的不熟悉，对系统的配置性错误导致的问题，并非是系统bug。产品经理作为需求处理的最后一道防线，提交给开发要做的一定是确定的事实，提交一个非bug需求给到开发去处理，不仅会浪费开发时间，还有质疑产品经理对业务的熟悉度和专业性。
产品方案提交给开发前，产品经理至少应该明确的问题：
你提这个需求是要为谁解决什么问题？
这个问题是否客观存在？
（退一步讲，如果客观存在）你为什么觉得你的解决方案可以解决这个问题？
除此之外你想过其他解决方案吗？你为什么觉得这个方案是最优的？
如果你连这些基本问题都没有想过或是想清楚，被动等着开发去问的时候才去思考，结果可想而知。
（8）沟通需求、需求文档要尽量详细明确。
这个是产品经理基本功，也是经常容易被忽视的一点。
沟通需求一定要有目的，要具体，否则多半是浪费开发的时间；需求文档一定要详细并且明确无歧义，具体文档详细到什么程度，可根据每个团队的风格、默契程度确定。如果没法确定，那就说明的越细越好。开发在编码的过程其实就是细节的实现过程，产品经理在细节上深入思考后和程序员沟通会更加顺畅。
（9）平等、尊重与理解。
从归属部门来看，产品经理一般属于产品部，程序员属于研发部，归属部门上不同，但都处同一个工作流上。
从工作流程来说，产品经理处于需求的上游，程序员处于需求的下游，双方对于用户、需求、业务的理解程度有很大的不同，程序员在理解需求时有问题太正常不过，有问题时产品经理应该及时给与耐心的回答。
尊重程序员的工作成果，涉及需求改动甚至需要砍掉的需求，尽可能跟开发说明白为什么。毕竟谁也不想自己费了很长时间、花了很大气力做的东西，因为产品经理一个未经思考的决定改动。
要让程序员从心理上认同做这件事的价值，程序员没有理由拒绝一个合理的需求，如果需求能给用户或者企业带来价值，或是体验上的提升，即使开发量很大或是难度很大，程序员也会激情满满。
有许多经验帖都谈到产品经理与程序员的矛盾症结在于改需求，其实改需求只是表象，互联网本来就是一个快速变化的行业，改需求不可避免，根源在于产品经理是否有独立思考的能力和意识。
改需求是人云亦云，是老板Push，还是实践过后从观察数据洞悉人性得来的深刻启发，这里大不相同。
因此产品经理除了要当团队的连接器之外，还得锻炼自己成为团队的大脑，只有你把需求想踏实了，想细致了，想全面了，才有足够的底气去应对各方各面的挑战，在程序员面前更具信服力。
我自认为优秀的产品经理都是相对清闲的，因为前期的需求文档和原型图都写得非常细致了，预知研发人员会问什么问题，都在原型图上醒目的标识，让研发人员很少甚至是无需过问产品经理，从此产品经理可以在于研发的纠缠中解放出来，真正去想长远的规划。
产品经理最主要的能力之一就是共情能力，遇到沟通问题或是矛盾、冲突时，站在程序员的角度思考下自身可能存在的问题，相信你会和程序员的沟通会更加顺畅。
-END-