学会这4步,让开发心甘情愿加需求

4 评论 7431 浏览 43 收藏 14 分钟

本文根据非暴力沟通原则,整理出了一套和开发沟通的原则:说出困难、急客户所急、探讨解决方案、约定完成时间。

产品上线版本是有计划的,一般是半个月或者一个月一次。但产品需求先行,在上一个版本中期就要确定好下一个版本的内容。

那么,假如1个月1个版本,客户在我们确定下一版本内容后提出的需求,往往要在1.5-2个月之后才能上线。但客户常常会有比较紧急的小需求,需要我们快速上线。

一个方法是砍掉既定的需求,作为产品经理来说,其实是不愿意的,确定的版本会预先通知客服、销售和关心的客户,砍掉容易引起其他人的不满。那还有一种方式就是加需求了。

于是乎,产品经理和开发的博弈就开始了。开发当然不希望增加工作量,在原本就需要加班完成的情况下再增加时间。他们经常说的三句话:

  1. “来不及。”
  2. “简单?你来做啊。”
  3. “当初怎么不设计好呢?”

战情似乎一触即发。先不要动怒,想想自己是怎么和他说的?

上来就说:“能不能加个需求啊,很急。” 开发当然条件反射:不能,哪次不急。

质疑他:“这功能很简单,别人半天就做完了,你为什么要2天?” 开发当然想:那你做啊。

压迫他:“重点客户要的,老板说了要加。” 开发当然更不乐意啦:你产品设计有问题,还要我善后。

是不是产品经理和开发就是天生的对头呢?其实不是,开发也可以心甘情愿地加需求。

01 非暴力沟通法则

大家应该都听说过《非暴力沟通》这本书,这本书很简单,只用了4步就解决了绝大多数沟通上的问题:

  1. 描述事实。讲述客观事实,不要带入自己的主观观点和评论。
  2. 表达感受。描述自己对于这个事实的感受,让对方感同身受。
  3. 明确需求。表明自己想要如何处理这个问题,获得什么样的结果。
  4. 提出请求。请求对方采取行动满足自己的需求。

经过实践证明,这4步也能很好的解决和开发的沟通问题。

02 与开发沟通法则

我们稍稍将上面的法则改变下,变成一套更适合和开发沟通的法则。

总的法则是这样的:

下面对各步做一个详细的说明:

1. 说出困难

产品经理告诉开发目前面临的难题。只说客观事实,不要带主观评论。

可以用场景分析法来描述:什么「人」在什么「时候」在什么「地方」出于什么「目的」做了「什么事」,遇到了「什么困难」。

错误事例:我要加个需求。

正确事例:中医给患者看完病后,会在我们系统里面开立中药处方,一般一贴中药会有20-30几种药。每次在系统里面新增完药品后,都需要手动去点击一下填写药品的单次数量,填完后再点击一下去新增药品,开立处方要花费2分多钟的时间,比手写花费的时间还要多。现在医生看同样多的患者,需要加班。

2. 急客户所急

因为开发不是客户,很多时候告诉他:客户很急,如果不解决,日常工作都受到严重影响了。他未必能理解。我们在上面已经描述了客户的场景和困难,就要努力把开发带入那个环境中,让他们感同身受,急客户之所急。

如果能通过自己的操作感受到,就让他们按着步骤操作一下,会有更深的感受。

比如说上面的开药,给开发一张中药的处方单,让他照着单子开一遍药,连着看诊3个患者。开发在开完第一个方子后就忍不住吐槽:“这太麻烦了。每天看诊十几二十个患者,太累了。”

当开发说出这句话时,就成功了一半。

3. 探讨解决方案

虽然开发已经理解了客户的心情,但让他心甘情愿的加班做还差那么小小的一步。我们不要直接告诉他需求是什么,不妨让他加入你的思考,一起探讨解决方案,甚至引导他提出需求。

比如对开发说:你在开处方的时候,是不是觉得每次输入内容都要用鼠标点击一下,有点手忙脚乱的感觉。我看你们平时操作电脑都不用鼠标,键盘控制就可以了,能不能也让客户只操作键盘就可以了?

开发回答:那当然可以了,浏览器自带的切换键是tab键,每次按一下键,光标就会自动移到下一个输入框。

我说:但是我们不大习惯用tab键,上下箭头控制可以吗?

开发会说:箭头控制不大好做,我可以通过回车键来控制,这也是比较常用的。

我心想,本来就是想让你做回车键切换。

顺势接过来:这确实比我想的那个办法实现简单,操作也挺方便的。能不能做到新增药品以后直接光标到剂量的输入框中,减少按回车键的次数呢?

开发说:这个可以啊,我看你给我的处方单上,后面服药要求都很少填,我能控制就在新增和剂量处切换,这样按键次数更少了。

我心想,这就是我最想要的结果啊。

4. 约定完成时间

在产品经理和开发的共同努力下,我们就需求达成了一致。最后就要逼宫了,敲定完成时间。这时开发心里已经没有那么抗拒了。

虽然很不好意思,但还是要问一句:你做这个要多长时间,能跟着这个版本一起上线吗?

开发会思考一下,不是很复杂的事情,一个人半天内能做完的,会说:我可以加会班,把这个塞进去。

如果有点复杂的,可能需要其他人配合的,会说:这个麻烦一点,现在还在赶版本内的东西,你等联调的时候再和我说下,我有时间就做进去。要是实在来不及,等这个版本上线后,再给你发一个小版本上线。

虽然有时候并不能拿到确切的上线时间,但至少开发已经答应我们会加进去做了。再教大家一个额外的小技巧,让功能尽早上线。

5. 额外技巧

俗话说:会哭的孩子有奶吃。我发现,那些越是挑剔,老是找我们刺的客户,提出的需求越容易得到重视。

我以前是一个很乖的产品经理,开发说等联调的时候找他,我就在那时找,结果联调问题一大堆,自己改bug都顾不过来,更别提给我加需求了。

后来我就隔三差五的提醒他一下,问问他最近有没有空,记得有时间的话就做下那个需求,并表明不是催他,只是怕他事多忘了。提醒了几次以后,开发估计觉得也挺烦的吧,像欠了我什么似的,赶紧把需求做了。

有的人就会提出疑问,你这是给开发下套啊,他上了一次当以后,下次不就不好使了吗?实际上,下次还会好使的。我们从心理角度来分析下。

03 沟通中的心理战术

1. 晓之以理

我们会遇到这样的情况,领导说:你给我做个xx功能吧。也不告诉你为什么要做,使用场景是什么。我们就会怀疑,又在拍脑袋做决定了吧,我不觉得这个功能合适。

开发也会这样想:每次都是你说要做什么,我们就像是工具一样,老是说客户体验,客户要,但你也不是客户啊。

所以,在和开发沟通的时候,不要一开始就让他对你产生抵触心理,那后面不管说什么,都很难改变认知了。

这就是为什么要从说事实入手了,事实是双方都能认同的,能先降低心理防线。

2. 动之以情

虽然困难不尽相同,但是情感是共通的。让开发体会到客户的不便、着急,也会调动起他类似心情的经历,觉得这件事情是很有必要快速解决的。

这时开发的心理防线又低了些,后面再提出需求的时候,也会觉得顺理成章。

3. 赞美对方

需求是产品经理提出的,最终拍板的也是产品经理,但我们可以适当的提高开发的成就感。

比如说,让开发参与需求的讨论,多问问他,站在他的专业角度看,这个怎么实现会更好。有时候,他们会提出更加简单高效的方法。

也别忘了多给开发肯定。不管他们的方案是不是符合自己的初衷,先肯定他们的提出,更好的方案也要毫不犹豫的采纳,并赞扬他们。

不是有段时间很流行夸夸群吗,赞美能让开发和你站在同一战线。

4. 尊重对方

如果开发和我们说:你这设计的都是什么玩意啊。我们会怎么想:那你来设计啊?你怎么不来做产品?我们真的只是客户传话筒?

这也就难怪,我们在和开发说:这个很简单啊,你一会儿就改完了。开发会非常不高兴。如果你不想帮他写代码,就不要质疑他的能力。时间由他来定,如果觉得太长了,再商量下。

5. 互相理解

这是长久合作的基石。开发加需求是情分,不加是本分。要不是被客户逼疯了,尽量不要找开发加需求。

在加之前我们也要全面评估好,这个功能的大小,难度。如果明知道这个功能需要好几个人,花好几天做完,就不要去说了。大功能还是要按照正常的版本计划来规划,不然整个开发进程就乱了。

小需求也要把影响范围全部列出来,给到开发。不然可能改完出大bug了,就得不偿失了。

如此一来,开发也能理解,我们也是无奈才找他们加需求的,能帮助就尽量做了,哪怕稍微加会儿班。

04 总结

与开发的沟通法则是我在成千上百次和开发的沟通中总结出来的,也是一直使用的较为有效的方法。

按这4步来:说出困难,感化开发,探讨方案,约定时间。

建议关注收藏文章,尝试练习,也能根据自己面对的开发的特点,来适当调整,找到适合自己的方法。

 

作者:司马特小队,丁香园高级产品经理。微信公众号:司马特小分队

本文由 @司马特小队 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作为产品,还是要做足功课,总加需求就是说明基本功不到位

    来自北京 回复
  2. 都是要被怼

    来自广东 回复
  3. 相互理解才是根本,互相帮助,统一战线

    来自浙江 回复
  4. 赞,我有点同情开发了,实际上无论你说的让对方对么开心,加班时间实际一点没少,不过心情好了一些

    来自北京 回复