产品经理这个岗位经常需要和研发人员进行沟通，这个过程中，产品经理就需要掌握一定的沟通技巧了，有效的沟通才可以最大程度地提升效率。这篇文章里，作者总结了一些沟通秘诀，一起来看。
产品经理是一个需要经常与研发人员进行频繁沟通的岗位，挂着“经理”级别的头衔，却没有指挥命令别人的实权。只能靠一张嘴，去贩卖你的产品理念，让研发部门的小伙伴帮你去实现。
如果你在产品研发过程中总是充斥着各种“吵架”，那一定是你的沟通方式出了问题。
专业技术如果是硬实力，沟通能力就是软实力，软硬兼备，才能成为一个合格的产品经理。
作为产品经理，研发人员说的让你记忆最深刻的一句话是什么呢？
那么，反过来，研发人员内心对产品经理的独白又是什么呢？
（都不算内心独白，大部分研发都是耿直boy，有啥不爽都是对着你的脸开喷，从不需要考虑你的感受，就是这么屌炸天！）
程序员吐槽大会中有人说，产品经理和程序员就像唐僧和孙悟空：
这段话多么形象的描述出产品和研发之间的矛盾，虽然目标一致要取得真经（产品上线），但取经路上总是充满了争执。
沟通就是解决你和研发之间diss不断的一种有效方式，掌握一定的沟通技巧，可以让你与研发和平共处在一个“水泥格子间”这种压抑的空间里，保持心情愉悦。
产品经理在跟研发的沟通过程中，双方经常会因为观点的分歧而发生争论，有时候争的面红耳赤、口吐芬芳，甚至都开始人身攻击，从否定这件事情，到否定对方做人有问题。
最后，也不知道争论的问题是什么，演变成了一场完全没有意义的“口水仗”。
为什么会出现这种毫无意义的“口水仗”呢？
因为，没有目标传导，大家做事情的方向不一致。研发认为做产品是给产品经理做的，而不是给客户做的，不是为了公司的业绩去做的。
为此，就很容易出现，产品经理想什么是你产品的事，我研发想怎么做是我研发的事。彼此不在一个方向上使劲，甚至还会在对立的方向上相互较劲。
所以，在做产品之前，你需要告知研发团队做这个产品的目标是什么，做这个产品可以给客户带来哪些价值，给企业带来哪些收益。
这样大家才能“心往一处想，劲往一处使”。
在一个需求的决策链条上，产品经理掌握了来自客户、销售和领导提供的各种信息，清楚自己为什么要这样做功能设计。而作为需求链最末端的程序员，因为情报信息的闭塞，就只能自己去意淫产品的使用场景，这样就容易做出来的程序偏离实际，带来糟糕的用户体验。
因此，产品经理在给研发讲需求的时候，一定要结合客户实际使用场景去介绍，为什么功能要这样设计，这样研发才不会按照自己的理解去进行架构设计。
最好的方式是可以讲一个故事：什么人，在什么时间，什么地点，做了一件什么事情，遇到了什么样的问题，希望怎么样去解决，不解决会带来什么样的后果。
故事讲完了，研发对这个功能也就理解了，在做这个开发的过程中，也就知道如何去设计自己的程序更好的去解决客户问题了。
需求在开发过程中进行来回调整，是再正常不过的事情。为什么会经常发生上述的争吵呢？因为，没有证据死无对证，各说各有理。
不管做了多么细小的需求变动，最好第一时间去更新相关的需求文档，并进行邮件的信息同步。
产品出了问题，即使是研发的原因，产品经理也都需要为之负责。如果有工作邮件存档，那这个责任就不是“无限”的，而是可以明确责任界限的。
同时，千万不要有“担心打扰到领导”这种多余的顾虑。所有的工作邮件，都建议你抄送给上级。如果是对外的邮件，或者是涉及重要敏感内容的邮件，还需要抄送给更上一层的领导。
一方面，是为了“有锅一起背”；另一方面，也是为了确保，如果自己“犯傻”，能有人及时发现并提醒。
在研发的过程中，确实会遇到研发人员对于功能理解不到位，对于实现方式有疑虑的情况。这种时候，研发就想找个人一起讨论一下，不一定是要你改需求，或许只是想和你交流下可行性。
当你可以站在研发人员的角度去思考如何实现，就可以积极去贡献自己的想法和思路，一起去探讨出更优的技术方案。
换位思考，也有可能发现，是自己的需求文档描写的不够详细，描述的不够清晰，容易让人不好理解，甚至产生误解。
所以，不要和研发在岗位职责上把界限划的太清，大家组成一个团队就是要一起去解决问题，一起去保障产品的顺利上线。
如何高效的开展工作，如何让自己的时间产生的价值收益最大化？首要避免的就是去做信息的“传递员”、“搬运工”。
最好的方式就是建群，遇到相应的问题@相关的人员，需要哪些资源@相关的人员。
尽量避免产品或项目上的事项，进行一对一的私聊，最好都在群里或发邮件沟通讨论，让所有人都可以看见。
这样既可以提升沟通的效率，也能减少因为自己脑子突然短路，没人提醒带来的风险。
一般来说和你沟通的都是同一级别的，说白了干活的都是小兵，你派单，他干活，老板发钱。
所以，当遇到不好沟通解决的问题时，把老板“端”出来，很多问题就迎刃而解了，毕竟没有到要离职的份上，谁没事会头铁到去找老板理论。
就算这个需求是你提的，你也可以说是老板要的，总不至于会有研发人员真的去问老板，你为什么要提那样的需求？
当然这个“核武器”，不能常用，更不能乱用，要不等到真正要用的时候就失去了威慑力。一定是确实遇到沟通不了，僵持不下的时候，才把老板“搬”出来。
……..2000 years later……….
做产品研发的过程中，最怕的就是改需求，更可怕的是来回改需求。
这个时候，产品经理就得有“资源”意识，每一次需求的改动都是有成本，不能总是把刀口向内给研发一顿嚯嚯，也得硬气几回把刀口向外跟客户讲讲道理。
要尊重研发人员的工作成果，涉及到需求改动甚至需求要砍掉的时候，尽量要跟大家说明白为什么，多说几句大家辛苦了的话。
这个时候要是再摆出一副“地主”心态，不管大家的死活，只管收租要成果，早晚大家不得高举“打倒地主老财”的大旗，拿你祭天解气。
做产品经理时间长了你就知道，项目过程中总会伴随着各种问题，即使测试了很长时间，在产品上线后还是会出现一些非常明显或者莫名其妙的bug。
这个时候就立马甩锅给研发，没有任何意义，想着如何快速修复bug，避免后续再出现类似的问题才是应该去做的事情。
在产品开发的过程中，总会因为资源有限，时间紧迫，面临一些功能的取舍问题。如果一定要去强迫研发人员按时按质完成产品的上线，铁定会导致研发人员产生抵触的情绪，最后即使按时上线了，产品质量也是小坑不断，大坑难填。
你如果不能保证产品需求100%不改动，并且没有逻辑漏洞，那就不要去要求研发和测试100%不出错，没有bug。
在做项目研发工时评估的时候，产品经理总是会担心研发人员虚报工时，糊弄自己。
明明一天可以做完的内容，非得说三天才行。而客户要求上线的时间又摆在哪里，不能按时上线的话，到时候销售还不得跟个“你欠他钱”似的“催死你”。
这个问题最好的解决方式，就是把你自己化身为客户，说明下为什么要在xxx时间内上线，不上线会有什么问题风险，按时上线会有收益好处。
比如，领导要来视察；项目资金必须要在xxx时间节点付不出；xx月xx日正好是一个特殊的日子，公司需要借此时机宣传造势把产品推出去。
当然，还是会存在这种情况：就算把刀架在脖子上，把研发杀了，在客户规定的时间内也上不了线。
怎么办呢？就不要去对研发“以死相逼”了，打工的何必为难打工的。
换做你是客户，你是不是就可以有一些别的方式来解决。
比如，如果在领导视察的规定时间实在完不成产品上线，能不能先上线部分核心的功能，能不能先完成前端页面的开发，能不能用UI效果图先放上去呈现效果，先度过了领导视察这一关，后面再慢慢开发。
产品经理在和研发的沟通过程中，实际上讨论最多的并不是业务需求，而是技术实现细节。
但凡你不了解一些技术实现的方式，不知道技术相关的名词术语，就有可能出现，鸡同鸭讲的“无厘头式”对话。
产品经理说白话，研发人员说黑话。你说你的，他说他的，说的都不是一个事情，最后争执不下，就不了了之。
产品经理可以不会上手写代码，但你至少得能听懂研发在说啥，能理解功能背后的技术实现原理。
要啥都不懂，研发人员一句“技术实现不了”，你就得屁颠屁颠回去改需求，回过头还得感谢研发的提醒。被人卖了还帮着数钱，就是这么傻白甜。
真要遇到自己不懂的技术术语，就问下研发人员，就去百度一下，慢慢的你不就懂了吗？慢慢的你不就可以和研发在同一认知维度上对话了吗？慢慢的你不就可以参与到技术实现方式的讨论和意见发表了吗？
当然，要避免的一种情况：当你懂一些技术之后，认为自己的技术方案更合适，要求研发采用自己的方式去做，最后出了问题，就只能是找你背锅。要相信，每一个程序员都是自己代码的产品经理。
最后的话：
和研发的沟通其实不需要什么套路，不需要纠结说如何做到跟不同类型的人去打交道，因为你一直都是在和“需求”打交道。
只要你站在用户的角度，本着产品按时按质按量上线的目标去做沟通，就不会有那么多的争论，更不会搞得办公室的“剑拔弩张、战火纷飞、硝烟弥漫”。
你有什么和研发沟通的经验呢？写出来给大家看看吧。
本文由@武林 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。