3. 变更请求的发起与记录：变更请求的来源、变更请求模板设计、记录规范与工具
好，咱们进入第三个实战环节。变更请求怎么来？来了之后怎么记？
说实话，我在ASPICE评估中见过太多团队，一听到“变更”就头大。要么是口头说一句“改一下”，要么是邮件里随便写两行。结果呢？项目后期根本说不清楚谁改了啥、为什么改、改完有没有影响。
今天咱们就把这事掰扯清楚。
3.1 变更请求的来源：不是只有“客户说改”
很多人以为变更请求就是客户提的。其实不然。我参与过的项目里，变更请求的来源五花八门。你想想看，一个汽车电子项目动辄几十万行代码，几百个需求，怎么可能只有外部输入？
常见的来源我归纳为以下几类：
- 客户需求变更：这是最直接的。客户说“我要加个功能”，或者“这个参数要调”。嗯，这种变更通常优先级最高。
- 内部需求澄清：开发过程中发现需求描述有歧义。比如“系统应在3秒内响应”，但没说是从哪个触发点开始算。这种不明确的地方，必须发起变更来澄清。
- 设计缺陷或优化：我在一个项目中遇到过，硬件接口定义和软件设计对不上。不改的话，联调时肯定出问题。这种变更，说白了就是“补窟窿”。
- 测试发现的问题：测试人员发现某个功能实现和需求不一致。这算不算变更？算。因为要么改代码，要么改需求文档。
- 法规或标准更新：汽车行业尤其明显。ISO 26262更新了，ASPICE新版本发布了，你的流程和产品都得跟着变。
- 工具或平台升级：编译器版本变了，或者MCU换型号了。这种变更影响面往往很大，我建议一定要走正式流程。
3.2 变更请求模板设计：别让工程师填“天书”
模板设计这事，我踩过坑。最早我设计的模板有20多个字段，结果没人愿意填。后来我简化到核心字段，大家才配合起来。
一个实用的变更请求模板，我建议包含以下内容：
| 字段 | 说明 | 必填？ |
|---|---|---|
| 变更ID | 唯一标识，建议用“CR-项目名-序号”格式 | 是 |
| 标题 | 一句话概括变更内容，比如“修改CAN报文周期” | 是 |
| 来源 | 客户/内部/测试/法规等 | 是 |
| 提出人 | 谁发起的变更 | 是 |
| 提出日期 | 发起时间 | 是 |
| 变更描述 | 详细说明要改什么，为什么改 | 是 |
| 影响分析 | 对需求、设计、测试、进度、成本的影响 | 是 |
| 优先级 | 高/中/低 | 是 |
| 关联工件 | 涉及的需求ID、设计文档、代码模块等 | 推荐 |
| 审批状态 | 待审批/已批准/已拒绝 | 是 |
| 实施人 | 谁负责改 | 是 |
| 预计工时 | 改完需要多久 | 推荐 |
| 实际完成日期 | 改完的时间 | 是 |
重点提醒：影响分析这个字段，很多人随便写两句。我建议至少回答三个问题：
- 这个变更会影响哪些下游工件？
- 会不会影响其他模块的接口？
- 对项目进度和成本有多大影响？
我在评估时，如果看到影响分析只写了“无影响”，基本都会追问。因为汽车电子系统里，几乎没有“无影响”的变更。
3.3 记录规范：写清楚，别让人猜
记录规范这事，说白了就是“写人话”。我见过有人写“修改了bug”，这等于没写。正确的写法应该是“修复了CAN总线在低温环境下偶发丢帧的问题”。
我总结了几条记录规范：
- 标题要精准：不要用“修改xxx”这种模糊表述。用“将xxx从A改为B”这种明确句式。
- 描述要完整：说清楚“当前状态”和“目标状态”。比如“当前报文周期为100ms，目标改为50ms”。
- 原因要可追溯：为什么改？是客户要求？还是测试发现？还是设计评审结论？最好能关联到具体文档或会议纪要。
- 影响范围要明确：不要只说“影响不大”。要具体到“影响需求文档第3.2节、软件设计第5章、测试用例TC-012到TC-015”。
- 状态要实时更新：变更从“提出”到“实施”到“验证”到“关闭”，每个阶段都要有记录。我曾经见过一个变更，提出来半年了还是“待审批”，这明显是流程失控。
避坑指南：我曾经在一个项目中，发现团队用Excel记录变更。结果版本一多，数据就乱了。有人改了Excel但没保存，有人同时改了不同版本。最后我们不得不花两周时间重新梳理所有变更。所以，我建议至少用专业的工具来管理。
3.4 工具选择：别让工具成为负担
工具这事，没有绝对的好坏。关键看你的团队规模和项目复杂度。
我常用的几种方案：
- 小型团队（5人以下）：可以用Jira或Redmine。轻量级，够用。我建议配置一个“变更请求”工作流，包含“新建→分析→审批→实施→验证→关闭”这几个状态。
- 中型团队（5-20人）：推荐Polarion或Codebeamer。这些工具和ASPICE流程结合得很好，能自动生成审计轨迹。我评估时，看到用这些工具的团队，变更管理通常比较规范。
- 大型团队（20人以上）：建议用IBM DOORS或西门子Polarion。这些工具支持需求、设计、测试的全链路追溯。变更请求可以自动关联到受影响的工件。
不管用什么工具，有几点是通用的：
- 权限要清晰：谁可以提变更？谁可以审批？谁可以关闭？这些权限要提前设好。
- 通知要自动：变更状态变化时，要自动通知相关人员。别等人去查。
- 历史要可查：所有变更记录都要保留，不能删除。这是ASPICE审核的基本要求。
我的建议：不管你用什么工具，先跑通一个完整的变更流程。从提出到关闭，走一遍。看看哪里卡住了，哪里信息丢失了。然后再优化。别一上来就想搞个大而全的系统，容易翻车。
好了，关于变更请求的发起与记录，咱们就聊到这。下一章咱们聊聊变更请求的分析与影响评估。那个环节更考验功力，到时候我会分享一些实战中的分析技巧。