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

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

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

那么，假如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协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: