第 19 章 配置与变更管理本章核心是通过 “配置管理管‘项目资产’、变更管理管‘项目变化’、项目文档管理管‘项目记录’” 三大核心模块让信息系统项目的 “资产可追溯、变化可控制、记录可查询”避免因配置混乱、变更无序、文档缺失导致项目失控。三者相辅相成配置管理是基础变更管理是核心流程文档管理是重要支撑。19.1 配置管理配置管理就像项目的 “资产管家”核心是系统控制配置变更在项目全生命周期维持配置的完整性和可跟踪性—— 简单说就是让每个项目 “零件”配置项的来龙去脉清晰可查变更有迹可循不出现 “找不到旧版本、不知道谁改了、改了什么” 的混乱。19.1.1 管理基础配置项CI纳入配置管理的 “最小资产单位”涵盖软件源代码、可执行程序、硬件服务器、设备、文档需求说明书、测试用例、甚至变更请求、服务协议等经评审通过后统一编号存入配置管理数据库CMDB。分类基线配置项核心资产如设计文档、源代码相当于 “项目核心零件”非基线配置项辅助资产如项目计划、周报相当于 “项目辅助工具”权限规则基线配置项对开发人员开放 “只读权”只能看不能随便改非基线对项目经理、CCB变更控制委员会开放相关操作权。配置项状态按生命周期分三类状态流转清晰可控草稿刚创建未评审如刚写完的需求草稿还没经过团队讨论正式评审通过后 “冻结”如定稿的需求规格说明书不能随意修改修改正式配置项需变更时进入如发现需求遗漏需修改已冻结的文档流转示例需求草稿状态草稿→ 团队评审通过状态正式→ 发现遗漏需修改状态修改→ 再次评审通过状态正式。配置项版本号规则形象记忆不同状态对应不同 “编号格式”避免混乱草稿状态0.YZYZ 为 01-99比如 0.01→0.02→0.03逐步修正正式状态X.YX 为主版本号 1-9Y 为次版本号 0-9首次正式为 1.0小幅度变更累加 Y如 1.1大幅度变更累加 X如 2.0修改状态X.YZX.Y 不变Z 累加比如 1.0→1.01→1.02修改完成评审后变为 2.0实例需求文档从草稿0.03→ 正式1.0→ 修改1.01→ 再次正式2.0。配置基线一组 “冻结” 的配置项代表项目某一时刻的稳定状态如 “V1.0 版本基线”包含对应版本的需求、设计、代码、测试用例是变更的基准 —— 要改基线里的内容必须走正式变更流程不能私下改。核心价值相当于项目的 “快照”比如后续出现问题时可通过基线重建当时的配置快速定位问题新功能开发可基于基线开分支不影响原有稳定版本。配置管理数据库CMDB存储所有配置项及关系的 “大仓库”记录配置项的版本、变更轨迹、关联的问题 / 变更请求、供应商信息等比如查询 “某台服务器关联了哪些变更请求”“某个需求文档被哪些配置项引用”都能在 CMDB 中找到答案。配置库存放配置项的具体工具分三类按用途划分形象比喻帮你记开发库动态库开发人员的 “个人工作台”存放正在开发的配置项如未提交的代码、草稿文档开发人员可自行修改不影响他人受控库主库团队的 “共享区”存放基线及基线变更如评审后的代码、定稿文档纳入完全配置管理修改需走流程产品库静态库项目的 “成品货架”存放已发布的最终产品如测试通过的软件安装包、用户手册等待交付用户建库模式按配置项类型文档、代码、硬件适合通用软件开发统一管理效率高按开发任务模块 A、模块 B适合专业软件开发灵活适配不同任务。19.1.2 角色与职责三类核心角色分工明确不重叠配置管理负责人配置经理“总指挥”负责全局决策审批配置管理计划、配置库结构变更定义配置项属性、状态、关系评估配置管理过程推动持续改进配置管理员“执行管家”负责具体落地建立和维护配置库、CMDB识别配置项、建立基线、管理版本执行配置控制如变更的检出 / 检入、发布状态报告、开展配置审计配置项负责人“资产所有者”对具体配置项负责记录所负责配置项的所有变更维护配置项之间的关联关系如需求文档与设计文档的关联配合配置审计处理发现的差异问题如配置项与记录不一致。19.1.3 目标与方针管理目标让配置项 “可识别、可追溯、可控制”所有配置项被完整记录状态清晰配置信息准确支持变更影响分析、问题定位等管理活动配置项按规则变更不出现随意修改、版本丢失的情况管理方针按规则办事核心原则配置项必须编号、分类、明确责任人定期开展配置审计确保配置项与记录一致配置管理与变更管理、项目管理其他过程联动如变更后同步更新配置信息定期回顾配置管理过程持续优化如简化不必要的审批步骤。19.1.4 管理活动核心流程按顺序展开制订配置管理计划配置管理的 “行动指南”需 CCB 审批明确目标、范围哪些资产要管、角色职责配置项命名规则、基线计划何时建立基线、进度安排配置库、CMDB 的规划存在哪里、用什么工具配置项识别“给资产建档”基础中的基础确定范围如服务器、代码、需求文档都要纳入管理记录属性名称、编号、责任人、状态、关联配置项等赋予唯一标识符硬件贴标签、软件存库时加版本标签确定基线如 “需求基线”“设计基线”和配置结构各配置项的层级关系如需求文档→设计文档→代码配置项控制“管变更”核心是基线变更的规范化流程如下变更申请提交申请表说明变更内容、原因、影响的配置项 / 基线、实施方案变更评估CCB 评估变更的必要性、可行性、工作量通告结果批准 / 否决 / 推迟通知相关干系人变更实施修改配置项记录变更信息验证确认测试修改后的配置项提交 CCB 确认发布归档将修改后的配置项纳入基线通知相关人配置库层面的变更控制形象示例从产品库取出待修改基线V2.1放入受控库程序员从受控库 “检出Check out” 代码锁定别人不能改修改后 “检入Check in” 受控库解锁别人可继续修改所有修改完成将新基线V2.2存入产品库保留旧版本V2.1配置状态报告“拍快照”及时反馈配置现状内容配置项的标识与状态、变更申请状态、基线版本对比、配置管理活动记录作用让干系人清楚 “当前配置项是什么版本、有没有变更、变更有没有落地”配置审计“查漏洞”确保配置项 “一致且完整”分两类功能配置审计查 “功效对不对”如代码是否符合需求、文档是否完整物理配置审计查 “东西在不在”如交付的配置项是否齐全、有没有未授权的配置项审计场景新配置库建立后、重大变更前后、软件发布前、灾难恢复后配置管理回顾与改进“复盘优化”定期开回顾会汇报配置管理绩效如配置项识别准确率、变更控制合规率检查上次改进计划的执行情况制定新的改进措施如优化配置项命名规则、简化小额变更审批流程。19.2 变更管理变更管理就像项目的 “交通指挥员”核心是对变更从 “提出→审批→实施→收尾” 的全流程规范化管理避免因 “无序变更” 导致项目范围蔓延、成本超支、进度延误。19.2.1 管理基础变更与配置管理的关系配置管理是变更管理的基础变更的是配置项需通过配置库记录轨迹变更管理的结果要反馈给配置管理如变更后更新配置项版本、基线变更产生的常见原因产品 / 项目范围定义过失如需求漏写、工作边界不清增值变更如优化流程降低成本应对风险如风险发生后的紧急调整项目执行与基准不一致如进度滞后后的被动调整外部事件如政策变化、供应商变更变更的分类按性质重大变更、重要变更、一般变更不同审批权限按迫切性紧急变更如线上故障修复、非紧急变更如优化功能按行业特点产品范围变更、环境变更、设计变更、实施变更、技术标准变更弱电工程为例变更的含义本质是 “调整资源配置”要么拒绝变更要么调整项目基准进度、成本、范围核心是 “增值” 或 “规避风险”。19.2.2 管理原则基准管理基准是变更的依据初始基准建立后每次变更审批通过都要更新基准流程化所有变更必须走统一流程不能私下改整合变更原因、资源、决策权等元素明确分工评估、评审、执行的职能要分开如技术评估找专家审批找 CCB评估影响不仅要考虑客户可见的成果变更还要考虑项目内部如人员分工、资源配置的影响文档留存变更相关的申请表、评估报告、审批结果、实施记录要完整保存。19.2.3 角色与职责变更管理负责人变更经理“总协调员”负责变更全流程监控确定变更类型、组织变更计划协调资源、确保变更按流程执行变更完成后回顾与关闭变更请求者“发起人”负责提交变更申请提交初步方案、评估风险和影响给变更分类如紧急 / 非紧急变更实施者“执行者”负责落地变更具备执行变更的技术能力按实施计划完成变更任务变更顾问委员会“专家团”负责重大变更论证由技术、经济专家组成提供专业意见紧急变更时授权人员可代行审批19.2.4 工作程序核心流程一步都不能少变更申请干系人以书面形式提交变更申请表写清 “改什么、为什么改、怎么改”项目经理 / 配置管理员收集并初审变更初审确认变更的必要性避免无价值变更校验申请表格式、信息完整性如有没有写清影响的配置项让干系人对变更信息达成共识变更方案论证技术评估变更能不能实现、怎么实现经济 / 社会效益评估变更的价值、潜在风险大型变更需召开论证会由变更顾问委员会提供意见变更审查CCB含客户、专家决定是否批准变更重大变更可开正式会议评审专业评审和经济评审分开如技术专家评可行性投资人评成本客户意见对项目目标 / 交付成果变更起核心作用发出通知并实施批准后调整基准进度、成本、范围通知相关干系人如变更交付期要提前告知客户项目经理组织实施变更确保资源到位实施监控项目经理监控基准执行情况CCB 监控变更成果、里程碑效果评估对照基准评估变更目标是否达成如优化功能后是否降低了成本分析论证内容与实施过程的差距如实际工作量与估算是否一致变更收尾确认资源配置到位如人员调整已落实按新基准监控项目确保项目回归正常轨道。19.2.5 变更控制变更申请控制确保所有变更都走申请流程不能绕过按变更影响和代价提高效率如高层共识的变更可简化流程变更过程控制进度变更控制判断进度状态、影响因素管理实际变更如调整工期、优化资源成本变更控制控制费用偏差、确保变更批准后再调整预算避免超支合同变更控制规范合同修改流程文书工作、争议解决、审批层级需与整体变更控制结合。19.2.6 版本发布和回退计划发布前准备备份相关配置项代码、数据、配置定义回退触发条件如发布后出现重大故障明确回退职责谁通知用户、谁回退系统回退步骤通知相关用户、关联系统回退数据对象、配置数据、应用程序回退后测试确保系统正常通知用户回退完成事后改进分析回退原因完善回退计划避免下次重复问题。19.3 项目文档管理项目文档是项目的 “记忆”包括纸质和电子文档核心是 “规范管理、方便查询、留存知识”。19.3.1 管理基础文档分类信息系统开发项目为例开发文档描述开发过程可行性研究报告、需求规格说明、设计文档、测试计划产品文档描述开发产物培训手册、用户指南、产品手册管理文档记录项目管理信息进度记录、变更记录、项目计划、配置管理计划文档质量分级1 级最低限度开发者自用程序程序清单、开发记录2 级内部文档专用程序含安装使用注释3 级工作文档多团队联合开发或对外使用较详细4 级正式文档正式发行产品符合国标如工资计算程序19.3.2 规则和方法文档书写规范统一符号、图标含义如流程图符号一致程序注释、文档书写人 / 日期要完整如代码开头写清功能、设计人图表编号规则采用分类结构如第 1 位生命周期阶段、第 2 位文档类型、第 3-4 位文档内容、第 5-6 位流水码示例编号 “1-2-03-005” 可判断为 “启动阶段 - 需求文档 - 核心需求 - 第 5 张图”文档目录编写标准包含文档编号、名称、格式纸质 / 电子、份数、存储地点、保管人、存档时间文档管理制度建立书写、编号、目录规范文档借阅要登记控制使用权限如涉密文档仅限指定人查看签字确认后的文档要与电子文档一一对应电子文档设为只读避免篡改。