点赞 💡 为热爱充电**| 关注 🌐**为同行导航
收藏 📎 为价值存档**| 评论 ✨**为共鸣发声
目录
[2.1 变更管理基础](#2.1 变更管理基础)
[2.1.1 变更管理与配置管理的关系](#2.1.1 变更管理与配置管理的关系)
[2.1.2 变更的常见原因](#2.1.2 变更的常见原因)
[2.1.3 变更分类](#2.1.3 变更分类)
[2.1.4 变更管理原则](#2.1.4 变更管理原则)
[2.1.5 变更程序](#2.1.5 变更程序)
[2.2 角色与职责](#2.2 角色与职责)
[2.2.1 变更控制委员会（CCB）](#2.2.1 变更控制委员会（CCB）)
[2.2.2 变更管理负责人（变更经理）](#2.2.2 变更管理负责人（变更经理）)
[2.2.3 变更请求者](#2.2.3 变更请求者)
[2.2.4 变更实施者](#2.2.4 变更实施者)
[2.2.5 变更顾问委员会](#2.2.5 变更顾问委员会)
[2.3 版本发布和回退计划](#2.3 版本发布和回退计划)
[2.3.1 版本发布的准备工作](#2.3.1 版本发布的准备工作)
[2.3.2 回退步骤](#2.3.2 回退步骤)
[3.1 项目文档分类](#3.1 项目文档分类)
[3.2 文档质量级别](#3.2 文档质量级别)
[3.3 文档规则和方法](#3.3 文档规则和方法)
[🔥 感谢有你，我的创作才更有意义！🔥](#🔥 感谢有你，我的创作才更有意义！🔥)
2.变更管理
- 定义： 项目做着做着，因为环境变化或各种原因，需要改项目的功能、性能、架构、技术要求、集成方式、进度等，对这些修改进行管理 ，就是项目变更管理。
- 定位： 它属于项目整体管理的一部分，归在整体变更控制里，用来管住项目范围、保证项目能按目标做完。
2.1 变更管理基础
2.1.1 变更管理与配置管理的关系
- 配置管理 ：如果把项目要交付的所有成果当成 "配置项" 来管，相当于一套守护项目完整、不乱套的管理系统。
- 变更管理 ：项目做到一半要改需求、改进度、改功能时，走的一套审批、实施、确认的流程。
两者关系：
- 可以理解成：变更管理是配置管理的一部分 ，专门用来调整项目基准。
- 也可以看成：两套互相配合的机制。要改基准时，配置管理会调用变更管理；变更改完后，再把结果同步回配置管理，保证项目实际情况和文档记录完全对得上。
2.1.2 变更的常见原因
- **产品范围（成果）**定义时，考虑不周、出错或漏项
- **项目范围（工作）**没定义清楚，有遗漏或错误
- 增值变更
- 为了应对风险，启动应急方案或避开风险
- 项目实际执行和原定计划不一致，被迫调整
- 外部 发生了不可控的事件，导致必须变更
2.1.3 变更分类
- 按变更重要程度分 ：
- 重大变更、重要变更、一般变更
- 不同级别，审批权限不一样
- 按紧急程度 分：
- 紧急变更、非紧急变更
2.1.4 变更管理原则
- 以基准 是变更的依据，不乱改
- 变更必须走流程，不能口头说改就改
- 明确组织分工
- 改之前必须评估会带来什么影响
- 变更相关的文档要保存好 ，必要时用++配置管理工具++来管
2.1.5 变更程序
-
变更申请： 相关人员提出要修改的需求，正式提交变更申请。
-
对变更的初审： 先简单审核变更是否合理、有没有必要，初步过滤不合理的变更。
-
变更方案论证：详细分析变更怎么做、要花多少时间成本、有什么风险和影响。
-
变更审查：CCB （变更控制委员会）正式评审，决定是否批准变更。
-
发出通知并实施： 批准后通知相关人员，按方案执行变更。
-
实施监控： 在变更过程中跟踪进度，确保按要求完成，不跑偏。
-
效果评估： 变更做完后，检查是否达到预期 ，有没有带来新问题。
-
变更收尾：记录 变更结果，更新配置项和相关文档，完成闭环。
变更管理细节：
- 项目的任何干系人 都可以提出变更申请；
- 变更申请的提交，首先应当确保要改的所有操作都写清楚，不能漏项；
- 所有变更申请都必须以书面形式 记录，并纳入变更管理 以及配置管理系统中；
- 每项变更申请都必须由一个责任人批准或否决 ，这个责任人通常是项目发起人 或项目经理；
- 必要时，应该由变更控制委员会**（CCB）** 进行审查批准；
- 变更控制委员会 是由主要项目干系人的代表组成的一个小组 ，项目经理 可以是其中成员之一，但通常不是组长。
2.2 角色与职责
2.2.1 变更控制委员会（CCB）
- 相当于项目的决策小组，代表项目方权益，能不能改CCB说了算。
- 成员一般是用户方 和实施方的领导 / 决策人。
- 只做决策、评审，不干活、不写变更方案。
- 只负责判断：项目基准能不能变，不负责具体怎么改。
2.2.2 变更管理负责人（变更经理）
是整个变更流程的总负责人，主要干这些事：
- 对整个变更方案 和最终结果负责
- 全程盯着变更流程，做好监控
- 协调人员、资源，保证变更按流程顺利进行
- 确定 变更类型 ，组织 制定变更计划 和时间安排
- 管理变更的实施时间和进度
- 变更做完后，进行回顾 并正式关闭变更
- 承担变更相关责任 ，同时有对应的审批 、管理权限
- 可以通过逐级审批或开会的方式，参与变更的风险评估与审批
2.2.3 变更请求者
- 提变更需求的人。
- 负责填写并提交变更申请单。
- 提交初步 的变更方案和计划。
- 简单评估 风险和影响，给变更分类型。
- 要能理解变更流程。
2.2.4 变更实施者
- 具体动手变更的人。
- 要有对应的技术能力。
- 按照实施计划，真正去完成变更工作。
2.2.5 变更顾问委员会
变更顾问委员会 主要负责审批重大变更 ，同时给出专业建议、协助审批：
- 遇到紧急变更 时，由委员会里被授权的人员直接行使审批权；
- 定期听变更经理汇报 工作，评估变更管理做得怎么样，有问题就提改进建议。
2.3 版本发布和回退计划
绝大多数信息系统项目，只要做了项目变更，必须同步更新版本、发布新版本 ，而且提前备好应急回退方案（万一发布失败能快速复原）。
核心要求：
-
严控版本发布 ：每次新版本发布前，都要专人管理、做好前置准备，杜绝盲目上线。
-
备好回退预案 ：提前写好 发布失败后的回退步骤 ，确保出问题能快速撤回、恢复原状。
事后复盘优化：
-
深挖回退原因 ，总结经验教训，避免下次再出现同类问题。
-
复盘 回退执行过程中的问题 ，完善回退机制，让后续回退更顺畅。
2.3.1 版本发布的准备工作
- 做好回退分析，出问题能快速定位。
- 备份好数据库里的存储 过程、函数等内容，方便出问题时回退。
- 备份配置数据，并明确用什么方式数据备份。
- 备份 生产环境里的接口、应用、工作流等版本。
- 明确什么时候触发回退，达到什么条件就立刻撤版。
- 说清楚回退由谁负责 、怎么通知 相关部门、要回退哪些关联系统 、什么时间点回退。
2.3.2 回退步骤
- 先通知相关用户，系统要开始回退了
- 通知所有关联系统，一起进行版本回退
- 把数据库里的存储过程等数据对象恢复回去
- 把配置数据也恢复到之前的版本
- 回退应用、接口、工作流等程序版本
- 回退完后，通知 各个关联系统
- 做完测试 ，确认系统能正常运行
- 最后通知用户，回退完成
3.文档管理
3.1 项目文档分类
3.2 文档质量级别
| 文档级别 | 描述 | 啥意思 | 里面写啥 |
|---|---|---|---|
| 1 级文档 | 最低限度文档 | 开发工作量很小（少于一个人月），纯粹自己用，不打算给别人看。 | 代码清单、开发时随手记的东西、测试数据、程序简单介绍。 |
| 2 级文档 | 内部文档 | 给本单位内部同事 用的专用程序，不对外公开，大家知道怎么装怎么用就行。 | 代码里写点注释，说清楚怎么安装、怎么用就够了。 |
| 3 级文档 | 工作文档 | 要么是本单位好几个人一起做的，要么是准备给别的单位使用的，需要正式一点。 | 按标准写清楚，方便多人协作或对外交接。 |
| 4 级文档 | 正式文档 | 正儿八经拿出来卖 或者给大众用 的，质量要求最高，比如工资系统这类关键软件。 | 写得最规范、最完整，跟正规软件产品一样。 |
简单说就是：自己用→同事用→单位间用→大众用，文档要求依次变高。
3.3 文档规则和方法
（1）文档书写规范
（2）图表编号规则
（3）文档目录编写标准
（4）文档管理制度
注意： 文档的规则不包含 ：文档的保密(安全) 、 文档的权限
图表编号规则：
🔥 感谢有你，我的创作才更有意义！🔥
