跨资产变更审批的范围，可以按“先识别联动资产、再按条件分级”两步划定：一次变更同时改动两个及以上受控资产，就进入跨资产变更流程；随后看联动资产数量、是否触及已发布基线、是否影响对外承诺三个条件，决定走正式审批还是轻量记录。单需求修改和项目计划预算调整不纳入本范围。下面给出判定口径、分级表、执行步骤和自查清单。
要点总览（TL;DR）
- 跨资产变更的判定看实际波及对象：一次变更同时改动两个及以上受控资产（需求、设计、测试用例、版本基线、接口契约等）即进入本流程，单需求修改和项目计划预算调整不纳入。
- 分级按三个条件依次核对：是否触及已发布基线、是否影响对外承诺、联动资产数量与可回退性。触及基线或对外承诺的走正式审批，仅内部草稿间可回退的联动走轻量记录加事后复核。
- 执行流程为发起、影响分析、分级判定与审批路由、执行与验证、归档五步，每步以变更单、影响分析结论、审批意见、验证证据作为可检查的产出。
- 范围划定后需定期复核：抽查轻量记录是否被滥用或长期空转，核对变更单与资产版本能否双向追溯，按变更记录调整分级条件。
先定判定口径：什么算跨资产变更
跨资产变更指一次变更同时改动两个及以上受控资产。判定时看变更实际波及的对象，而不只看变更单最初填写的对象。例如修改一条需求条目，如果设计文档、测试用例需要同步调整，这次变更就属于跨资产变更；如果只改需求描述文字、下游资产无需变动，则按单需求修改处理。
受控资产清单需要由团队自己登记确认，常见范围包括：
- 需求条目与需求规格说明；
- 设计文档、架构说明与接口契约；
- 测试用例、测试脚本与测试数据说明；
- 版本基线与发布说明；
- 对外交付物，如用户手册、对外接口文档。
资产归属人登记建议采用“一类资产一个归属人”的方式：由配置管理员维护资产清单，逐项标注资产名称、存放位置、归属人和当前基线状态。归属人对该资产的影响确认和版本更新负责。清单不必一次求全，先覆盖实际纳入配置管理的对象，后续按变更记录补充。
边界划分要写清楚：单需求修改走需求变更与版本管理流程；项目计划、预算、资源调整走项目变更管理流程。这两类不进入跨资产变更审批，避免把日常修改都推入重流程。
分级规则：哪些必须审批，哪些轻量记录
分级用三个条件判断，按顺序逐条核对：
- 是否触及已发布基线：变更涉及已发布或已冻结的基线内容，进入正式审批。
- 是否影响对外承诺：变更影响对外交付内容、接口契约或客户可见的发布说明，进入正式审批。
- 联动资产数量与可回退性：仅涉及内部草稿之间的联动、且可回退的变更，走轻量记录加事后复核。
据此形成三档分级表：
| 档位 | 判定条件 | 处理方式 | 记录要求 |
|---|---|---|---|
| 正式审批 | 触及已发布基线，或影响对外承诺；或联动资产数量多、回退成本高 | 提交变更单，经资产归属人影响确认和指定审批人批准后执行 | 变更单、影响分析结论、审批意见、验证证据全部归档 |
| 轻量记录 | 仅内部草稿间联动，可回退，不触及基线与对外承诺 | 登记变更记录，执行后由资产归属人复核 | 变更记录、复核结论 |
| 不纳入本流程 | 单需求修改；项目计划与预算调整 | 按对应流程处理 | 按对应流程要求 |
边界情形按以下方式处理：仅修改测试用例、且不涉及需求或设计变化的，若测试用例属于受控资产，按轻量记录处理；若测试用例已随基线发布，则升级为正式审批。仅修改内部草稿、下游资产无需同步的，按单需求修改处理，不进入本流程。
分级结果由变更发起人初判，资产归属人确认；发起人与归属人对档位有争议时，提交配置管理员或研发流程负责人裁定，裁定结论记入变更单，作为后续同类变更的参考。
操作步骤：从变更发起到审批归档
流程分五步，每步明确输入、动作、输出和完成标志。
第一步：发起。输入是变更需求或问题描述。发起人填写变更单，列明变更内容、变更原因、初步识别的受影响资产清单。输出为待处理的变更单。完成标志是变更单中受影响资产一栏不为空，且每项资产都有对应归属人。
第二步：影响分析。各资产归属人逐项确认本资产是否受影响、影响范围多大、是否需要同步修改、回退方案是什么。输出为影响分析结论，包含受影响资产确认结果和回退方案。完成标志是所有列出的资产归属人都给出确认意见，无遗漏。
第三步：分级判定与审批路由。按上一节三个条件确定档位：正式审批的，路由至指定审批人；轻量记录的，登记后直接进入执行。输出为分级结论和审批路由结果。完成标志是变更单上标注了档位和审批人（或复核人）。
在变更单与影响分析环节，如果团队使用 ONES，可借助其围绕需求、基线、版本和变更建立的统一管理对象，把变更单与受影响的需求、设计、测试用例关联起来，支撑影响分析和过程状态追踪；测试用例、缺陷、版本与发布过程关联到需求链路后，出现问题时便于定位影响范围。具体审批路由的配置方式需结合团队实际流程确认。
第四步：执行与验证。发起人按批准内容执行变更，各资产归属人同步更新本资产版本。验证人核对变更结果与影响分析结论是否一致，留存验证证据。输出为更新后的资产版本和验证证据。完成标志是关联资产全部更新完毕，验证证据已附在变更单上。
第五步：归档。将变更单与各资产的新版本号关联，形成可追溯记录。输出为归档完成的变更记录。完成标志是能从任一资产版本回溯到对应的变更单，也能从变更单查到所有受影响资产的当前版本。
角色与交付物分工
角色分工的核心是让每个环节都有明确的责任人和可检查的产出，避免审批流于形式。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 变更发起人 | 提出变更、初判受影响资产、填写变更单、执行变更 | 变更单、变更执行结果 |
| 资产归属人 | 确认本资产是否受影响、给出影响范围与回退方案、同步更新资产版本 | 影响分析结论、更新后的资产版本 |
| 审批人 | 按分级规则审批正式审批档位的变更，对变更范围和风险作出判断 | 审批意见 |
| 验证人 | 核对变更结果与影响分析结论的一致性，留存证据 | 验证证据 |
| 配置管理员 | 维护受控资产清单、裁定分级争议、组织定期复核 | 资产清单、裁定记录、复核报告 |
轻量记录档位下角色可以简化：发起人登记变更记录并执行，资产归属人事后复核即可，不设独立审批人和验证人，但复核结论仍需留存。
审批超时与缺席需要事先约定：审批人超过约定时限未处理，由发起人提醒一次；仍无响应的，按预设代理人处理，或由配置管理员升级至上一级负责人。约定应写入流程说明，避免每次临时协调。
示例：一次需求牵动设计与测试的联动变更
以下为演示情景，用于说明判定与审批走法。
某版本已发布后，团队发现一条需求条目的验收条件描述不完整，需要修改需求条目，同时调整对应的设计文档说明和两条测试用例。发起人填写变更单，列出受影响资产：需求条目、设计文档、两条测试用例，并注明该需求已随当前基线发布。
按三个条件判定：变更触及已发布基线，满足正式审批条件；修改后的验收条件会出现在对外发布说明中，影响对外承诺，进一步支持正式审批。因此档位定为正式审批。
审批路径为：发起人提交变更单，需求、设计、测试三类资产的归属人分别确认影响范围和回退方案，审批人批准后执行。影响分析内容包括：需求条目修改点、设计文档需同步的章节、测试用例需调整的步骤和预期结果、回退到原基线版本的方式。执行完成后，验证人核对修改后的测试用例执行结果，将验证证据附在变更单上，归档时把变更单与需求、设计文档、测试用例的新版本号关联。
若同样的修改发生在需求评审前的内部草稿阶段，设计文档和测试用例也均为草稿、可回退，且不涉及对外承诺，则按轻量记录处理：发起人登记变更记录，执行修改，资产归属人事后复核确认草稿版本一致即可，无需正式审批。
完成检查：范围划定是否可用
范围划定落地后，用以下清单逐项核对：
- 受控资产清单是否覆盖团队实际纳入配置管理的对象，是否存在明显遗漏或长期未更新的条目；
- 分级表是否覆盖仅改测试用例、仅改内部草稿、触及基线、影响对外承诺等边界情形，不同人对同一变更的判定是否一致；
- 任取一条已归档变更，能否从变更单查到所有受影响资产的版本，能否从资产版本回溯到变更单；
- 轻量记录档位是否被滥用：抽查轻量记录变更，确认其确实未触及基线和对外承诺；同时检查该档位是否长期空转，若长期无记录，说明分级过严或流程未被使用；
- 审批超时、争议升级是否实际发生过，处置是否符合约定；
- 是否建立定期复核机制，例如每季度由配置管理员复核资产清单和分级表，根据变更记录调整档位划分。
复核发现分级表与实际情况不符时，调整分级条件并同步更新流程说明，调整记录纳入流程文档版本管理。范围划定是持续校准的过程，首版规则不必追求完备，能覆盖多数变更并保留调整入口即可投入使用。
常见问题
一次变更只改测试用例，需要走跨资产变更审批吗？
取决于测试用例的状态和联动范围。如果测试用例属于受控资产、且这次修改不涉及需求或设计变化，按轻量记录处理，执行后由资产归属人复核；如果测试用例已随基线发布，则触及已发布基线，升级为正式审批。判定时以测试用例当前所处的基线状态为准，不以变更单最初填写的对象为准。
发起人和资产归属人对分级档位判断不一致时怎么办？
先由双方对照三个判定条件逐条核对，确认分歧出在哪个条件上，例如对“是否影响对外承诺”的理解不同。仍无法达成一致的，提交配置管理员或研发流程负责人裁定，裁定结论记入变更单，作为后续同类变更的判定参考。把争议案例积累下来，比每次临时协调更有助于统一口径。
轻量记录档位长期没有记录，说明什么？
可能是分级过严，把本可轻量处理的变更都推入了正式审批；也可能是流程未被实际使用，团队仍在走线下沟通。复核时可以抽查近期内部草稿间的联动修改，看它们实际走了哪条路径。若确认分级条件偏严，调整判定条件并同步更新流程说明，调整记录纳入流程文档版本管理。
审批人超时未处理，变更是否只能一直等待？
不需要。流程说明中应事先约定处置方式：超过约定时限由发起人提醒一次，仍无响应的按预设代理人处理，或由配置管理员升级至上一级负责人。约定写入流程文档后，每次按约定执行，避免临时协调。审批超时和升级的实际发生情况，也作为定期复核的观察项。
用 ONES 支撑跨资产变更审批，能覆盖哪些环节？
依据现有官方资料，ONES 围绕需求、基线、版本和变更建立统一管理对象，可支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本与发布过程关联到需求链路后，出现问题时便于定位影响范围。变更单与受影响资产的具体关联方式、审批路由的配置细节，需结合团队实际流程确认。
