需求变更是项目生命周期中最大的挑战之一，用户、领导、产品策划随时都可能提出各种各样的需求变更，从而导致原先的设计和工作都不得不返工。如此不仅压缩了工期，还浪费了大量的人力，因此经常会使开发团队手忙脚乱，苦不堪言。甚至互联网公司还流传着“拥抱变化”的口号，那么到底有什么办法可以有效轻松地管理需求变更呢。
一、变更有代价
上游部门为了应对来自老板的想法，或者时刻变化的外部环境，经常会提出所谓“优化版”的需求变更，对于他们而言，只要提出来，交付给下游就算完工了，至于下游需要耗费多少力气去做改造，他们可能并不能直观地感受到。因此，我们需要带领他们感受到由于变更所带来的额外工作量和浪费的资源，从而达成一个初步的共识：变更需求是有代价的。
比如，我们可以在某次迭代回顾会上，拉上需求提出人和领导，看一下迭代中存在的需求变更记录。
相信看到这张表后，大家就都很清楚，需求变更给团队带来了什么。但是需求变更也是正常的，不可能存在不变更的情况，那么如何合理有效地管理需求变更呢，下面是一般建议的步骤：
- 需求的提起和变更必须提单子，经由领导和相关人员进行审批，做到留痕；
- 变更的需求需要相关人员进行评审，评估可行性和代价，并由领导或者需求决策组织决定是否接受变更；
- 通过的需求变更需要及时邮件告知团队所有成员，并及时澄清和调整资源，同时记录变更历史；
如此，大家对需求变更的代价和流程都有了一个最为基本的认识，相信乱七八糟、无关紧要的需求变更就会少很多了。
二、一次性把事情做对
应对风险最好的方法就是把风险扼杀在摇篮里面，所以如果我们在一开始做需求分析和设计的时候就把把关，把质量提高，到后面开发阶段就能顺畅很多。
通常的做法就是提需求给不同的系统，各个系统的分析人员各自为战，然后再约时间一起开会过一下，沟通着“我是这样想的，你是那样想的”，然后回去修改一遍再来一次。这样的过程冗长繁杂，往往要经过好几轮才能最终把需求的设计方案确定下来，而且质量也很难保证。
推荐的方式是将各个系统的分析人员直接凑到一块，在接下来的几天时间里面，大家一起讨论和设计，然后再进行成稿，避免了来回反复的多次沟通成本，再将设计方案展示给团队所有人进行评审，大家各抒己见，为方案找找漏洞，如此形成的最终方案想必会成熟很多，出问题的概率也大大降低了。
三、灵活应对不可抗的变更
以上方法只适合应对同级别的同事提出来的需求变更管理办法，如果提出来的人是大老板、重要客户，而且非常执着怎么办呢？肯定不可能按照如上的方式进行管理。
其实我们要搞清楚老板和用户为什么要提出来这个需求变更，很大可能是因为他们突然看到或者想到某个点子，想应用在自己的系统中，然而这个点子是不够成熟的，没有行为数据的支撑。如果团队一味迎合他们的需求变更，可能最后什么也做不成，还搞得团队很累。所以可以通过如下的方式：
- 成立一个专门应对不可抗需求变更的小组，帮助领导和用户快速实现、快速试错，最后发现效果不好，砍掉也不会太大影响原有项目需求的进度。
- 对于那些团队不太认可，但是一定要上的需求变更，可以进行小规模的灰度发布，然后统计行为数据进行验证，相信领导也会明白的。
