软件工程20-如何应对让人头疼的需求变更问题？

在国内很多软件公司，需求变更是常态，开发到一半，很多原始需求就发生了变化，这时候当初的设计已经不能满足要求了，很多代码需要修改，不得不加班加点来赶上进度。

反观不加班的美国公司，需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计，而不用考虑太多可能的变更，从容地在项目计划的时间内完成任务，而不需要加班加点。

在需求变更这个事情上，没有赢家，每个人都是受害者。

程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人说：“杀一个程序员不需要用枪，改三次需求就可以了！”

产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？

既然大家都不满意，那么我们就需要想办法去改善，这也是软件工程这门学科存在的目的和意义。

目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。

方案一：增强需求变更流程，让需求变更规范起来。
这个方案简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。

方案二：快速迭代，缩短版本周期。
这个方案是另一个思路，就是将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应。

不过，在看到这两个方案后，我还是希望你不满足于当前的答案，自己停下来思考一下这两个问题：

1. 这些方案是否解决了你当前项目的问题？
2. 如果换一个项目环境，当前方案是否依然适用？

之所以要思考这样的问题，是因为对于像软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。

因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了。所以我们要多去思考和分析逻辑，这样未来遇到类似的问题时，才可以做到对症下药，选择合适的解决方案，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。

为什么建筑工程中少有需求变更？

要解决需求变更