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

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

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

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

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

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

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

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

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

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

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

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

01 非X沟通fǎ则

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

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

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

02 与开发沟通fǎ则

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

总的fǎ则是这样的:

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

1. 说出困难

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

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

错误事例:我要加个需qiú。

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

2. 急客户所急

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

如果能X自己的cāo作感受到,就让他们按着步骤cāo作一下,会有更深的感受。

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

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

3. 探讨解决方案

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

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

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

我说:但是我们不大xí惯用tab键,上下箭头X可以吗?

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

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

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

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

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

4. 约定完成时间

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

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

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

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

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

5. 额外技巧

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

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

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

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

03 沟通中的心理战术

1. 晓之以理

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

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

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

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

2. 动之以情

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

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

3. 赞美对方

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

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

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

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

4. 尊重对方

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

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

5. 互相理解

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

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

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

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

04 总结

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

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

建议关注收zàng文章,尝试练xí,也能根据自己面对的开发的特点,来适当调整,找到适合自己的方fǎ。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 学会这4步,让开发心甘情愿加需求 https://www.xiongfawang.com/3727.html

常见问题

相关文章

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

分享本文封面