4. 建立变更控制委员会（CCB）：成员构成、职责划分与决策机制

好，咱们聊到变更控制，最核心的一个组织就是CCB。说白了，CCB就是那个“拍板”的人。没有它，变更就是一团乱麻。我见过太多项目，因为谁都能说一句“改一下”，最后改得面目全非。所以，CCB不是摆设，它是项目的“守门员”。

4.1 CCB的成员构成：谁该坐在桌边？

CCB的成员不是随便拉几个人凑数的。你得根据项目的特点来定。我个人习惯，核心成员一般包括这几类人：

• 项目经理（PM）：负责评估变更对进度、成本、资源的影响。他是执行层面的总协调人。
• 技术负责人/架构师：评估变更的技术可行性、对系统架构的冲击。我在项目中遇到过，一个看似简单的界面调整，结果底层数据库要改三个表，这就是技术评估没到位。
• 产品负责人/业务代表：确认变更是否真的符合业务需求。有时候业务方自己都没想清楚，提的变更其实是伪需求。
• 测试负责人：评估变更对测试用例、回归测试范围的影响。嗯，这里要注意，测试资源往往是瓶颈。
• 配置管理员（可选）：如果变更涉及版本管理、基线调整，这个人必须到场。

你想想看，如果少了业务代表，技术团队可能闭门造车；如果少了测试负责人，变更上线后可能就是灾难。所以，这个构成要平衡。

4.2 职责划分：谁干什么，要清楚

光有人不行，职责必须清晰。我曾经在一个项目中，CCB成员职责模糊，结果技术负责人去拍板业务需求，业务代表去评估技术方案，乱成一锅粥。所以，咱们得把分工说清楚。

角色	核心职责	决策权重
项目经理	评估变更对进度、成本、资源的影响；组织CCB会议	一票（协调权）
技术负责人	评估技术可行性、架构影响、工作量估算	一票（技术否决权）
业务代表	确认业务价值、优先级、是否必须变更	一票（业务否决权）
测试负责人	评估测试影响、回归策略、质量风险	一票（质量否决权）
配置管理员	管理基线、版本控制、变更记录	建议权

这里有个小技巧：技术负责人和业务代表拥有“一票否决权”。什么意思？如果技术上说“这个改不了”，或者业务上说“这个改了没意义”，那这个变更基本就凉了。但项目经理没有否决权，他的职责是协调，不是拍板。

4.3 决策机制：怎么拍板？

决策机制是CCB的灵魂。没有机制，会议就会变成扯皮大会。我建议采用以下几种方式：

4.3.1 投票机制

最常用的方式。每个成员一票，简单多数通过。但要注意，涉及技术或业务核心的变更，必须获得技术负责人或业务代表的同意票。说白了，就是“相关方必须点头”。

4.3.2 分级决策

不是所有变更都要上CCB会议。我习惯把变更分成三级：

• 一级变更（微小变更）：不影响进度、成本、质量，比如修改一个文案。项目经理直接审批即可，事后报备CCB。
• 二级变更（一般变更）：影响范围可控，比如增加一个非核心功能。CCB邮件投票，无需开会。
• 三级变更（重大变更）：影响进度、成本、架构或核心业务。必须召开CCB会议，现场决策。

这样做的好处是，CCB不会被琐事淹没。我曾经见过一个项目，连改个按钮颜色都要上会，结果CCB成员天天开会，正事全耽误了。

4.3.3 紧急变更通道

项目里总有突发情况。比如线上故障，必须立即改代码。这时候走正常流程就来不及了。我建议设立“紧急变更通道”：

• 由项目经理和技术负责人共同确认是否属于紧急变更。
• 允许先实施，后补审批（但必须在24小时内完成CCB确认）。
• 紧急变更不能超过总变更数的10%，否则说明项目计划有问题。

4.4 CCB会议的节奏与记录

CCB会议不能天天开，也不能不开。我建议：

• 常规会议：每周一次，固定时间，比如周三下午3点。时长控制在1小时内。
• 临时会议：遇到重大变更，随时召集。但必须提前24小时发议程。
• 会议记录：每次会议必须有正式的《CCB会议纪要》，内容包括：变更编号、决策结果、责任人、截止日期。这个记录是项目审计的重要依据。

你想想看，如果没有记录，三个月后谁还记得当时为什么改？谁拍板的？出了问题就是一笔糊涂账。所以，记录一定要留好。

嗯，这一节就聊到这里。下一节咱们讲讲变更的优先级排序，那也是个头疼的问题。