瀑布阶段验收的核心做法是：在阶段结束前，由项目经理发起，先确认该阶段交付物清单与验收标准已在阶段启动时约定，再由交付方提交成果与自检记录，评审方按标准逐项核对并记录结论，最后形成阶段验收结论、遗留问题清单和下一阶段准入决定。文章围绕单项目层面的验收方法展开，说明验收前约定什么、四步流程怎么走、各角色交付什么、如何判定完成，并介绍用ONES承载验收记录与遗留项跟踪的方式。
要点总览（TL;DR）
- 阶段验收的关键在启动时就把交付物清单、验收标准、评审角色和基线约定清楚，验收会上只做核对，不临时定标准。
- 验收按提交、核对、结论、闭环四步推进，每步都有输入、动作、输出和完成标志，缺自检记录的提交不进入评审。
- 项目经理负责组织与准入决策，交付负责人对提交内容和自检质量负责，评审负责人集中结论签字权，质量或配置管理角色负责材料完整性与归档。
- 结论分通过、有条件通过、不通过；阻断性遗留项未关闭前，阶段不关闭、下一阶段不正式启动。
- 验收记录、核对结论和遗留项集中在一处管理，遗留项转为带责任人和期限的任务跟踪，阶段关闭后仍可追溯。
阶段验收前要先定好哪些东西
阶段验收最容易出问题的地方，是验收会上才讨论“什么算合格”。标准临时确定，评审就变成各方讨价还价，结论难以服人，返工也难以界定。可行的做法是在阶段启动时就把验收约定写清楚，作为阶段计划的一部分固定下来，阶段结束时只做核对，不做标准谈判。
需要提前约定的要素包括四类：交付物清单、验收标准、评审角色、基线。四者缺一不可，且应当在阶段启动会上由项目经理组织确认，交付方与评审方共同认可。
| 约定要素 | 填写内容 | 确认时点 | 负责人 |
|---|---|---|---|
| 阶段交付物清单 | 逐项列出本阶段应产出的文档、代码、测试记录、评审纪要等，注明名称、版本要求、存放位置 | 阶段启动 | 项目经理与交付负责人 |
| 验收标准 | 每项交付物对应的可核对条件，如“需求文档覆盖全部已确认需求条目，每条需求有唯一编号和验收依据” | 阶段启动 | 交付负责人起草，评审方确认 |
| 评审角色 | 指定评审负责人及各专业评审人，明确谁有结论签字权 | 阶段启动 | 项目经理 |
| 阶段基线 | 本阶段计划、交付物清单和标准的版本，作为后续偏差对比的参照 | 阶段启动 | 项目经理或配置管理角色 |
验收标准的写法决定验收能否执行。可核对的标准通常包含三个成分：对象、条件、判定方式。例如“接口文档（对象）覆盖本阶段全部对外接口，字段说明完整（条件），由评审人抽查不少于十条接口逐一比对（判定方式）”。相反，“文档质量良好”“代码规范”这类表述无法逐项核对，应在阶段启动时改写或补充判定依据。
交付物清单要区分主交付物和过程记录。主交付物是下一阶段工作的直接输入，如需求规格、设计说明；过程记录是证明工作按要求完成的证据，如评审纪要、自检表、测试报告。两类都要列入清单，但验收时的核对重点不同：主交付物看内容是否满足标准，过程记录看是否齐全、是否与交付物对应。
基线确认是容易被忽略的一步。阶段启动时把计划、交付物清单和标准固化为一个版本，阶段中如有变更，走变更记录并更新基线。这样验收时出现“标准是什么时候改的”这类争议，可以直接对比版本追溯。ONES的项目计划支持按阶段分解工作、设置任务依赖并用里程碑标记重要决策点，也支持设置计划和里程碑基线、对比计划与执行偏差，可作为承载阶段约定与基线确认的工具基础。
阶段验收的四步操作流程
验收动作可以拆成四步：提交、核对、结论、闭环。每一步都有明确的输入、动作、输出和完成标志，项目经理按此组织，评审各方按此配合。下表给出四步流程的整体框架，随后逐条说明操作要点。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：提交成果与自检记录 | 阶段交付物清单、验收标准、实际产出物 | 交付负责人整理交付物，按标准逐项自检，填写自检记录并说明偏差 | 交付物包、自检记录、偏差说明 | 交付物齐全且自检记录覆盖全部标准条目 |
| 第二步：按标准逐项核对 | 交付物包、自检记录、验收标准 | 评审方逐项核对，记录每项结论（符合/不符合/待补充）及依据 | 逐项核对记录 | 全部标准条目均有核对结论，无遗漏项 |
| 第三步：形成结论与遗留问题清单 | 逐项核对记录 | 评审方汇总结论，区分通过、有条件通过、不通过；列出遗留问题 | 阶段验收结论、遗留问题清单 | 结论经评审负责人确认，遗留问题均有描述 |
| 第四步：遗留项闭环与阶段关闭 | 遗留问题清单、验收结论 | 为每个遗留项指定责任人与期限，跟踪关闭；确认准入条件后关闭阶段 | 遗留项关闭记录、阶段关闭决定 | 阻断性遗留项全部关闭，阶段状态更新 |
第一步：交付方提交成果与自检记录
提交不是把文件丢给评审方，而是带着自检结论提交。交付负责人对照阶段启动时约定的标准逐条自查，在自检记录中写明每项的完成情况和存在的偏差。自检记录的价值在于把明显不满足标准的内容提前暴露，减少评审会上的无效讨论。完成标志是交付物齐全、自检记录覆盖全部标准条目；缺少自检记录的提交应退回补充，不进入评审。
第二步：评审方按标准逐项核对
核对要按标准条目走，而不是按文档通读。评审人逐项记录结论，对“不符合”的条目写明具体位置和不符合的理由，对“待补充”的条目写明缺什么。核对记录是后续结论和遗留问题的直接依据，因此要求每条标准都有对应结论，不允许出现“整体感觉可以”这类笼统判断。完成标志是全部条目均有结论，核对记录可追溯到具体交付物。
第三步：形成验收结论与遗留问题清单
结论分三种：通过、有条件通过、不通过。有条件通过适用于主体交付物满足标准、遗留问题不影响下一阶段启动的情形；不通过适用于存在阻断性问题，需要返工后重新验收。遗留问题清单要为每个问题写明描述、影响范围、提出人，并初步判断是否阻断下一阶段。完成标志是结论经评审负责人确认，遗留问题清单完整且与核对记录对应。
第四步：遗留项闭环与阶段关闭
遗留项在结论确认后转为可跟踪的任务，指定责任人和完成期限，按期限跟踪关闭。阻断性遗留项关闭前，阶段不关闭、下一阶段不正式启动；非阻断项可随下一阶段并行处理，但要有明确的关闭时点。完成标志是阻断性遗留项全部关闭、阶段状态更新为已关闭，并在阶段记录中留下准入决定。
各角色在验收中分别交付什么
验收出问题，常见原因是职责重叠或空缺：要么多人签字却无人对结论负责，要么材料无人归档、遗留项无人跟踪。按角色划分交付物，可以让每个环节都有明确的责任人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 发起验收、组织评审、确认结论、做出阶段关闭与准入决定 | 验收通知、评审安排、阶段验收结论、阶段关闭决定 |
| 交付负责人 | 整理交付物、完成自检、说明偏差、落实返工 | 交付物包、自检记录、偏差说明、返工结果 |
| 评审方（含各专业评审人） | 按标准逐项核对、给出结论、提出遗留问题 | 逐项核对记录、评审意见、遗留问题清单 |
| 质量或配置管理角色 | 检查材料完整性、管理版本与基线、归档验收记录 | 材料完整性检查结果、版本与基线记录、归档的验收记录 |
项目经理的职责重点在组织与决策，不代替评审方做技术判断。交付负责人对提交内容的真实性和自检质量负责，返工安排也由其落实。评审方对核对结论负责，结论签字权应集中在评审负责人一人，避免多人签字导致责任分散。质量或配置管理角色不参与技术结论，但负责确认材料齐全、版本正确、记录可追溯，并在阶段关闭后完成归档。
角色划分要落到具体人名，而不是岗位名称。阶段启动时在验收约定中写明每个角色的承担人，人员变动时更新约定并通知相关方。对于规模较小的项目，一人可以兼任多个角色，但评审方与交付方不宜由同一人担任，以保证核对结论的独立性。
一个阶段验收的完整示例
以下示例为演示情景，用于说明流程如何落地，不对应具体项目。假设某系统建设项目进入需求阶段验收，阶段启动时已约定交付物为需求规格说明书、需求跟踪矩阵和需求评审纪要，验收标准包括：每条需求有唯一编号和验收依据；需求跟踪矩阵覆盖全部需求条目；评审纪要中的问题均有处理结论。
提交环节，需求负责人整理三份交付物，按标准逐条自检，在自检记录中注明“跟踪矩阵中编号R-037至R-041的验收依据待业务方确认”，并说明该偏差不影响主体内容评审。评审环节，评审人按标准核对：需求编号与验收依据逐条抽查，发现两条需求的验收依据描述过于笼统，记为“不符合”；跟踪矩阵覆盖情况核对后确认完整；评审纪要问题处理情况核对后确认全部有结论。核对记录中每条标准都有对应结论。
结论环节，评审负责人汇总为“有条件通过”：主体交付物满足标准，两条验收依据描述需补充细化，列为遗留问题，由需求负责人在五个工作日内完成，业务方确认后关闭；该遗留项判定为非阻断，下一阶段可启动，但需在下一阶段首次评审时确认关闭情况。质量角色检查材料齐全、版本正确后归档验收记录，项目经理更新阶段状态并记录准入决定。
这个示例可迁移的规律有三条：标准在阶段启动时已具体到可抽查的条目，评审才能逐项核对；自检记录提前暴露偏差，减少了评审中的意外；遗留问题带责任人和期限，并与阶段准入挂钩，验收结论才真正影响后续工作。换到设计阶段或测试阶段，只需替换交付物和标准内容，流程结构保持一致。
验收完成的检查项与阻断条件
验收是否真正完成，不能只看会议是否开过。以下清单可在结论确认前逐项核对，全部满足才判定验收完成。
- 材料完整性：阶段约定的交付物全部提交，版本与基线一致，自检记录覆盖全部标准条目。
- 标准覆盖：每条验收标准都有核对结论，无遗漏项；不符合项已写明具体位置和理由。
- 结论确认：验收结论明确为通过、有条件通过或不通过，经评审负责人确认并留有记录。
- 遗留项管理：每个遗留问题都有描述、责任人、完成期限，并标注是否阻断下一阶段。
- 归档与状态：验收记录、核对记录、遗留问题清单已归档，阶段状态已更新。
出现以下情况时，不能判定验收通过，应判定不通过或暂缓：主交付物缺失或版本与基线不符；存在未核对的标准条目；阻断性遗留问题未关闭且无明确处理计划；验收结论未经评审负责人确认；材料未归档导致后续无法追溯。暂缓适用于材料基本齐全但个别条目待补充的情形，需明确补充期限和复评方式，避免暂缓变成无限期拖延。
用工具承载验收记录与遗留项跟踪
验收方法确定后，落地效果取决于记录是否集中、流转是否可见、遗留项是否被持续跟踪。分散在邮件和共享盘里的验收材料，阶段关闭后很难追溯；遗留项如果没有转为带责任人和期限的任务，容易在下一阶段被遗忘。
在ONES中，可以按阶段组织项目计划，用里程碑标记阶段验收这一决策点，并把阶段交付物清单和验收标准作为阶段工作的组成部分管理。验收材料与结论可以集中记录在项目文档中，ONES Wiki支持文档关联任务，也支持在文档中插入工作项列表，便于把验收记录与对应的交付物、任务对应起来，形成可追溯的记录链。
评审流转可以通过任务状态标记推进：提交、核对、结论确认各环节对应不同的工作项状态，评审人处理后在系统中留下记录，项目经理据此掌握验收进度。遗留问题在结论确认后转为可跟踪的工作项，设定责任人与期限，按状态跟踪关闭；阻断性遗留项的关闭情况作为阶段关闭和下一阶段启动的前置条件核对。阶段计划与里程碑基线可用于对比实际进展与计划的偏差，帮助在阶段关闭前识别尚未处理的问题。深圳农商银行使用ONES瀑布项目模板对关键里程碑和交付物进行规范化管理的实践，也说明了这种承载方式在瀑布项目中的适用场景，具体效果因团队执行情况而异。
工具承载的是记录和跟踪，验收的判断标准仍来自阶段启动时的约定。把约定、核对记录、结论和遗留项放在同一处管理，验收才既能当次说清，也能事后查清。
常见问题
阶段验收时发现验收标准本身写得不够清楚，怎么处理？
先判断是表述问题还是标准缺失。若只是表述笼统，可由评审方在核对记录中写明实际采用的判定依据，并在结论中注明该条标准的解释方式，事后补充到标准文档；若某项交付物在阶段启动时根本没有对应标准，应视为约定遗漏，由项目经理组织交付方与评审方补充确认后再核对，不宜在评审会上直接按口头理解判定通过。
这类情况暴露的是阶段启动环节的问题，建议在阶段关闭记录中一并记下，作为下一个阶段约定标准时的改进输入。
有条件通过之后，下一阶段能不能直接启动？
取决于遗留项是否阻断。判定为非阻断的遗留项，下一阶段可以启动，但要为每项写明责任人和关闭期限，并在下一阶段的首次评审中确认关闭情况；判定为阻断的遗留项，需关闭后才能正式启动下一阶段，期间下一阶段的准备工作可以开展，正式投入需等待准入决定。
有条件通过不是模糊地带，结论中应明确哪些项阻断、哪些项不阻断，避免下一阶段启动后责任落空。
小项目人手少，评审方和交付方能否由同一人担任？
不建议。交付方对自己的成果做核对，结论的独立性难以保证，也容易漏掉自检阶段已经忽略的问题。人手紧张时可以让同一人兼任项目经理与质量或配置管理角色，或让评审方只保留一名评审负责人，但交付与评审两个角色应分开。
如果确实无法分开，至少在核对记录中写明这一安排，并由上一级或相关方对结论做一次确认，降低结论失真的风险。
遗留问题清单和缺陷跟踪是什么关系，需要合并吗？
两者可以分开管理，也可以合并到同一套工作项中跟踪，关键是每个遗留项都要有唯一标识、责任人、期限和是否阻断的标记。阶段验收产生的遗留项往往包含文档补充、标准细化等非缺陷类工作，直接混入缺陷库可能影响缺陷统计口径。
实际操作中，可以在验收记录中保留遗留问题清单作为结论依据，同时把需要持续跟踪的条目转为工作项，两边用同一编号对应，既保证验收记录完整，也保证跟踪不遗漏。
阶段验收的记录需要保留到什么程度？
至少保留四类内容：阶段启动时约定的交付物清单与验收标准（含版本）、交付方的自检记录、评审方的逐项核对记录、验收结论与遗留问题清单。这些记录的作用是在后续出现范围争议、返工界定或审计追溯时提供依据。
记录不必追求篇幅，但要能对应到具体交付物和具体标准条目。归档时与阶段基线版本一并保存，变更过的标准要保留变更记录，便于事后对比。
