【信管12.3】项目变更管理

项目变更管理

对于传统的项目管理来说，变更控制管理真的非常重要。我个人一直觉得，传统和敏捷之间最大的不同就是在面对变更时的态度不同。敏捷非常欢迎变更，拥抱变化是它的宣言之一，甚至是无变更不敏捷。而传统项目管理其实是比较讨厌变更的，因为我们会认为项目中的各种不确定因素都是变更带来的，它会带来功能的变化、风险、各种计划的变动。所以，对于传统的项目管理来说，我们要非常严肃的对待变更问题。

之前在 项目整体管理 的 实施整体变更控制 中，其实已经学习过很多变更相关的知识了，包括变更产生的原因，实施变更的流程，CCB 是干什么的这一系列内容。今天我们再根据教材中的 项目变更管理 章节再一次地深入学习一次变更相关的内容。如果你跟着我在之前的课程中学习过了，而且你还有印象的话，就当是一次复习。如果你已经没有印象了，那就要重视起来了哦，变更非常重要，而且也是选择和简答题中常见的内容。

项目变更管理

项目变更管理，是指在信息系统工程建设项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。

变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

项目变更产生的原因包括：

• 产品范围（成果）定义的过失或者疏忽

• 项目范围（工作）定义的过失或者疏忽

• 增值变更

• 应对风险的紧急计划或回避计划

• 项目执行过程与项目基准要求不一致带来的被动调整

• 外部事件

项目变更的类型我们也可以从不同的维度划分：

• 按变更性质：可分为重大变更、重要变更和一般变更。通过不同审批权限控制。

• 按变更的迫切性：可分为紧急变更和非紧急变更，通过不同变更处理流程进行。

• 按变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更。

• 按变更所发生的空间，可分为内部环境变更和外部环境变更。

• 按变更的内容，IT行业的变更更进一步可细分为多个子行业（如弱电工作、应用开发、集成和IT咨询等）的变更。

这两部分内容是我们之前在 项目整体管理 的 实施整体变更控制 中学习过的哦，大家还有印象吗？原因最后可以总结哪五个字还记得吗？不记得的小伙伴可以回去复习一下哦！

项目变更管理流程

变更管理的原则是项目基准化、变更管理过程规范化，包括以下内容：

• 基准管理

• 变更控制流程化

• 明确组织分工

• 评估变更的可能影响

• 妥善保存变更产生的相关文档

变更管理组织机构

在项目团队中，负责变更管理的其实最主要的就是一个机构和一个角色。机构指的就是 CCB ，而角色则指的是项目经理。我们再来一个一个的看一下。

• 项目控制委员会（CCB——Change Control Board）或配置控制委员会（CCB）。通常由项目经理、用户代表、质量控制人员（QC）、配置管理人员（CMO）等组成。它是一个决策机构，不是作业机构。通常 CCB 的工作是通过评审手段来决定项目基准是否能变更，但不提出变更方案。

• 项目经理（PM）。响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策；并根据评审结果实施即调整基准。确保项目基准反映项目实施情况。

变更控制

变更控制主要由配置控制委员会（Configuration Control Board，CCB），负责对配置变更做出评估、审批以及监督已批准变更的实施。其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。变更管理的任务主要有三个：

• 分析变更，根据成本/效益和涉及的技术判断变更的必要性，确定是否进行变更

• 记录和跟踪变更

• 采取措施保证变更受控。这些措施其实就包括配置库、变更控制和变更记录。

我们在 项目整体管理 的 实施整体变更控制 过程中学习过一套变更流程。在这里再给出一个信息系统方面的变更流程，其实和之前我们学过的变更流程是差不多的，如果简答题碰到了回答哪个都是可以的。

• 提出接受变更申请

• 对变更的初审（常见方式：变更申请文档的审核流转）

• 变更方案论证（技术评估转换成果、经济评估转换价值和风险）

• 项目变更控制委员会 CCB 审查（文档会签形式）

• 发出变更通知并开发实施

• 变更实施的监控（项目经理负责项目基准的监控；管理委员会监控成果、进度里程碑）

• 变更效果的评估

• 判断发生变更后的项目是否已纳入正常轨道

在项目变更时，应该注意以下几点：

• 对变更产生的因素施加影响：防止不必要的变更，减少无谓的评估，提高必要变更的通过效率。

• 对变更的确认应当正式化。

• 变更的操作过程应当规范化。

版本发布和回退计划

为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案。版本发布前的准备工作包括：

• 进行相关的回退分析

• 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理

• 备份配置数据，包括数据备份的方式

• 备份在线生产平台接口、应用、工作流等版本

• 启动回退机制的触发条件

• 对变更回退的机制职责的说明

为确保每次版本发布风险的可防可控，可以准备以下的回退方案：

• 通知相关用户系统开始回退

• 通知各关联系统进行版本回退

• 回退存储过程等数据对象

• 配置数据回退

• 应用程序、接口程序、工作流等版本回退

• 回退完成通知各周边关联系统

• 回退后进行相关测试，保证回退系统能够正常运行

• 通知用户回退完成

总结

今天的内容非常简单吧？主要是如果你之前好好学习过了，那么关于变更的内容其实你都会有一些印象。但是如果你是第一次接触项目管理的话，之前没记住也是很正常的。所以，可以将今天的内容当作是一次变更相关的汇总资料。好吧，整个变更相关的内容都是重点咯。最后的版本相关的内容了解一下即可。

参考资料：

《信息系统项目管理师教程》

《某机构培训资料》

《项目管理知识体系指南 PMBOK》第六版