项目质量不符合项是交付物或过程活动未满足既定质量要求的具体偏差。遇到它时，先界定对象、严重度和影响范围，再按“要求是否清晰—执行是否到位—验证是否覆盖”的顺序用证据排查原因，然后决定返工、返修、让步接收或报废，最后通过复验和同类问题复查确认恢复。本文按这条主线给出判定表、证据对照和处置清单。
要点总览（TL;DR）
- 先界定不符合项的对象、严重度和影响范围：从安全、合规、客户验收、后续工序四个维度判断优先级，再确定是单点、批次、跨阶段还是重复问题。
- 原因排查按“要求是否清晰—执行是否到位—验证是否覆盖”的顺序推进，每条假设都要有需求文档、作业记录或变更记录等证据支撑，未取得证据前只写疑似。
- 处置先标识隔离，再评审决定返工、返修、让步接收或报废；返工前确认基线、备份和回退条件，涉及验收或合规的问题及时升级。
- 关闭以复验结果符合原验收标准、记录字段完整、原因有证据为条件；随后横向复查同类工序或供应商，把预防动作落到检查项和流程文件上。
不符合项出现在哪些环节、影响多大
不符合项可以出现在项目交付物上，也可以出现在过程活动、项目文档或供应商来料上。判断时先明确“哪一类对象、违反了哪一条要求”，再评估影响。对象不清、要求不明的记录，往往会在后续处置中反复扯皮，因此登记的第一条信息应当是对象标识和对应的质量要求条款。
严重度分级建议围绕四个维度展开：是否影响人身或系统安全，是否违反合同、法规或行业强制要求，是否影响客户验收，是否阻断后续工序。四个维度中任一为“是”，都应进入高优先级处置；全部为“否”的，可按一般不符合项处理，但仍需记录和关闭。
| 判定维度 | 高严重度特征 | 一般严重度特征 | 处置优先级 |
|---|---|---|---|
| 安全 | 可能导致人身伤害、系统失效或数据泄露 | 无安全影响，仅影响外观或非关键性能 | 立即隔离并上报 |
| 合规 | 违反法规、合同强制条款或行业认证要求 | 偏离内部规范但可纠正 | 当日启动评审 |
| 客户验收 | 导致验收不通过或客户拒收 | 客户可接受但需说明 | 验收前完成处置 |
| 后续工序 | 阻断下游工作，或缺陷会随工序传递放大 | 可在本工序内消化 | 下道工序开始前处理 |
范围界定要回答三个问题：是单个工作项还是整批对象，是局限在一个阶段还是跨阶段，是首次出现还是重复出现。单个工作项可按点处置；批次性问题需要暂停相关批次并扩大抽样；跨阶段问题要回溯上游输入；重复出现的问题则说明前次处置未触及根因，应升级为专项分析。
不符合项与相邻概念的区别在于判定依据不同。缺陷通常指交付物在功能或性能上的失效，是不符合项的一种常见来源；变更请求是对已确认要求的修改，本身不构成偏差，但变更未同步执行会引发不符合项；风险是尚未发生的不确定事件，不符合项是已经发生的既成事实。区分清楚这三者，才能避免把变更当成缺陷处理，或把风险预警误记为不符合项。
原因假设与排除证据
原因排查的常见误区是先有结论再找证据。更稳妥的做法是把可能原因拆成若干条假设，为每条假设指定可验证的证据来源，逐条确认或排除。未取得证据前，原因只能写成“疑似”，不能写入处置结论。
| 原因假设 | 需要取得的证据 | 假设成立的表现 | 假设被排除的表现 |
|---|---|---|---|
| 要求本身未明确 | 需求文档、验收标准、评审记录 | 标准缺失、表述歧义或各方理解不一致 | 标准明确且有评审确认记录 |
| 执行未按规程 | 作业记录、操作日志、工序签认 | 实际步骤与规程不符，或关键参数超出范围 | 记录完整且与规程一致 |
| 验证环节遗漏 | 检查计划、检验记录、抽样方案 | 该检查项未列入计划，或抽样未覆盖问题对象 | 检查已执行且结果有效 |
| 输入变更未同步 | 变更记录、版本对比、通知记录 | 上游已变更，下游仍按旧版本执行 | 变更已同步且执行版本一致 |
排查顺序建议固定为三步。第一步确认要求是否清晰：调取需求、验收标准和评审记录，确认当时是否存在可执行、可判定的质量要求。第二步查执行记录：对照作业规程检查实际操作、参数和签认是否一致。第三步查验证覆盖：确认检查项、抽样范围和判定标准是否覆盖了出问题的对象。这个顺序的价值在于，要求不清时继续追查执行细节会浪费精力，而执行记录完整时再怀疑验证遗漏才有意义。
区分假设与结论的标准是证据能否独立支撑。例如“操作人员可能看错了图纸”只是假设，需要调取当班作业记录、图纸版本和培训记录才能判断；如果记录显示执行版本正确、参数合规，这条假设就应被排除并记录排除理由。排查过程本身也应留痕，写明每条假设的验证方式、证据位置和结论，便于后续复查和复盘。
按严重度安排处置步骤
处置的第一步是标识与隔离，而不是急于修复。对已确认的不符合项对象加标识、暂停流转，防止其流入下道工序或被误用；对批次性问题，同步暂停同批次对象并扩大检查范围。隔离动作要记录时间、执行人和隔离范围，这是后续判定责任和评估影响的依据。
评审与决策环节需要明确谁有权作出判定。返工适用于可恢复到符合要求状态的对象；返修适用于经处理后可满足使用要求但可能留下永久性偏差的对象；让步接收需要客户或授权代表书面同意，并明确适用范围和期限；报废适用于无法修复或修复成本不合理的情形。判定角色应与问题严重度匹配，涉及安全、合规或客户验收的，应由质量负责人会同相关方共同确认。
返工前要确认三件事：当前基线版本、必要的备份、回退条件。对代码、配置、文档等可版本化对象，先锁定基线并留存副本；对实物或已部署环境，明确回退步骤和停止点，一旦返工过程中出现超出预期的破坏，立即停止并按预案回退。破坏性操作前未确认备份的，不应开始处置。
处置记录建议包含以下字段，缺一项都可能导致关闭时无法举证：
- 不符合项编号与对象标识，关联的质量要求条款；
- 发现时间、发现环节、发现人；
- 严重度判定与判定依据；
- 原因结论及支撑证据的位置；
- 处置方式（返工、返修、让步接收、报废）与判定人；
- 责任人、计划完成期限、实际完成时间；
- 复验结果与关闭结论。
升级条件应提前写清：影响客户验收、涉及合规要求、跨项目重复出现、或处置期限已过仍未关闭的，应上报项目负责人和质量负责人。升级不是追责动作，而是调动资源和协调决策的机制，越早触发越能避免问题在验收阶段集中暴露。
当不符合项数量较多、需要跨角色流转时，登记、评审、处置、复验的状态衔接容易散落在聊天和邮件里。ONES Project 支持缺陷跟踪管理，可将问题提交至对应项目或迭代并统计状态分布，也可自定义需求状态与属性、按项目角色分配权限，用于承载不符合项从登记到关闭的记录流转；质量判定和处置决策仍由相应角色依据证据作出。
复验、关闭与复发预防
复验应回到原验收标准，而不是按处置后的新状态自检。处置完成后，由未参与原处置的人员按原标准重检；对批次性问题，复验抽样范围应覆盖原问题对象及同批次其余对象；对高严重度问题，可增加独立复核环节。复验不通过时，回到处置步骤重新判定，不能以“已返工”为由直接关闭。
关闭需要同时满足三个条件：复验结果符合原验收标准，处置记录字段完整，原因结论有证据支撑。关闭时留存复验记录、判定意见和证据位置，形成可追溯的闭环。仅有处置动作而无复验证据的记录，应视为未关闭。
复发预防从同类问题复查开始。横向检查相同工序、相同供应商或相同版本的其他对象，确认是否存在同样偏差；若存在，按同一流程登记处置，而不是并入原记录。随后把根因对应的动作落到具体载体上：要求不清的，补充验收标准并纳入评审要点；执行偏差的，更新作业规程或增加关键步骤签认；验证遗漏的，调整检查计划和抽样方案；变更未同步的，在变更流程中增加下游通知与版本核对节点。
预防动作是否有效，需要一段观察期来验证。可设定一个观察周期，统计同类不符合项的新增数量；观察期内再次出现同类问题的，重新进入原因排查，并检查前次预防动作是否真正执行。把观察期、复查结果和复发情况记入原记录，既是对本次处置的验证，也为后续项目积累可复用的检查项。
常见问题
不符合项登记后发现对象或要求描述不清，应该先补记录还是先处置？
先补齐对象标识和对应的质量要求条款，再启动处置。对象不清会导致隔离范围无法确定，要求不明则无法判断是否真的构成偏差。若一时无法确认要求条款，可先做临时隔离防止流入下道工序，同时调取需求文档、验收标准和评审记录补全判定依据，再进入评审环节。
返工过程中发现影响范围比原判定更大，处置流程要怎么调整？
立即停止当前返工，按预案回退到已确认的基线，并重新界定范围。范围扩大通常意味着原严重度判定偏低或批次划分有误，应重新评估安全、合规、客户验收和后续工序四个维度，必要时升级至项目负责人和质量负责人共同判定。原处置记录保留，新增范围作为关联记录登记，避免把两次判定混在一条记录里。
让步接收需要满足什么条件，后续还要做什么？
让步接收适用于经评估可满足使用要求、但存在永久性偏差的对象，需要客户或授权代表书面同意，并明确适用范围和期限。同意后仍要留存偏差说明、判定依据和批准记录；在观察期内跟踪该对象在实际使用中的表现，出现异常时重新进入不符合项处置流程。
同类问题在不同项目重复出现，单项目层面还能做什么？
单项目层面可以做两件事：一是把本次根因对应的检查项、评审要点补充到本项目后续阶段的检查计划中；二是把复发情况和证据整理后提交给质量负责人，作为组织级流程或标准修订的输入。组织质量制度的调整属于更高层级的工作，项目内先确保同类工序和相同供应商的对象完成横向复查。
用项目协作工具承载不符合项记录时，需要关注哪些配置点？
重点看三处：登记对象能否关联质量要求条款和证据位置，状态能否覆盖登记、评审、处置、复验、关闭的流转，权限能否按项目角色区分判定人与执行人。以 ONES Project 为例，它支持缺陷跟踪管理，可将问题提交至对应项目或迭代并统计状态分布，也支持自定义需求状态与属性、按项目角色分配权限，可用于承载不符合项从登记到关闭的记录流转；质量判定和处置决策仍由相应角色依据证据作出。
