设计过程质量检查表，核心是把组织级质量要求转成可判定的条目：先明确检查对象与阶段关口，再按检查项、判定标准、证据、责任人、检查时点、处置方式六类字段搭结构，随后用一次试点校准条目，以问题闭环和条目有效性复盘作为完成标志。本文面向组织质量保障体系，单项目质量控制与测试执行不展开。
要点总览（TL;DR）
- 检查表设计从范围开始：先列出覆盖的阶段、关键关口和优先检查活动，第一版控制在三到五个关口、每个关口五到十条检查项。
- 表结构采用六类字段——检查项、判定标准、证据要求、责任人、检查时点、处置方式，判定结果统一为符合、不符合、不适用三档。
- 检查项从过程规范条款拆解而来，一条对应一个可验证动作或产物，改写时去掉“充分”“完整”这类无法判定的表述。
- 执行机制要写清检查人与被检查对象分离、关口触发检查、不符合项登记整改复核的路径和升级条件。
- 初稿完成后选一个阶段完整的项目试点两到三个关口，按可判定、有证据、能区分三条标准修订条目，再发布带版本号的正式版。
先定检查对象：检查表对准哪些过程与关口
检查表设计的第一步是划定范围。范围不清，检查表容易写成覆盖所有活动的长清单，执行时逐条打勾，却无法说明哪些过程真正受控。范围界定的产出是一份检查范围说明，写清检查覆盖哪些阶段、每个阶段的关键关口、优先检查的活动，以及本次不纳入的过程。
按研发过程阶段划分是常用做法。需求阶段关注需求来源、需求评审、需求变更记录；设计阶段关注设计评审、接口定义、设计变更影响分析；开发阶段关注编码规范执行、代码评审、分支与版本管理；发布准备阶段关注发布评审、回滚方案、交付物齐套。每个阶段再识别关口，例如需求基线建立、设计评审通过、代码合入主干、发布评审通过，关口是检查表最自然的挂载点。
范围确定后，需要识别高风险活动并排优先级。判断依据可以来自历史问题分布、外部评估或审核中反复出现的薄弱环节、变更频繁的模块、跨团队交接环节。优先检查对象应控制在可执行的数量内，第一版检查表覆盖三到五个关口、每个关口五到十条检查项，比一次铺开全部阶段更容易落地。
范围说明还需写明边界：检查表服务组织质量保障，关注过程活动是否按规范执行、证据是否留存；单项目质量控制的具体做法、测试用例设计与测试执行属于其他管理范畴，另行处理。把边界写进范围说明，可以避免检查表被当成测试清单使用。
检查范围说明建议包含以下内容：
- 覆盖阶段与对应关口清单；
- 每个关口的优先检查活动及排序理由；
- 本次不纳入的过程及原因；
- 检查表适用的组织范围与生效时间。
检查表的核心结构：六类字段怎么定
检查表的结构决定它能否被稳定执行。建议采用六类字段：检查项、判定标准、证据要求属于内容字段，回答查什么、怎么判、看什么；责任人、检查时点、处置方式属于执行字段，回答谁查、何时查、查出问题怎么办。六类字段齐备，检查表才具备可重复执行的基础。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 检查项 | 一条对应一个可验证的动作或产物 | 需求评审记录是否包含评审结论与遗留问题跟踪人 |
| 判定标准 | 写成可判定的表述，结果统一为符合、不符合、不适用 | 记录中有明确结论，且每条遗留问题有跟踪人，判为符合 |
| 证据要求 | 指向可核查的记录或产物，写明名称与位置 | 需求评审会议记录、评审问题跟踪表 |
| 责任人 | 区分检查执行人与被检查过程负责人 | 质量保证人员执行，需求负责人配合提供证据 |
| 检查时点 | 绑定关口或固定频次 | 需求基线建立后三个工作日内 |
| 处置方式 | 写明不符合项的记录、整改与复核路径 | 登记问题单，限期整改，复核通过后关闭 |
判定标准是六类字段中最容易写虚的一类。“评审充分”“记录完整”这类表述无法区分符合与不符合。可判定的写法要落到可观察的事实：记录中是否包含结论、是否列出遗留问题、每条问题是否有跟踪人。判定结果统一为三档，遇到过程未发生或活动不适用时选“不适用”，并在备注中说明理由，避免用“不适用”掩盖缺失。
证据字段要写清证据的名称和存放位置，例如“评审会议记录存放于项目知识库评审目录”。证据指向模糊，检查时就会变成口头确认，检查结论也难以复核。执行字段中的检查时点建议绑定关口而非固定日期，关口触发检查，检查表才能跟随研发节奏运转。
检查项怎么写：从过程要求到可判定条目
检查项来自过程规范、质量要求或外部标准中的条款。拆解分三步：先找出条款要求的动作或产物，再确认该动作留下的记录，最后把要求改写成能回答“是或否”的句子。一条检查项对应一个可验证动作或产物，包含多个要求的条款应拆成多条，便于定位不符合的具体位置。
改写前后的对比如下：
| 原始要求 | 改写后的检查项 |
|---|---|
| 需求变更应受控 | 需求变更是否提交变更申请，申请中是否包含变更原因与影响分析 |
| 代码评审应有效执行 | 合入主干的代码是否有评审记录，评审意见是否逐条回复处理结论 |
| 设计文档应完整 | 设计文档是否包含接口定义、异常处理说明与设计评审结论 |
改写时避免三类问题：一是把多个要求塞进一条，导致部分符合时无法判定；二是使用程度副词，如“基本完整”“大致符合”，检查人只能凭主观判断；三是检查项描述的是检查动作本身，而非被检查的过程活动。
检查项数量需要控制并分级。可按必查与抽查两类标注：涉及安全、合规、外部评估的关口设为必查，逐条核对；成熟度高、历史问题少的过程设为抽查，按比例抽样。第一版检查表每个关口控制在五到十条，条目过多会拉长单次检查时间，降低执行意愿。条目分级也便于在资源有限时优先保证关键关口的检查覆盖。
角色分工与执行节奏：谁查、何时查、怎么记录
检查表落地依赖清晰的角色分工。质量保证角色负责执行检查、记录结论、跟踪不符合项关闭；过程负责人负责在检查前准备证据、对不符合项制定整改措施；项目角色配合提供记录并在整改中落实动作。三类角色中，检查执行人与被检查对象应分离，避免过程负责人自检自判。
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 质量保证人员 | 按检查表执行检查，判定符合性，登记问题 | 检查记录、不符合项清单 |
| 过程负责人 | 准备证据，确认问题，制定并执行整改 | 整改措施与完成证据 |
| 项目角色 | 配合检查，落实过程动作 | 过程记录与产物 |
| 质量负责人 | 裁决争议判定，审批升级事项 | 判定结论、升级处理决定 |
检查时点由关口和频次共同决定。关口类检查在阶段交付物完成、评审通过后触发；周期性检查按固定间隔执行，适用于持续进行的过程活动，如代码评审抽查。频次设定要考虑过程风险和检查成本，高风险关口每次必查，低风险过程可按季度抽查。
检查记录应包含检查表版本、检查时间、检查人、逐条判定结果、证据位置和不符合项描述。不符合项登记后进入处置路径：一般问题由过程负责人限期整改，质量保证人员复核后关闭；影响关口通过或涉及外部评估的问题，升级至质量负责人裁决，必要时暂缓关口放行。升级条件要事先写清，例如同一关口连续两次检查出现同类不符合，或整改逾期超过约定时限。
当检查项、检查记录和不符合项整改需要在同一处流转时，可以把检查表作为工作项模板放入研发管理平台，检查记录关联到对应阶段与交付物，不符合项转为整改任务并跟踪到复核关闭。ONES 在 ASPICE 解决方案中提供项目管理、知识库、工单管理等模块组合，可用于承载过程活动记录与问题闭环；具体配置方式需结合团队实际流程确定。
示例：一条完整检查项从设计到闭环
以下示例演示一条检查项从编写到关闭的全过程，场景为演示用途。
检查项设计。某团队在需求阶段关口设置检查项：“需求评审记录是否包含评审结论、遗留问题清单及每条问题的跟踪人。”判定标准：三项内容齐备判为符合，缺任一项判为不符合，需求未经过评审则判为不适用并注明原因。证据要求：需求评审会议记录、遗留问题跟踪表，存放于项目知识库需求评审目录。责任人：质量保证人员执行检查，需求负责人提供证据。检查时点：需求基线建立后三个工作日内。处置方式：不符合项登记问题单，限期五个工作日整改，复核通过后关闭。
执行与记录。检查人在基线建立后第二天执行检查，调取评审记录，发现记录中有评审结论和遗留问题清单，但三条遗留问题均未填写跟踪人。判定为不符合，记录中写明缺失内容、证据位置和检查时间。
整改与复核。问题单流转至需求负责人，负责人在两个工作日内补充跟踪人并更新跟踪表。检查人复核更新后的记录，确认三条问题均有跟踪人，判定整改有效，关闭问题单，并在检查记录中登记关闭时间与复核证据。
完成标志。该检查项的闭环以“问题单关闭且复核证据留存”为完成标志，而非以整改承诺提交为标志。若同类问题在同一项目再次出现，按升级条件提交质量负责人处理。
试点校准与完成检查
检查表初稿完成后，用一次试点验证有效性。试点范围建议选择一个正在进行且阶段完整、配合度较高的项目，覆盖两到三个关口，由质量保证人员按正式流程执行检查，过程负责人正常配合。试点期间记录每一条检查项的判定耗时、争议点和证据获取难度。
条目有效性从三个方面判断：可判定，即不同检查人对同一条目能得出一致结论；有证据，即证据在常规过程活动中自然产生，无需额外补做；能区分，即条目能真实区分符合与不符合的过程，长期全部判为符合的条目需要复核是否过于宽松。试点结束后，删除无法判定的条目，合并重复条目，补充证据要求不清的条目，形成检查表正式版本。
检查表需要维护机制。过程规范变更、组织调整、外部评估反馈都应触发条目评审；版本号、生效日期和变更说明随检查表一同发布，旧版本归档保留，便于追溯历史检查结论对应的判定口径。
完成检查清单：
- 检查范围说明已明确阶段、关口、优先检查活动与不纳入范围；
- 六类字段全部定义，判定标准可判定，证据指向具体记录；
- 每条检查项对应一个可验证动作或产物，已完成必查与抽查分级；
- 角色分工、检查时点、记录方式与升级条件已书面确认；
- 至少完成一次试点，争议条目已修订，正式版本已发布并标注版本号；
- 不符合项闭环路径可执行，复核与关闭有明确完成标志。
常见问题
检查表条目长期全部判为符合，是过程做得好还是条目太宽松？
两种情况都可能，需要分开验证。先抽取几条判为符合的记录，核对证据是否真实存在、内容是否满足判定标准；如果证据齐全且确实满足，说明过程执行到位。如果证据缺失或只是形式上有记录，说明判定标准写得太松，应把标准收紧到可观察的事实，例如从“评审记录完整”改为“记录包含评审结论、遗留问题清单及每条问题的跟踪人”。
另一种情况是检查人长期固定、检查对象也固定，判定容易形成惯性。可以安排交叉检查或由质量负责人抽查部分结论，帮助发现判定偏差。
过程规范还没定稿，检查表可以先做吗？
可以先做范围说明和字段框架，检查项内容建议等规范条款稳定后再定稿。检查项是从过程要求拆解出来的，规范频繁变动会导致检查表反复返工。可行的做法是先按现有规范或行业通用要求起草条目，标注来源条款，规范定稿后逐条对照更新，再进入试点。
如果规范长期无法定稿，也可以先用检查表暴露过程执行中的分歧点，把检查中反复出现的争议反馈给规范制定方，反过来推动规范细化。
多个项目共用一份检查表，还是每个项目单独设计？
组织级检查表建议统一一份，保证判定口径一致、检查结论可横向比较；项目之间的差异通过“不适用”选项和备注说明处理，例如某项目未开展某项活动时判为不适用并注明原因。如果某类项目的过程差异很大，例如涉及外部评估的项目与内部迭代项目，可以在统一框架下增设附加条目，而不是另起一套表。
统一检查表也便于汇总多个项目的检查结果，识别共性薄弱环节，为过程改进提供依据。
检查发现的不符合项，过程负责人不认可判定怎么办？
需要在执行机制中预设争议处理路径。常见做法是检查人与过程负责人先就判定标准和证据当面核对，确认是证据缺失还是标准理解不一致；仍无法达成一致时，提交质量负责人裁决，裁决结论和理由记入检查记录。
如果争议反复出现在同一条目上，说明判定标准表述不清，应在下一版检查表中修订该条目，并把争议案例作为修订依据留存。
检查记录和不符合项整改放在研发管理平台里管理，有什么实际好处？
检查表条目多、执行频次高时，分散在文档和邮件里的记录很难追溯。把检查表作为工作项模板放入平台，检查记录可以关联到对应阶段和交付物，不符合项转为整改任务并跟踪到复核关闭，检查结论与过程记录在同一处可查。
ONES 在 ASPICE 解决方案中提供项目管理、知识库、工单管理等模块组合，可用于承载过程活动记录与问题闭环；具体配置方式需结合团队实际流程确定。
