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

　　一、需求变更的原因

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

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

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

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

　　二、需求变更的形式

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

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

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

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

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

　　三、需求变更的沟通

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

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

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

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