本文章转载于搜狗测试
前言
在整个测试过程中，大家应该或多或少都遇到过”需求变更“，“项目一旦启动，变更也就随之而来。”变更是无法避免的，作为一个合格的项目管理者，我们应该用有效的方法来管理需求变更。
先看几个情景：
情景1：需求变更没有通知到测试，也没有更新需求文档。
开发都写完代码了，测试接手测试时发现和需求文档完全不一样或者有很大出入，找产品确认的时候，产品同学才告知说需求有变更，和开发说了，忘记和测试说了。
情景2：需求新增量大，超出版本排期。
在开发阶段或者测试阶段，产品觉得策略或者方案不是特别好，就对其中一些策略进行了调整，导致开发和测试工作量骤增，直接影响到版本的发布。
情景3：来自于不同源头的需求变更。
设计端的需求新增、运营端的需求新增，需求较多，且来源渠道不同，如果管理不当，就容易出现遗漏的情况。
情景4：在测试一轮都快要结束的时候，发生需求变更，测试和开发都措手不及。
需求变更是为了让产品更完美，策略更优化，所以我们接受合理的需求新增。那么，为了让项目高效运行，我们今天就针对”需求变更“，梳理一下对应的流程规范和相关的文档。
发生需求变更后，我们的处理过程大体是以下几步：
第一步：需求变更的原因分析&成本评估
目的，也是对本次需求变更的优先级和影响范围进行评估，具体请参考上一篇《“你不得不知道的流程规范“@需求的优先级排期》
在软件测试流程中，需求变更建议三方沟通，即测试、开发、产品同时对需求变更内容和影响范围进行评估，达成一致。
要注意需求变更发生的时机：
①项目开始前
在项目开始前发生需求变更，因为各配合团队还处在资源准备、需求理解、策划方案的阶段，需求变更带来的影响较小，是比较容易控制的。
②项目进行中
我们大部分的需求变更都是发生在项目进行过程中，这样就要严格遵循本文的流程规范处理。
③项目将要结束前
因为项目已经接近尾声，开发和测试工作基本告一段落，特别是测试已经经过完整的测试流程，如果在这个时候发生需求变更，很有可能导致开发代码有较大的变动，测试也需要重新评估改动带来的测试范围和影响。工作量增加，质量出现风险。所以不建议在项目将要结束前进行需求变更，甚至可以要求在二轮测试之后，不允许需变。
第二步：提出需求变更
在三方达成共识后，由产品同学提出变更，提出变更有2个要求：
（1）项目相关人员周知
小编现在所在的搜狗手机输入法项目，需求变更邮件规范，内容详尽。借此，向各位同学简单介绍下需求变更邮件的内容：
（此邮件会发送给相关开发和测试，并抄送整个项目大组、项目管理同学知晓。）
（2）变更内容清晰明了
具体需求文档的规范请参考《"你不得不知道的流程规范"@需求文档规范》。当发生需求变更时，产品同学应该将对应的需求文档更新，特别是在文档最前写明变更记录：
第三步：实施需求变更
到具体实施阶段，就按照接到需求→排期→测试的流程进行。
第四步：项目排期变更
如果需求变更影响到项目排期，项目管理人员应该及时更新项目排期/进度汇报（最好在邮件中红色标注delay或者延期的字样），发邮件通知各方配合团队周知。
总结环节
一件事情做完后无论成功与否，坐下来把当时预先的想法、中间出现的问题、为什么没达成目标等因素整理一遍，在下次做同样的事时，自然就能吸取上次的经验教训。这就是复盘。我们应该对每次需求变更进行复盘，精益求精：
（1）是否能尽早提出需求变更
（2）需求变更带来了多少工作量，成本如何
（3）需求变更是否达到了预期
