如何让开发心甘情愿加需求？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

产品和开发似乎总是站在两个阵营，一个要加需求，一个要实现需求。制定一个得到双方认可的需求文档已经相当不易，那么如果中途添加需求，有多大可能会被开发接受呢？答案不言而喻，作者在和开发的斗智斗勇中，总结出了一套方法论，按这四步走，与开发和平相处，顺利加需求。

作者：司马特小队

作者公众号：司马特小分队（ID：lifelaosiji）

题图来自 Unspalsh, 基于CC0协议

全文共 3668 字 3 图，阅读需要 8 分钟

—————— / BEGIN / ——————

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

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

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

还有一种方式就是加需求，于是乎，产品经理和开发的博弈就开始了。

开发当然不希望增加工作量，在原本就需要加班完成的情况下再增加时间，他们经常会这么反驳：

• “来不及。”

• “简单？你来做啊。”

• “当初怎么不设计好呢？”

战情似乎一触即发。

先不要动怒，想想自己是怎么和他说的？

上来就说：“能不能加个需求啊，很急。” 

开发当然条件反射：不能，哪次不急。

质疑他：“这功能很简单，别人半天就做完了，你为什么要2天？” 

开发当然想：那你做啊。

压迫他：“重点客户要的，老板说了要加。”

开发当然更不乐意啦：你产品设计有问题，还要我善后。

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

一、非暴力沟通法则

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

1. 描述事实：讲述客观事实，不要带入自己的主观观点和评论。

2. 表达感受：描述自己对于这个事实的感受，让对方感同身受。

3. 明确需求：表明自己想要如何处理这个问题，获得什么样的结果。

4. 提出请求：请求对方采取行动满足自己的需求。

实践证明，这4步也能很顺利解决和开发的沟通问题。

二、与开发的沟通法则

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

总的法则是这样的：

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

1. 说出困难

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

可以用场景分析法来描述：

什么「人」在什么「时候」在什么「地方」出于什么「目的」做了「什么事」，遇到了「什么困难」。

错误示例：我要加个需求。

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

2. 急客户所急

因为开发不是客户，很多时候告诉他“客户很急，如果不解决，日常工作都受到严重影响了”，他未必能够理解。

我们已经描述了客户的场景和困难，就要努力把开发带入那个环境中，让他们感同身受，急客户之所急。如果能通过自己的操作感受到，就让他们按着步骤操作一下，会有更深的感受。

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

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

3. 探讨解决方案

虽然开发已经理解了客户的心情，但让他心甘情愿加班做需求还差那么小小的一步。

我们不要直接告诉他需求是什么，不妨让他加入你的思考，一起探讨解决方案，甚至引导他提出需求。

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

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

我说：但是我们不大习惯用Tab键，上下箭头控制可以吗？

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

我心想，太好了，本来就是想让你做回车键切换。顺势接过来：这确实比我想的那个办法实现简单，操作也挺方便的，能不能做到新增药品以后直接光标移动到剂量的输入框中，减少按回车键的次数呢？

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

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

4. 约定完成时间

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

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

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

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

虽然有时候并不能拿到确切的上线时间，但至少开发已经答应我们会加进去做了。

再教大家一个额外的小技巧，让功能尽早上线。

5. 额外技巧

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

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

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

有的人就会提出疑问，你这是给开发下套啊，他上了一次当以后，下次不就不好使了吗？

实际上，下次还会好使的。接下来，我们从心理角度来分析下。

三、沟通中的心理战术

1. 晓之以理

我们会遇到这样的情况，领导说：你给我做个xx功能吧。

也不告诉你为什么要做，使用场景是什么。我们就会怀疑，又在拍脑袋做决定了吧，我不觉得这个功能合适。

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

所以，在和开发沟通的时候，不要一开始就让他对你产生抵触心理；那后面不管说什么，都很难改变认知了。这就是为什么要从说事实入手了，事实是双方都能认同的，能先降低心理防线。

2. 动之以情

虽然困难不尽相同，但是情感是共通的。

让开发体会到客户的不便、着急，也会调动起他类似心情的经历，觉得这件事情是很有必要快速解决的。这时开发的心理防线又低了些，后面再提出需求的时候，也会更加顺理成章。

3. 赞美对方

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

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

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

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

4. 尊重对方

如果开发和我们说：你这设计的都是什么玩意啊？

我们会怎么想：那你来设计啊？你怎么不来做产品?我们真的只是客户传话筒？

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

5. 互相理解

互相理解是长久合作的基石。

开发加需求是情分，不加是本分；要不是被客户逼疯了，尽量不要找开发加需求。

在加需求之前我们也要全面评估好，这个功能的大小、难度。如果明知道这个功能需要好几个人，花好几天做完，就不要去说了。

大功能还是要按照正常的版本计划来规划，不然整个开发进程就乱了。小需求也要把影响范围全部列出来，给到开发；不然可能改完出大bug了，就得不偿失了。

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

四、总结

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

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

尝试练习，根据自己面对的开发的特点，来适当调整，找到适合自己的方法。

—————— / 活动推荐/ ——————

成长路上，我们不断摔倒、振作，在探索中曲折前行。我们也庆幸：有前辈化身引路人，为我们提供帮助与指引。

为感谢每一位引路人的帮助与指引，人人都是产品经理举办了2019年度作者评选，向他们致敬并颁发专属奖项。

一同致敬引路人，还有机会参与百万抽奖，赢取起点学院千元大奖、互联网人必备书籍和美容仪器！快来扫码领略引路人的风采吧！

▼ 点击“阅读原文”为你喜爱的作者点亮“❤”