Appearance
配置管理与变更管理（零基础版）：管住图纸版本，管住"临时起意"
本页导读：装修进行到一半，业主突然说："客厅这面墙别敲了，改回原来的。"这时马上冒出一串问题：现在手里的图纸到底是哪一版？工人手里的是不是最新版？改墙这个要求谁说了算？——这就是配置管理（管住"现在到底是什么版本"）和变更管理（管住"能不能改、怎么改"）要解决的事。本页从零讲起：配置项、基线、三库（开发库/受控库/产品库）用"图纸放在哪个抽屉"讲清楚；变更八步流程用"业主改户型、全家开会拍板"演一遍。这两个考点是软考特色，PMBOK 里着墨少、第4版教程单独成章，案例题的保留节目。
一、开胃比喻：图纸抽屉与家庭会议
配置管理 = 图纸版本管理。
装修队的图纸桌上摆着三摞图纸，对应三个"抽屉"：
- 开发库（草稿抽屉）：设计师随手改的草图，今天画个开放式厨房、明天改回封闭式，随便涂；
- 受控库（定稿抽屉）：业主签字确认过的版本，想改必须走流程（填单子、说理由、审批），不能谁想拿笔就改；
- 产品库（交付抽屉）：竣工验收后归档的最终版，锁起来，只能看不能动。
为什么要分三个抽屉？血泪教训：设计师口头说"墙往左挪 30 公分"，工人挪了；第二天业主说"谁让你挪的？"——双方各执一词，因为没人说得清"以哪版为准"。配置管理的使命就是让"现在系统到底是什么状态"永远清清楚楚。
变更管理 = 业主临时要改户型。
业主在工地看着毛坯房突然说："主卧飘窗改成落地窗吧！"包工头怎么办？
- 先让业主把要求写下来（口头的不算，要填变更申请单）；
- 包工头初审：单子信息全不全；
- 找设计师算账：改飘窗要加多少钱、工期延误几天、结构安全有没有问题（影响评估与方案论证）；
- 全家开会拍板（业主、出资的爸妈、设计师坐一起 = CCB 变更控制委员会）：批不批？
- 批了就发通知、按新图纸施工（实施）；
- 施工中盯着按批准的方案干（监控）；
- 改完后验收效果（评估）；
- 新图纸入定稿抽屉、变更单归档，以后都以新版为准（入库归档）。
这八步就是教材的变更管理八步流程。核心精神一句话：改可以，但要"先批后改、全程留痕、改完归档"。
二、你将学会
读完本页，你将能够：
- 分清配置管理与变更管理各自的职责（版本底座 vs 改动闸门）；
- 说出配置项、基线（功能/分配/产品）的含义与状态流转；
- 用"三个抽屉"判断任何工件该放开发库、受控库还是产品库；
- 背出配置管理四大活动（识别、控制、状态报告、审计）与两类审计（功能 FCA/物理 PCA）；
- 熟练背写变更八步流程（提—审—论—批—行—控—评—归）；
- 说清 CCB 的角色定位（只批不改）与紧急变更的处理（先做后补）。
三、知识框架图
- 配置管理（管版本）
- 配置项：纳入版本管理的产品/过程工件，状态：草稿→正式→修改中
- 基线：经正式评审批准的版本，改必须走变更（功能基线/分配基线/产品基线）
- 配置库三抽屉：开发库（随便改）→ 受控库（改走流程）→ 产品库（严控归档）
- 四大活动：配置项识别、配置项控制、配置状态报告、配置审计（FCA+PCA）
- 变更管理（管改动）
- 变更分类：基准变更/非基准变更、重大/一般、紧急变更
- CCB 变更控制委员会：审批变更的决策机构
- 变更八步流程：提出→初审→论证→审批→实施→监控→评估→归档
- 二者关系：配置管理是变更管理的基础——改之前先知道"现在是什么"，改之后记得"换成新版本"
四、配置管理精讲（管住版本）
1. 配置项：什么东东归我管
定义（大白话）：凡是要"管版本、防乱改"的产品或过程工件，都是配置项。装修版的图纸、预算表、材料清单；软件版的需求文档、设计文档、代码、测试用例、计划文件。
分类：
- 产品配置项（交付件）：最终要交给客户的东西——系统程序、用户手册；
- 非产品配置项（过程件）：不交付但支撑过程的工件——项目计划、会议纪要。
状态流转（三态）：草稿 → 正式发布 → 正在修改。
- 草稿状态：随便改，放草稿抽屉（开发库）；
- 正式发布：通过评审、入库受控，从此不能随手改；
- 正在修改：要走变更流程把文档"借出"改，改完评审通过再"还回去"。
版本编号惯例（了解）：草稿 0.x.y；正式版 X.Y；修改中 X.YZ。以组织规范为准，考概念不抠细节。
2. 基线：钉死的那一版
定义（大白话）：基线就是"大家都签字认可的版本"，是后续工作的起跑线。像业主确认过的施工图：从此施工都以它为准，要改必须走变更流程。基线不是不能改，而是"改必须走正式变更控制"——这是最常考的一句话。
| 基线 | 什么时候形成 | 装修版对应 | 钉死了什么 |
|---|---|---|---|
| 功能基线 | 需求分析完成、需求规格评审通过 | 业主确认的《需求清单》 | 系统要做什么（功能与技术指标） |
| 分配基线 | 概要设计/需求分配完成 | 设计师出的《施工图》 | 功能怎么分到各模块/工种 |
| 产品基线 | 测试验收阶段 | 竣工验收版全套图纸文档 | 最终交付产品的完整形态 |
零基础辨析：配置管理的"基线"和十大领域的"基准"（范围基准、进度基准、成本基准）概念相通——都是"经批准的起点"，只是配置基线侧重文档与产品的版本，基准侧重计划的目标值。
3. 配置库：三个抽屉（高频判断题）
| 库 | 别名 | 放什么 | 谁能动 | 装修版 |
|---|---|---|---|---|
| 开发库 | 动态库/工作区 | 正在写、随便改的日常版本 | 开发人员自由读写 | 设计师桌上的草图纸 |
| 受控库 | 主库 | 通过评审的基线版本、里程碑版本 | 检入/检出受控，改要走变更 | 业主签字的定稿抽屉 |
| 产品库 | 静态库/备份库 | 已发布交付的正式版本 | 严控，一般只读，出库要审批 | 竣工归档的最终图纸 |
典型流转：草稿在开发库写 → 评审通过检入受控库（成为基线） → 交付发布后入产品库归档。判断口诀：随便改的进开发库，定稿的进受控库，交出去的进产品库。
配置管理计划：写清哪些东西入库、怎么命名编号、三库权限怎么分、基线怎么建怎么改、审计什么时候做谁做、状态报告多久出一次。日常由**配置管理员（CMO）**操作配置库。
4. 配置管理四大活动（必背）
- 配置项识别：圈定"哪些东西要管版本"，定命名编号规则；
- 配置项控制：管住"出库—修改—评审—入库"全流程，任何改动可追溯；
- 配置状态报告：记账先生——记录并汇报每个配置项的状态变化（哪个版本、谁改的、变更批没批），回答"现在是什么版本、改过什么"；
- 配置审计：对账先生——核实"库里存的、实际做的、文档记的"三者一致，分两种：
- 功能配置审计（FCA）：查"做的和说的一致"——功能是否与需求文档对得上；
- 物理配置审计（PCA）：查"交的和记的一致"——交付物的构成、版本、文档是否齐全（有没有少一本《安装手册》）。 记法：FCA 管功能对不对，PCA 管东西全不全。
五、变更管理精讲（管住改动）
1. 为什么变更是常态、又必须管住
项目"渐进明细"（细节越干越清楚）+ 环境一直变 ⇒ 变更不可避免。但放任自流 = 范围蔓延 + 基线失效：业主每天口头改一句，一个月后没人知道合同范围是什么，钱和工期全失控。
教材三大原则：基准化原则（变更前得有基线，知道从哪改起）、变更控制原则（一切改动走流程）、过程记录原则（全程留痕可追溯）。
2. 变更怎么分类
- 基准变更 vs 非基准变更：动范围/进度/成本基线的（大动干戈，必须 CCB）；一般文档、过程调整的（非基准，流程可简化）；
- 重大变更 vs 一般变更：按影响分级审批；
- 紧急变更：机房半夜宕机，等开会黄花菜都凉了——可以先实施、后补审批手续。"先做后补"合规的前提是事后补齐手续（案例题判断点）。
3. CCB：全家开会拍板的那个会
CCB（Change Control Board，变更控制委员会）= 装修决策的"家庭会议"：
- 谁坐席：项目主要干系人代表——发起方（出钱的爸妈）、管理方、实施方（包工头/设计师）、技术专家、客户代表；可设多级（公司级/项目级），主席通常是有决策权的管理者；
- 干什么：审批变更——批准、否决、推迟；
- 不干什么：不负责实施（实施是项目经理和团队的事），也不负责提变更（谁都能提）。
考点一句话：CCB 是决策机构，只批不改；项目经理负责提交与执行。
4. 变更八步流程（必背顺序）
接着开篇"改飘窗"的故事，八步对应：
| 步骤 | 名称 | 装修版画面 | 关键动作 |
|---|---|---|---|
| 1 | 提出与接受变更申请 | 业主填《飘窗改落地窗申请单》 | 任何干系人可提，必须书面 |
| 2 | 变更初审 | 包工头查单子：信息全不全、理由清不清 | 形式审查，不用深评估 |
| 3 | 变更方案论证 | 设计师算账：加钱多少、误期几天、结构安全吗 | 技术可行性+影响评估 |
| 4 | CCB 审查 | 全家开会：批/否/缓 | 批准与否决都在这步 |
| 5 | 发出变更通知并组织实施 | 会议结论贴出来，工人拿新图纸开工 | 更新计划与基线再实施 |
| 6 | 变更实施的监控 | 包工头盯着：确实按批准的方案改 | 防止"批的是 A 做成 B" |
| 7 | 变更效果的评估 | 改完验收：落地窗装好了、没漏水 | 验证目的达成、无新问题 |
| 8 | 判断是否纳入正常轨道 | 新图纸入定稿抽屉、变更单归档 | 更新配置库、关闭变更单 |
记忆口诀：提—审—论—批—行—控—评—归。（"提"出申请、"审"初审、"论"证方案、"批"CCB 拍板、实"行"、"控"制实施、"评"估效果、归档收尾。）
顺序考点（选择题陷阱）：论证在初审之后（先查单子全不全，再花力气评估）；CCB 审批在实施之前（先批后改是铁律）；监控在实施之后；评估完才能归档。
5. 变更流程常见错误（案例找错模板）
- 口头变更、没有书面申请（业主微信语音说改就改了）；
- 项目经理未经评估直接答应/拒绝客户；
- 未走 CCB 审批就实施基准变更；
- 批准后不更新计划与基线、不通知相关干系人；
- 实施后不验证效果、不做配置入库；
- 变更记录缺失，无法追溯（连改过几次飘窗都说不清）。
六、把两者串起来：一个需求的完整闭环
场景：业主提出"次卧加一个飘窗插座"。正确姿势全程走一遍（案例题满分顺序）：
- 业主提交书面变更申请（变更单编号登记）；
- 包工头（项目经理）初审：单子信息完整；
- 设计师论证：影响评估（材料+200 元、工期+0.5 天、无结构风险），给出实施方案；
- 提交 CCB（家庭会议）审批：批准；
- 发出变更通知：更新图纸与预算（基线变更），工人按新图施工；
- 监控实施：确认按批准方案做，没顺手多改别的；
- 评估效果：插座装好、测试通电、无新问题；
- 归档闭环：新图纸版本检入受控库（配置项控制），变更单关闭归档，配置状态报告记录这次变更——从此"次卧图纸 V2.1（含插座）"成为唯一真相。
配置管理场景判断速查（表格化）：
| 场景 | 判断 |
|---|---|
| 未经审批直接改了受控库文档 | 违反配置项控制 |
| 发给客户的版本与测试版本不一致 | 缺配置审计/状态报告 |
| 基线变了但没人知道改了什么 | 缺配置状态报告 |
| 交付时发现缺《安装手册》 | 物理配置审计（PCA）能发现 |
| 需求规格与实际功能对不上 | 功能配置审计（FCA）能发现 |
七、高频考点与易错点
- 三库判断题：给场景选库——"开发中频繁修改的代码"→开发库；"通过评审的需求基线"→受控库；"已交付客户的正式版本"→产品库。
- 基线三分类：功能基线（需求）→分配基线（设计）→产品基线（交付）；基线可改但必须走变更控制。
- 配置审计二分：功能审计（FCA）查功能一致性、物理审计（PCA）查构成齐套性——张冠李戴是高频坑。
- 八步顺序题：提—审—论—批—行—控—评—归；先批后改；批的是 A 不能做成 B。
- CCB 职责：只批不改；实施归项目经理与团队。
- 易错点清单：
- 配置状态报告属于配置管理活动，不是发给客户的绩效报告；
- 紧急变更"先做后补"合法，但必须补手续；
- 变更完成要"入库归档"才算闭环；
- 配置管理是变更管理的基础（不是反过来）；
- 变更申请人人可提，审批权在 CCB。
八、例题（自编模拟题，带详解）
【例题 1】 业主在工地口头对瓦工说："这面墙的瓷砖横着贴吧。"瓦工当场就改了排砖方案并施工。关于此操作，正确评价与规范做法是（ ）。
A. 响应客户快就是好服务，做法正确 B. 口头变更无效应一律拒绝，业主无权改 C. 应要求业主提交书面变更申请，评估影响后交 CCB 审批，批准后实施并验证、归档 D. 只要业主愿意加钱，可以直接实施
答案：C
详解：变更三铁律：书面化、先批后改、留痕归档。口头要求也要补书面申请（A 错在"口头即干"）；业主当然有权提变更，但流程必须走（B 错在"一律拒绝"）；加钱也得先评估审批（D 错）。C 是八步流程的标准走法。答案选 C。
【例题 2】 关于配置库与配置审计，下列说法正确的是（ ）。
A. 开发人员可以直接修改受控库中的基线版本 B. 开发库中的工作产品经评审通过后应检入受控库 C. 功能配置审计（FCA）检查交付物是否齐全 D. 物理配置审计（PCA）检查功能与需求是否一致
答案：B
详解：受控库的基线要改必须走出库—变更—评审—入库流程，不能直接改（A 错）。C、D 正好张冠李戴：FCA 查功能一致性（做的和说的一致），PCA 查物理齐套性（交的和记的一致）。B 是标准流转：开发库（草稿）→评审→检入受控库。答案选 B。
九、术语卡（考前扫一眼）
| 术语 | 一句话解释 |
|---|---|
| 配置项 | 要管版本的产品/过程工件 |
| 基线 | 经正式批准的版本，改必须走变更 |
| 功能/分配/产品基线 | 需求定稿/设计定稿/交付定稿 |
| 开发库 | 草稿抽屉：随便改 |
| 受控库 | 定稿抽屉：改走流程（检入/检出） |
| 产品库 | 交付抽屉：严控归档 |
| 配置项识别 | 圈定管什么、定命名规则 |
| 配置项控制 | 出库—修改—评审—入库全流程管控 |
| 配置状态报告 | 记账：版本与变更状态汇报 |
| FCA/PCA | 功能审计（做没做对）/物理审计（东西全不全） |
| CMO | 配置管理员：日常管库的人 |
| CCB | 变更控制委员会：只批不改 |
| 变更八步 | 提—审—论—批—行—控—评—归 |
| 紧急变更 | 先做后补，事后必须补手续 |
| 范围蔓延 | 不受控的变更悄悄堆大范围 |
十、自测 5 题（先做再看答案）
点击展开自测题与答案
1. 变更管理八步流程中，"变更方案论证"和"CCB 审批"的正确顺序是（ ）。
A. 先论证后审批：评估清楚了才好拍板 B. 先审批后论证：领导同意了再花力气评估 C. 两者可并行，无先后要求 D. 论证只用于重大变更，一般变更可跳过审批
答案：A。流程是提出→初审→论证→审批：论证给审批提供依据（B 顺序反）；并行与跳过都违反流程控制。
2. 项目深夜遭遇机房宕机，运维人员未经审批临时修改了配置恢复业务。事后正确的处理是（ ）。
A. 属于违规操作，应追究责任并恢复原配置 B. 属于紧急变更，可先实施，但事后必须补办审批与记录手续 C. 无需任何处理，恢复业务就是最高优先级 D. 直接关闭变更流程，不必留痕
答案：B。紧急变更"先做后补"合法，但事后必须补审批手续并记录归档——"补"是合规的前提。
3. 已通过评审并入库受控的《需求规格说明书》，因客户新增需求需要修改。正确路径是（ ）。
A. 开发人员直接改完再评审 B. 走变更流程批准后从受控库出库修改，评审通过后检入形成新版本 C. 在开发库里改一份新的，受控库里的旧版作废 D. 直接删除旧版，避免版本混乱
答案：B。受控库基线的修改路径：变更批准→出库→修改→评审→检入新版本。A、C、D 都绕开了变更控制。
4. 交付验收时发现交付物里缺少《用户操作手册》。这本来可以通过哪项配置管理活动提前发现？（ ）
A. 配置状态报告 B. 功能配置审计（FCA） C. 物理配置审计（PCA） D. 配置项识别
答案：C。PCA 检查交付物的构成、版本与文档齐套性——"交的和记的"是否一致；FCA 查的是功能一致性。
5. 关于配置管理与变更管理的关系，最准确的说法是（ ）。
A. 两者互不相关，各管各的 B. 配置管理是变更管理的基础，变更后的新版本要回到配置管理中入库归档 C. 变更管理是配置管理的基础 D. 配置管理只管代码，变更管理只管文档
答案：B。配置提供版本/基线底座（改之前知道"现在是什么"），变更控制对基线的改动（改之后记得入库归档）。C 关系颠倒；A、D 明显错误。
十一、本页小结
- 配置管理四活动：识别（管什么）、控制（怎么改）、状态报告（记着什么）、审计（对不对账）——FCA 查功能、PCA 查齐套。
- 三库三抽屉：开发库随便改 → 受控库改走流程 → 产品库严控归档。
- 三基线：功能（需求）→ 分配（设计）→ 产品（交付）；基线可改，但必须走正式变更控制。
- 变更八步：提—审—论—批—行—控—评—归；先批后改、全程留痕、改完归档。
- CCB 只批不改；紧急变更先做后补（必须补）；配置是底座，变更是闸门。