不想再加班？你应该如何应对需求变更
序：
之前写过一篇文章《为什么前后端分离了，你比从前更痛苦？》，却发现有很多同学把楼盖歪了，开始讨论起需求变化谁也无法掌控。
本文还按照笔者一贯风格，以“掰开勃勃说馅”的方式教会开发同学理解 “需求变更” 的原因，以及应对需求变更的方法。
需求变更不仅会打断开发同学的思路，降低开发效率，还会因为不断返工产生巨大浪费。
正所谓：
打断他人正常工作，影响工作效率，为不仁！
逼迫他人完成不合理需求，影响同事感情，为不义！
反复修改没有产出，浪费公司资源，为不忠！
破坏社会安定和谐，辜负父母养育之恩，为不孝！
为什么会 “变” ？
首先我们必须允许需求的变化，因为我们不允许，需求也会变。😂
信息化时代，瞬息万变，风云莫测。今天还受万众追捧，转眼就成过眼云烟。
唯有快速响应变化才能够活下去。所以变未见得全是坏事，能够满足市场需求，给用户创造价值，我们又怎么能拒绝呢？
然而，并不是所有的变化都是应对市场需求，而是信息不对等所带来的。
我们来看一个场景
需求：商品列表，如图:
脑洞有多大，需求就有多大，有木有？
产品经理：为什么没有分页？这种事也要我说吗？你要专业好不啦！
程序员：...
产品经理：这个筛选、过滤先不做，老板还没想好。忘记和你说了，先revert 吧。
程序员：...
其实，你以为只有程序员才是受害者吗？
殊不知这个世界上还有一个“恶人”，他们根本不关心用户的需求，只想满足自己的想法，这个人就是——老板。
然而这世界上还有一个人，不仅不关心用户需求只想满足自己，还逼迫你把好好的产品变成“垃圾”，比老板还要“恶毒”，这个人就是——甲方爸爸。
你说这个世界要有光，就有光，你以为你是上帝啊。
你无情，你冷酷，你无理取闹啊。
就是这两大“恶人”，把多少青年才俊（产品经理）活活逼成了“传话筒”。众生皆苦，相煎何急。
究其原因，还是因为变更的成本过低。动动嘴，程序员就开始加班…实在太过容易。所以要管理好“老板们”的期望，需求变动是可以，但并不是没有成本，这些成本需要明确出来，并且买单。
什么是 “需求变更” ？
既然我们要讨论应对需求变更的方法，就要先了解什么是需求变更。
在这个需求没有上线的变化叫做需求变更，上线之后的呢？——这叫新需求！！！
只要我们将需求做到持续交付，快速上线，那么后面的新需求就要按照优先级重新排期，走新需求的流程啦。
是不是很有道理呢？
瀑布式开发的同学可能就要哭了，我们的产品要3个月之后才要上线，岂不是只能任人宰割了。😥
回过头来再看刚刚的定义，为什么一定是**“上线”之后修改才是新需求？因为这个需求做完**了。
奥妙不在于上线，而是在需求上线之后才标记为 “完成”，之后的需求都是新需求。
So…
定义 “完成” 才是解救我们于水火的唯一途径啊。
定义 “完成”
经过年多的经验，我们发现团队中每个成员对于“完成”的理解都不一样：
- 我在本机开发完就算完成；
- 需要自测一下，没问题就算完成；
- 需要前后端联调一下就算完成；
- 经过测试同学验证的就算完成；
- 而对于产品经理来说，只有上线才算完成；
并不需要追求全球统一，团队内部中达成一致就好。在开发中的任意阶段都需要被定义“完成”，我们今天只讨论需求完成的定义。
再看一下刚刚的需求应该如何修改？
以一种故事卡的形式存在，不仅可以描述需求应对的【角色】，【角色】的操作，还可以体现出这个卡对【角色】的价值。当一个需求没办法描述出对【角色】带来的价值我们就需要考虑这张卡是否有必要，以及它的优先级。
定义好的验收条件，让开发和测试同学明确知道这张卡的范围。开发同学要在卡上评估工作量，并记录在案。
接下来我们就可以这样应对：
场景1
低成本的小改动，也要落实到纸面上，有迹可循，明确我们工作方式。
需求方：“小明，这个文字帮我修改一下”。
小明：“好的，没问题，咱们这交情。在卡上加个备注，让测试同学知道修改内容”。
场景2
需求方总以为增加人手可以解决一切问题，增加人手同时会增加沟通成本和管理成本。
在沟通中我们需要明确出这些成本带来的影响。
需求方：“小明，这个功能之前设计有点问题，需要改成XXX，帮我修改一下”。
小明：“好的，这样修改会影响之前评估工作量，咱们这交情你总不会让我加班吧”
需求方：“需要多久？”
小明：“需要增加1天时间”
需求方：“加 1个人和你一起做呢？”
小明：“可以啊，需要找产品经理先给他讲一遍需求，然后我需要花半天时间和他讲一遍代码，（如果是全新的同学，至少需要2天熟悉开发环境等…）然后我们才能开始一起做。”
场景3
完成的卡，修改都是新需求。
需求方：“小明，这个功能之前设计有点问题，需要改成XXX，帮我修改一下”。
小明：“这个需求已经做完了，创建新的需求来做这个功能吧，我们会重新评估工作量”。
如果新修改不是 “Must to have” 而是 “Nice to have” 我们还可以这样建议：
小明：“我注意到新修改只是优化了XXX操作，不影响用户使用，建议先放在这个迭代最后，如果还有时间我们再调整”。
因不可抗力因素导致的必然修改同样有指导意义。迭代计划中完成 5 个需求，因变更带来了返工，导致只做了 3 个需求。在迭代结束之后将报告发给需求方，可以帮助更好的运转。
总结
需求的变化一方面是对用户的价值不明确，所导致的频繁修改，另一方面则是内部信息的理解的不一致所产生了分歧。文中提到的方法可以帮助我们消除理解上的差异。
解决了信息不对等的问题，需求修改就变成了一道选择题。
文中提到了【用户故事】和 【完成的定义】都是敏捷实践。很多公司认为敏捷是快速响应变化，结果却做成了加班文化。通过敏捷让产品快速上线，使得我们的假设得以验证，及时根据反馈调整产品。让若产品一直在内部不断修改，迟迟无法发布，会延迟对假设验证。这些看起来有价值的修改只是需求方的“自娱自乐”。
