瀑布阶段验收发生在阶段结束、下一阶段启动之前：项目组提交阶段成果和自检记录，验收方按事先约定的标准逐项核对，形成书面结论。本文按单项目层面展开，依次说明验收基线怎么定、执行步骤怎么走、各角色交付什么、记录怎么填，以及如何判断验收真正完成。
要点总览（TL;DR）
- 阶段验收的起点在阶段开始前：把交付物清单、可逐项核对的验收标准、验收方和验收时点写进基线并冻结，阶段末才有统一的核对依据。
- 执行按提交成果与自检记录、逐项核对并记录偏差、未通过项整改复核、签署结论并归档四步推进，每步都有明确的完成标志。
- 项目经理组织验收并把关结论，交付负责人对成果完整性和自检质量负责，验收方独立核对并签署，质量或评审角色提供抽查与争议意见。
- 验收完成的判断标准是结论书面签署、核对项无空白、整改项闭环、基线变更留痕、材料可查且下一阶段启动条件明确。
阶段验收前先定好验收基线
阶段验收能否顺利进行，很大程度上取决于阶段开始前是否已经把“验什么、按什么标准验、谁来验、什么时候验”写清楚。基线没有提前锁定，阶段末就容易出现交付物范围争议、标准解释不一致、验收方临时更换等情况，验收会退化成反复沟通。可执行的做法是在阶段启动会上完成基线确认，并把它作为阶段计划的一部分冻结。
验收基线通常由四类内容组成，来源应尽量引用已有文件，减少口头约定：
- 交付物清单：本阶段应产出的文档、设计、代码、测试报告、培训材料等，逐项列明名称、形态和存放位置。来源一般是合同或工作说明书、需求规格、阶段计划中的任务分解。
- 验收标准：每个交付物对应的核对条件，例如“接口文档覆盖全部对外接口，字段说明完整”“测试用例执行率达到约定比例，遗留缺陷按等级分类记录”。标准要写到他人可以照着核对的程度，避免“文档完整”“质量合格”这类无法判定的表述。
- 验收方：明确每类交付物由谁核对、谁有最终签署权。涉及多方的，写清主验人和会签人。
- 验收时点：阶段结束的具体日期、提交截止时间、评审安排和结论签署时限。
基线由项目经理组织编制，交付负责人提供交付物范围和自检方式，验收方确认标准可核对、可判定，三方在阶段启动时共同确认后冻结。冻结之后如需调整，应走变更记录：写明变更内容、原因、影响的范围和时点，由原确认方重新确认，并保留变更前后的版本。阶段进行中新增的交付物，同样补入基线再执行，避免验收时临时追加要求。
| 基线项 | 内容要点 | 常见来源 | 确认方 |
|---|---|---|---|
| 交付物清单 | 名称、形态、存放位置、责任人 | 合同、需求规格、阶段计划 | 项目经理、交付负责人、验收方 |
| 验收标准 | 逐项可核对的判定条件 | 需求规格、质量要求、行业规范 | 验收方确认，交付负责人认可 |
| 验收方 | 主验人、会签人、各自核对范围 | 项目章程、合同约定 | 项目经理与验收方上级确认 |
| 验收时点 | 提交截止、评审时间、签署时限 | 阶段计划、里程碑安排 | 项目经理确认，验收方知会 |
阶段验收的执行步骤
基线确定后，阶段验收按“提交—核对—整改—签署”的顺序推进。每一步都要有明确的输入、动作、输出和完成标志，避免验收停在“已经发邮件了”这种中间状态。下表给出可直接套用的流程。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交阶段成果 | 交付物清单、实际成果、自检记录 | 交付负责人按清单逐项整理成果，附自检结果和已知问题说明，在截止时间前提交给验收方 | 成果包、自检记录、提交说明 | 验收方确认收到，材料齐全或列出缺件 |
| 2. 核对与偏差记录 | 验收基线、成果包 | 验收方按标准逐项核对，记录通过、不通过及原因；对需要演示或抽测的项目安排现场核对 | 验收核对记录、偏差清单 | 全部验收项均有核对结论，无空白项 |
| 3. 整改与复核 | 偏差清单 | 对未通过项明确整改责任人、整改内容和完成期限；整改完成后提交补充材料，由原核对人复核 | 整改记录、复核结论 | 每个未通过项都有复核结果，或经批准转为遗留问题 |
| 4. 签署结论与归档 | 核对记录、整改复核结果 | 验收方给出阶段验收结论（通过、有条件通过、不通过），各方签署；结论与全套记录归档 | 阶段验收结论、归档记录 | 结论书面签署，归档可查，下一阶段启动条件明确 |
第2步是验收质量的关键。核对时建议按基线顺序逐项打勾，不跳项、不合并；对不通过项写清“哪一条标准未满足、实际表现是什么”，而不是只写“不合格”。有条件通过的结论要同时写明遗留事项、责任人和关闭时间，否则容易在下一阶段被遗忘。
在工具层面，阶段成果的提交、核对和整改可以落到具体工作项上：用工作项承载每个交付物和偏差项，通过状态变化反映“待提交—待核对—整改中—已复核”，评审意见和结论记录在对应工作项或关联文档中。ONES 支持按项目阶段分解计划、用里程碑标记阶段决策点，并可设置计划和里程碑基线、对比计划与执行的偏差，这些能力可以帮助把验收时点和偏差记录放在同一处跟踪；阶段验收结论、核对记录等文档可通过 ONES Wiki 与相关任务关联，便于后续查阅。是否采用工具承载，取决于团队已有的记录习惯，纸质或表格记录同样可以完成验收。
角色分工与各自交付物
阶段验收出问题，常见原因不是标准不清，而是职责重叠或空缺：有人以为对方会核对，有人签了字却不掌握核对依据。把角色、动作和交付物固定下来，可以减少这类扯皮。下表按单项目场景列出典型分工，团队规模较小时可由一人兼任多个角色，但核对与交付两项职责建议分开。
| 角色 | 在验收中的职责 | 具体动作 | 提交或签署的文档 |
|---|---|---|---|
| 项目经理 | 组织验收、控制节奏、把关结论 | 组织基线确认与冻结；安排验收时点；跟踪整改期限；确认下一阶段启动条件 | 验收基线、验收计划、阶段验收结论（会签）、变更记录 |
| 交付负责人 | 对成果完整性和自检质量负责 | 按清单整理成果；完成自检并说明已知问题；组织整改并提交补充材料 | 成果包、自检记录、整改说明 |
| 验收方 | 按标准独立核对并给出结论 | 逐项核对；记录偏差；复核整改结果；签署验收结论 | 验收核对记录、偏差清单、验收结论（签署） |
| 质量或评审角色 | 提供独立的质量视角 | 抽查交付物与标准的一致性；核对自检记录是否真实；对争议项给出评审意见 | 质量抽查记录、评审意见 |
分工确定后，应在基线确认时同步告知各方，避免验收当天才明确谁签字。验收方不宜同时承担交付责任；如果人员紧张必须兼任，至少安排另一名人员对关键交付物做交叉核对，并在记录中注明。
一个阶段验收的填写示例
以下为演示情景，用于说明验收记录如何填写，不代表真实项目数据。某系统建设项目进入“需求与设计阶段”验收，阶段范围包括需求规格说明书、概要设计文档和需求评审记录三项交付物，验收方为甲方业务负责人和技术负责人。
| 验收项 | 验收标准 | 核对结果 | 偏差说明 | 结论 |
|---|---|---|---|---|
| 需求规格说明书 | 覆盖本期全部业务需求，每条需求有唯一编号、优先级和验收条件 | 通过 | — | 通过 |
| 概要设计文档 | 包含系统架构、模块划分、接口定义；接口字段说明完整 | 不通过 | 对外接口第3、5项缺少异常返回字段说明 | 整改后复核 |
| 需求评审记录 | 记录评审参与人、意见和处理结论，意见闭环 | 通过 | — | 通过 |
整改记录部分填写为：偏差项“概要设计文档接口说明”，整改责任人“设计负责人”，整改内容“补充第3、5项接口的异常返回字段及示例”，完成期限“验收会后3个工作日”；复核人“技术负责人”，复核结果“已补充，字段说明与需求规格一致”，复核日期按实际填写。全部整改闭环后，验收结论填写为“阶段验收通过”，由项目经理、交付负责人和验收方签署，注明结论日期，并将核对记录、整改记录和结论一并归档。
填写时注意两点：偏差说明要指向具体条目，便于整改人定位；结论栏区分“通过”“整改后复核”“不通过”，不要用“基本通过”这类模糊表述，否则下一阶段启动条件无法判断。
验收完成检查与常见遗漏
验收会开完不等于验收完成。可以用下面的清单逐项核对，全部满足再启动下一阶段。
- 验收结论已书面化，写明通过、有条件通过或不通过，并有验收方签署和日期。
- 核对记录覆盖基线中的全部验收项，没有空白项或口头结论。
- 未通过项已闭环：整改完成并复核，或经批准转为遗留问题，写明责任人和关闭时间。
- 基线变更均有记录，包括变更内容、确认人和变更时点，验收依据与最终基线一致。
- 验收材料已归档，存放位置可查，后续阶段和审计能够调取。
- 下一阶段启动条件已明确：前置交付物、遗留事项处理安排、资源到位情况。
常见遗漏集中在几处：一是结论只停留在会议纪要里，没有独立签署的验收结论；二是整改项记录了但没人复核，偏差清单长期挂着“整改中”；三是阶段中口头调整了交付物范围，基线未更新，验收时按新范围核对却找不到依据；四是有条件通过后直接进入下一阶段，遗留事项没有纳入下阶段计划跟踪。把这些环节纳入检查清单，并在阶段验收会上逐项确认，可以明显减少返工和争议。
常见问题
阶段验收时发现交付物范围与阶段计划不一致，应该怎么处理？
先确认范围差异的来源：是阶段中经批准的范围变更，还是交付方自行增减。属于已批准变更的，调出变更记录，核对变更内容、确认人和时点是否完整，按变更后的基线执行验收；变更记录缺失的，由项目经理组织原确认方补充确认后再核对，并在验收记录中注明依据的基线版本。
属于未经批准的增减，按原基线验收，新增内容另行安排，避免在验收会上临时扩大或缩小核对范围。无论哪种情况，验收结论都应写明本次核对所依据的基线版本，便于后续追溯。
验收方在阶段末临时更换，之前的核对标准还有效吗？
标准本身不因人员更换而失效，前提是基线在阶段开始时已经书面确认并冻结。新任验收方应先阅读基线文件、变更记录和已有的核对记录，确认标准内容后再开展核对；对标准理解有疑问的条目，由项目经理组织交付负责人一起澄清，澄清结论补入记录。
如果新任验收方提出与原标准不同的判定条件，应走基线变更流程，由原确认方重新确认，不宜在核对过程中直接按新理解判定，否则交付方无法预期验收结果。
有条件通过之后，遗留事项如何避免在下一阶段被遗忘？
有条件通过的结论要同时写明遗留事项清单、每项的责任人和关闭时间，并把这些事项纳入下一阶段的计划跟踪，作为该阶段的一项明确任务，而不是只写在验收结论的备注里。
下一阶段启动时，由项目经理确认遗留事项已进入计划、责任人已知晓；关闭时由原验收方或指定复核人确认结果。遗留事项长期未关闭的，应在阶段例会上作为风险项提出，避免拖到项目收尾才集中处理。
团队规模小、人员必须兼任多个角色时，验收怎么保证独立性？
核对与交付两项职责建议分开。人员确实紧张时，至少对关键交付物安排另一名人员做交叉核对，例如由未参与该交付物编写的成员按标准逐项检查，并在记录中注明核对人和交叉核对安排。
签署环节同样要留痕：兼任情况写进验收记录，说明谁核对、谁签署、交叉核对由谁完成。这样即使角色合并，验收依据和结论仍可追溯，后续审计或复盘时能看清当时的实际分工。
用工具管理阶段验收，需要关注哪些记录点？
关注三类记录：交付物和偏差项是否落到可跟踪的工作项上，状态能否反映提交、核对、整改、复核的推进；验收时点和阶段决策点是否有里程碑标记，计划与执行的偏差能否对比；验收结论、核对记录等文档是否与相关任务关联，便于后续调取。
ONES 支持按项目阶段分解计划、用里程碑标记阶段决策点，并可设置计划和里程碑基线、对比计划与执行的偏差；阶段验收相关文档可通过 ONES Wiki 与任务关联。团队已有的记录习惯不同，用表格或文档承载同样可以完成验收，工具的作用在于让状态和记录集中可查。
