不想再加班？你应该如何应对需求变更

序：

之前写过一篇文章《为什么前后端分离了，你比从前更痛苦？》，却发现有很多同学把楼盖歪了，开始讨论起需求变化谁也无法掌控。

本文还按照笔者一贯风格，以“掰开勃勃说馅”的方式教会开发同学理解 “需求变更” 的原因，以及应对需求变更的方法。

需求变更不仅会打断开发同学的思路，降低开发效率，还会因为不断返工产生巨大浪费。

正所谓：

打断他人正常工作，影响工作效率，为不仁！

逼迫他人完成不合理需求，影响同事感情，为不义！

反复修改没有产出，浪费公司资源，为不忠！

破坏社会安定和谐，辜负父母养育之恩，为不孝！

为什么会 “变” ？

首先我们必须允许需求的变化，因为我们不允许，需求也会变。😂

信息化时代，瞬息万变，风云莫测。今天还受万众追捧，转眼就成过眼云烟。

唯有快速响应变化才能够活下去。所以变未见得全是坏事，能够满足市场需求，给用户创造价值，我们又怎么能拒绝呢？

然而，并不是所有的变化都是应对市场需求，而是信息不对等所带来的。

我们来看一个场景

需求：商品列表，如图:

脑洞有多大，需求就有多大，有木有？

产品经理：为什么没有分页？这种事也要我说吗？你要专业好不啦！

程序员：...

产品经理：这个筛选、过滤先不做，老板还没想好。忘记和你说了，先revert 吧。

程序员：...

其实，你以为只有程序员才是受害者吗？

殊不知这个世界上还有一个“恶人”，他们根本不关心用户的需求，只想满足自己的想法，这个人就是——老板。

然而这世界上还有一个人，不仅不关心用户需求只想满足自己，还逼迫你把好好的产品变成“垃圾”，比老板还要“恶毒”，这个人就是——甲方爸爸。

你说这个世界要有光，就有光，你以为你是上帝啊。

你无情，你冷酷，你无理取闹啊。

就是这两大“恶人”，把多少青年才俊（产品经理）活活逼成了“传话筒”。众生皆苦，相煎何急。

究其原因，还是因为变更的成本过低。动动嘴，程序员就开始加班…实在太过容易。所以要管理好“老板们”的期望，需求变动是可以，但并不是没有成本，这些成本需要明确出来，并且买单。

什么是 “需求变更” ？

既然我们要讨论应对需求变更的方法，就要先了解什么是需求变更。

在这个需求没有上线的变化叫做需求变更，上线之后的呢？——这叫新需求！！！

只要我们将需求做到持续交付，快速上线，那么后面的新需求就要按照优先级重新排期，走新需求的流程啦。

是不是很有道理呢？

瀑布式开发的同学可能就要哭了，我们的产品要3个月之后才要上线，岂不是只能任人宰割了。😥

回过头来再看刚刚的定义，为什么一定是**“上线”之后修改才是新需求？因为这个需求做完**了。

奥妙不在于上线，而是在需求上线之后才标记为 “完成”，之后的需求都是新需求。

So…

定义 “完成” 才是解救我们于水火的唯一途径啊。

定义 “完成”

经过年多的经验，我们发现团队中每个成员对于“完成”的理解都不一样：

• 我在本机开发完就算完成；
• 需要自测一下，没问题就算完成；
• 需要前后端联调一下就算完成；
• 经过测试同学验证的就算完成；
• 而对于产品经理来说，只有上线才算完成；

并不需要追求全球统一，团队内部中达成一致就好。在开发中的任意阶段都需要被定义“完成”，我们今天只讨论需求完成的定义。

再看一下刚刚的需求应该如何修改？

以一种故事卡的形式存在，不仅可以描述需求应对的【角色】，【角色】的操作，还可以体现出这个卡对【角色】的价值。当一个需求没办法描述出对【角色】带来的价值我们就需要考虑这张卡是否有必要，以及它的优先级。

定义好的验收条件，让开发和测试同学明确知道这张卡的范围。开发同学要在卡上评估工作量，并记录在案。

接下来我们就可以这样应对：

场景1

低成本的小改动，也要落实到纸面上，有迹可循，明确我们工作方式。

需求方：“小明，这个文字帮我修改一下”。

小明：“好的，没问题，咱们这交情。在卡上加个备注，让测试同学知道修改内容”。

场景2

需求方总以为增加人手可以解决一切问题，增加人手同时会增加沟通成本和管理成本。

在沟通中我们需要明确出这些成本带来的影响。

需求方：“小明，这个功能之前设计有点问题，需要改成XXX，帮我修改一下”。

小明：“好的，这样修改会影响之前评估工作量，咱们这交情你总不会让我加班吧”

需求方：“需要多久？”

小明：“需要增加1天时间”

需求方：“加 1个人和你一起做呢？”

小明：“可以啊，需要找产品经理先给他讲一遍需求，然后我需要花半天时间和他讲一遍代码，（如果是全新的同学，至少需要2天熟悉开发环境等…）然后我们才能开始一起做。”

场景3

完成的卡，修改都是新需求。

需求方：“小明，这个功能之前设计有点问题，需要改成XXX，帮我修改一下”。

小明：“这个需求已经做完了，创建新的需求来做这个功能吧，我们会重新评估工作量”。

如果新修改不是 “Must to have” 而是 “Nice to have” 我们还可以这样建议：

小明：“我注意到新修改只是优化了XXX操作，不影响用户使用，建议先放在这个迭代最后，如果还有时间我们再调整”。

---

因不可抗力因素导致的必然修改同样有指导意义。迭代计划中完成 5 个需求，因变更带来了返工，导致只做了 3 个需求。在迭代结束之后将报告发给需求方，可以帮助更好的运转。

总结

需求的变化一方面是对用户的价值不明确，所导致的频繁修改，另一方面则是内部信息的理解的不一致所产生了分歧。文中提到的方法可以帮助我们消除理解上的差异。

解决了信息不对等的问题，需求修改就变成了一道选择题。

文中提到了【用户故事】和 【完成的定义】都是敏捷实践。很多公司认为敏捷是快速响应变化，结果却做成了加班文化。通过敏捷让产品快速上线，使得我们的假设得以验证，及时根据反馈调整产品。让若产品一直在内部不断修改，迟迟无法发布，会延迟对假设验证。这些看起来有价值的修改只是需求方的“自娱自乐”。

资料：

https://tonydeng.github.io/user-stories-applied/

What is Definition of Done (DoD)?