瀑布阶段验收清单通常围绕七类检查项展开：范围完成度、交付物完整性、质量与测试结论、需求与设计追溯、变更与遗留问题、文档与配置基线、下一阶段准入。每项检查都要写明通过标准、所需证据、负责人和检查时点；范围未闭环、关键缺陷未关闭、追溯链断裂、基线未固化或验收结论未签署时，阶段不能判定通过。
要点总览（TL;DR）
- 瀑布阶段验收清单围绕七类检查项展开：范围完成度、交付物完整性、质量与测试结论、需求与设计追溯、变更与遗留问题、文档与配置基线、下一阶段准入。
- 每项检查要写明通过标准、证据、负责人和检查时点；通过标准需可观察、可核对，证据可以是评审记录、测试报告、签署文档或配置基线记录。
- 范围未闭环、关键缺陷未关闭、追溯链断裂、基线未固化、验收结论未签署属于阻断项，出现任一项阶段不能判定通过。
- 验收报告模板通常包含基本信息、检查结果汇总与证据索引、遗留问题与变更记录、验收结论与签署、下一阶段准入意见。
- 清单在交付物提交后、正式评审前完成自检，评审会上由项目经理、阶段负责人、质量、业务方和配置管理员逐项确认。
谁在什么时点使用这份验收清单
这份清单服务于单项目的阶段验收，使用对象包括项目经理、阶段负责人、质量人员、业务方和配置管理员。项目经理组织验收并汇总结论，阶段负责人对交付结果负责，质量人员核对测试与缺陷数据，业务方确认需求满足程度，配置管理员核对文档与配置基线。
检查时点分为两段。阶段交付物提交后、正式评审会前，由阶段负责人完成自检并补齐证据；正式评审会上，各角色逐项核对并确认结论。清单在里程碑评审中作为输入材料，评审通过后支撑阶段移交和下一阶段启动。
| 角色 | 主要职责 | 使用时点 |
|---|---|---|
| 项目经理 | 组织验收、汇总检查结果、记录结论 | 评审前准备、评审会主持 |
| 阶段负责人 | 完成自检、提交交付物与证据 | 交付物提交后、评审前 |
| 质量人员 | 核对测试执行、缺陷关闭与遗留缺陷影响 | 评审前核验、评审会确认 |
| 业务方 | 确认需求覆盖与业务可用性 | 评审会 |
| 配置管理员 | 核对文档版本与配置基线 | 评审前核验 |
阶段启动前与交付前的准备检查项
准备检查的目的是让正式评审只做确认，不做补材料。以下项目在评审会前应全部完成，任一项缺失都会推迟评审。
| 检查项 | 通过标准 | 负责人 | 时点 |
|---|---|---|---|
| 验收范围与阶段目标基线 | 阶段目标、范围边界和验收口径已确认，与批准的计划一致 | 项目经理 | 阶段启动时确认，评审前复核 |
| 交付物清单与版本 | 清单列明全部交付物，每项有版本号和存放位置，无缺项 | 阶段负责人 | 交付物提交后 |
| 评审材料 | 验收报告初稿、测试报告、追溯记录等材料齐备并可查阅 | 阶段负责人 | 评审前 |
| 参会角色与日程 | 各验收角色确认参会，评审时间与议程已通知 | 项目经理 | 评审前 |
| 上一阶段遗留项 | 每项有处理状态、责任人和计划完成时点，影响本阶段的已闭环或有明确结论 | 项目经理 | 评审前 |
阶段验收正式检查项：范围、交付物与质量
正式检查聚焦交付结果本身，逐项核对以下四类内容，每类都要有可查证据。
范围完成度
阶段计划内的工作项应全部关闭，或对未完成项给出明确结论，例如移出范围、延期至下一阶段并说明影响。检查时对照阶段计划逐项核对，不以口头说明代替状态记录。
交付物完整性
按交付物清单核对文档、代码、数据、环境等是否按约定交付。每项交付物应有版本标识和存放位置，交付范围与清单一致。
质量结论
核对测试执行情况、缺陷关闭情况和遗留缺陷等级。遗留缺陷需说明影响范围和规避措施；关键缺陷未关闭时，该项不能判定通过。
需求与设计追溯
抽查需求、设计、开发任务与测试用例之间的对应关系，确认追溯链完整可查。追溯断裂意味着无法证明交付覆盖了约定需求，应作为阻断项处理。
| 检查项 | 通过标准 | 证据 |
|---|---|---|
| 范围完成度 | 计划内工作项全部关闭或有书面结论 | 工作项状态记录、范围变更记录 |
| 交付物完整性 | 清单内交付物齐备，版本与存放位置明确 | 交付物清单、版本记录 |
| 质量结论 | 测试按计划执行，关键缺陷已关闭，遗留缺陷有等级与影响说明 | 测试报告、缺陷列表 |
| 需求与设计追溯 | 需求—设计—开发—测试对应关系可查，抽查无断链 | 追溯矩阵、评审记录 |
变更、遗留问题与文档基线检查项
这部分检查过程记录是否完整，直接影响阶段能否被认定为可移交状态。
- 变更审批：阶段内变更是否走完审批流程，计划、范围和文档是否同步更新。未审批的变更不计入完成范围。
- 遗留问题登记：每项遗留问题有描述、责任人、计划解决时点和影响说明，并明确由下一阶段承接。
- 文档与配置基线：阶段交付的文档和配置项形成基线，纳入版本管理，基线版本与验收对象一致。
- 验收记录归档：检查结果、评审记录和验收结论归档到项目文档，供后续阶段和审计查阅。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 变更审批 | 阶段内变更均有审批记录，计划与文档已同步 | 变更单、更新后的计划 | 项目经理 |
| 遗留问题登记 | 每项有责任人与计划解决时点 | 遗留问题清单 | 阶段负责人 |
| 文档与配置基线 | 基线已固化，版本与验收对象一致 | 配置基线记录 | 配置管理员 |
| 验收记录归档 | 检查结果与结论已归档可查 | 归档记录 | 项目经理 |
每项检查的通过标准与证据要求
通过标准要写成可观察、可核对、有明确判定条件的表述。“测试基本完成”无法判断，“计划内测试用例执行率100%，关键缺陷关闭率100%”才能逐项核对。写法上建议包含判定对象、判定条件和判定阈值三部分。
常见证据类型包括评审记录、测试报告、签署文档和配置基线记录。证据由交付方提供，由对应核验角色确认：质量数据由质量人员核验，基线由配置管理员核验，业务确认由业务方签署。
无法提供证据时，该项按未通过处理，并记录原因和补证计划。允许在评审会上补充说明，但补充说明本身不替代证据；补证完成后需重新核验该项。
| 检查项 | 通过标准示例 | 证据 | 提供方 | 核验方 |
|---|---|---|---|---|
| 范围完成度 | 计划内工作项关闭率100%，未关闭项均有书面结论 | 工作项状态记录 | 阶段负责人 | 项目经理 |
| 质量结论 | 关键缺陷关闭率100%，遗留缺陷均有等级与影响说明 | 测试报告、缺陷列表 | 阶段负责人 | 质量人员 |
| 追溯完整性 | 抽查的需求均有对应设计与测试记录 | 追溯矩阵 | 阶段负责人 | 质量人员 |
| 配置基线 | 基线版本与验收对象一致且已固化 | 配置基线记录 | 配置管理员 | 项目经理 |
阻断项与阶段完成条件
阻断项是不通过就不能判定阶段完成的条件。典型阻断项包括：范围未闭环且无书面结论；关键缺陷未关闭；需求与设计追溯链断裂；文档或配置基线未固化；验收结论未签署。出现任一阻断项，阶段结论应记为未通过。
有条件通过适用于非关键检查项存在轻微偏差的情形，例如个别文档待补充但不影响交付使用。此时需在验收记录中写明附加条件、责任人和完成时限，并在条件满足后确认关闭。阻断项不适用有条件通过。
阶段完成条件为：全部阻断项通过，非阻断项的有条件通过项已登记附加条件，验收结论经各角色签署并归档。未通过时，由阶段负责人制定返工计划，明确整改项和完成时点，整改完成后重新组织复评，复评范围至少覆盖未通过项及其关联项。
| 阻断项 | 判定说明 | 处理方式 |
|---|---|---|
| 范围未闭环 | 计划内工作项未关闭且无书面结论 | 补齐结论或调整范围后复评 |
| 关键缺陷未关闭 | 存在影响交付使用的未关闭缺陷 | 修复并验证后复评 |
| 追溯链断裂 | 需求无法对应到设计与测试记录 | 补齐追溯记录后复评 |
| 基线未固化 | 文档或配置项未形成可核对基线 | 固化基线后复评 |
| 验收结论未签署 | 缺少必要角色的确认签署 | 完成签署后归档 |
验收报告模板应包含的字段
验收报告与清单检查结果一一对应，建议包含以下字段，便于评审会上逐项确认和后续追溯。
- 基本信息：项目名称、阶段名称、验收日期、参与角色与签署人。
- 检查结果汇总：各检查项的结论（通过、有条件通过、未通过）及证据索引，证据索引指向具体文档或记录位置。
- 遗留问题与变更记录：本阶段遗留问题清单、阶段内变更清单及审批情况。
- 验收结论与签署：整体结论、有条件通过项的附加条件、各角色签署。
- 下一阶段准入意见：是否具备进入下一阶段的条件，需带条件移交的事项及责任人。
用工作项与文档承载验收记录
清单要真正可追踪，检查结果需要落到具体的工作项和文档状态上，而不是停留在会议记录里。做法是把每项检查建成工作项或检查单，记录结论、证据位置和负责人；验收报告作为文档与阶段工作项关联；遗留问题转为后续工作项并跟踪状态；评审结论确认后同步更新阶段状态。
ONES 的瀑布项目管理能力可以承载这一流程：用项目计划按阶段或交付物分解工作，用里程碑标记阶段验收这一决策点，并为计划和里程碑设置基线，对比计划与执行的偏差、追溯变更细节。检查项和遗留问题可以作为工作项跟踪状态，验收报告可通过文档关联任务的方式与阶段工作项对应，使检查结论、证据和后续整改在同一处可查。具体检查项和判定口径仍需结合项目类型、合同要求和组织流程裁剪。
常见问题
阶段验收时发现个别文档还没定稿，能不能先通过再补？
要看这份文档是否属于阻断项。如果文档是交付物清单内的正式交付物，且未定稿导致配置基线无法固化，应按未通过处理，补齐后再复评。如果只是非关键的辅助说明材料，且不影响交付物使用和基线一致性，可以记为有条件通过，在验收记录中写明附加条件、责任人和完成时限，条件满足后确认关闭。无论哪种情况，口头承诺都不替代记录，结论要落到验收报告里。
遗留缺陷等级不高，但数量较多，会影响阶段验收结论吗？
影响程度取决于缺陷对交付使用的影响，而不只看数量。检查时先确认关键缺陷是否已全部关闭，这是阻断项；再核对遗留缺陷是否逐条登记了等级、影响范围和规避措施。如果遗留缺陷集中在非核心功能、有明确规避方案且业务方确认可接受，可以作为有条件通过项登记。如果遗留缺陷数量多到无法逐条说明影响，说明质量结论的证据不充分，该项不能判定通过。
有条件通过和未通过在实际操作中怎么区分？
有条件通过适用于非阻断项存在轻微偏差、不影响阶段交付使用的情形，例如个别文档待补充、非关键配置项待核对。此时阶段可以继续推进，但附加条件、责任人和完成时限要写入验收记录，并在到期后确认关闭。未通过则意味着至少存在一个阻断项，例如范围未闭环、关键缺陷未关闭、追溯链断裂或基线未固化，阶段不能移交，需要制定返工计划并重新组织复评。阻断项不适用有条件通过。
复评时需要把全部检查项重新过一遍吗？
复评范围至少覆盖上次未通过的检查项及其关联项。例如追溯链断裂补齐后，要同时核对该追溯链涉及的需求、设计和测试记录是否一致；基线重新固化后，要确认基线版本与验收对象仍然匹配。与未通过项无关且上次已确认通过的检查项，可以在复评记录中引用原结论，不必重复核验，但要在报告中注明引用关系，保证结论可追溯。
验收清单和验收报告是什么关系，需要各做一份吗？
两者用途不同，通常配合使用。清单是逐项核对的检查工具，记录每项检查的通过标准、证据、负责人和结论；验收报告是汇总文档，把清单的检查结果、证据索引、遗留问题、变更记录和最终结论组织成可签署、可归档的材料。实际操作中可以先填清单再汇总成报告，也可以在报告内嵌检查结果表，关键是报告中的每条结论都能对应到清单中的检查项和证据位置。
