2.9 项目管理过程：实施整体变更控制

2.9.1 项目的变更控制

项目的不确定性因素导致了项目的进展未必能按计划进行，而当这种不确定性变得明确的时候，就会导致项目出现变更。项目目标是项目所有活动的最终判断准则。那些可能会引起项目目标变化的因素包括：内部因素和外部因素。

● 内部因素是指由于项目的实际实施绩效偏离原有计划要求，导致无法实现原定项目目标，不得不变更项目计划。

● 外部因素是指干系人本身对项目目标发生了变化，从而引起计划的变更。

项目变更如图2—21所示。

图2—21 项目变更

无论是外部请求变更还是内部的偏差变更都有可能是来源于或导致项目的四个目标因素发生变化。但在实践中，外部请求变更大多只由范围因素变更所引起，而内部偏差引起的变更则可能由于范围、时间、成本和质量等各个因素所引起。

项目管理中的核心控制过程如图2—22所示。

进度控制、成本控制和质量控制都是关注实施结果和目标之间的偏差控制。对范围目标有两个相关的管理过程：范围确认和范围控制。其中，范围控制是对“项目范围的变更进行控制”。此外，还需对“范围目标”是否正确进行检验，这一活动由“范围确认”过程来承担。有关“确认”的深刻意义参照第6章的相关内容。范围目标正确性的判断必须引入客户参与。

图2—22 项目管理中的核心控制过程

变更的最终效果是引起项目基准计划产生变化。由于项目基准计划是项目各项活动开展的基础，为了不引起混乱，它的变化必须是一个严格而受控的过程。大多数的变更控制过程都是相似的。

项目变更控制流程如图2—23所示。

图2—23 项目变更控制流程

一般的变更过程始于正式提出变更申请。变更申请的英文翻译为：ChangeRequest或ModificationRequest，所以也经常简称为CR或MR。在变更申请中，需要详细地描述变更的来源，主要是反映项目目标变化。例如：

● 客户对项目范围产生了变化，范围变更。

● 客户需求发生了变化，引起了产品的需求变更。

● 实施效率偏差导致了基准计划的修订，例如进度和成本目标的变化。

● 通过质量检验，发现交付产品没有达到质量目标，必须对产品实施返工从而引起的产品变更。

收到了变更请求后，会有专门的人员先做一个初步的分析，主要是评估变更的来源、变更的理由、变更产生的影响、变更的代价。某些变更会在这个阶段作出一个初步的处理。例如：

● 描述不清楚的变更请求，或被要求提出者重新补充信息。

● 删除那些明显错误的变更请求。

● 一些简单且影响小的变更可以直接由分配人员处理。

● 余下的变更请求会被提交到变更控制委员会进行评审。

变更控制委员会评审是整个变更控制过程的核心。一般来说，变更控制委员会是一个项目主要的管理机构，由项目重要的干系人代表、各个相关组织的代表、主要的技术人员等组成。变更控制委员会评审就是评估那些被提交上来的变更请求，针对这些变更的目的、要求和影响作出如下决策：

● 同意实施一项变更请求，并且在会议上安排相关的变更实施责任人和相关联的协作组织。

● 拒绝某一项变更请求，并给出拒绝的理由。

变更控制委员会评审一般以会议的形式进行，有关各方都会参加，可以定期召开，也可以针对某一项重要变更临时召集。

如果变更请求得到批准，则变更被实施。变更实施的过程中要特别关注那些可能会产生广泛影响的变更，避免在变更实施过程中出现不一致。完成变更后，需要对变更的实施结果进行验证，以确保被批准的变更得到了正确实施。

2.9.2 变更控制和配置管理

在很多类型的项目中，项目变更最终导致的结果几乎都是项目的产出物（包括最终可交付物和中间产品）发生了变化。这些项目的产出物一般都被置于项目的配置管理系统中进行管理。配置管理活动并不是专门为项目而存在的活动，它是组织中更普遍的一类支持性活动。它主要管理组织内部活动的产出物，但不仅仅管理项目的工程活动结果，也管理项目的管理活动内容。可以说，项目的变更其实就是对处于配置管理下的产出物进行变更操作。管理变更，可以简单地认为就是管理这些产出物的变更。因为无论怎样变化，只有那些导致项目产出物最终发生变化的变更才是我们需要关注的。这也是为什么很多这种类型的项目中，变更控制大都是在配置管理活动中表述的根本原因。有鉴于此，我们需要了解一下配置管理活动的基本概念。

项目活动大多是团队协作，也可以被认为是基于项目产出物的协作。所有人的工作一定是以某一个产出物作为输入，自己的工作输出会体现在另一个产出物上，而这个产出物将是另外一个人的工作输入。

基于产出物的协作过程如图2—24所示。

图2—24 基于产出物的协作过程

每个人的工作输入和输出都是基于产出物，确保每个人的工作是基于正确的产出物十分重要。特别是在项目运行当中，这些产出物都会经过很多变化，必须确保这些变化不会产生错误。配置管理系统就是建立这样一种目的的管理体系。完整的配置管理活动包括4个部分的内容：

● 配置项识别。

● 配置控制。

● 配置状态报告。

● 配置审计。

既然协作是基于产出物的协作，那么首先就应该定义哪些产出物是大家协作的基础，这些产出物就应该处于配置管理系统的控制之下。这个活动就是配置项识别。每一个产出物都被称为配置项（Configuration Item, CI）。为了有利于管理、提高效率，可以为每一个配置项确定一个配置项标识。所谓标识，其实就是一个代号，作为该配置项的唯一识别。所有这些配置项应该有一个统一管理的存放地，这包括那些物理的产出物，或是以电子文档形式存在的文件。特别是后者，应有专门的配置管理工具来存储这些电子文件。从某种意义上来说，配置管理系统是组织的中央数据库。每一个配置项都应该被指明该配置项所存放的物理或逻辑位置，让有关的人可以快速而准确地找到。

表2—28是一个软件研发项目配置项列表。

表2—28 配置项列表

每一个配置项都作为某项工作的输入和输出。输出意味着配置项被创建或者被修改，而后者是更普遍的情况。输入意味着另一项工作依赖于某一个配置项。一个配置项被一个活动创建后，作为另一个活动的输入。同样，如果一个配置项被更改，会导致以它为输入的活动发生变化，而这项活动所输出的配置项也会相应发生变化。如此类推，会产生一个“变更链”。所以，要确保正确工作，必须约定以下几个规则：

● 每一个配置项由于会产生变化，就必须约定配置项的版本。

● 有依赖关系的配置项之间必然有版本上的约定。例如，设计文档V2.0是基于规格说明V1.2的。

● 每一个配置项的变更必须受控，并且其产出物会用版本号来标识。

这一活动就被称为配置控制。一般来说，完整的配置控制内容包括：标识配置项的版本，变更管理体系，配置项的变更控制过程。为了方便而有效地管理变更，每一次变更都必须有完整的标识和跟踪记录，一般可通过“变更管理工具”来完成。

项目中每一个人的工作都依赖于配置管理系统里的配置项，所以配置项的状态就需要以某种方式获得和了解，这就是配置状态报告活动的目的。一般来说，配置状态报告会包括以下几项内容：

● 每一个配置项当前的版本状态。

● 距上次配置状态报告到现在，都经历了哪些变更，导致了哪些配置项的版本变化。

配置状态报告就是配置系统当前的“快照”，以及从上次“快照”到这次“快照”之间的“变化”。显然，如果存在较完善的变更管理过程和工具的支持，这些变化就是以变更标识号的列表来表示的。

因为配置管理活动至关重要，所以必须确保所有人员都是遵守这些约定的。如果出现没有遵守而导致的“错误”，必须尽快发现和纠正。这一活动就是配置审计活动。通常意义上的配置审计活动内容包括：功能配置审计（Functional Configuration Audit, FCA）和物理配置审计（Physical Configuration Au-dit, PCA）。

● 功能配置审计是检查项目的最终产出物是否按照要求完成了它所期望的目的和功能。这要通过检查产出物的内容来实现。

● 物理配置审计是检查项目的各个产出物是否按照约定的规则被创建和维护。这主要通过检查配置管理系统和变更管理系统的记录来完成。

2.9.3 产品的生命周期与演化

一个产品从创建开始到最终退出市场，经历了不断变化更新的过程，如图2—25所示。

图2—25 产品变更过程

每一个产品都由一组产品的子部件组成。每一个子部件又有其自身的版本演化。每一个发布的产品就由一组确定版本的子部件组成。当我们由于某种需要进行产品的升级或者维护时，表现的操作结果就是对各个子部件提出相应的变更请求，并且付诸实施。各个子部件的版本因此而变化，而新发布的产品就会包含一组新确定版本的子部件组成。

我们在从头开始创建产品的时候，也可以利用变更请求来控制，只不过这时各子部件的最初版本实际上是“空”而已。而每一次产品的升级都是以上一次发布的产品版本为基准，进行了一系列的变更请求变化而成。我们看到产品基于这样一种模式在演化：

产品新基线=产品基线+变更请求

这种演化模式贯穿了产品的整个生命周期。这种操作模式有两个关键的管理系统：保存产品各个子部件的版本控制系统和跟踪变更请求的变更控制系统。这两个系统的组合就是上节所提到的配置管理系统。

在项目当中，对于其产出物本身的演化周期并不长，配置管理系统的作用大多体现在变更控制上。而在产品管理上，配置管理系统的作用相当关键。在很多情况下，一次产品的升级过程就是一个项目，而这时的项目范围就是一组变更请求。