1. 文档管理

1.1. 分类

1.1.1. 开发文档

1.1.1.1. 描述开发过程本身

1.1.1.2. 可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明（包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等）

1.1.2. 产品文档

1.1.2.1. 描述开发过程的产物

1.1.2.2. 培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告

1.1.3. 管理文档

1.1.3.1. 记录项目管理的信息

1.1.3.2. 开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义、项目计划、项目阶段报告；配置管理计划

1.2. 文档的质量

1.2.1. 最低限度文档（1级文档）

1.2.1.1. 适合开发工作量低于一个人月的开发者自用程序

1.2.1.2. 包含程序清单、开发记录、测试数据和程序简介

1.2.2. 内部文档（2级文档）

1.2.2.1. 没有与其他用户共享资源的专用程序

1.2.2.2. 1级文档提供的信息

1.2.2.3. 包括程序清单内足够的注释以帮助用户安装和使用程序

1.2.3. 工作文档（3级文档）

1.2.3.1. 同一单位内若干人联合开发的程序

1.2.4. 正式文档（4级文档）

1.2.4.1. 正式发行供普遍使用的软件产品

1.2.4.2. 遵守GB/T 2006-8567《计算机软件文档编制规范》的有关规定

1.3. 规则和方法

1.3.1. 文档书写规范

1.3.2. 图表编号规则

1.3.3. 文档目录编写标准

1.3.4. 文档管理制度

1.3.4.1. 文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则

1.3.4.2. 注意保密

1.3.5. 【高23上选61】

2. 变更管理

2.1. 【高22上案一】

2.1.1. 【高20下案一】

2.1.2. 【高23上选60】

2.2. 对变更从提出、审议、批准到实施、完成的整个过程的管理

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

2.3.1. 【高22上选50】

2.4. 变更管理，即是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法

2.4.1. 【高21上选52】

2.5. 变更管理工具

2.5.1. 【高19下选52】

2.6. 每一个记入文件的变更申请必须由项目管理团队内部的有权者，或者代表某一外部组织的发起人、赞助人或顾客认可或否决

2.6.1. 【高18上选36】

3. 变更产生原因

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

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

3.3. ③增值变更

3.4. ④应对风险的紧急计划或回避计划

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

3.6. ⑥外部事件

4. 变更分类

4.1. 变更性质

4.1.1. 重大变更

4.1.2. 重要变更

4.1.3. 一般变更

4.1.4. 【高21下选52】

4.2. 迫切性

4.2.1. 紧急变更

4.2.2. 非紧急变更

5. 变更的诱发

5.1. 主动变更

5.1.1. 常用于提高项目收益，包括降低成本、改进过程以及提高项目的便捷性和有效性等

5.2. 被动变更

5.2.1. 常用于范围变化、异常、错误和适应不断变化的环境等

6. 管理原则

6.1. 项目基准化和变更管理过程规范化

6.2. 基准管理

6.2.1. 基准是变更的依据

6.3. 变更控制流程化

6.4. 明确组织分工

6.5. 评估变更的可能影响

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

7. 角色与职责

7.1. 项目经理

7.1.1. 组织委托的项目经营过程负责者

7.1.2. 响应变更提出者的需求

7.1.3. 评估变更对项目的影响及应对方案

7.1.4. 将需求由技术要求转化为资源需求，供授权人决策

7.1.5. 并据评审结果实施（即调整基准），确保项目基准反映项目实施情况

7.2. 变更管理负责人

7.2.1. 变更经理

7.2.2. 变更管理过程解决方案的负责人

7.2.3. ①负责整个变更过程方案的结果

7.2.4. ②负责变更管理过程的监控

7.2.5. ③负责协调相关的资源，保障所有变更按照预定过程顺利运作

7.2.6. ④确定变更类型，组织变更计划和日程安排

7.2.7. ⑤管理变更的日程安排

7.2.8. ⑥变更实施完成之后的回顾和关闭

7.2.9. ⑦承担变更相关责任，并且具有相应权限

7.2.10. ⑧可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批

7.3. 变更请求者

7.3.1. 提交初步的变更方案和计划

7.3.2. 初步评价变更的风险和影响，给变更请求设定适当的变更类型

7.3.3. 对理解变更过程有能力要求

7.4. 变更实施者

7.4.1. 拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务

7.5. 变更顾问委员会

7.5.1. 负责对重大变更行使审批，提供专业意见和辅助审批

7.5.2. CCB 是决策机构，不是作业机构

7.5.2.1. 【高21上选53】

7.5.3. 在紧急变更时，其中被授权者行使审批权限

7.5.4. 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议

8. 变更控制

8.1. 变更申请的控制

8.1.1. 变更控制的前提是项目基准健全，变更处理的流程事先共识

8.2. 变更过程控制

8.2.1. 对进度变更的控制

8.2.2. 对成本变更的控制

8.2.3. 对合同变更的控制

8.2.3.1. 规定合同修改的过程

8.3. 变更实施的过程监控，通常由项目经理负责基准的监控。管理委员会监控变更明确的主要成果、进度里程碑等，可以通过监理单位完成

8.3.1. 【高22上选51】

8.4. 负责组织对变更申请进行评估并确定以下内容

8.4.1. 【高22上选49】

8.4.2. 变更对项目的影响

8.4.3. 变更的内容是否必要

8.4.4. 变更的范围是否考虑周全

8.4.5. 变更的实施方案是否可行

8.4.6. 变更工作量估计是否合理

9. 版本发布和回退计划

9.1. 版本发布前的准备工作

9.1.1. ①进行相关的回退分析

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

9.1.3. ③备份配置数据，包括数据备份的方式

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

9.1.5. ⑤启动回退机制的触发条件

9.1.6. ⑥对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点

9.2. 过程检查单（Checklist）

9.3. 回退步骤

9.3.1. ①通知相关用户系统开始回退

9.3.2. ②通知各关联系统进行版本回退

9.3.3. ③回退存储过程等数据对象

9.3.4. ④配置数据回退

9.3.5. ⑤应用程序、接口程序、工作流等版本回退

9.3.6. ⑥回退完成通知各周边关联系统

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

9.3.8. ⑧通知用户回退完成

10. 变更的工作程序

10.1. 【高21下选53】

10.2. 所有变更都需要走变更流程，并且记录文档

10.2.1. 【高19下选28】

10.3. 变更申请

10.4. 对变更的初审

10.4.1. 对变更提出方施加影响，确认变更的必要性，确保变更是有价值

10.4.1.1. 【高20下选53】

10.4.2. 格式校验，完整性校验，确保评估所需信息准备充分

10.4.3. 在干系人间就提出供评估的变更信息达成共识

10.5. 变更方案论证

10.6. 变更审查

10.7. 发出通知并实施

10.8. 实施监控

10.9. 效果评估

10.10. 变更收尾

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

10.11. 【高19下选53】

10.11.1. 【高18下选53】

10.11.2. 【高18上选52】