产品经理如何与研发打交道?(速看这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呢?”
  • 研:“好像这样也可以。”
  • …….

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

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

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

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

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

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

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

最后的话:

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

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

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


本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部