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