组织保障

这一章在讲什么

前面 9–14 章讲的是"怎么把一个项目管好"，这一章讲的是"组织凭什么能一直把项目管好"——靠三样东西：资料管得住（15.1 信息和文档管理）、版本管得住（15.2 配置管理）、变更管得住（15.3 变更管理）。

这三节是递进关系：先知道项目里有哪些信息和文档、怎么分类分级；再把这些东西纳入配置管理，编号入柜、状态留痕；最后，凡是要改，一律走变更管理——而配置管理正是变更管理的基础和载体。

本书把变更管理单列一节，是因为"许多项目失败是对变更处理不当造成的"，它同时也是下午案例大题的常客。

逻辑骨架

一句话脉络：东西先认全 → 编号入柜管版本 → 要改就走流程 → 改完发版留退路。

考点地图

本章速记

• 配置库三种：开发库（动态库/程序员库，开发人员自行控制）→ 受控库（主库，当前基线＋对基线的变更）→ 产品库（静态库/发行库，已发布基线的存档）。
• 配置项三状态与版本号：草稿 0.YZ、正式 X.Y（首次 1.0）、修改 X.YZ（改完转正式 Z 置 0、增加 X.Y）。
• 基线配置项 vs 非基线配置项：设计文档、源代码、可执行代码、数据库脚本、需求规格说明书＝基线；各类计划和报告＝非基线。基线配置项向开发人员开放读取，非基线向 PM、CCB 及相关人员开放。
• 配置审计两种：功能配置审计＝一致性（功效是否与需求一致）；物理配置审计＝完整性（东西在不在、必需项全不全）。审计软件不得自动更新配置库。
• 角色分工：CCB 拍板（决策机构非作业机构）、配置管理员 CMO 干活（识别、基线、状态报告、审计、发布）、配置经理管全局。
• 变更 8 步：申请 → 初审 → 方案论证 → 审查 → 通知并实施 → 实施监控 → 效果评估 → 收尾。
• 变更的依据是项目基准；宜早不宜晚；项目经理管基准监控，CCB 管成果与里程碑，也可由监理完成监控。
• 回退 8 步与发布前准备（回退分析、备份、触发条件、职责说明）常出案例。

节列表

• 15.1 信息和文档管理
• 15.2 配置管理
• 15.3 变更管理
• 15.4 本章练习