设计项目质量检查表，核心是把质量要求变成可逐项判定、可留证据、可追责任的条目。先划定检查覆盖的阶段与交付物，再把要求拆成单一事实的检查项，为每项配齐判定标准、证据、责任人和处置方式，最后绑定检查时点与整改闭环。下文给出字段模板、角色分工和一份已填样例，可按单项目直接套用。
要点总览（TL;DR）
- 检查表设计从划定范围开始：按项目阶段或里程碑切分，逐阶段列出关键交付物与过程活动，形成“阶段—交付物—检查主题”清单，再决定用单表还是分阶段多表。
- 检查项拆解以“一个可判定事实”为单位，来源包括需求验收条件、设计规范强制条款、评审规则和历史缺陷；按“对象＋动作＋条件”表述，换人检查能得出相同结论。
- 必备字段为编号、检查项、判定标准、证据要求、责任人、检查时点、结论、处置；判定标准写成可观察的通过条件，结论固定为通过、不通过、不适用，不通过项必须填写整改内容、期限和复核人。
- 角色上区分检查人、责任人、复核人，检查人与责任人不重合；未通过项按“标记—整改—复核—关闭”推进，关闭条件是复核确认而非责任人声称已改。
- 设计完成后用自检清单验收：范围覆盖、条目可判定、证据可定位、责任唯一、时点明确、闭环与迭代规则齐全，试用一至两个阶段后完成第一轮修订。
先定检查对象：检查表覆盖哪些阶段和交付物
检查表设计的第一步是划定范围。一张表包打全部项目，条目会膨胀到无人愿意填；范围过窄，又会在关键关口漏检。可行的做法是按项目阶段或里程碑切分，先列出每个阶段的关键交付物与过程活动，再决定用单表还是分阶段多表。
范围划定的输入是项目计划与阶段划分。动作是逐阶段识别两类对象：一类是交付物，如需求规格、设计说明、接口文档、上线方案；另一类是过程活动，如需求评审、设计评审、变更审批。输出是一份“阶段—交付物—检查主题”对应清单，作为后续拆检查项的依据。完成标志是每个阶段至少有一个明确的检查主题，且没有交付物处于无人检查的状态。
粒度选择上，阶段多、交付物差异大的项目适合分阶段多表，每张表只服务一个关口；周期短、交付物同质的小项目可以用一张主表加阶段列。无论哪种，都应在表头写明适用阶段，避免同一张表被跨阶段误用。
同时要明确不纳入本表的范围。组织级质量制度、质量方针的符合性，以及测试用例设计与测试执行管理，属于另外的管理活动，写进项目检查表会让条目失焦。把边界写在表头说明里，能减少填写时的争议。
检查项怎么拆：从质量要求到可判定的条目
检查项的质量决定整张表是否可用。拆解的基本单位是“一个可判定事实”：检查人看完条目，能给出通过或不通过的明确结论，不需要再解释。把“设计文档质量良好”这类要求直接抄进表里，检查时只能凭感觉打分，结果无法复核。
检查项有四个常见来源：需求文档中的验收条件、设计与编码规范中的强制条款、评审规则中约定必须确认的事项、历史项目缺陷与复盘结论。从历史问题反推条目尤其有效，曾经导致返工或线上故障的问题，应转化为固定检查项。
拆解时按“对象＋动作＋条件”组织表述。例如把“接口设计要完整”拆成“接口清单是否覆盖本期全部对外服务”“每个接口是否写明入参、出参与错误码”“接口变更是否记录变更原因与影响范围”三条。每条只对应一个事实，判定时互不干扰。
分类与编号建议采用“阶段代码－主题代码－序号”的结构，如 DSN-IF-01 表示设计阶段接口主题第一条。编号稳定后，整改记录、统计和版本修订都能按编号追溯。分类维度可按交付物类型，也可按质量特性，同一张表内保持一种维度即可。
要避免的写法包括：一条里塞入多个要求，导致部分满足时无法判定；使用“合理”“充分”“适当”等无标准的形容词；把检查项写成整改建议，失去判定功能。每条检查项写完后，可以自问：换一个人来检查，能否得出相同结论。
检查表字段设计：判定标准、证据与责任人
字段结构决定检查表能否被稳定执行。下表给出单项目质量检查表的必备字段与填写要求，可直接作为模板使用。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 编号 | 按阶段－主题－序号编制，全表唯一且不随修订改变 | DSN-IF-02 |
| 检查项 | 一个可判定事实，表述为对象加条件 | 每个对外接口是否写明入参、出参与错误码 |
| 判定标准 | 写成可观察的通过条件，必要时给出数量或格式要求 | 接口文档中每个接口均含三部分字段说明，缺一项即不通过 |
| 证据要求 | 说明需要留存或指向的材料及位置 | 接口文档链接、评审记录编号 |
| 责任人 | 对该项质量结果负责的唯一角色 | 接口负责人 |
| 检查时点 | 绑定具体关口或事件，不写“适时” | 设计评审前一个工作日 |
| 结论 | 取值固定，建议为通过、不通过、不适用 | 不通过 |
| 处置 | 未通过时写明整改要求、期限与复核人 | 补齐错误码说明，评审前完成，由设计负责人复核 |
判定标准是字段设计的重点。它应描述检查人能看到的事实，例如“清单中列出的全部接口均有对应文档条目”，而不是“文档完整”。证据字段解决“凭什么判定”的问题，要求证据可定位，链接、编号或附件均可，避免只写“已确认”。
结论取值要收敛为固定选项，便于统计。不适用项需注明理由，防止用“不适用”规避检查。处置字段与结论联动：结论为不通过时，处置栏必须填写整改内容、完成期限和复核人；结论为通过时该栏留空。责任人一栏只写一个角色，多人共担会让整改无人推进。
角色与交付物：谁填表、谁判定、谁复核
检查表运行涉及三类角色，职责要分开，避免自己检查自己。检查人负责按条目核对并记录结论与证据；责任人（通常是被检查交付物的作者或负责人）负责提供证据并对未通过项整改；复核人负责确认整改结果并关闭条目。小项目中检查人与复核人可由同一人担任，但不应与责任人重合。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 检查人 | 在约定时点逐项核对，记录结论与证据位置 | 已填检查表、问题条目清单 |
| 责任人 | 提交证据，对未通过项制定并执行整改 | 证据材料、整改说明 |
| 复核人 | 验证整改是否满足判定标准，决定关闭或退回 | 复核结论、关闭记录 |
| 项目负责人 | 汇总检查结果，在关口决策中引用 | 阶段检查汇总、关口结论 |
填写时点与提交对象要写进表头。常见约定是：检查人在关口评审前完成填写并提交给复核人；未通过项在评审会上确认整改责任人与期限；整改完成后由责任人提交证据，复核人复核后关闭。检查结果按阶段汇总，向项目负责人和关口评审提交，作为阶段放行的输入之一。
角色分工还要覆盖争议处理。检查人与责任人对判定标准理解不一致时，以表内判定标准原文为准；标准本身有歧义，应提交检查表维护人修订，而不是在单次检查中临时解释。这条规则能防止同一张表在不同项目中判出不同结果。
填写示例：一个阶段检查表的完整样例
以下为演示情景，用于说明填写规范，不代表真实项目记录。背景：某系统改造项目进入设计阶段，关口为设计评审，检查表为设计阶段专用表。
| 编号 | 检查项 | 判定标准 | 证据要求 | 责任人 | 结论 | 处置 |
|---|---|---|---|---|---|---|
| DSN-IF-01 | 接口清单是否覆盖本期全部对外服务 | 清单条目与需求文档中的对外服务逐条对应，无遗漏 | 接口清单链接、需求条目编号 | 接口负责人 | 通过 | — |
| DSN-IF-02 | 每个接口是否写明入参、出参与错误码 | 每个接口均含三部分说明，缺一项即不通过 | 接口文档链接 | 接口负责人 | 不通过 | 补齐支付查询接口错误码说明，评审前完成，设计负责人复核 |
| DSN-DB-01 | 数据表变更是否记录变更原因与影响范围 | 每条变更含原因、影响模块、回退方案三项 | 变更记录编号 | 数据设计人 | 通过 | — |
未通过项的闭环记录如下：检查人在设计评审前一日标记 DSN-IF-02 不通过，并在处置栏写明整改内容与期限；责任人于次日补充错误码说明并提交文档链接；复核人按判定标准核对三部分说明齐全后关闭该条，检查表状态更新为已闭环。评审会上仅需确认闭环记录，不再重复讨论该条。
样例体现的填写规范有三点：判定标准写到可逐项核对的程度；证据指向具体文档或记录编号；处置栏同时包含整改内容、期限和复核人，使关闭条件清晰。
检查表怎么用起来：时点、闭环与迭代
检查表只有嵌入项目流程才会产生作用。时点绑定有两种常见方式：绑定阶段关口，在评审或放行前完成检查；绑定关键事件，如需求冻结、设计定稿、上线审批。两种方式都要求检查时点写在表内，并与项目计划中的里程碑对应，避免检查被顺延到关口当天才匆忙补填。
未通过项的闭环按“标记—整改—复核—关闭”推进。关闭条件是复核人确认整改结果满足原判定标准，而不是责任人声称已改。逾期未整改的条目应升级到项目负责人，在关口决策中作为风险项处理。检查表应保留每次修订的记录，使整改过程可追溯。
结果统计建议固定口径：按阶段统计检查项总数、通过数、不通过数、不适用数，以及未通过项的关闭率和平均关闭时长。趋势观察看两个方向：同类检查项在不同阶段反复不通过，说明上游过程存在问题；某类不适用项持续增多，说明检查表范围与实际项目脱节。
检查表本身需要定期修订。触发条件包括：连续两个项目出现同一类未被覆盖的缺陷；判定标准在检查中反复产生歧义；项目阶段划分或交付物类型发生调整。修订应保留版本号与变更说明，已关闭的历史记录不随新版本改写。
在工具承载上，检查表可以作为项目文档或工作项清单管理，检查时点与项目里程碑对齐，未通过项转为整改任务并设置复核人。ONES 支持按阶段或交付物分解计划、用里程碑标记重要决策点，并可设置计划与里程碑基线对比执行偏差，适合把检查关口固定在项目节奏中；检查结果也可纳入效能度量观察。检查表模板与整改闭环的具体配置方式，以实际产品版本为准。
完成检查：检查表设计是否可用的自检清单
设计完成后，用以下清单逐项核对。全部满足即可投入试用；存在未满足项时，先修订再发布，避免带着结构缺陷进入项目。
- 范围与阶段覆盖：每个项目阶段都有对应检查主题，关键交付物无遗漏，表头写明适用阶段与不纳入范围。
- 检查项可判定：每条只对应一个事实，表述中不含“合理”“充分”等无标准词，换人检查能得出相同结论。
- 判定标准可观察：通过条件写到可逐项核对的程度，必要时给出数量或格式要求。
- 证据要求可定位：每项写明需留存的材料及位置，能指向具体文档或记录编号。
- 责任唯一：每项有且仅有一个责任人，检查人与责任人不重合。
- 时点明确：检查时点绑定具体关口或事件，并与项目里程碑对应。
- 结论与处置联动：结论取值固定，不通过项必须填写整改内容、期限和复核人。
- 闭环机制清晰：关闭条件为复核确认，逾期条目有升级路径。
- 统计口径固定：明确统计维度与观察指标，能支撑阶段汇总。
- 迭代规则明确：写明修订触发条件、版本号与变更记录方式。
试用一至两个阶段后，结合检查记录回看：是否有条目从未被判定为不通过，是否有条目频繁产生歧义。前者可能标准过松，后者需要改写表述，据此完成第一轮修订。
常见问题
检查表条目太多，团队不愿意填，怎么精简？
先判断条目膨胀的原因。常见情况是把规范全文搬进表里，或把多个要求塞进一条。精简的做法是保留两类条目：曾经导致返工或线上故障的历史问题，以及关口放行必须确认的强制条款；其余要求留在规范文档中，检查表只引用条款编号。
另一个办法是分阶段拆表，每张表只服务一个关口，单次填写量控制在检查人能在半天内完成的规模。条目减少后，判定标准和证据要求反而可以写得更具体。
检查人、责任人、复核人在小项目里人手不够，能否合并？
可以部分合并，但要守住一条底线：检查人与责任人不能是同一人。小项目中检查人与复核人可由同一人担任，前提是该角色不负责被检查交付物的编写。若团队只有两三个人，可让上游环节的负责人检查下游交付物，形成交叉检查。
合并角色时要在表头写明当前项目的角色对应关系，避免后续接手的人误判职责。争议处理规则不变：以表内判定标准原文为准，标准有歧义时提交维护人修订。
判定标准写到什么程度算够用？
判断标准是换一个人来检查能否得出相同结论。可观察的写法通常包含三类要素：检查对象、通过条件、数量或格式要求。例如“每个接口均含入参、出参、错误码三部分说明，缺一项即不通过”，比“接口文档完整”更可执行。
如果一条标准在两次检查中判出不同结果，说明表述需要改写，应作为检查表修订的触发条件记录下来，而不是在单次检查中临时解释。
未通过项一直不整改，检查表会不会形同虚设？
关键在关闭条件和升级路径。关闭条件设为复核人确认整改结果满足原判定标准，责任人声称已改不能关闭条目。逾期未整改的条目应升级到项目负责人，在关口决策中作为风险项处理，与阶段放行结论挂钩。
统计上可以观察未通过项的关闭率和平均关闭时长，连续多个阶段关闭率偏低，说明整改责任分配或期限设置有问题，需要调整检查表运行规则。
检查表多久修订一次，历史记录怎么处理？
修订按触发条件进行，不必固定周期。常见触发包括：连续两个项目出现同一类未被覆盖的缺陷；判定标准在检查中反复产生歧义；项目阶段划分或交付物类型发生调整。
修订时保留版本号与变更说明，已关闭的历史记录不随新版本改写，保证整改过程可追溯。新版本发布后，新启动的阶段使用新表，进行中的阶段沿用原版本直至关口结束。
