6、 需求变化

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

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

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

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

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

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

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

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

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

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

    第三步：可以实现看进度

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

    .对于活动级别的进度影响

    .对于项目整体工期的影响

    第四步：变更成本

    .人力相关的变更成本

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

        .项目组需要增加的工时数

    是否正常工时（工作日加班、节假日加班）

    .项目工数报价

    非人力成本

    .软硬件费用

    .资料费用等

    第五步：质量和风险

    变更对质量的多方面影响

    .分阶段影响（需求、设计、编码、测试、维护）

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

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

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

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

    第六步：需求变化的确定