「项目中变更是常态」——这是每个在现场工作的项目经理（PM）都知道的事实。
但是，如果在变更管理上出现失误，就会导致交付物不一致或质量下降，并带来延期交付的风险。

要让变更管理成功，仅仅制定审批流程是不够的。
有必要建立需求管理和配置管理，并利用可追溯性（追踪可能性）数据来把握影响范围。

本文将基于CMMI最佳实践，讲解现场可实施的变更管理基本要点和机制。

要想有效开展变更管理，需求管理和配置管理这两个流程是不可或缺的。

对基线化的配置项提出的变更请求进行管理。
具体确认以下三点：

• 是否可变更
• 对依赖交付物的影响
• 对成本和进度的影响

通过配置项的识别、配置控制、状态记录与报告、配置审核，建立并维护交付物的一致性。
变更应基于基线进行，以防止非预期的修改或版本混乱。

图1：成功实施变更管理的流程全览。整理了需求管理、配置管理和可追溯性流程的示意图。

1. 管理需求变更
   当需求发生变更时，记录变更内容、理由及响应历史。

2. 追踪变更请求
   对基线化的配置项提出的变更请求进行管理。
   具体实施如下：

   • 判断是否可变更
   • 确定对依赖交付物的影响
   • 分析对成本和进度的影响

3. 控制配置项
   在更新并批准基线之前，确认是否存在非预期影响。

4. 维护需求的双向可追溯性
   在变更管理中，利用需求的双向可追溯性来确定对依赖关系交付物的影响。

某电商系统开发中，业务部门提出的追加需求未反映到变更管理表中。
结果，测试设计依旧按旧规格进行。
在QA阶段发现不一致，本次上线发布被延期了2周。

原因在于“变更请求管理数据”更新遗漏，以及审批流程不明确。
对策是为变更请求管理工具设置自动通知，并将每周审核列为必需。
自此，再未发生类似错误。

教训：当审批流程和记录仅流于形式时，对变更影响的把握将迅速崩溃。

图2：配置管理的基本要素——配置项与基线的关系。在变更管理中确保一致性的基础。

• 配置项：需要追踪和变更管理的交付物（需求定义文档、设计文档、代码等）
• 基线：某一特定时点的官方版本。变更必须以此为基准。没有基线就会出现“应该修改哪个版本”不明确的问题。

图3：变更请求管理数据示例。可视化变更内容、理由和影响范围，将需求管理与配置管理连接起来的机制。

对变更内容、理由、影响范围、状态等进行统一管理，可视化变更进度。

图4：可追溯性数据全貌。通过垂直和水平方向的可追溯性分析变更管理的影响范围。

追踪开发流程上下游之间的关联（例：代码→设计→需求）。

追踪同一层级内的依赖关系（例：需求之间、设计模块之间、组件之间）。
分析“若变更此处会影响何处”，以抑制变更的波及效应。

在某嵌入式软件开发项目中，将所有文档进行100%映射。
目的是完全覆盖影响分析，但却花费了每周超过20小时用于跟踪矩阵管理。

结果，实施优先级的判断被延误，进度计划受到严重挤压。

另一方面，在一个小规模的Web项目中，即使是轻微变更也要求与大规模改造相同的审批流程。
还强制编写详细文档。

结果，开发人员和设计师开始对新的提案犹豫不决。
服务改进的机会也减少了。

无论哪种现场，都出现了本应关注的准确把握影响范围和确保变更一致性反而产生了更大副作用的情况。
也就是说，维护追踪数据和审批工作本身成为了目的。

教训：变更管理和可追溯性缺少不行，但过度也危险。
应根据项目规模和特性，聚焦3~5个关键项。
还需要通过脚本或AI自动化等方式，减少运维负担。

在项目管理中，变更是不可避免的。
重要的是建立起需求管理和配置管理这两个基础流程。
并利用基线与可追溯性数据准确把握变更的影响。

只要适当运用这些机制，就能避免因变更引发的混乱。
从而实现保证质量和交付期的项目运作。
尤其“变更管理成功的关键”，就在于如何结合需求管理、配置管理与可追溯性。