项目质量不符合项出现后，处理顺序可以概括为：先界定范围与影响，再验证原因，按严重度分级处置，最后用可复核证据确认关闭并把改进补回质量计划。本文聚焦单个项目内的质量控制，给出一套从发现到关闭的操作路径，涉及返工、回退或放行时，同时说明前提与停止点。
要点总览（TL;DR）
- 发现不符合项后先写清对象、对应质量要求、实际偏差和发现时点，再判断影响范围与严重度，避免用“质量不行”直接进入处置。
- 原因排查先列假设再找证据，按标准与理解、执行、外部输入的顺序逐项确认或排除，证据不足时只给暂定原因并限定处置范围。
- 处置按分级选择纠正、返工、让步接收、回退或重新评审，明确责任人与时限；涉及下游使用时先评估影响再决定暂停范围。
- 关闭以复检结果和评审结论为证据，涉及下游的补充下游确认；验证不通过回到原因排查，不直接关闭。
- 把根因对应的检查点、评审规则和责任分工补入质量计划，并按同类不符合项出现频次设定观察周期。
不符合项的症状与影响范围怎么界定
第一步是把“质量不行”这类笼统判断转成可核查的不符合项描述：哪个对象、对照哪条质量要求、实际表现与要求的偏差是什么、什么时候由谁发现。描述完成后再判断影响范围与严重度，顺序不能颠倒，否则分级容易受主观印象影响。
需要区分三类问题。不符合项指交付物或过程结果未满足已明确的质量要求，例如接口响应超出约定上限、评审发现的必改项未修改。缺陷通常指产品在运行或测试中表现出的功能错误，属于不符合项的一种具体形态。一般优化问题指满足现有要求但可以更好的改进建议，不进入不符合项流程，避免把改进清单和问题清单混在一起，稀释处置资源。
界定表建议包含以下字段，现场登记时逐项填写：
| 字段 | 填写要求 | 示例（演示情景） |
|---|---|---|
| 对象 | 具体到交付物、模块或过程记录，避免写“系统” | 订单查询接口 v1.2 |
| 对应质量要求 | 引用质量计划、验收标准或评审检查单中的条款 | 接口响应时间不超过 500ms |
| 实际表现 | 写可观察的事实与数据，不写评价 | 压测下平均响应 1.2s，超限 2.4 倍 |
| 发现时点与发现人 | 记录发现环节（自检、评审、测试、下游反馈） | 集成测试阶段，测试负责人 |
| 影响范围 | 单交付物、关联模块、已流转下游、客户可见程度 | 影响订单查询页，尚未对外发布 |
| 分级 | 按严重度、影响面、是否阻断后续环节综合判断 | 严重，阻断联调 |
分级口径建议提前约定，减少临场争议。可参考三档：严重级指阻断后续环节、已交付下游或客户可见且违反关键要求，须立即暂停相关流转；中等级指影响关联模块但存在临时绕行方式，需在约定时限内处置；轻微级指单交付物局部偏差、不影响下游，可纳入常规迭代修正。分级结论要写明依据，例如“因已流转至下游联调，定为严重级”，便于后续复盘时复核判断是否合理。
原因假设与排除证据怎么组织
原因排查的常见错误是把表面现象直接当根因，例如看到响应超时就归因于“开发没优化”，随后返工，问题却在下一个版本重现。更稳妥的做法是先列原因假设，再为每类假设指定可取得的证据，按排查顺序逐项确认或排除，只有证据支持的才写成已证实原因。
常见原因类别与对应证据可整理成对照表：
| 原因类别 | 验证证据 | 排查顺序建议 |
|---|---|---|
| 需求理解偏差 | 需求文档、澄清记录、验收标准与实现方案的对照 | 先查，成本最低且常是源头 |
| 标准缺失或不清 | 质量计划中是否有对应条款、条款是否可量化 | 与需求偏差同步核查 |
| 执行遗漏 | 检查单记录、提交记录、自检结果 | 标准明确后核查 |
| 评审放行过早 | 评审记录、必改项关闭情况、放行审批 | 在确认执行情况后核查 |
| 外部输入变化 | 第三方接口变更通知、依赖版本变更记录 | 前述均排除后核查 |
排查顺序遵循“先查标准和理解、再查执行、后查外部”的原则：标准层面的问题影响面最大，确认成本也低；外部输入变化通常有变更记录可查，放在后面避免一开始就把责任推给外部。每排除一类假设，记录排除依据，例如“需求文档明确约定 500ms，澄清记录无歧义，排除需求理解偏差”。
证据不足时不要强行下结论。可以给出暂定原因，同时限定处置范围，例如先对当前交付物做针对性修复，不扩大到流程调整，并设定观察期继续收集证据。暂定原因要在记录中标注状态，待证据充分后再升级为已证实原因，避免后续复盘时把假设当成定论。
不符合项的处置步骤与风险边界
处置路径按分级选择，不同路径的前提和停止点不同。纠正指修正当前偏差使交付物恢复符合要求，适用于原因清楚、影响局限的情况；返工指按原要求重新执行受影响环节，适用于执行遗漏或过程失效；让步接收指偏差可接受、经授权放行，前提是有明确的评审结论和接收条件；回退指撤回已流转的交付物或版本，适用于下游已使用且偏差不可接受的情况；重新评审适用于标准本身存在争议、需要先统一判断口径的情形。
处置流程建议按以下步骤推进：
- 确定责任人：由不符合项所属交付物的负责人牵头，质量责任人复核处置方案，涉及下游时纳入下游代表。
- 设定时限：按分级约定处置完成时间，严重级当日给出方案，中等级在约定工作日内完成，轻微级纳入迭代计划。
- 评估是否暂停：涉及已交付或下游正在使用时，先评估影响再决定是否暂停相关流转，暂停范围写清楚，避免整条链路停摆。
- 执行处置：返工或回退前确认备份可用，破坏性操作（覆盖数据、回滚版本、删除分支）须经评审并保留操作前快照。
- 记录结论：处置记录包含处置方式、执行人、完成时间、影响评估结论、审批人及审批意见。
风险边界要提前写明：让步接收必须由有权角色审批，并记录接收条件和后续观察安排；回退前确认下游已产生的数据或依赖如何处理；任何破坏性操作设置停止条件，例如复检不通过即停止后续步骤并回到原因排查。处置记录与审批信息建议在项目协作工具中随工作项流转，ONES 的项目计划支持按交付物维度分解工作并设置依赖与里程碑，可作为不符合项定位到具体交付物、记录处置状态的组织基础；具体字段与审批配置按团队实际设置。
如何验证恢复并防止同类问题复发
关闭不符合项不能以“已修改”为依据，要以可复核的证据确认交付物恢复符合要求。常用证据包括：按原质量要求执行的复检结果、评审结论（含必改项全部关闭）、下游使用方的确认记录。三类证据中至少具备复检结果和评审结论，涉及下游的补充下游确认。
验证不通过时按原路径回流：回到原因排查环节补充证据，重新确定处置方案，不直接关闭也不跳过评审。回流次数和每次回流的原因要记录，同一不符合项多次回流往往说明原因判断有误或处置范围不足，应升级评审。
复发预防把个案处置转成质量计划的改进，具体动作包括：
- 把根因对应的检查点补入质量计划或评审检查单，例如标准不清导致的偏差，补充可量化的验收条款。
- 调整评审规则，例如必改项未关闭不得放行，放行审批留痕。
- 明确责任分工，把新增检查点落实到具体角色和环节。
- 设定观察周期，按同类不符合项的出现频次监测改进效果，例如连续两个迭代同类问题为零再结束观察。
复发监测的数据可以来自日常流转记录。ONES 效能管理提供交付质量等维度的度量分析，自动收录系统内流转的研发数据并支持自定义指标，团队可据此观察同类不符合项的出现频次；是否预置不符合项关闭率、复发频次等具体模板，以实际版本配置为准。观察期结束后，把有效的改进措施固化进质量计划，无效的措施回到原因排查重新分析，形成从个案处置到计划改进的闭环。
常见问题
不符合项已经流转到下游，是先暂停还是先修复？
先评估影响再决定暂停范围。需要确认下游已经使用了哪些内容、偏差在下游会造成什么后果、是否存在临时绕行方式。如果偏差违反关键要求且下游无法绕行，暂停相关流转并写明暂停范围，避免整条链路停摆；如果存在可接受的临时措施，可以在限定范围内继续，同时约定修复时限和复检节点。无论哪种选择，影响评估结论和暂停决定都要写入处置记录。
原因一时查不清，可以先按表面现象返工吗？
可以处置，但要把原因状态标为暂定。做法是限定处置范围，只修正当前交付物的偏差，不扩大到流程调整，同时设定观察期继续收集证据。记录中区分“暂定原因”和“已证实原因”，待证据充分后再升级。这样既能让当前交付物恢复符合要求，也避免把假设当成定论写进复盘结论。
让步接收需要满足什么条件才算合规？
让步接收的前提是偏差经评估可接受，并由有权角色审批。记录中要写明接收条件、偏差范围、后续观察安排和审批意见。涉及客户可见或已交付内容的，还需要相关方确认。让步接收属于有条件的放行，不能替代原因排查，同类偏差反复出现时应回到原因分析，判断标准是否本身需要调整。
关闭验证需要哪些证据，只有修改记录够不够？
只有修改记录不足以关闭。常用证据包括按原质量要求执行的复检结果、评审结论（含必改项全部关闭），涉及下游的补充下游使用方确认记录。三类证据中至少具备复检结果和评审结论。验证不通过时回到原因排查补充证据，重新确定处置方案，不跳过评审直接关闭。
复发预防的观察周期怎么定？
观察周期按不符合项的出现频次和项目节奏设定，常见做法是以迭代为单位，例如连续两个迭代同类问题为零再结束观察。观察期内持续记录同类问题的出现次数和来源环节，数据可来自日常流转记录。观察期结束后，有效的改进措施固化进质量计划，无效的措施回到原因排查重新分析。
