瀑布阶段的准入准出检查清单，字段主线可以统一为“阶段—检查点—检查项—判定标准—证据—责任人—结论—例外处理”。准入清单判断进入下一阶段的条件是否具备，准出清单判断本阶段成果能否交付，阶段交接单记录交付物版本、遗留事项与接收确认。三类表共用同一套字段口径，评审时才能逐项核对、留下可追溯的记录。
要点总览（TL;DR）
- 准入清单、准出清单与阶段交接单共用“阶段—检查点—检查项—判定标准—证据—责任人—结论—例外处理”字段主线，交接单额外记录交付物版本、遗留事项与接收确认。
- 判定标准要写成可观察、可验证的表述，证据字段记录证据类型与存放位置，清单才能被第三方复核。
- 判定标准、责任人、结论三项在任何裁剪方案中都应保留；检查项数量与检查点密度可按项目类型调整。
- 三张表配合使用：准出清单的例外处理进入交接单的遗留事项，交接单的交付物版本成为下一阶段准入的核对依据。
- 模板需版本化管理，记录修订原因与生效范围，并在协作工具中把检查项、证据与确认记录留在同一项目空间。
可复制的准入准出检查清单空白模板
下面三张表可直接复制到文档或表格工具中使用。列名保持统一，填写时只补充内容，不改字段名称，便于不同阶段、不同项目之间横向比对。
准入检查清单空白表
| 阶段 | 检查点 | 检查项 | 判定标准 | 证据类型 | 证据位置 | 责任人 | 确认人 | 结论 | 例外处理 |
|---|---|---|---|---|---|---|---|---|---|
准出检查清单空白表
| 阶段 | 检查点 | 检查项 | 判定标准 | 证据类型 | 证据位置 | 责任人 | 确认人 | 结论 | 例外处理 |
|---|---|---|---|---|---|---|---|---|---|
阶段交接单空白表
| 移交阶段 | 接收阶段 | 交接对象 | 交付物名称 | 交付物版本 | 存放位置 | 遗留事项 | 遗留事项处理计划 | 移交人 | 接收人 | 接收确认 | 确认日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|
三张表的共用口径体现在：阶段名称使用同一套阶段划分；检查点对应同一批评审或决策节点；检查项编号可被交接单引用；责任人、确认人的角色定义一致；结论取值统一为“通过、有条件通过、不通过”。交接单不重复检查项内容，只引用准出清单的检查项编号和结论，避免同一事实在两处出现不同表述。
检查清单字段说明：每个字段记录什么
字段说明解决的是“不同角色填同一张表，理解是否一致”。下表逐列解释填写口径，并列出常见错误。
| 字段 | 记录什么 | 填写口径 | 常见错误 |
|---|---|---|---|
| 阶段 | 检查所属的项目阶段 | 使用项目计划中已定义的阶段名称，如“需求分析”“概要设计” | 同一项目出现“需求阶段”“需求分析期”两种叫法 |
| 检查点 | 阶段内的具体评审或决策节点 | 写明节点名称与计划日期，如“需求评审会 3月12日” | 只写“评审”不写具体节点，无法对应会议记录 |
| 检查项 | 需要核实的一条具体条件 | 一条只写一个可判断的事项，必要时编号 | 一条里塞入多个条件，部分满足时无法判定 |
| 判定标准 | 判断检查项是否满足的依据 | 写成可观察、可验证的表述，如“评审记录已归档且结论为通过” | 使用“基本完成”“大致符合”等无法核验的措辞 |
| 证据类型 | 证明满足标准的材料类别 | 如评审纪要、签字确认单、测试报告、版本记录 | 把证据内容整段抄进清单，表格失去索引作用 |
| 证据位置 | 证据存放的具体位置 | 写到文档库路径、工作项编号或归档目录 | 只写“见文档”或“已上传”，他人无法定位 |
| 责任人 | 负责完成该检查项的人 | 写具体姓名或岗位，一名责任人对应一条检查项 | 写部门名称，出问题时找不到具体承担者 |
| 确认人 | 对结论签字确认的人 | 通常为阶段负责人或质量角色，与责任人分离 | 责任人与确认人填同一人，失去复核意义 |
| 结论 | 该检查项的判定结果 | 从“通过、有条件通过、不通过”中选一项 | 写“待定”后长期不更新，清单停留在未完成状态 |
| 例外处理 | 未满足标准时的处理安排 | 写明补救措施、完成时间与批准人 | 只写“后续处理”，没有时间和批准人 |
交接单中的“交付物版本”和“遗留事项”需要特别说明。版本字段记录被移交文件的实际版本号或基线标识，与准出清单中的证据位置对应；遗留事项字段记录本阶段未关闭、需下一阶段继续跟踪的事项，并附处理计划。接收确认一栏由接收方填写确认结论和日期，表示接收方已核对交付物清单，而非仅表示收到通知。
必填与选填：哪些字段不能留空
必填字段的判断依据是：缺少它，检查结论就无法被第三方复核。以下划分是通用建议，项目规模、合同条款或行业监管有更严要求时，按更严要求执行。
| 字段 | 建议属性 | 理由或适用场景 |
|---|---|---|
| 阶段 | 必填 | 没有阶段归属，清单无法与项目计划对应 |
| 检查项 | 必填 | 清单的基本单元，缺失则整行无意义 |
| 判定标准 | 必填 | 没有标准，结论只能凭主观判断 |
| 责任人 | 必填 | 明确谁对检查项负责 |
| 结论 | 必填 | 评审和交接都以结论为输入 |
| 检查点 | 必填（有正式评审时） | 小型内部阶段可合并为一次检查，但仍需写明节点 |
| 证据类型与位置 | 必填（结论为通过或有条件通过时） | 结论为不通过时，可先记录缺失的证据类别 |
| 确认人 | 必填（对外交付或合同项目） | 内部小项目可由阶段负责人兼任，但需在模板说明中注明 |
| 例外处理 | 条件必填 | 结论为有条件通过或不通过时必须填写 |
| 交付物版本 | 必填（交接单） | 版本不清会导致接收方使用错误文件 |
| 遗留事项处理计划 | 条件必填 | 存在遗留事项时必须填写 |
| 确认日期 | 必填（交接单） | 用于确定责任转移的时间点 |
可裁剪的部分集中在检查项数量和检查点密度。例如内部工具类项目可以把准入与准出合并为一次阶段评审，减少检查点行数；合同项目或受监管项目则应保留完整的准入、准出、交接三段记录。不可裁剪的边界是：判定标准、责任人、结论三项在任何裁剪方案中都应保留，否则清单退化为事项备忘，无法支撑阶段决策。
填写示例：一个需求阶段到设计阶段的完整衔接
以下示例为演示情景，项目背景为一次内部管理系统的需求阶段收尾，用于说明三张表如何配合。
准入清单填写示例（进入设计阶段）
| 阶段 | 检查点 | 检查项 | 判定标准 | 证据类型 | 证据位置 | 责任人 | 确认人 | 结论 | 例外处理 |
|---|---|---|---|---|---|---|---|---|---|
| 概要设计 | 设计启动会 3月15日 | 需求基线已建立 | 需求文档版本标记为基线，变更需走变更单 | 版本记录 | 文档库/需求/基线V1.0 | 需求负责人 | 项目经理 | 通过 | — |
| 概要设计 | 设计启动会 3月15日 | 设计输入清单已确认 | 设计人员确认收到需求文档与接口说明 | 确认邮件 | 项目邮箱/3月14日 | 设计负责人 | 项目经理 | 通过 | — |
准出清单填写示例（需求阶段收尾）
| 阶段 | 检查点 | 检查项 | 判定标准 | 证据类型 | 证据位置 | 责任人 | 确认人 | 结论 | 例外处理 |
|---|---|---|---|---|---|---|---|---|---|
| 需求分析 | 需求评审会 3月12日 | 需求文档通过评审 | 评审记录结论为通过，意见已闭环 | 评审纪要 | 文档库/需求/评审记录0312 | 需求负责人 | 业务负责人 | 通过 | — |
| 需求分析 | 需求评审会 3月12日 | 非功能需求已明确 | 性能、权限、日志要求写入需求文档 | 需求文档章节 | 文档库/需求/V1.0第6章 | 需求负责人 | 架构师 | 有条件通过 | 日志保留周期待运维确认，3月20日前补充，架构师批准 |
交接单填写示例
| 移交阶段 | 接收阶段 | 交接对象 | 交付物名称 | 交付物版本 | 存放位置 | 遗留事项 | 遗留事项处理计划 | 移交人 | 接收人 | 接收确认 | 确认日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 需求分析 | 概要设计 | 设计组 | 需求规格说明书 | V1.0（基线） | 文档库/需求/ | 日志保留周期未定 | 3月20日前由运维确认，更新至需求文档V1.1 | 需求负责人 | 设计负责人 | 已核对交付物清单，同意接收 | 3月15日 |
三张表的关系在这个示例中很直接：准出清单中“非功能需求”一项为有条件通过，例外处理写明了补充时间和批准人；交接单把这条未关闭事项登记为遗留事项，并给出处理计划；准入清单则确认设计阶段启动所需的需求基线和设计输入已经具备。任何一方事后核对，都能沿检查项编号、证据位置和确认日期还原当时的判断依据。
模板的调整与维护方法
模板落地后需要按项目类型裁剪，并保持版本一致，否则不同项目各用一套旧表，阶段评审结论难以横向比较。
裁剪字段时，先确定项目类型对应的检查深度：内部小项目可合并准入与准出检查点，保留判定标准、责任人、结论三项核心字段；合同项目保留完整三表，并增加确认人签字要求；受监管项目可在检查项中增加合规条款编号，便于审计对照。裁剪结果应记录在模板说明中，写明适用项目类型和不适用情形。
模板版本与变更记录建议包含以下内容：
| 版本号 | 修订日期 | 修订内容 | 修订原因 | 生效范围 | 批准人 |
|---|---|---|---|---|---|
| V1.0 | 初始版本 | ||||
| V1.1 |
复盘与修订的触发条件可以设为：连续两个项目在同一检查项上出现“有条件通过”且例外处理雷同，说明判定标准或前置条件需要调整；阶段评审出现因证据缺失而无法判定的情况，说明证据字段的填写口径需要细化；项目类型或合同要求发生变化时，同步调整必填字段范围。修订后应通知所有在用项目切换版本，并在模板头部标注生效日期。
在协作工具中固化模板，可以把检查项建成工作项或检查项列表，把证据位置指向文档库中的评审记录，把交接确认记录在阶段交接文档中。ONES 支持用项目计划按阶段分解工作并设置里程碑，配合基线和版本对比跟踪计划与执行的偏差；ONES Wiki 的文档可关联任务并插入工作项列表，适合承载检查清单与交接记录。具体字段如何配置为工作项属性或文档模板，需按团队实际使用的产品版本确认。这样做的直接结果是：检查项状态、证据链接和确认记录留在同一项目空间内，阶段评审时按清单逐项核对即可，无需另行收集散落的表格。
常见问题
准入清单和准出清单的字段几乎一样，能否合并成一张表？
字段可以共用，但两张表回答的问题不同：准入清单判断进入下一阶段的条件是否具备，准出清单判断本阶段成果能否交付。内部小项目可以把两次检查合并为一次阶段评审，减少检查点行数，但建议在表头注明本次检查同时覆盖准入与准出，并保留判定标准、责任人、结论三项核心字段。合同项目或受监管项目应保留完整的两段记录，便于分别追溯“进入条件”和“交付成果”的判断依据。
证据位置写到什么程度才算可核验？
证据位置需要让他人无需询问就能找到材料，建议写到文档库路径、工作项编号或归档目录，例如“文档库/需求/评审记录0312”。只写“见文档”“已上传”无法定位，评审时仍需额外沟通。证据类型与证据位置分开记录：类型说明材料类别（评审纪要、测试报告、版本记录），位置说明具体存放点，清单本身保持索引作用，不把证据内容整段抄入。
遗留事项在交接单里登记后，由谁负责关闭？
遗留事项的处理责任应在交接单的“遗留事项处理计划”中写明，包括处理人、完成时间和验证方式。通常由接收阶段的相关角色负责推进，移交人保留跟踪责任，确认人负责验证关闭。若遗留事项影响下一阶段的关键路径，应在准入清单中对应设置一条检查项，结论为“有条件通过”，避免交接单登记后无人跟进。
模板裁剪后，不同项目的检查结论还能横向比较吗？
可以比较的前提是核心字段口径不变。裁剪时保留阶段名称、判定标准、责任人、结论的统一定义，只调整检查项数量和检查点密度，并在模板说明中记录裁剪方案适用的项目类型。若不同项目对“通过”的理解不一致，或结论取值不统一，横向比较就失去意义。建议在模板版本变更记录中写明每次调整对结论口径的影响。
在协作工具中承载检查清单，需要配置到什么程度？
常见做法是把检查项建成工作项或检查项列表，把证据位置指向文档库中的评审记录，把交接确认记录在阶段交接文档中。ONES 支持用项目计划按阶段分解工作并设置里程碑，配合基线和版本对比跟踪计划与执行的偏差；ONES Wiki 的文档可关联任务并插入工作项列表，适合承载检查清单与交接记录。具体字段配置为工作项属性还是文档模板，需按团队实际使用的产品版本确认。
