项目质量检查表的设计，核心是围绕单个项目的交付物，把检查对象、检查项、判定标准、检查方式、责任人、检查时点和不符合项处置写成可逐项勾选、可留证据的表格。设计时先确定检查范围与质量目标，再按交付物类型拆检查项，为每项写清通过标准与证据要求，指定检查人和检查时点，最后配套不符合项的记录、整改与复核闭环。下面按这个顺序展开，并给出一份可直接套用的字段模板和填写示例。
要点总览（TL;DR）
- 检查表设计从项目质量目标和交付物清单出发，先划定检查范围，按阶段或交付物类型分册，避免一张表覆盖所有要求。
- 核心字段包括检查项编号、检查对象、检查内容、判定标准、检查方式、证据要求、检查人、检查时点、结论和备注，判定标准要写成两名检查人能得出一致结论的条件。
- 检查项按交付物结构或过程环节逐层拆解，每个条目只对应一个判定点，按风险区分必检项与抽检项，并让每条检查项能回溯到质量目标。
- 检查人、被检查人、复核人三类角色要落实到具体人员，检查时点与里程碑或交付节点绑定，检查记录统一归档。
- 不符合项按记录、分级、整改、复核、关闭闭环处理，到期未整改的按项目内升级路径处理；设计完成后用自检清单核对再发布。
先定检查范围：检查表覆盖哪些交付物和阶段
检查表设计的第一步是划定边界。项目质量检查表服务于单项目的质量控制，覆盖范围应当从项目质量目标和交付物清单推导出来，而不是把所有质量要求都塞进一张表。范围定得清楚，后续拆检查项才有依据。
具体做法分三步。第一，取出项目质量计划中的质量目标，列出本项目需要交付的成果物，包括文档类、软硬件产品类、过程记录类。第二，按阶段或交付物类型把清单分组，例如需求阶段、设计阶段、开发与集成阶段、测试阶段、交付验收阶段，每一组对应一份检查表分册。第三，为每个交付物标注检查责任角色，明确由谁主检、谁配合提供材料。
范围界定还要分清三类内容的归属：组织级质量制度、流程规范和审计要求属于质量保证体系，不在本文展开；测试用例设计与测试执行属于测试管理，检查表只引用其结论；本文聚焦的是单项目层面对交付物和关键过程节点的质量控制。把这条边界写进检查表说明，可以避免检查表被当成制度文件使用。
完成标志是产出一份检查范围清单，至少包含交付物名称、所属阶段、检查责任角色三列，并经项目负责人确认。
检查表的核心字段与逐项设计方法
字段决定检查表能否被逐项执行。一张可用的检查表通常包含十个字段，每个字段都有明确的填写规则，缺一项就会在执行时产生歧义。
| 字段 | 填写规则 | 示例 |
|---|---|---|
| 检查项编号 | 按分册加序号编码，便于引用和追踪 | REQ-01 |
| 检查对象 | 写明具体交付物名称及版本 | 需求规格说明书 V1.2 |
| 检查内容 | 一个判定点，描述要核实的事实 | 每条需求是否标注优先级和验收条件 |
| 判定标准 | 写成可通过或不通过的条件，避免“基本完整”这类模糊表述 | 抽样20条需求，全部具备优先级与验收条件为通过 |
| 检查方式 | 文档审查、现场核对、抽样验证、演示确认中选择 | 文档审查加抽样验证 |
| 证据要求 | 写明需留存的记录形式 | 检查记录截图、抽样清单、评审签到表 |
| 检查人 | 填写具体角色或姓名，不写“相关人员” | 质量工程师 |
| 检查时点 | 对应里程碑或提交节点 | 需求评审通过后2个工作日内 |
| 结论 | 通过、不通过、不适用三选一 | 不通过 |
| 备注 | 记录例外情况、关联不符合项编号 | 关联不符合项 NC-007 |
判定标准是字段设计中最容易出问题的地方。合格的标准是：两名不同的检查人依据同一条标准检查同一对象，能得出一致结论。做不到这一点，就说明标准还需要细化，例如把“文档格式规范”改成“章节编号连续、图表均有编号和标题、术语表与正文一致”。
检查方式要与检查内容匹配。文档类交付物多用文档审查，实物或环境类多用现场核对，批量数据或记录类适合抽样验证，功能类可以安排演示确认。证据要求则要提前想清楚留存形式，检查结束后再补证据往往补不回来。
检查项怎么拆：从质量目标到可勾选条目
检查项拆解的质量直接决定检查表是否好用。拆得太粗，检查流于形式；拆得太细，执行成本过高。合理的做法是按交付物结构或过程环节逐层分解，直到每个条目只对应一个判定点。
以需求规格说明书为例，质量目标可能是“需求完整、可验证、可追溯”。拆解时先按文档结构分成需求描述、验收条件、优先级、追溯关系四个部分，再把每部分转成条目：每条需求是否有唯一编号；每条需求是否写明验收条件；优先级是否覆盖全部需求；每条需求是否关联上游来源和下游设计。每个条目只回答一个问题，检查时勾选通过或不通过即可。
条目数量需要控制。建议按风险高低区分必检项和抽检项：涉及安全、合规、对外承诺、核心功能的内容设为必检，逐条核对；格式规范、辅助说明类内容设为抽检，按比例抽样。一张分册的必检项通常控制在二十到四十条之间，超过这个量级应考虑再拆分册。
拆解完成后要做一次对应关系检查：每个质量目标至少对应一条检查项，每条检查项能回溯到某个质量目标或交付物要求。没有对应目标的条目要么删除，要么补充目标说明，避免检查表越用越臃肿。
| 质量目标 | 交付物部分 | 检查项 | 类型 |
|---|---|---|---|
| 需求可验证 | 验收条件 | 每条需求具备可测试的验收条件 | 必检 |
| 需求可追溯 | 追溯关系 | 每条需求关联来源与下游设计 | 必检 |
| 需求完整 | 优先级 | 优先级字段无空缺 | 抽检 |
角色分工与检查时点安排
检查表要落地，必须回答三个问题：谁检查、什么时候检查、结果交给谁。角色划分建议设置检查人、被检查人、复核人三类。检查人负责按表核对并记录结论，通常由质量角色或跨模块的同行担任；被检查人负责提供交付物和证据，并对不通过项作出回应；复核人负责确认检查结论和后续整改，一般由项目负责人或技术负责人承担。
检查时点应与项目里程碑和交付物提交节点绑定，而不是按固定日历安排。常见对应关系是：需求评审通过后检查需求文档，设计评审前检查设计说明，提测前检查开发自测记录，上线前检查发布清单与回滚方案，验收前检查交付物完整性。时点写在检查表字段里，同时进入项目计划，避免检查被进度挤压。
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 检查人 | 按表逐项核对，记录结论与证据 | 填写完成的检查表 |
| 被检查人 | 提交交付物与证据，回应不通过项 | 交付物、整改说明 |
| 复核人 | 确认结论，决定不符合项分级与关闭 | 签收记录、关闭确认 |
检查结论的确认方式要事先约定，可以是检查人与被检查人共同签字，也可以在协作工具中由复核人确认状态。检查记录应统一归档在项目文档库中，按分册和版本保存，确保后续复盘和审计可以调取。若项目使用ONES承载项目过程，检查表可以作为项目文档模板管理，检查项对应工作项，检查人、时点和结论记录在工作项字段中，不符合项转为缺陷或任务跟踪，整改状态与复核结果在同一处可见，减少表格与沟通记录分散的情况。
不符合项怎么记录、整改与复核
检查发现不通过项后，检查表本身只完成了记录，真正驱动质量改进的是不符合项的闭环。每条不符合项应包含编号、关联检查项、问题描述、严重程度、责任人、要求完成时间、整改措施、整改证据、复核结论和关闭时间。
问题描述要写事实，不写评价。例如“需求规格说明书第3章有7条需求缺少验收条件”，比“需求文档质量差”更有助于整改。分级可以按影响范围划分：影响交付验收或存在合规风险的为严重，影响下游工作但可绕行的为一般，表述或格式类问题为轻微。分级决定整改期限和升级路径。
整改完成后，复核人依据原判定标准验证整改证据，确认问题消除才可关闭。关闭条件应写进检查表说明，例如“同类问题抽样复查无复发”。对于到期未整改或反复出现的不符合项，按项目内升级路径处理：先由项目负责人协调，仍无法解决的提交项目指导委员会或对应管理层决策，并在项目例会上通报状态。
| 字段 | 说明 |
|---|---|
| 不符合项编号 | 与检查项编号关联，如 NC-REQ-007 |
| 问题描述 | 事实、位置、数量、影响 |
| 严重程度 | 严重、一般、轻微 |
| 责任人 | 具体到人，明确整改期限 |
| 整改措施与证据 | 做了什么、留下什么记录 |
| 复核结论 | 通过关闭或退回继续整改 |
完整示例：一份交付物质量检查表
以下示例以某项目的需求规格说明书为检查对象，演示检查表填写后的实际形态。示例为演示情景，不代表特定项目真实数据。
| 编号 | 检查内容 | 判定标准 | 检查方式 | 证据要求 | 检查人 | 时点 | 结论 |
|---|---|---|---|---|---|---|---|
| REQ-01 | 需求编号唯一且连续 | 全文无重复编号，编号规则与模板一致 | 文档审查 | 检查记录截图 | 质量工程师 | 需求评审后2日 | 通过 |
| REQ-02 | 每条需求具备验收条件 | 抽样20条，全部具备可测试的验收条件 | 抽样验证 | 抽样清单 | 质量工程师 | 需求评审后2日 | 不通过 |
| REQ-03 | 需求关联来源与下游设计 | 追溯矩阵中每条需求上下游均非空 | 文档审查 | 追溯矩阵导出记录 | 系统工程师 | 设计评审前 | 通过 |
REQ-02 判定不通过后，登记不符合项 NC-REQ-007：需求规格说明书第3章有7条需求缺少验收条件，严重程度为一般，责任人为需求负责人，要求三个工作日内补齐。整改后提交修订版文档和补充的验收条件清单，复核人按原判定标准重新抽样20条，确认全部具备验收条件，复核通过并关闭该不符合项，关闭时间记录在跟踪表中。
完成检查：检查表设计是否可用的自检清单
检查表设计完成后，投入项目使用前逐项核对以下内容，全部满足即可视为可用；存在缺项的，先修订再发布。
- 每条检查项都有可判定的判定标准，两名检查人依据标准能得出一致结论。
- 每条检查项都写明了证据要求，证据形式可留存、可调取。
- 检查人、被检查人、复核人已落实到具体角色或人员，没有“相关人员”这类模糊表述。
- 检查时点与项目里程碑或交付物提交节点一一对应，并已进入项目计划。
- 不符合项从记录、分级、整改、复核到关闭的路径完整，升级路径明确。
- 每条检查项能回溯到项目质量目标或交付物要求，没有无对应目标的冗余条目。
- 必检项与抽检项的划分有风险依据，条目数量在可执行范围内。
- 检查表已在至少一个交付物上试用，并根据试用中发现的歧义和遗漏完成修订。
- 检查记录的归档位置和保存方式已确定，项目成员知道在哪里填写和查阅。
自检通过后，检查表应随项目质量计划一同发布，并在项目复盘中收集执行反馈，按版本更新。检查表的价值在于被稳定执行并持续修订，条目和标准随项目经验逐步校准，才能成为项目质量控制的可靠工具。
常见问题
项目规模较小、交付物不多时，检查表可以简化到什么程度？
可以合并分册，但字段不宜删减。小项目常把需求、设计、交付验收合并为一张表，此时保留检查项编号、检查内容、判定标准、证据要求、检查人、时点和结论这些字段即可，检查对象一栏写清具体交付物名称和版本。判定标准和证据要求不能省，否则检查结论无法复核。条目数量可以压缩，优先保留涉及验收、对外承诺和核心功能的必检项，格式类条目改为抽检。
检查人和被检查人是同一个角色时，检查还有意义吗？
自检仍有价值，可以作为提交前的第一道核对，但不宜作为质量控制的唯一环节。建议把自检和独立检查分开：被检查人先用检查表自检并留下记录，再由质量角色或跨模块同行按同一张表复核关键必检项。涉及验收和合规的条目应由独立于交付物作者的人确认，复核人负责最终签收。这样既保留自检的效率，也避免同一人既写又判带来的盲区。
检查表执行一段时间后条目越来越多，怎么控制？
先做对应关系清理：逐条核对检查项能否回溯到项目质量目标或交付物要求，找不到对应目标的条目删除或合并。再把偶发问题沉淀的条目按风险重新分级，影响验收和合规的保留为必检，其余转为抽检或移入经验库。每轮项目复盘时集中修订一次，按版本发布，避免检查表在项目执行中随意追加条目。条目数量超出可执行范围时，考虑按交付物类型再拆分册。
不符合项整改期限到了但问题没解决，项目内应该怎么处理？
先由复核人确认整改状态并记录未关闭原因，再由项目负责人协调资源或调整计划。若涉及交付验收或合规风险，应在项目例会上通报，并提交项目指导委员会或对应管理层决策，明确是延期关闭、带条件放行还是暂停相关交付。处理结论要回写到不符合项跟踪表中，保留决策记录。反复出现或长期未关闭的问题，应在复盘时分析根因，判断是检查标准不清、责任不落实还是流程本身存在缺口。
检查表用文档表格管理，还是放到项目管理工具里更合适？
取决于项目规模和检查频次。交付物少、检查次数有限的项目，用文档表格加统一归档目录即可满足要求。检查项多、跨多个阶段、需要跟踪整改状态的项目，把检查项对应为工作项、检查人和时点写入字段、不符合项转为缺陷或任务跟踪，能让结论、责任人和整改状态在同一处可见，减少表格版本分散和沟通记录丢失。选择时重点看整改闭环是否需要多人协同和状态追踪，而非工具本身的功能多少。
