研发过程检查发现的问题进入整改流程前，先要完成两件事：用统一口径分类定级，再用证据判断问题根源是体系缺陷还是项目执行偏差。定级决定处置优先级，归因决定整改责任落在规则制定方还是项目组。本文给出一套可直接对照使用的分类表、归因证据清单、分类处置路径和验证方法，并说明如何在ONES工作项与文档中把登记、定级、整改、复查串成闭环。
要点总览（TL;DR）
- 分类定级用两个维度：按问题对象分为交付物缺陷、过程活动缺失、记录与证据缺失、角色职责不清、工具与数据问题；按严重程度分为阻断级、严重级、一般级、观察项，并同步记录影响范围与复发情况。
- 归因判断按四条证据逐条排查：规则是否存在、规则是否可执行、是否跨项目重复出现、执行记录是否可查；规则缺失或不可执行指向体系缺陷，规则明确但个别项目未落实指向执行偏差。
- 处置按类型分工：体系缺陷由规则制定方修订规则、模板与职责并试点宣贯；执行偏差由项目组纠正交付物、补做活动并限期完成；两类共存时先止血、再修规则、后跟踪执行。
- 验证回到同一检查口径：复查原问题、抽查同类项目、核对整改记录与新规则可用性；把高频问题纳入检查清单、定期复盘归因分布、跟踪整改关闭率来防止复发。
- 定级与归因结论都要有证据支撑，单点问题未完成跨项目抽查前不宜直接上升为体系问题，多个项目同时偏离也要先确认规则本身是否可执行。
检查发现的问题先按什么口径分类定级
分类定级的目标是让检查人员、项目组和过程改进人员对同一个问题形成一致描述，避免“严重”“一般”各说各话。建议采用两个维度同时记录：问题对象决定由谁整改，严重程度决定何时整改。
按问题对象分类
问题对象指问题直接落在哪类事物上，它决定了整改动作的类型和承接角色。
- 交付物缺陷：需求文档、设计说明、代码、测试用例等交付物内容不完整、不一致或不符合约定标准。
- 过程活动缺失：规定的评审、走查、阶段确认等活动未开展，或开展时未达到规定条件。
- 记录与证据缺失：活动做了但无记录，或记录无法证明活动按要求完成，例如评审结论未留痕、问题关闭无依据。
- 角色职责不清：同一活动多人负责或无人负责，审批人、评审人、责任人未在规则中明确。
- 工具与数据问题：工作项状态与实际不符、数据字段缺失、工具配置导致流程无法按规则执行。
按严重程度定级
定级依据是问题对交付质量和后续阶段的影响，而不是问题被发现的难易程度。
| 级别 | 判定依据 | 处置时限要求 |
|---|---|---|
| 阻断级 | 问题已导致或必然导致下游活动无法开展，或交付物存在重大错误且已流入下一阶段 | 立即停止相关活动，先处置再继续 |
| 严重级 | 关键过程活动缺失或关键交付物不符合要求，影响阶段目标达成，但尚未扩散到下游 | 限期纠正，纠正前不得进入下一阶段 |
| 一般级 | 交付物或过程存在偏差，影响局部质量，可通过补充活动或修订内容消除 | 纳入本轮整改计划 |
| 观察项 | 当前未造成实际影响，但存在演变为问题的趋势，或做法不统一 | 记录跟踪，定期复盘 |
定级时同步记录两个附加信息：影响范围分为单项目、多项目、组织级；复发情况注明首次发现还是重复出现。重复出现的问题即使单次影响不大，也应提高关注级别，因为它往往指向规则或执行机制的问题。
分类定级表应包含的字段
建议每条问题至少记录以下字段，作为后续归因和整改的输入：
| 字段 | 填写要求 |
|---|---|
| 问题描述 | 写清事实、位置和不符合的具体要求，避免评价性表述 |
| 问题对象 | 从五类对象中选择，可多选但需标注主对象 |
| 级别 | 阻断级、严重级、一般级、观察项 |
| 影响范围 | 单项目、多项目、组织级 |
| 复发情况 | 首次发现或重复出现，重复出现需关联历史记录 |
| 证据 | 检查记录、交付物版本、工作项链接、访谈记录等可复核材料 |
| 责任人 | 问题所属项目的直接责任人，以及待定的整改承接方 |
这张表的作用是让定级结论可追溯。没有证据支撑的级别判断，在整改评审时容易被推翻，也会让归因失去基础。
怎么判断是体系缺陷还是项目执行偏差
归因的核心问题是：问题出在“没有规则或规则不可用”，还是“有规则但没执行”。判断依据是证据，不是问题出现的次数或相关人员的印象。建议按四条证据逐条排查，先形成候选原因，再逐条验证或排除。
四条判断证据
| 证据 | 排查问题 | 指向体系缺陷 | 指向执行偏差 |
|---|---|---|---|
| 规则是否存在 | 组织或项目层面是否有覆盖该活动的明确规则 | 规则缺失，或同一事项存在互相冲突的多份规定 | 规则明确存在且现行有效 |
| 规则是否可执行 | 规则要求的模板、准入条件、职责分工是否具备 | 模板不可用、评审无准入条件、职责未定义，按规则做不下去 | 规则可操作，所需模板和角色均已具备 |
| 是否跨项目重复出现 | 同类问题在其他项目是否同样存在 | 多个项目以相同方式偏离，说明规则本身或宣贯存在问题 | 仅个别项目偏离，其他项目按规则执行 |
| 执行记录是否可查 | 活动是否开展、是否留下可核验的记录 | 规则未要求留痕，或留痕方式无法证明活动完成 | 规则要求留痕，但该项目未记录或记录缺失 |
两类根源的典型证据
体系缺陷的典型证据包括：规则缺失，某项活动没有任何文件规定；规则冲突，两份文件对同一评审的参与角色要求不一致；模板不可用，规定使用的模板字段缺失或与实际交付物不匹配；职责未定义，问题关闭由谁确认没有明确；评审无准入条件，评审何时可以启动、达到什么状态才能通过没有标准。
项目执行偏差的典型证据包括：规则明确但未执行，项目组知晓要求却跳过活动；记录缺失，活动实际开展但未按要求留痕；跳过评审，评审条件已满足但未组织评审直接进入下一阶段；个别项目偏离，同类活动在其他项目均按规则完成。
先假设后验证的排查顺序
拿到一条问题后，不要直接下结论。先列出候选原因，例如“规则未规定”“规则规定了但模板缺失”“规则和模板都有但项目未执行”“规则存在但项目组不了解”。然后按以下顺序找证据：
- 调取现行规则文件，确认该活动是否有规定、规定是否唯一有效。
- 核对规则配套的模板、检查表和角色定义是否齐备、是否可用。
- 抽查其他同类项目的执行记录，判断问题是普遍存在还是个别现象。
- 访谈项目责任人，确认其是否知晓规则、是否具备执行条件。
每一步都要留下证据，排除一个候选原因就记录排除依据。单点问题在未完成跨项目抽查前，不应直接上升为体系问题；同样，多个项目同时偏离也不能简单归为执行不力，需要先确认规则本身是否可执行。
当问题登记、定级和归因结论分散在邮件和表格中时，排查证据容易丢失。ONES 可围绕项目计划、阶段推进、任务协同和研发过程管理建立清晰的项目管理方式，检查问题可以作为工作项记录对象、级别、影响范围和证据附件，归因结论与整改任务在同一处关联，复查时能直接回溯当时的判断依据。
进入整改流程后的处置步骤
归因结论不同，整改承接方和处置动作也不同。体系缺陷由规则制定方牵头，项目执行偏差由项目组牵头，两类问题共存时按“先止血、再修规则、后跟踪执行”的顺序推进。
体系缺陷的处置
- 修订规则或模板：明确缺失的活动要求、统一冲突条款、补齐模板字段和评审准入条件，修订后标注生效日期和适用范围。
- 明确职责与准入条件：为每个关键活动指定责任人、评审人和关闭确认人，写清活动启动和通过的条件。
- 组织宣贯与试点：新规则先在少量项目试点，确认可执行后再推广，宣贯记录作为整改证据留存。
体系缺陷的整改责任通常在质量或过程管理部门，项目组配合提供执行反馈。规则修订涉及流程变更时，需评估对在研项目的影响范围，明确新旧规则的切换时点，避免在研项目中途适用两套要求。
项目执行偏差的处置
- 纠正具体交付物：对存在缺陷的交付物补充、修订并重新确认，纠正后的版本与问题记录关联。
- 补做缺失活动：对跳过的评审、走查等补充开展，补做时说明补做范围和结论有效性。
- 明确项目责任人与完成时限：每条问题指定项目内责任人，设定完成时间，整改结果由检查人员确认关闭。
执行偏差的整改要避免只补记录不补活动。补做活动应留下真实的过程记录，补做的评审结论需要评审人确认，不能由责任人自行标注完成。
两类问题共存的处置顺序
- 先止血：阻断级问题立即停止相关活动，控制影响范围，防止缺陷流入下游。
- 再修规则：对已确认的体系缺陷启动规则和模板修订，明确责任人和生效时间。
- 后跟踪执行：规则生效后，跟踪各项目执行情况，把执行偏差纳入常规检查。
处置过程中的风险边界需要提前交代：涉及流程变更的，评估影响范围并设置过渡期；涉及数据修改的，修改前备份或保留修改痕迹，确保整改过程可追溯；涉及跨项目推广的，先试点再推广，避免规则频繁变动影响在研项目。
整改后如何验证效果并防止复发
整改关闭不等于问题解决。验证要回答两个问题：同类问题是否还会发生，规则是否真的被执行。验证证据应与定级时的证据口径一致，便于对比。
验证证据清单
| 验证对象 | 验证动作 | 通过标志 |
|---|---|---|
| 原问题 | 复查同一检查项 | 原问题已纠正，证据完整，关闭条件满足 |
| 同类项目 | 抽查其他项目同类活动 | 未发现相同问题，或发现的问题已单独登记 |
| 整改记录 | 核对整改任务与关闭结论 | 每条问题有责任人、完成时间和确认人 |
| 新规则 | 在试点项目中试用 | 规则可操作，模板被实际使用，无频繁例外 |
两类问题的验证重点
体系缺陷的验证重点是规则可用性：新规则在试点项目中是否可执行，模板是否被实际填写和使用，评审准入条件是否清晰到项目组无需额外解释即可操作。如果试点中仍频繁出现例外申请，说明规则还需调整。
项目执行偏差的验证重点是执行一致性：同类活动在后续检查中是否按规则完成，记录是否完整可查，责任人是否清楚自己的整改义务。验证应覆盖不止一个项目，避免只复查被检查项目本身。
复发预防机制
- 把高频问题纳入检查清单：重复出现的问题转化为检查项，下次检查直接对照，减少同类问题漏检。
- 定期复盘归因结论：按季度或阶段汇总问题分类和归因分布，观察体系缺陷与执行偏差的比例变化，判断改进方向是否有效。
- 跟踪整改关闭率：统计各项目和各类问题的整改完成情况，对超期未关闭的问题升级处理。
这些跟踪动作需要稳定的记录载体。ONES 支持研发过程管理和跨域协作全过程的可追溯性，问题从登记、定级、归因到整改、复查可以在工作项和文档中连续记录，阶段推进中的检查结论与整改状态保持关联，复盘时按项目、级别和归因类型汇总，整改关闭情况有据可查。对于采用 IPD 或 ASPICE 等过程框架的团队，这套记录方式也能与既有的阶段评审和流程活动衔接。
分类定级和归因判断的价值在于让整改有明确对象和责任人。定级靠影响和证据，归因靠四条证据逐条排查，处置按问题类型分工，验证回到同一检查口径。把这四步固定下来，检查发现的问题才能从单次纠正转为体系持续改进的输入。
常见问题
检查发现的问题同时涉及规则缺失和项目未执行，归因时怎么处理？
这类问题按两条线索分别记录，不强行合并成一个结论。先确认规则层面缺什么：是活动要求没有规定、模板不可用，还是职责和准入条件未定义；再确认项目层面哪些动作未落实。整改时把规则修订交给规则制定方，把交付物纠正和活动补做交给项目组，两条整改任务分别设责任人和完成时限。验证阶段也要分开看：新规则在试点项目中是否可执行，项目组在后续检查中是否按规则完成。
只有一两个项目出现的问题，可以直接定为体系缺陷吗？
不建议直接下结论。单点问题先按执行偏差排查：规则是否存在且现行有效、模板和角色是否具备、项目组是否知晓要求。如果规则明确、条件具备而项目未执行，归为执行偏差。只有在跨项目抽查中发现同类问题以相同方式普遍出现，或规则本身缺失、冲突、不可执行时，才上升为体系缺陷。排查过程中的证据要留存，作为归因结论的依据。
阻断级问题在整改流程中是否要先停掉整个项目？
阻断级的处置要求是立即停止相关活动，控制影响范围，防止缺陷流入下游，范围限定在受影响的活动和交付物，不必扩大到整个项目。停止后先评估缺陷是否已扩散、涉及哪些下游交付物，再决定纠正和返工范围。如果问题同时暴露规则缺失，止血完成后启动规则修订，避免同类问题在其他项目重复发生。
整改完成后，复查只检查原项目够不够？
不够。原项目复查只能证明这一条问题被纠正，不能证明同类问题不再发生。验证应至少覆盖三个方向：复查同一检查项确认原问题关闭条件满足；抽查其他同类项目的相同活动，确认没有相同问题；核对整改记录是否完整，每条问题有责任人、完成时间和确认人。体系缺陷还要确认新规则在试点项目中可操作、模板被实际使用。
问题分类定级和归因记录放在哪里，复查时才能快速回溯？
关键是让问题描述、级别、影响范围、证据附件、归因结论和整改任务保持关联，而不是分散在邮件和独立表格中。ONES 可围绕项目计划、阶段推进、任务协同和研发过程管理建立清晰的项目管理方式，检查问题可以作为工作项记录上述字段，归因结论与整改任务在同一处关联，复查时能直接回溯当时的判断依据。对于采用 IPD 或 ASPICE 等过程框架的团队，这套记录方式也能与既有的阶段评审和流程活动衔接。
