产品经理如何与研发打交道？（速看这10条沟通秘诀）

产品经理是一个需要经常与研发人员进行频繁沟通的岗位，挂着“经理”级别的头衔，却没有指挥命令别人的实权。只能靠一张嘴，去贩卖你的产品理念，让研发部门的小伙伴帮你去实现。

如果你在产品研发过程中总是充斥着各种“吵架”，那一定是你的沟通方式出了问题。

专业技术如果是硬实力，沟通能力就是软实力，软硬兼备，才能成为一个合格的产品经理。

一、产品和研发之间存在的沟通问题

作为产品经理，研发人员说的让你记忆最深刻的一句话是什么呢？

• “这个需求实现不了。”
• “这个改动太大了，做不了。”
• “这个需求文档没有定义啊！”
• “这个得重新做了。”
• “这个功能设计的不合理。”
• “这是第三方的问题，我解决不了。”
• “xxx帮忙催一下啊！”——“为什么要我催啊？”——“你是产品经理啊！”
• ………

那么，反过来，研发人员内心对产品经理的独白又是什么呢？

（都不算内心独白，大部分研发都是耿直boy，有啥不爽都是对着你的脸开喷，从不需要考虑你的感受，就是这么屌炸天！）

• 又要改需求，我X！
• 产品经理整天都在干啥啊，需求写的这么垃圾。
• 我跟你解释这么多干嘛，你又听不懂，我懒得跟你解释。
• 这么奇葩的需求还非得让我写代码实现！
• “这个需求很简单，怎么实现我不管，明天就要上线。”——你个沙雕。
• ………

程序员吐槽大会中有人说，产品经理和程序员就像唐僧和孙悟空：

• 唐僧：“我就要取经。”
• 孙悟空：“那得杀了白骨精变成的妖怪。”
• 唐僧：“不能滥杀无辜。”
• 孙悟空：“那怎么办？”
• 唐僧：“我不管，我就要取经。”

这段话多么形象的描述出产品和研发之间的矛盾，虽然目标一致要取得真经（产品上线），但取经路上总是充满了争执。

沟通就是解决你和研发之间diss不断的一种有效方式，掌握一定的沟通技巧，可以让你与研发和平共处在一个“水泥格子间”这种压抑的空间里，保持心情愉悦。

二、分享10条和研发的沟通经验

1. 明确团队作战的目标

• 研：“这个需求开发预计要两周的时间。”
• 产：“就这么简单的功能，要那么长的时间嘛？”
• 研：“你看下你设计的功能多复杂，涉及到的改动点很多。”
• 产：“我觉得你在框我，最多一个星期就可以完成。”
• 研：“那我做不了。”
• 产：“那我不管，一个星期就得上线。”
• 研：“你不能每次都这样，这么短的时间怎么做？”
• 产：“我哪里有每次，明明就是你们故意把时间估长。”
• 研：“那你需求要设计的这么傻B我有什么办法？”
• 产：“我需求设计成什么样，要你来教吗？我是产品经理我说了算！”
• 研：“你是产品经理了不起啊，你要能写代码你来写呀！”
• ………

产品经理在跟研发的沟通过程中，双方经常会因为观点的分歧而发生争论，有时候争的面红耳赤、口吐芬芳，甚至都开始人身攻击，从否定这件事情，到否定对方做人有问题。

最后，也不知道争论的问题是什么，演变成了一场完全没有意义的“口水仗”。

为什么会出现这种毫无意义的“口水仗”呢？

因为，没有目标传导，大家做事情的方向不一致。研发认为做产品是给产品经理做的，而不是给客户做的，不是为了公司的业绩去做的。

为此，就很容易出现，产品经理想什么是你产品的事，我研发想怎么做是我研发的事。彼此不在一个方向上使劲，甚至还会在对立的方向上相互较劲。

所以，在做产品之前，你需要告知研发团队做这个产品的目标是什么，做这个产品可以给客户带来哪些价值，给企业带来哪些收益。

这样大家才能“心往一处想，劲往一处使”。

2. 讲需求告知前因后果

• 产：“这个功能你怎么给我改成这个样子了？谁让你改的？”
• 研：“我觉得改成这样数据结构比较合理，逻辑上也更简单。”
• 产：“问题是你改成这样子，客户用不了啊！”
• 产：“客户是因为xxxxx，所以才需要做这个功能。”
• 研：“啊！你开始没跟我讲，我怎么知道？”
• 产：“这种东西还要讲嘛？”
• 研：“废话，我又不是客户。”
• …….

在一个需求的决策链条上，产品经理掌握了来自客户、销售和领导提供的各种信息，清楚自己为什么要这样做功能设计。而作为需求链最末端的程序员，因为情报信息的闭塞，就只能自己去意淫产品的使用场景，这样就容易做出来的程序偏离实际，带来糟糕的用户体验。

因此，产品经理在给研发讲需求的时候，一定要结合客户实际使用场景去介绍，为什么功能要这样设计，这样研发才不会按照自己的理解去进行架构设计。

最好的方式是可以讲一个故事：什么人，在什么时间，什么地点，做了一件什么事情，遇到了什么样的问题，希望怎么样去解决，不解决会带来什么样的后果。

故事讲完了，研发对这个功能也就理解了，在做这个开发的过程中，也就知道如何去设计自己的程序更好的去解决客户问题了。

3. 养成信息同步的习惯

• 产：“这个功能怎么做的和原型设计的不一样啊？”
• 研：“我不是问过你，这么改嘛？你同意了。”
• 产：“我什么时候同意了？”
• 研：“我不记得了，反正是问过你的。”
• 产：“那我不管，得给我按照原型来做。”
• 研：“靠，你这不是坑我嘛！”
• ………

需求在开发过程中进行来回调整，是再正常不过的事情。为什么会经常发生上述的争吵呢？因为，没有证据死无对证，各说各有理。

不管做了多么细小的需求变动，最好第一时间去更新相关的需求文档，并进行邮件的信息同步。

产品出了问题，即使是研发的原因，产品经理也都需要为之负责。如果有工作邮件存档，那这个责任就不是“无限”的，而是可以明确责任界限的。

同时，千万不要有“担心打扰到领导”这种多余的顾虑。所有的工作邮件，都建议你抄送给上级。如果是对外的邮件，或者是涉及重要敏感内容的邮件，还需要抄送给更上一层的领导。

一方面，是为了“有锅一起背”；另一方面，也是为了确保，如果自己“犯傻”，能有人及时发现并提醒。

4. 用上做产品的同理心

• 研：“这个功能我们评估了一下，要做成这样至少要一个星期的时间。”
• 产：“那我不管，这是你研发的事情，我只管功能实现。”
• 研：“这个功能想和你讨论下怎么实现的问题？”
• 产：“我不是做技术的，怎么实现是你们的事情。”
• 研：“就是和你交流下，看下这样做可不可行。”
• 产：“我都说了，怎么做是你们技术的事情，不要找我。”
• 研：“那好吧！”
• …….

在研发的过程中，确实会遇到研发人员对于功能理解不到位，对于实现方式有疑虑的情况。这种时候，研发就想找个人一起讨论一下，不一定是要你改需求，或许只是想和你交流下可行性。

当你可以站在研发人员的角度去思考如何实现，就可以积极去贡献自己的想法和思路，一起去探讨出更优的技术方案。

换位思考，也有可能发现，是自己的需求文档描写的不够详细，描述的不够清晰，容易让人不好理解，甚至产生误解。

所以，不要和研发在岗位职责上把界限划的太清，大家组成一个团队就是要一起去解决问题，一起去保障产品的顺利上线。

5. 不做信息的“搬运工”

• 研：“X工，帮我问下xx他们的接口文档什么时候可以给出来？”
• 产：“这个问题你不可以自己去问嘛？”
• 研：“谁叫你是产品经理啊，当然是你去问了。”
• 产：“他们说没有那么快，还需要一周左右的时间。”
• 研：“那你再帮我问下，可不可以先提供xx这部分的接口，我先看下。”
• 产：“你有问题能不能一起说完？”
• 研：“我也是刚刚才想到的。”
• 产：“我没空，你自己去问吧！”
• 研：“那这个功能就不做了。”
• …….

如何高效的开展工作，如何让自己的时间产生的价值收益最大化？首要避免的就是去做信息的“传递员”、“搬运工”。

最好的方式就是建群，遇到相应的问题@相关的人员，需要哪些资源@相关的人员。

尽量避免产品或项目上的事项，进行一对一的私聊，最好都在群里或发邮件沟通讨论，让所有人都可以看见。

这样既可以提升沟通的效率，也能减少因为自己脑子突然短路，没人提醒带来的风险。

6. 把领导充当“挡箭牌”

• 研：“这个需求有点复杂，改动起来的工作量太大。”
• 产：“你是想说什么问题？”
• 研：“能不能不要这样做？”
• 产：“没办法，领导要求要做成这样，要改你问领导去。”
• 研：“好吧，就当我没说。”
• …….

一般来说和你沟通的都是同一级别的，说白了干活的都是小兵，你派单，他干活，老板发钱。

所以，当遇到不好沟通解决的问题时，把老板“端”出来，很多问题就迎刃而解了，毕竟没有到要离职的份上，谁没事会头铁到去找老板理论。

就算这个需求是你提的，你也可以说是老板要的，总不至于会有研发人员真的去问老板，你为什么要提那样的需求？

当然这个“核武器”，不能常用，更不能乱用，要不等到真正要用的时候就失去了威慑力。一定是确实遇到沟通不了，僵持不下的时候，才把老板“搬”出来。

7. 一定要有“资源”意识

• 产：“大家停一下，这个需求客户要求改一下。”
• 研：“啊？我都开发完了，准备提测了。”
• 产：“那没办法，客户说要改的。”
• 研：“为什么一开始不问清楚，这个时候来改，前面的不都白做了嘛？”
• 产：“我也没有办法～”

……..2000 years later……….

• 产：“停一下，客户后面还是觉得之前那个方案比较好，要改回去。”
• 研：“我靠，你这不是玩我嘛？”
• 产：“哎，说清楚，不是我玩你，是客户要这么玩。”
• 研：“那就是你需求没有搞清楚。”
• 产：“我是产品经理还是你是产品经理？”
• 研：“你是产品经理，你牛逼！”
• ………

做产品研发的过程中，最怕的就是改需求，更可怕的是来回改需求。

这个时候，产品经理就得有“资源”意识，每一次需求的改动都是有成本，不能总是把刀口向内给研发一顿嚯嚯，也得硬气几回把刀口向外跟客户讲讲道理。

要尊重研发人员的工作成果，涉及到需求改动甚至需求要砍掉的时候，尽量要跟大家说明白为什么，多说几句大家辛苦了的话。

这个时候要是再摆出一副“地主”心态，不管大家的死活，只管收租要成果，早晚大家不得高举“打倒地主老财”的大旗，拿你祭天解气。

8. 别拿完美主义“作祟”

• 产：“这么明显的bug都测试不出来吗？怎么测试的？”
• 研：“我在测试环境的时候没有出现啊！”
• 产：“现在就是用户使用的时候，出现了，别跟我说测试环境。”
• 研：“那你验收的时候，怎么没有发现？”
• 产：“我就是不验收，你也得保证产品100%没有问题，要不要测试干什么。”
• ………

做产品经理时间长了你就知道，项目过程中总会伴随着各种问题，即使测试了很长时间，在产品上线后还是会出现一些非常明显或者莫名其妙的bug。

这个时候就立马甩锅给研发，没有任何意义，想着如何快速修复bug，避免后续再出现类似的问题才是应该去做的事情。

在产品开发的过程中，总会因为资源有限，时间紧迫，面临一些功能的取舍问题。如果一定要去强迫研发人员按时按质完成产品的上线，铁定会导致研发人员产生抵触的情绪，最后即使按时上线了，产品质量也是小坑不断，大坑难填。

你如果不能保证产品需求100%不改动，并且没有逻辑漏洞，那就不要去要求研发和测试100%不出错，没有bug。

9. 化身客户催项目上线

• 产：“这个功能还有多久上线？”
• 研：“还要评估下这个功能怎么实现，现在给不出时间。”
• 产：“能不能给个大概的时间？”
• 研：“给不了。”
• 产：“这个月底上线，可不可以？”
• 研：“时间太短了，上线不了。”
• 产：“下个月初客户要举行一个发布会，到时候会有上级领导来参观考察。”
• 产：“客户发布会的时间已经定了，改不了。”
• 研：“那既然这样，就只能周末加班搞了。”
• …….

在做项目研发工时评估的时候，产品经理总是会担心研发人员虚报工时，糊弄自己。

明明一天可以做完的内容，非得说三天才行。而客户要求上线的时间又摆在哪里，不能按时上线的话，到时候销售还不得跟个“你欠他钱”似的“催死你”。

这个问题最好的解决方式，就是把你自己化身为客户，说明下为什么要在xxx时间内上线，不上线会有什么问题风险，按时上线会有收益好处。

比如，领导要来视察；项目资金必须要在xxx时间节点付不出；xx月xx日正好是一个特殊的日子，公司需要借此时机宣传造势把产品推出去。

当然，还是会存在这种情况：就算把刀架在脖子上，把研发杀了，在客户规定的时间内也上不了线。

怎么办呢？就不要去对研发“以死相逼”了，打工的何必为难打工的。

换做你是客户，你是不是就可以有一些别的方式来解决。

比如，如果在领导视察的规定时间实在完不成产品上线，能不能先上线部分核心的功能，能不能先完成前端页面的开发，能不能用UI效果图先放上去呈现效果，先度过了领导视察这一关，后面再慢慢开发。

10. 必须得懂点技术语言

• 研：“这个功能你这样设计不好做。”
• 产：“怎么个不好做？”
• 研：“这里每修改一次，我都要从后端接口获取一次数据。”
• 产：“为什么不可以先把数据保存在前端呢？”
• 研：“好像这样也行。”
• 研：“还有，这个数据能不能不要做成实时显示的？”
• 产：“为什么？”
• 研：“因为计算结果都是后端返回给我的，后端数据都是当天晚上凌晨才会生成？”
• 产：“为什么不可以在触发这个按钮，就去请求后端的数据呢？”
• 产：“为什么一定要等到凌晨去生成数据，不可以隔10分钟就跑一个batch呢？”
• 研：“好像这样也可以。”
• …….

产品经理在和研发的沟通过程中，实际上讨论最多的并不是业务需求，而是技术实现细节。

但凡你不了解一些技术实现的方式，不知道技术相关的名词术语，就有可能出现，鸡同鸭讲的“无厘头式”对话。

产品经理说白话，研发人员说黑话。你说你的，他说他的，说的都不是一个事情，最后争执不下，就不了了之。

产品经理可以不会上手写代码，但你至少得能听懂研发在说啥，能理解功能背后的技术实现原理。

要啥都不懂，研发人员一句“技术实现不了”，你就得屁颠屁颠回去改需求，回过头还得感谢研发的提醒。被人卖了还帮着数钱，就是这么傻白甜。

真要遇到自己不懂的技术术语，就问下研发人员，就去百度一下，慢慢的你不就懂了吗？慢慢的你不就可以和研发在同一认知维度上对话了吗？慢慢的你不就可以参与到技术实现方式的讨论和意见发表了吗？

当然，要避免的一种情况：当你懂一些技术之后，认为自己的技术方案更合适，要求研发采用自己的方式去做，最后出了问题，就只能是找你背锅。要相信，每一个程序员都是自己代码的产品经理。

最后的话：

和研发的沟通其实不需要什么套路，不需要纠结说如何做到跟不同类型的人去打交道，因为你一直都是在和“需求”打交道。

只要你站在用户的角度，本着产品按时按质按量上线的目标去做沟通，就不会有那么多的争论，更不会搞得办公室的“剑拔弩张、战火纷飞、硝烟弥漫”。

你有什么和研发沟通的经验呢？写出来给大家看看吧。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！