本文提供一份已填写的项目质量不符合项整改记录示例，覆盖发现与描述、分级与判定、责任人与时限、原因分析、整改措施、验证结论六类信息，并逐项解释填写依据。示例为演示情景，不对应真实客户或项目；读者可参照结构替换内容，分级口径与时限要求需以所在项目或组织的质量制度为准。
要点总览（TL;DR）
- 一份可用的整改记录围绕一个不符合项形成闭环，六类信息齐全：发现与描述、分级与判定、责任人与时限、原因分析、整改措施、验证结论。
- 问题描述要写到他人可独立复现的程度，分级要写明判定依据，原因分析区分直接原因与根因，措施与原因逐条对应。
- 验证确认的是问题已消除而非措施已执行，验证人与整改人分离记录，结论写明核对对象与核对方法。
- 换其他类型的不符合项时保持六类信息齐全即可迁移，分级口径、时限与关闭权限以本项目或组织质量制度为准。
- 示例中的编号、日期、角色和时限均为演示设定，套用时替换为实际内容，先确认分级标准与关闭权限。
示例目标：这份整改记录要解决什么问题
这份示例设定在一个处于交付阶段的自研软件项目中，项目质量负责人例行检查时发现一项不符合项，需要留下从发现到关闭的完整记录。记录的使用对象包括三类角色：项目质量负责人负责登记与判定，整改责任人负责原因分析与措施执行，验证人负责确认整改效果并给出结论。示例要回答的是单项目质量控制中的记录闭环问题：一项不符合项被发现之后，如何用一份记录把判定依据、责任分工、处理过程和最终结论串起来，使后续追溯时有据可查。
记录目标可以归纳为三点。第一，可追溯：任何人拿到这份记录，都能还原问题在什么时间、什么环节、以什么方式被发现。第二，可对应：分级、原因、措施、验证四部分内容彼此呼应，措施针对原因，验证针对措施。第三，可交接：记录在整改人、验证人之间流转时，不依赖口头补充信息。示例中的项目背景、人员角色和数据均为演示设定，用于说明填写方式，不代表任何真实组织的实际做法。
完整示例：一份填好的不符合项整改记录
下表是一份已填写的整改记录。示例情景设定为：某软件项目在交付前的内部质量检查中，发现接口文档与已实现接口不一致。记录按六类信息组织，读者可对照自己的项目替换具体内容。
| 记录部分 | 字段 | 填写内容（示例） |
|---|---|---|
| 一、发现与描述 | 不符合项编号 | NCR-2024-017 |
| 发现时间与环节 | 2024-06-11，交付前内部质量检查 | |
| 发现人 | 项目质量负责人（示例角色） | |
| 问题描述 | 用户信息查询接口的文档标注返回字段为 6 个，实际实现返回 8 个，多出“最近登录时间”“账号状态”两个字段，文档未同步更新 | |
| 证据 | 接口文档第 3.2 节截图、接口实际返回报文样例 | |
| 二、分级与判定 | 严重程度 | 一般 |
| 判定依据 | 不影响功能正确性，但会导致对接方按文档开发时字段解析不全，影响范围为使用该接口的外部对接模块 | |
| 判定人 | 项目质量负责人 | |
| 三、责任人与时限 | 整改责任人 | 接口开发负责人（示例角色） |
| 整改时限 | 2024-06-14（发现后 3 个工作日内） | |
| 关联工作项 | 需求变更单 CR-2024-052（文档同步更新） | |
| 四、原因分析 | 直接原因 | 接口在迭代中新增两个返回字段，开发完成后未同步更新接口文档 |
| 根因 | 接口变更与文档更新未纳入同一检查环节，文档更新缺少触发条件 | |
| 五、整改措施 | 纠正措施 | 更新接口文档第 3.2 节，补充两个字段的说明与示例报文；通知已获取旧版文档的对接方 |
| 预防措施 | 在接口变更流程中增加“文档同步确认”检查点，由接口开发负责人在提交变更时勾选确认 | |
| 完成情况 | 2024-06-13 完成文档更新并发出通知，预防措施于 2024-06-14 纳入变更流程 | |
| 六、验证结论 | 验证方式 | 对照实际接口返回报文逐字段核对更新后的文档，并抽查一名对接方确认收到通知 |
| 验证人 | 项目质量负责人（与整改责任人分离） | |
| 验证结论 | 2024-06-14 验证通过，文档与实际返回一致，不符合项关闭 |
这份记录的关键在于六部分内容能相互对应：问题描述中的“两个字段未同步”对应原因分析中的“接口变更未触发文档更新”，对应纠正措施中的“补充字段说明”，最终由验证环节用实际报文核对确认。任何一环缺失，记录都会变成一份无法复核的情况说明。
逐项解释：每个字段为什么这样填
发现描述写到可复现的程度
问题描述字段的填写标准是：换一个人拿着描述和证据，能够独立复现同样的判断。示例中写明了接口名称、文档标注的字段数量、实际返回的字段数量以及多出的具体字段名，并附上文档截图和返回报文样例。常见的不合格填法是“接口文档有问题”“文档与实现不一致”，这类描述无法支撑后续验证，也无法判断影响范围。发现环节与发现时间同样要写清楚，便于判断问题是在哪个检查节点被拦截的。
分级依据与影响范围挂钩
严重程度不能只写一个等级词，要同时写明判定依据。示例将问题定为“一般”，依据是不影响功能正确性，但会影响外部对接方的字段解析。分级依据通常从三个角度展开：对功能或交付的影响、影响波及的范围、是否已有替代或规避方式。分级口径应与项目或组织既定的标准一致，同一类问题在不同项目中可能被定为不同等级，记录中写清依据比等级本身更重要。
原因分析区分直接原因与根因
直接原因回答“这次为什么发生”，根因回答“为什么这类问题会重复出现”。示例中直接原因是新增字段后未更新文档，根因是接口变更与文档更新没有纳入同一检查环节。只写直接原因，整改措施往往停留在补这一次的文档；写到根因，才能引出预防措施。原因分析应基于事实和过程记录，避免写成“责任心不强”这类无法验证的表述。
整改措施可执行、可检查
措施分为纠正措施和预防措施两类。纠正措施针对本次问题，要写清做什么、做到什么程度、由谁完成；预防措施针对根因，要写清落在哪个流程或检查点上。示例中的预防措施明确为“在接口变更流程中增加文档同步确认检查点”，这是一个可以被后续检查的动作。措施填写完成后，应能回答“怎么判断这件事做完了”，完成情况字段就是对这个问题的回答，需写明完成日期和具体结果。
验证结论需有证据支撑
验证不是确认“措施已执行”，而是确认“问题已消除”。示例中的验证方式是对照实际返回报文逐字段核对文档，并抽查对接方是否收到通知，验证结论写明验证日期和关闭状态。验证人由项目质量负责人担任，与整改责任人分离，使验证结论具有独立性。验证结论应写明依据，例如核对结果、抽查记录，避免只写“已验证，通过”。
可迁移规律：换一个不符合项怎么套用
示例针对的是文档与实现不一致，但记录结构可以迁移到其他类型的不符合项，例如交付物缺项、过程记录缺失、评审意见未闭环等。迁移时保持六类信息齐全即可构成最小闭环：发现与描述、分级与判定、责任人与时限、原因分析、整改措施、验证结论。缺少任何一类，记录在追溯时都会出现断点。
- 分级标准与项目或组织的口径保持一致，记录中写明判定依据，不自行发明等级。
- 责任与时限落到具体角色和具体日期，避免写“相关同事”“尽快处理”。
- 原因分析至少写到可以直接推出措施的程度，措施与原因逐条对应。
- 验证人与整改人分离记录，验证方式写明核对对象和核对方法。
- 每条措施都有对应的完成情况，完成情况带日期和可观察的结果。
- 记录中引用证据的位置固定，例如截图、报文样例、检查记录，便于复核。
当不符合项数量增多时，单份记录之外还需要一个统一的登记入口，让编号、状态和责任人可以被集中查看。在 ONES 中，项目内的需求、任务与缺陷等工作项可以承载这类登记与流转，配合项目计划与里程碑基线对比计划与执行的偏差，帮助质量负责人更早发现偏离（依据 ONES 瀑布项目管理解决方案资料）。是否将不符合项作为独立工作项类型管理，需结合团队现有流程确认。
适用边界：哪些情况需要另行处理
本示例聚焦单项目质量控制中的不符合项记录，适用于项目内部发现、由项目角色判定和关闭的问题。以下情况超出示例范围，需要按对应制度另行处理。
- 组织级质量制度设计，包括分级标准、时限要求、验证权限的制定，归研发质量保证体系，本文示例中的分级口径仅作填写示范。
- 测试执行与测试用例管理，包括测试设计、执行记录和缺陷跟踪的具体方法，归测试管理，本文不展开。
- 跨项目的质量趋势分析与组织级度量，需要在单项目记录之上另行汇总，本文不涉及汇总口径。
- 涉及合同、法规或客户验收的不符合项，其处理流程和记录要求通常由合同条款或行业规范约定，应以相应文件为准。
此外，示例中的时限（发现后 3 个工作日）、分级名称和验证角色设置均为演示设定，不同组织的质量制度可能要求不同的时限和审批层级。读者在套用时应先确认本项目的分级标准与关闭权限，再替换示例内容。记录格式本身可以复用，具体数值和角色分工需按实际情况填写。
常见问题
不符合项整改记录和问题清单有什么区别，两者都要维护吗？
问题清单通常用于集中登记和跟踪状态，字段偏简，便于快速查看有哪些问题、由谁负责、进展如何；整改记录针对单个不符合项展开，需要写清发现过程、分级依据、原因分析、措施和验证结论。两者可以并存：清单作为入口，整改记录作为每个不符合项的详细档案，通过编号关联。项目规模较小、问题数量不多时，也可以把整改记录的关键字段并入清单，避免维护两份内容。
整改责任人自己验证整改结果可以吗？
整改人自行验证在部分组织中是允许的，前提是验证方式和证据写清楚，例如核对对象、核对方法和核对结果。需要独立确认整改效果的场景，更常见的做法是验证人与整改人分离，由项目质量负责人或指定角色担任验证人。是否强制分离取决于项目的质量制度与关闭权限设置，记录中应写明验证人角色，便于后续追溯时判断结论的独立性。
原因分析写到什么程度才算够？
判断标准是：从原因能否直接推出对应的措施。只写到“文档未更新”，措施只能停在补这一次的文档；写到“接口变更与文档更新未纳入同一检查环节”，才能引出在变更流程中增加检查点的预防措施。原因分析应基于过程记录和事实，避免“责任心不强”“沟通不到位”这类无法验证、也无法对应措施的表述。若一时无法确定根因，可以先记录直接原因和已采取的措施，在记录中注明根因待进一步分析。
不符合项关闭后还需要保留记录吗，保留多久？
建议保留。关闭后的记录是后续追溯、复盘和质量趋势分析的依据，例如同类问题再次出现时可以对照历史原因和措施判断预防措施是否有效。保留期限和归档方式通常由组织的质量制度或合同要求约定，涉及客户验收或法规要求的项目可能有更长的保存要求，应以相应文件为准。记录归档时应保证编号、证据附件和验证结论完整可查。
多个不符合项原因相同，需要逐条写整改记录吗？
可以合并处理，但记录方式要能保持可追溯。常见做法是每个不符合项保留独立编号和发现描述，在原因分析与措施部分引用同一条根因分析和同一组预防措施，并注明关联的其他编号。这样既避免重复撰写相同内容，也不会在追溯时丢失单个问题的发现与验证信息。合并的范围和引用方式建议在项目内统一约定，避免不同人写法不一致。
