在 ASPICE 评估中，变更管理（SUP.10）是「基本实践覆盖最全、证据最容易残缺」的过程之一。研发团队每天都在改需求、改设计、改代码，真正的问题不是「有没有改」，而是「每一次变更，能不能说清楚为什么改、影响什么、谁批准的、验证了吗」。
▌ SUP.10 的核心闭环
一个合规的变更管理流程，至少要跑通五个环节：
- 变更请求：谁提出、改什么、为什么改，登记在案（哪怕是邮件，也要可检索）；
- 影响分析：受影响的需求、设计、代码、测试用例逐项识别，评估工作量和风险；
- 决策审批：CCB（变更控制委员会）明确「做/不做/缓做」，结论留痕；
- 实施与验证：变更落地后，受影响的验证活动必须重跑，不能「改了代码、不改用例」；
- 关闭与追溯：双向追溯矩阵同步更新，变更请求正式关闭。
▌ 中小团队最常见的三个坑
坑一：口头变更。会议室里说一句「这里改一下」，需求就变了。评估时追溯断链，全组补记录。对策：约定最低限度的登记形式，微信里达成的变更也要当天录入系统。
坑二：CCB 形式化。每周例会走个过场，所有请求全部通过。影响分析流于形式，评估师一问「这个变更影响了哪些用例」就卡壳。对策：CCB 关注重心放在影响分析和优先级，而不是签字本身。
坑三：变更后不重验证。代码改了，测试用例和测试报告还是旧的。这是 SUP.10 与 SWE.5 交叉处最常开出的不符合项。
▌ 用工具把流程「焊死」
我们自研的 AsPiCe 开发系统把 SUP.10 的五个环节做成了在线工作流：变更请求自动关联受影响的工作产品，影响分析一键生成清单，CCB 决策与验证记录在系统内闭环，追溯矩阵实时更新。评估前导出变更台账，证据一次到位。
经验总结一句话：变更管理做得好不好，不看流程文档写得多厚，看随机抽一条变更，五分钟内能不能讲清全貌。