该帖子同步发自：(vpsoft001的博客  访问该博客)

近年来，互联网推动了大型IT行业信息科技的飞速发展，大型IT行业信息化手段与技术的采用越来越突出，软件需求量越来越大。在项目需求快速增长的现状下，业内人士在项目管理过程中不得不面对一个贯穿整个项目始末的问题——即需求变更，需求的变更在大型IT项目管理过程中对整个生命周期产生非常大的影响，如果不能及时的管控，项目计划和交付日期便会一拖再拖，不仅使企业对整个项目失去信心，同时开发人员也会产生很大的负面情绪。如何有效的对需求变更进行科学的管控是每一位项目参与成员需要思考的问题。

项目经理需要在变更产生之初，判断其原因并确认涉及范围，进而采用合适的变更管控方法。积极地控制项目中所产生的变更，而不是被变更所控制。

一、为什么要变更需求

大型IT项目需求变更的表现形式是多方面的，比如：项目预算增加或减少、高层领导临时改变决策、增加或者减少功能、行业政策的变化等。企业为什么要变更需求，原因是什么？

1、范围没有圈定就急于细化

需求细化是根据客户提出的描述性的、总结性的语言去细化的，提取其中的功能，并给出细化的描述。当细化到一定程度后并开始系统设计时，范围可能会发生变化，那细节用例的描述可能就有很多要改动。如原来需求文档是整体导入导出，要改为指定范围和内容导入导出，如原来需求是多元交叉受理，要改为集中受理、统一需求入口和出口等。

2、没有指定需求的基线

需求的基线是指是否容许需求变更的分界线。随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。项目进展越深入，基线将越定越高，容许的变更将越少。

3、没有良好的软件结构适应变化

组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循松耦合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。

二、需求变更管理的实施准则

大型IT项目需求变更时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么，很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。

当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，具体实施准则如下：

1、建立需求基线，需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

2、制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

3、成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受变更。CCB由项目所涉及的多方人员共同组成，包括行方和开发方的决策人员在内。

4、需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

5、需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

6、妥善保存变更产生的相关文档。

三、需求变更的有效管理

需求变更对大型IT开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以，实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

1、明确合同约束，建立需求基线

对于大型IT开发项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，客户跟项目经理扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候千万不能手软，不能让客户养成频繁变更的习惯。

在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要保证不频繁变更。

2、建立变更审批流程

成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——需求变更是必然的、可控的、有益的。控制需求渐变需要注意以下几点：

Ø  确认客户是否接受变更的代价 要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。

一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。

Ø  需求变更，不管大小都需要经过正规的需求管理流程，否则会积少成多。在实际大型IT项目执行中，项目经理往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变的不可控，最终导致项目失败。

3、用迭代方式应对需求频繁修订

大型IT项目开发过程中，建议采用迭代开发方式，每个阶段的产品进行版本规划，这样在第一版本交付过程中，质量较好可以使客户保持对项目成功的信心，这样也可以使客户需求更加明确和完善产品，客户最关住的是研发过程中与实际后续版本提供系统构架和新技术领域的探索，在后续版本过程中不断的对运营过程中分期完善，对系统的缺陷加以修订，这样才能保障软件生命周期的延续。

四、需求管理工具体现的价值

Visual RM是一款基于大型IT项目管理特点的需求内容级管理工具，以大型IT项目管理视角，帮助IT项目实现需求“管得住、控得了、可跟踪、可沉淀、可复用”的核心目标，其价值主要体现在以下方面：

1、由文档级转为内容级需求管控，助力IT过程的精益管理：改变传统的需求文档级管理过粗的方式，通过需求结构化、条目化技术，自动对需求文档进行自动化拆解，形成需求条目，将需求管理与跟踪的颗粒度细化到条目级，使得需求内容切分（应用分配）、需求内容质量管控、开发和测试任务的需求分配、投产内容的需求跟踪成为可能。

2、控好需求内容变更，维护好最新需求：Visual RM实现了需求文档级、条目级的需求基线管理，通过需求内容的变更控制手段，如：多人同时在线编制需求、变更需求、变更痕迹及历史管理、变更内容前后比对、需求变更影响分析和自动通知受影响的相关人员，使需求变更过程方便、快捷，且变更过程透明、可回溯。

3