研发审计整改要形成闭环，可以按“问题归集与分级—根因分析—整改方案与责任人—过程活动与证据同步修正—抽样验证与关闭—复盘防复发”六步推进。核心判断只有一条：每条审计发现都要对应到具体的研发过程活动、责任角色和可核查证据，整改动作落到流程文件、工作项状态和评审记录上，整改报告只是结果说明。
要点总览（TL;DR）
- 整改按六步推进：问题归集与分级、根因分析、方案与责任人、动作嵌入过程活动、抽样验证与关闭、复盘防复发。
- 每条审计发现要拆成独立整改条目，写清涉及过程活动、项目范围、严重程度和证据缺口，再按影响范围与问题性质排优先级。
- 根因分三类：流程未定义、已定义未执行、执行了未留证；结论决定整改动作是改流程、改执行机制还是改记录方式。
- 整改动作要落到需求、设计、开发、测试、发布等具体活动，让工作项状态、评审记录和变更记录随活动自然产生证据。
- 关闭需同时满足动作完成、证据齐全、抽样未再发现同类问题；验证通过的动作写入流程文件或工具规则，防止下个审计周期复发。
整改从哪里开始：把审计发现转成可执行的问题清单
审计报告里的“发现”通常是一段描述性结论，直接拿去分配任务往往无人认领。整改启动的第一步，是把每条发现拆成独立、可分配、可跟踪的问题条目，并补齐字段，让后续的根因分析、责任分配和验证都有统一对象。
审计发现与整改条目的区别在于：发现回答“哪里不符合”，整改条目回答“由谁在什么范围内改到什么程度”。一条发现如果涉及多个项目或多个过程活动，应拆成多条整改条目，避免一条任务对应多个责任人和多种证据。
问题清单建议包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 问题编号 | 唯一标识，便于与审计报告条目对应 |
| 发现描述 | 引用审计原文，写清不符合的事实与依据条款 |
| 涉及过程活动 | 需求、设计、开发、测试、发布、变更等具体活动 |
| 涉及项目/版本 | 明确范围，是单项目问题还是跨项目共性问题 |
| 严重程度 | 按对过程符合性和交付质量的影响分级 |
| 证据缺口 | 缺失的是流程文件、执行记录还是审批记录 |
| 整改责任人 | 初判责任角色，待根因分析后确认 |
| 计划完成时间 | 结合整改难度与下次审计节点设定 |
分级建议采用两级判断：先看影响范围，是单项目偶发还是多项目重复出现；再看问题性质，是流程缺失、执行不到位还是记录缺失。影响范围大且涉及流程缺失的问题优先整改，记录类问题可在流程和执行修正后同步补齐。分级结果直接决定资源投入顺序，不必对所有问题平均用力。
本节输出一份可分配的整改问题清单。完成标志是：每条审计发现都能在清单中找到对应条目，且每条条目都有明确的范围、证据缺口和初判责任人。
根因分析怎么做：区分流程缺失、执行偏差与证据缺失
整改最容易走偏的地方，是把所有问题都做成“补文档”。根因分析的目的，是判断问题出在规则本身、执行环节还是记录环节，不同结论对应完全不同的整改动作。
常见根因可分三类，每类的分析提问和取证方式不同：
| 根因类型 | 典型表现 | 分析提问 | 取证方式 |
|---|---|---|---|
| 流程未定义 | 制度或流程文件中没有对应要求 | 现有流程是否覆盖该活动？要求是否可执行？ | 查阅流程文件、访谈过程负责人 |
| 流程已定义但未执行 | 有规定，实际活动未按规定开展 | 是不知道要求、资源不足还是刻意绕过？ | 比对工作项记录与流程要求，访谈执行人员 |
| 执行了但未留证 | 活动实际发生，记录缺失或不完整 | 记录要求是否明确？记录动作是否嵌入活动本身？ | 核查评审、审批、变更记录，确认活动痕迹 |
根因结论直接决定整改动作类型：流程未定义的，整改动作是修订流程文件并宣贯；已定义未执行的，整改动作是调整执行机制，例如增加检查点、明确审批卡点或补充培训；执行了未留证的，整改动作是修改记录方式，把记录动作嵌入活动流程，让证据随活动自然产生。
判断时要注意一种混合情况：同一问题可能同时存在流程缺失和执行偏差。此时应拆开处理，先补规则再纠执行，避免用一次培训掩盖流程本身的空白。根因结论需要写明判断依据，例如查阅了哪份文件、比对了哪些记录，便于验证阶段复核。
本节输出根因分析结论表，每条问题对应一个根因类型和一类整改动作。完成标志是：没有条目停留在“原因待查”，且整改动作类型与根因结论一致。
整改方案与角色分工：谁改、改什么、何时完成
根因明确后，需要把整改动作转成带责任人和时间点的计划。整改方案的基本要素包括：整改动作、责任角色、配合角色、完成标志、计划完成时间。其中完成标志要写成可观察的结果，例如“流程文件发布并完成宣贯”“某类工作项增加评审节点并连续运行一个迭代”，避免写成“加强管理”这类无法验证的表述。
常见角色分工可参考下表，具体设置按组织实际调整：
| 角色 | 主要职责 |
|---|---|
| 研发负责人 | 对跨项目共性问题拍板整改方向，提供资源保障 |
| 项目经理 | 在项目内落实整改动作，确保工作项和记录按要求执行 |
| 质量/过程改进人员 | 修订流程文件，设计检查点，组织宣贯与自查 |
| 配置管理员 | 保障变更记录、版本记录等配置管理证据完整 |
| 审计对接人 | 汇总整改证据，组织验证，对外沟通整改结论 |
整改动作要与研发过程活动对应起来。例如“需求评审记录缺失”的整改，责任角色是项目经理，配合角色是质量人员，动作包括在需求活动中增加评审节点、明确评审结论的记录位置，完成标志是该节点在后续项目中稳定运行并有记录可查。
本节输出整改计划表与责任矩阵。完成标志是：每条问题都有唯一责任人、明确的完成标志和计划完成时间，配合角色清晰，不存在无人认领或多人共管却无人负责的条目。
整改落地：把动作写进研发过程活动与工作项
整改方案确定后，真正的落地是让整改要求进入日常研发活动，而不是在审计前集中补材料。做法是把每条整改动作映射到需求、设计、开发、测试、发布等具体活动，并明确该活动产生什么证据、证据存放在哪里。
映射时可以按活动逐项梳理：需求阶段关注需求评审与变更记录；设计阶段关注设计评审结论与版本对应；开发阶段关注代码评审和分支合并记录；测试阶段关注测试用例、执行记录与缺陷闭环；发布阶段关注发布审批与回滚预案。每条整改动作应至少对应一个活动和一个证据来源。
工作项状态、评审记录、变更记录是承载整改证据的主要载体。把整改要求转化为工作项上的必填字段、状态流转规则或评审卡点，证据就会随活动推进自动产生。整改期间的过程数据要按原有留存要求保存，不因整改而临时改变记录口径，否则验证阶段难以判断整改前后的差异。
在研发管理工具中承载这套动作时，可以把整改问题建成独立工作项类型，与需求、缺陷等工作项关联，状态从“待整改”流转到“待验证”“已关闭”，评审和审批记录随工作项留存。ONES 可用于承载整改问题跟踪、工作项状态流转与评审记录留存这类管理动作，具体配置按团队现有流程设计。涉及平台数据安全治理的配置不在本文范围。
本节输出整改动作—过程活动—证据来源对应清单。完成标志是：每条整改动作都能指出落在哪个活动、由谁执行、产生什么证据、证据在哪里可查。
验证与关闭：抽样复核和关闭标准
整改做完不等于整改有效。验证阶段要回答两个问题：动作是否真的执行了，同类问题是否还会再出现。抽样复核是常用方法，样本应覆盖整改涉及的项目和活动类型，优先抽取整改后新开展的活动，而不是整改期间专门准备的样例。
样本量没有统一数字标准，可按整改范围和问题严重程度确定：涉及单项目的问题抽取该项目整改后的若干次活动记录；跨项目共性问题则在多个项目中分别抽样，确认整改要求在各项目都生效。抽样时要记录抽样依据和样本清单，便于复核。
验证证据主要包括三类：流程文件，确认规则已发布且要求明确；工作项记录，确认活动按新要求执行；评审与审批记录，确认关键节点有结论和责任人。三类证据齐全，才能支撑关闭结论。
关闭标准建议同时满足三条：整改动作已完成并有记录；证据齐全且可追溯；抽样未再发现同类问题。任一条不满足，应退回责任人再整改，并重新约定完成时间和验证方式。退回原因要记录在验证记录中，避免同一问题反复退回却无改进。
本节输出整改验证记录表与关闭结论。完成标志是：每条问题都有验证结论，关闭条目证据可查，未关闭条目有明确的退回原因和下一步安排。
完整示例：一条审计发现从整改到关闭
以下为演示情景，用于说明全流程如何衔接，不代表任何具体组织的真实审计结论。
发现描述与分级：审计发现某项目多个版本的设计变更未经过评审即进入开发，涉及三个版本。该问题在多版本重复出现，判定为影响范围较大的执行类问题，优先级较高。
根因判断：查阅流程文件后发现设计变更评审要求已存在，但变更发起入口没有强制评审卡点，开发人员可直接修改设计文档。比对工作项记录确认变更实际发生，评审记录缺失。根因判定为“流程已定义但执行机制不足”，兼有记录缺失。
整改动作与责任角色：质量人员修订变更流程，在设计变更工作项上增加评审状态卡点；项目经理负责在项目内执行；配置管理员确保变更记录与版本对应。完成标志是变更工作项必须经过评审状态才能进入开发，并连续运行一个迭代。
证据形式与抽样验证：证据包括修订后的流程文件、变更工作项的评审状态记录、评审结论。验证时抽取整改后三个版本的设计变更记录，核对是否均有评审结论。
关闭结论与遗留事项：抽样未再发现无评审变更，动作完成、证据齐全，予以关闭。遗留事项是历史版本中已发生的无评审变更需补充影响评估，作为单独条目跟踪。
防复发与整改完成检查
单条问题关闭后，还要判断整改是否形成机制。有效的整改动作应固化为流程文件条款、工作项规则或检查项，使其在人员变动和项目切换后仍然生效。仅靠一次宣贯或一次集中补录，问题容易在下一个审计周期重现。
防复发可以从两个动作入手：把验证通过的整改要求写入流程文件或工具配置，形成固定卡点；在下次审计前安排预检查，按本次问题清单逐项自查，重点看同类活动是否仍按新要求执行。预检查的范围可覆盖本次整改涉及的项目和活动类型。
整改整体完成前，可用以下清单逐项核对：
| 检查项 | 核验要点 |
|---|---|
| 问题全覆盖 | 审计报告每条发现都有对应整改条目，无遗漏 |
| 根因有结论 | 每条问题写明根因类型和判断依据 |
| 责任到人 | 每条整改有唯一责任人和完成时间 |
| 证据可追溯 | 整改动作对应到过程活动，证据可查 |
| 抽样通过 | 验证抽样未再发现同类问题 |
| 机制固化 | 有效动作已写入流程文件或工具规则 |
本节输出整改完成检查表与防复发机制说明。完成标志是：清单各项均有结论，未通过项有后续安排，固化后的规则在下一个项目周期中可被直接执行和检查。
常见问题
审计发现涉及多个项目，整改条目应该合并还是拆开？
建议拆开。一条整改条目对应一个责任人和一类证据，涉及多个项目时合并成一条，容易出现责任分散、证据口径不一。可以按“同一根因、同一整改动作”归组，在每个项目下分别建条目，由同一责任角色统一推进，验证时再按项目分别抽样。
如果确认是跨项目共性问题，例如流程文件本身缺失，可另设一条共性整改条目负责修订规则，各项目条目负责落地执行，两类条目关联跟踪。
整改期间业务任务很紧，整改动作能否先记录、后补执行？
不建议把执行和记录分开。审计关注的是过程活动是否按规则开展，先执行后补记录会让证据与活动时间脱节，验证阶段难以判断整改是否真正生效。
资源紧张时更稳妥的做法是调整整改范围：优先处理影响范围大、涉及流程缺失的问题，把记录类问题排在流程和执行修正之后，并明确计划完成时间。缩小范围但保证每条整改真实落地，比全面铺开却集中补材料更容易通过验证。
抽样验证抽多少样本才够？
没有统一的数字标准，可按整改范围和问题严重程度确定。单项目问题抽取该项目整改后新开展的若干次活动记录；跨项目共性问题在多个项目中分别抽样，确认整改要求在各项目都生效。
抽样时优先选择整改后自然发生的活动，避开整改期间专门准备的样例，并记录抽样依据和样本清单。若抽样中再次发现同类问题，应退回再整改，而不是扩大样本量掩盖问题。
整改关闭后，历史遗留问题怎么处理？
历史遗留问题单独建条目跟踪，不并入已关闭的整改条目。例如整改前已发生的未评审变更，需要补充影响评估或风险确认，明确责任人和完成时间。
遗留条目同样要有完成标志和验证方式，在整改完成检查时一并核对。把遗留事项写清楚，可以避免关闭结论被理解为所有问题都已解决。
用研发管理工具承载整改跟踪时，重点看哪些配置？
重点看三处：整改问题能否作为独立工作项类型，与需求、缺陷等工作项建立关联；状态能否按“待整改—待验证—已关闭”流转并留下操作记录；评审与审批记录能否随工作项留存、便于按项目和活动类型检索。
ONES 可用于承载整改问题跟踪、工作项状态流转与评审记录留存这类管理动作，具体配置按团队现有流程设计。工具配置服务于整改流程，先确定问题清单字段和关闭标准，再落到工具里，避免为了用工具而增加无效字段。
