需求变更往往会引起返工，从而影响项目的范围、时间、质量和成本等多个要素，如果控制不好，会导致项目范围蔓延、进度延迟、质量不满足干系人要求和成本超支等问题，因而需求变更在很多项目中都是一件头疼的事情。这一章节主要介绍需求变更的原因、需求变更的方式以及我们如何控制需求变更。

一、需求变更的原因

行业软件与政策相关较大，可以说政策是需求变更的一大来源。另外，客户的想法、需求有缺陷等也是需求变更的重要起因。总结起来，变更原因主要有：

1、政策改变了。这种情况在政府行业表现尤其明显，三天两头一个红头文件，要求下级单位贯彻落实执行；

2、客户的要求变了。客户一开始没有想好，或者一开始没有想法但随着项目的进行、参考其他地方好的做法，产生了一些新的想法；也有一种情况是因为外部压力，主动或被动作出调整，比如因为业务流程太复杂，手续太繁琐遭办事人投诉等；

3、需求有缺陷。系统分析员经验不足，没有捕获到客户的关键业务需求或者客户整理需求能力不足，遗漏了关键的需求点等。

二、需求变更的形式

根据先前几个项目的观察，总结起来，常见的提出需求变更的形式主要有：

1、客户在项目开发过程中，向系统分析员提出变更。提法主要有：“这个功能我想改成这样，你看怎么样？”，“这个业务我有新的想法，参考某地的做法，好改成这样”；

2、客户在验收测试过程中，向系统分析员或测试人员提出变更。常见的提法有：“这个功能能不能这样？”，“这个界面不太好用，改成这样子”，“这个业务应该加上这个限制”，“这个地方原来没有考虑到，要改成这样”等等；

3、客户在正式的项目例会上提出变更。正式的会议往往会有高层参与，客户准备的较为充分，这些变更通常会以书面的形式提出；

4、项目组提出变更。由于需求有缺陷或者技术实现难度太大，需要提出需求变更。这时候项目组需要详细的书面文档说明变更的理由以及替换的方案。

三、需求变更的沟通

了解了变更产生的原因，在此基础上，我们可以建立相应的变更沟通策略，，具体定义如下：

1、政策变化导致的需求变更。政策变化属于强制的变更，这时候客户为了完成政治任务，变更是一定要发生的。对于项目组来说，需要对这些变更做好评估工作，包括变更新增的工作量估算、对项目目标（范围、时间、质量和成本）的影响等等，基于量化的数据与客户谈判。工作量不大，对基线影响很小的，纳入开发计划予以实施，但需与客户明确，我们这是在帮忙，这些工作不是项目范围的一部分；工作量较大，对基线有很大影响的，与客户进行商务谈判，要求项目追加预算或者以后通过在新项目中加入该部分的工作予以补偿。一般情况下，由于政策都有时限，为满足客户需求，变更都会先实施，然后再谈补偿；

2、客户想法或要求导致的需求变更。由于社会在发展，人的观念也在不断更新，可以说，客户提出变更也是可以理解的。项目组基于变更评估与客户沟通，策略有三类，一是指出变更不合理，影响太大，直接拒绝；二是提出替换方案；三是商务谈判，具体的做法与第1点类似；

3、需求本身有缺陷导致的变更。这时候与客户沟通，说明考虑不周的情况，提出解决方案。要注意的是，如果是项目组的失误导致的缺陷，需承认客观事实，不要掩饰或者推卸责任，否则可能会引致客户对项目组不信任，降低客户满意度，影响合作关系。

四、需求变更的控制

需求变更的控制关键在于建立建立相应的控制组织、变更控制和跟踪系统以及规范变更流程，主要有：

1、建立组织。项目启动时，我们会尽可能的与客户沟通，建立正式的对变更进行控制的组织，成员包括双方高层（挂名）、甲乙双方的项目负责人、相关的需求负责人等。如果客户认为无需单独设置这样的正式组织，我们也会要求客户指定项目的负责人，每个相关的业务科室指定一名需求负责人，这样做的目的是如出现变更可以很快的临时组建一个对变更负责的组织，并且可以找到相应的负责人；

2、建立变更控制和跟踪系统。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流；经比较和选型，我们选用了JIRA作为变更控制和跟踪系统；

3、规范流程。甲乙双方的项目组成立后，根据角色定义，确定变更流程。

1）变更申请。系统界面如按钮的位置、字段的位置的细微调整，不涉及到业务规则，对基线基本没有影响的变更，由测试人员直接在变更控制系统中提出；其他如操作风格的较大变化、业务规则的变化等，均要求客户提出电子和书面的需求变更单；

2）变更评估。由项目组组织人员对变更进行变更的合理性分析，变更替换方案分析，工作量的估算以及涉及什么模块、影响什么模块等影响分析；

3）变更决策。根据上节确定的沟通策略，与客户沟通交流，确定变更的处理方式；

4）变更实施。由测试人员在变更控制系统中填写变更信息（状态：待处理），由系统分析员填写处理方法和影响分析后交由开发人员实施（状态：处理中）；

5）变更验证。测试人员根据变更控制系统的变更状态反馈（状态：已解决），待相应的版本发布后，对变更进行验证测试，这时候特别要注意的是记录该变更的修改是否引起了该模块或其他模块产生缺陷。通常，测试人员根据系统分析员在变更控制系统中标注的影响模块，逐一进行回归测试，以确保不影响原有模块的前提下变更已正确实施；内部测试完毕后，如系统已上线，则由客户相关负责人在模拟生产环境中进行验收测试；

6）沟通归档。变更验证后，测试人员关闭变更（状态：已关闭），项目经理告知客户已测试完毕，沟通发布时间并说明那些模块可能有影响以及发现问题的反馈途径和方式。

通过以上几种手段，如执行实施到位，基本可以有效的把变更置于控制之下。

后，值得一提的是，变更实施或者系统缺陷修复涉及到多方面的人员，可能牵涉软件系统中的多个模块，处理和验证的流程复杂，沟通等管理成本高昂，如果变更和质量控制不好，会直接影响项目的进度和成本。