项目的需要变化是肯定有的，而且变化一般都很频繁，我们怎么应对客户的这种需求变化呢，以不变应万变。首先在前期的需求调研要做好，尽可能的替用户考虑，达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。在项目中期是发生需求变更是很常见的，这时要做好需求变更管理流程。需求变更表，小的变更自己掌握，客户要求的变更有开发人员和设计人员共同商讨后提交项目经理，项目经理预估变更损耗工程时间，在一定阶段一起提交给客户，大的变更直接提交客户，并且要把需求变更对项目产生的影响让客户知道，把球尽可能的踢给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级，关键部分不能改动的做特别确认(如系统架构等，如果改变等于从头再来)。同时完成客户签字确认，当然如果能将这部分写成合同细节中去是最好。以下是我认为变更的步骤：

　　￠ 第一步：客户提出变更内容

　　客户提交的变更必须基于书面形式

　　客户提交的变更必须有充分理由

　　如果变更被拒绝，对业务的负面影响

　　如果变更被接受，对业务的正面帮助

　　￠ 第二步：为能否实现变更作评估

　　从实现方式上考虑新的变更可否实现

　　对于较复杂的情形，辅以简单的说明。欲详述，可作附件处理

　　对于简单情形，例如页面布局更改，则无须说明

　　￠ 第三步：可以实现看进度

　　进度几乎是绝大部分项目关注的第一要素

　　对于活动级别的进度影响

　　对于项目整体工期的影响

　　￠ 第四步：变更成本

　　人力相关的变更成本

　　是否需要额外的项目组成员

　　项目组需要增加的工时数

　　是否正常工时(工作日加班、节假日加班)

　　项目工数报价

　　非人力成本

　　软硬件费用

　　资料费用等

　　￠ 第六步：质量和风险

　　变更对质量的多方面影响

　　分阶段影响(需求、设计、编码、测试、维护)

　　可靠性、安全性、可维护性、可用性等

　　可能对团队士气的负面影响

　　可能引发的间接任务对工期的负面冲击

　　开发方的成本负担可能超出力所能及的范围