配置管理
4.88 配置管理计划
核心定义
配置管理（Configuration Management） ：对项目的产品/成果的版本、规格、属性进行系统化管理，确保所有人使用的都是正确的版本。
⚡ 一句记：配置管理管的是"产品长什么样"，变更控制管的是"能不能改"。两者不同但配套使用。
配置管理 vs 变更控制
| 维度 | 配置管理 | 变更控制 |
|---|---|---|
| 管什么 | 产品/成果的版本 和规格 | 项目能不能改 |
| 核心活动 | 识别配置项、状态记录、版本控制 | 提交变更 → 审批 → 执行 |
| 关键输出 | 配置状态报告、配置项基线 | 批准的变更请求 |
| 考试关键词 | "版本号"、"谁在用哪个版本"、"规格文档" | "变更请求"、"CCB审批" |
配置管理计划的三大活动
┌─────────────────────────────────────────────┐
│ 配置管理计划 │
│ │
│ ① 配置识别 → 哪些是配置项？给编号、建基线 │
│ ② 配置状态记录 → 当前版本是什么？谁在改？ │
│ ③ 配置核实与审计 → 实际和记录一致吗？ │
└─────────────────────────────────────────────┘| 活动 | 做什么 | 举例 |
|---|---|---|
| ① 配置识别 | 确定哪些产出物需要受控，赋予唯一编号，建立基线 | 图纸V1.0、软件V2.3、需求文档REQ-001 |
| ② 配置状态记录 | 跟踪每个配置项的当前版本和历史变更 | 图纸V1.0→V1.1→V2.0，每次改了什么、谁改的 |
| ③ 配置核实与审计 | 定期检查实际产品是否和配置记录一致 | 现场装的设备型号和图纸上的型号一样吗？ |
配置项（Configuration Item）
需要实施配置管理的单个对象。不是所有东西都是配置项，只有关键的、多个团队共享的产出物。
哪些是配置项？
├── 设计图纸（多个团队用）
├── 产品规格说明书（影响制造和验收）
├── 软件源代码（多人协作）
├── 合同（涉及法律）
└── 会议纪要？ ← 一般不是，除非是关键决策记录配置管理基线
配置管理基线
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
功能基线 分配基线 产品基线
(Functional) (Allocated) (Product)
需求冻结 设计冻结 生产冻结
"要做什么定了" "怎么做定了" "最终产品定了"组织过程资产（OPA）与配置管理
OPA（Organizational Process Assets）：组织积累下来的可以复用的资源。分为两类：
| 类别 | 是什么 | 举例 | 与配置管理的关系 |
|---|---|---|---|
| 过程/程序类 | 有形的流程资产 | 模板、流程、政策、程序 | 纳入配置管理------模板也要版本控制 |
| 知识库类 | 无形的知识资产 | 经验教训、项目档案、历史数据 | 归档入库，下次项目配置管理时参考 |
⚡ 核心认知 ：有形的资产（文件/模板/流程）→ 纳入配置管理 控制版本。无形的资产（经验/教训/知识）→ 存入知识库供未来项目参考。两者都是 OPA，但管理方式不同。
OPA 在配置管理中的使用
过去项目的 OPA
│
├── 过程类 → 流程模板 → 本期配置管理计划直接引用
│
└── 知识库类 → 经验教训 →
├── "上次因为版本混乱导致安装错误" → 本次加强配置审计
└── "上次图纸编号规则不清楚" → 本次制定明确的编号规范
本期项目结束时
│
├── 更新过程类 OPA → 优化后的配置管理流程入库
└── 更新知识库类 OPA → 本期的经验教训入库常见错误
| 陷阱 | 正解 |
|---|---|
| 配置管理=变更控制 × | 配置管版本和规格，变更管能不能改，两者配套 |
| OPA 只是文档 × | OPA 分两类：无形的（经验/知识/教训）和有形的（模板/流程） |
| 所有产出物都是配置项 × | 只有关键的、多团队共享的产出物才纳入配置管理 |
| 配置管理是IT的事 × | 任何项目（建筑/制造/服务）都有配置管理需求 |