变更并非坏事，事实上变更反而是必要的。事先将所有需求都定义好，几乎是不可能的。随着开发的进展，用户的思想也在变化，外部的环境变化和业务需要跟进。一个高效的团队要能够灵活应对变化，使其构建的软件可以及时为业务方提供价值。
需求的变化在所难免，实际上用现在很流行的词儿"演化"去看，就顺利成章，没有什么会停止演化，除非要被淘汰。这样看来，需求如果还有变化就是一件好事儿，至少这个功能还被需要，还在被调整，从不完善趋近于完善。
应对变化的最好方式，就是要时刻保持这样一种“战斗”状态，随时都要准备为变化的需求做出调整。想在众多的日常工作中为某一个需求理出这么一块空间，就像杂乱的桌面上找出一块干净的地方放置新的事物，最好的办法就是让自己的桌面井井有条，让这个桌面随时欢迎新的成员加入进来。而一套好的需求管理办法就像这个整洁桌面的管理者——让变更的需求更加高效的加入到系统中来。
以往众多的项目都发生过变更，变更的原因包括前期理解差异、业务规则变化、业务方想法发生变化、新功能增加、界面交互变化等。我们能做的就是尽量减少变更的发生，并在发生变更时也能很好的处理它。作为开发方，外部变化我们无法改变，我们能做的就是：正确获取需求，并正确的在团队内部传递。在正确获取需求方面，可考虑丰富调研的形式，提高需求人员业务领域知识;在正确传递需求方面，可通过力求清晰形象地描述需求、需求反讲、需求验证等手段来实现。对于业务方提出的变更，我们也可以通过以下几点来管理好变更：
1)针对提出的需求变更在做出承诺之前经过深思熟虑的评估;
2)由合适的人员针对提出的变更做出明智的业务决策;
3)变更管理活动对受到影响的干系人可见;
4)核准的变更会被通知到所有受到影响的项目参与者;
5)项目组以一致且有效的方式处理需求变更。
需求变更给各方带来的麻烦是有目共睹的，需求变更会给项目带来巨大的延期风险、质量风险、成本风险等。当然在项目中，需求变更往往是不可避免的，我们一方面需要尽量减少并控制需求变更的发生，另一方面，在需求变更发生时，我们应对需求变更进行有效的管理，最大可能的降低需求变更带来的风险。