4、变更请求的提交流程与规范：CR模板、影响域标注、优先级划分
好，咱们进入正题。变更请求，说白了就是一张“请愿书”。你发现某个需求有问题，或者想加点东西，不能光靠嘴说。在座舱这种高安全、高耦合的系统里，口头沟通是最大的坑。我见过太多因为“我记得跟你说过”导致的返工，最后全成了扯皮。
所以，一套标准化的提交流程和模板，是质量管控的第一道防线。今天我就把我在几个量产项目中打磨出来的这套东西，掰开揉碎了讲给你。
4.1 变更请求（CR）模板：一张表说清所有事
CR模板不是越长越好。很多公司喜欢搞十几页的表格，结果没人愿意填，最后流于形式。我个人习惯，一张A4纸能说清楚的事，绝不用两张。核心字段必须包含以下四类信息：
| 信息类别 | 必填字段 | 说明 |
|---|---|---|
| 基础信息 | CR编号、提出人、提出日期、所属项目/车型 | 用于追溯和归档，编号规则建议统一，比如“CR-2025-001” |
| 变更描述 | 变更标题、详细描述、原始需求出处 | 描述要具体，避免“优化体验”这种模糊词。要写清楚“把空调温度调节步长从1℃改为0.5℃” |
| 影响域标注 | 影响模块、影响层级、影响范围 | 这是核心，下面会单独讲 |
| 优先级与决策 | 优先级（P1-P4）、紧急程度、建议完成时间 | 优先级划分标准必须统一，不能谁嗓门大谁优先级高 |
4.2 影响域标注：别让变更变成“拆东墙补西墙”
影响域标注，是CR里最容易被忽视、也最容易出问题的地方。你想想看，座舱系统里，一个简单的UI文字改动，可能牵扯到本地化资源文件、字体渲染引擎、甚至语音播报的触发逻辑。我曾经遇到过一个案例，开发改了一个按钮的文案，结果导致该按钮在夜间模式下的对比度不达标，最后被客户投诉。
所以，我建议影响域标注至少要从三个维度去分析：
- 模块维度： 这个变更会影响哪些子系统？HMI？语音？空调？还是底层BSP？
- 层级维度： 是只改应用层？还是涉及中间件？或者要动到底层驱动？层级越深，风险越大。
- 范围维度： 是只影响当前车型？还是会影响平台化项目？如果是平台化变更，那就要拉上所有项目组一起评审。
为了让大家更直观地理解，我画了一张影响域标注的流程图。你可以把它当作一个检查清单，每次提CR时，对着走一遍。
4.3 优先级划分：别让“紧急”变成“狼来了”
优先级划分，是变更管理里最考验“情商”和“技术判断力”的事。如果所有人都说自己的需求是P0（最高优先级），那这个体系就废了。我一般建议采用四档划分法，并且每档都要有明确的定义和触发条件。
| 优先级 | 定义 | 典型场景 | 响应时间 |
|---|---|---|---|
| P1 - 紧急 | 系统崩溃、安全漏洞、法规合规问题 | 倒车影像黑屏、制动信号丢失、GDPR数据泄露 | 4小时内响应，24小时内出修复方案 |
| P2 - 高 | 核心功能异常，有替代方案但体验差 | 导航定位漂移、语音唤醒失败率>30% | 24小时内响应，3天内出方案 |
| P3 - 中 | 非核心功能异常，或体验优化 | 某个主题颜色显示偏差、动画掉帧 | 纳入下一个迭代计划 |
| P4 - 低 | 建议性改进、未来版本需求 | 增加某种快捷手势、调整默认音量 | 纳入需求池，定期评审 |
这里有个关键点：优先级不是由提出人定的，而是由CCB（变更控制委员会）定的。 提出人可以给出“建议优先级”，但最终决策权在委员会。为什么？因为提出人往往只看到自己那一亩三分地，看不到全局的资源冲突。
我的经验： 在评审优先级时，我通常会问三个问题：
- 这个变更不做，车能不能开？—— 不能开，P1。
- 这个变更不做，客户会不会投诉？—— 会投诉，P2。
- 这个变更做了，会不会影响其他P1/P2的交付？—— 会，那就得重新排期。
这三个问题问完，优先级基本就清晰了。
4.4 提交流程：从“想法”到“执行”的标准化路径
流程这东西，太复杂了没人走，太简单了又容易漏。我推荐一个“五步走”的轻量级流程，既保证了管控，又不至于让开发觉得是在填表。
- 发起： 提出人填写CR模板，重点标注影响域和建议优先级。这一步要求“一次做对”，模板里必填项漏了，系统直接打回。
- 初审： 项目经理或技术负责人初审，判断CR是否有效、描述是否清晰。我见过太多“请优化性能”这种CR，初审直接打回，要求写清楚“优化哪个场景下的什么性能”。
- 影响分析： 相关模块的负责人进行影响分析，输出“影响分析报告”。这一步是技术活，要评估工作量、风险、以及对其他模块的依赖。
- CCB评审： 变更控制委员会召开评审会，确定优先级、排期、以及责任人。评审会要有纪要，明确谁在什么时间点做什么事。
- 执行与关闭： 开发实施、测试验证、上线部署。最后，由提出人确认变更已满足需求，关闭CR。
嗯，这里要注意一点：CR关闭不代表事情结束了。 我建议每个CR都要有一个“复盘”环节，尤其是那些导致返工或延期的CR。复盘不是为了追责，而是为了改进流程。比如，是不是影响域标注漏了什么？是不是优先级定低了？把这些经验沉淀下来，下次就能少踩坑。