瀑布阶段验收的核心，是在阶段结束前用一份事先约定的验收标准，把该阶段的交付物、评审记录和遗留问题核清，由阶段负责人组织评审、项目负责人或客户代表确认，形成书面验收结论后才进入下一阶段。本文按“定标准—走流程—分角色—看示例—做检查”的顺序，给出单项目层面可直接执行的阶段验收做法。
要点总览（TL;DR）
- 阶段验收的对象是阶段交付物、评审记录和遗留问题三类，判定口径统一为通过、有条件通过、不通过，并在阶段启动时写入阶段计划。
- 操作分四步：整理交付物清单与证据、组织验收评审、逐项判定并记录结论、遗留问题登记与签署归档，每步都有明确的完成标志。
- 角色上分开准备、评审与签署：阶段负责人组织与记录，交付物责任人自检，评审方逐项判定，项目负责人或客户代表签署结论。
- 验收结束后按验收前、验收中、验收后三组检查项核对，重点防范标准临时确定、口头通过无记录、遗留问题无人跟踪、验收与阶段关闭混为一谈。
瀑布阶段验收要验什么：先定标准再验收
阶段验收要回答的问题，是“这个阶段的约定产出是否达到约定标准，能否据此进入下一阶段”。它检验的对象有三类：阶段交付物本身、支撑交付物的评审记录、以及尚未关闭的遗留问题。把这三类对象分开核对，验收结论才有依据，避免用一句“基本做完了”代替判定。
验收标准来自三个地方，需要在阶段启动时就明确下来：项目计划中该阶段的目标与交付物清单，合同或需求基线中对本阶段成果的约定，以及项目适用的质量要求（如文档规范、评审规则、测试通过口径）。标准一旦确定，阶段内的工作就围绕它准备证据；阶段末临时追加要求，会让验收变成扯皮，也会让交付物责任人无所适从。
判定口径建议统一为三种，并事先约定各自的后续动作：
| 判定结果 | 含义 | 后续动作 |
|---|---|---|
| 通过 | 交付物齐全，逐项符合验收标准，无影响下一阶段的遗留问题 | 签署验收结论，阶段关闭，下一阶段按计划启动 |
| 有条件通过 | 主要交付物达标，存在不影响下一阶段启动的遗留问题 | 签署结论并附遗留问题清单，明确责任人与关闭时限，下一阶段可启动但需跟踪关闭 |
| 不通过 | 关键交付物缺失或未达标准，或存在阻断下一阶段的问题 | 不签署通过结论，列出整改项与复验时间，整改后重新组织验收 |
三种口径要在阶段启动时写进阶段计划或验收约定中，并说明哪些交付物属于“关键项”——关键项不达标即判不通过，非关键项的问题可进入有条件通过的遗留清单。这样判定时依据清楚，减少评审会上的临时争论。
阶段验收的操作步骤：从准备到签署
阶段验收可以拆成四步，每步都有明确的输入、动作、输出和完成标志。四步走完，验收才算真正结束，而不是开完会就散场。
第一步：整理交付物清单与证据
输入是阶段计划中的交付物清单和验收标准。阶段负责人组织各交付物责任人，逐项核对交付物是否完成、版本是否为最终版，并收集配套证据：评审记录、测试报告、问题处理记录、变更记录等。输出是一份待验清单，每项交付物对应其证据位置和自检结论。完成标志是待验清单经阶段负责人确认，所有条目都有明确状态（已交付、部分交付、未交付），没有“待补充”的空白项。
第二步：组织验收评审
输入是待验清单和评审材料。阶段负责人确定参与角色（技术评审人、质量人员、客户代表等，按阶段性质取舍），提前发出材料，约定评审方式和时间。评审可以采取会议评审，也可以对文档类交付物采用书面评审加意见汇总。输出是评审意见记录，包含每位评审人对各项交付物的判定意见和问题描述。完成标志是应到评审人均已给出意见，意见已汇总成条目，无遗漏项。
第三步：逐项判定并记录结论
输入是评审意见和待验清单。阶段负责人组织评审方对每项交付物给出通过、有条件通过或不通过的判定，汇总形成阶段整体结论。输出是验收记录，写明验收对象、判定依据、逐项结论、整体结论和参与人。完成标志是验收记录经评审方确认，整体结论明确，不存在“原则通过、细节待定”这类模糊表述。
第四步：遗留问题登记与签署归档
输入是验收记录中的问题项。对每个遗留问题登记描述、责任人、关闭时限和影响范围，判断是否阻断下一阶段。随后由项目负责人或客户代表签署验收结论，验收记录、遗留问题清单和阶段关闭确认一并归档。完成标志是签署完成、文档归档到位、遗留问题已进入跟踪清单并有明确关闭时间，下一阶段的启动条件据此确认。
角色与交付物分工：谁准备、谁评审、谁签字
阶段验收容易退化成阶段负责人一个人的确认，原因通常是角色边界不清。把“谁准备、谁评审、谁签字”分开，验收才有制衡，记录也才完整。
| 角色 | 主要职责 | 产出文档 |
|---|---|---|
| 阶段负责人 | 组织验收、汇总证据、主持评审、汇总判定结论 | 待验清单、验收记录、阶段关闭确认 |
| 交付物责任人 | 提供最终版交付物，完成自检并说明完成情况 | 交付物及其自检记录、配套证据 |
| 评审方（技术、质量、客户代表等） | 按验收标准逐项判定，提出问题和整改意见 | 评审意见记录 |
| 项目负责人或客户代表 | 确认整体结论，签署验收结论，决定是否进入下一阶段 | 签署后的验收结论 |
分工上有两点需要明确。其一，交付物责任人负责自检，评审方负责判定，两者不能由同一人兼任关键项的判定，否则验收失去独立核对的意义。其二，签署权归项目负责人或客户代表，阶段负责人负责组织和记录，不代替签署。遗留问题清单由阶段负责人维护，责任人由问题所属领域的交付物责任人担任，关闭确认由提出问题的评审方复核。
当项目使用 ONES 承载瀑布项目时，阶段交付物、评审记录和遗留问题可以放在同一套工作项与文档体系中管理：用「项目计划」按阶段分解 WBS 并用里程碑标记验收节点，用基线对比计划与执行偏差，验收记录和遗留问题通过文档关联对应任务，减少证据散落在个人电脑里的情况。工具承载的是记录与跟踪动作，判定标准和签署责任仍由上述角色承担。
示例：一个需求分析阶段的验收过程
以下为演示情景，用于说明验收如何落地，不作为真实项目案例。
阶段背景与验收标准。某系统建设项目进入需求分析阶段收尾。阶段启动时约定的验收标准为：需求规格说明书覆盖合同范围内的全部业务模块；每条需求有唯一编号、来源和优先级；需求评审记录完整，评审意见已闭环；需求基线经客户代表确认。关键项为需求规格说明书和客户确认，关键项不达标即判不通过。
交付物与证据清单。待验清单包括：需求规格说明书（最终版）、需求评审记录、评审意见处理记录、需求基线确认单、需求变更记录（阶段内发生的变更）。每项标注责任人和证据位置，自检结论均为已交付。
评审过程与判定结果。阶段负责人组织技术评审人和客户代表评审。技术评审人逐条核对需求编号与来源，发现两个模块的接口需求描述缺少输入输出定义；客户代表确认业务范围覆盖完整，但对一项优先级设定提出调整意见。逐项判定结果：需求规格说明书为有条件通过（接口描述需补充），评审记录通过，基线确认单待客户代表在补充完成后签署。整体结论为有条件通过。
遗留问题与关闭安排。登记两项遗留问题：接口需求补充，责任人为需求负责人，关闭时限为五个工作日内，由技术评审人复核；优先级调整，责任人为需求负责人，与客户代表确认后更新基线。两项均不阻断系统设计阶段启动，但需在设计评审前关闭。
可迁移的规律。这个示例体现三点：验收标准在阶段启动时约定，判定时直接对照；关键项与非关键项分开处理，避免小问题拖住整个阶段；有条件通过必须附带可跟踪的遗留清单，否则等同于无结论通过。
阶段验收的完成检查与常见疏漏
验收结束后，用下面这份清单逐项核对，可以判断这次验收是否做到位。
| 检查时点 | 检查项 | 核验方式 |
|---|---|---|
| 验收前 | 验收标准是否在阶段启动时已约定并写入阶段计划 | 查阅阶段计划或验收约定，确认标准、关键项和判定口径 |
| 验收前 | 交付物是否齐全且为最终版，证据是否可追溯 | 对照待验清单逐项核对，确认无空白状态 |
| 验收前 | 评审方是否确定并收到材料 | 确认参与人名单和材料发出记录 |
| 验收中 | 是否逐项判定，而非只给整体结论 | 检查验收记录中每项交付物均有判定结果 |
| 验收中 | 结论是否有书面记录并经确认 | 检查验收记录是否含参与人确认 |
| 验收后 | 遗留问题是否有人负责、有明确时限 | 核对遗留问题清单的责任人和关闭时间 |
| 验收后 | 验收结论是否归档，阶段关闭是否有确认 | 确认归档位置和阶段关闭确认记录 |
| 验收后 | 是否具备进入下一阶段的条件 | 对照判定口径，确认无阻断项或阻断项已安排 |
常见疏漏有四类，处理方式各不相同。标准临时确定：阶段末才讨论验收要求，导致返工和争议，应在阶段启动时把标准固化，阶段内变更走变更记录。口头通过无记录：会上说“没问题”但无书面结论，后续无法追溯，应要求验收记录当场形成并确认。遗留问题无人跟踪：清单建了但没人关闭，问题带入后续阶段累积，应指定责任人和时限并纳入下一阶段的跟踪。验收与阶段关闭混为一谈：验收通过不等于阶段关闭，阶段关闭还需确认文档归档、资源交接等收尾事项，两者应分别记录。
把这套做法固定下来后，每个阶段的验收都按同一口径执行：标准前置、证据齐全、逐项判定、遗留可跟踪、结论可追溯。阶段之间的衔接因此有据可依，项目整体进度和质量也更容易把控。
常见问题
阶段验收时客户代表无法到场签字，验收还能推进吗？
可以推进，但要把签署环节单独安排。评审会可以由阶段负责人主持，技术评审人和质量人员先完成逐项判定并形成验收记录；客户代表未确认的部分标注为待确认，不作为已通过项。整体结论可以暂定为有条件通过，遗留清单中登记“客户代表确认”这一项，明确责任人和确认时限，确认完成后再补签验收结论。需要避免的是把未确认项直接写成通过，后续追溯时无法说明依据。
有条件通过之后，遗留问题一直没关闭，下一阶段要不要停下来？
取决于遗留问题是否属于阻断项。判定为有条件通过时，已经确认这些问题不影响下一阶段启动，因此下一阶段可以按计划推进；但遗留清单要进入下一阶段的跟踪范围，由责任人在约定时限内关闭，提出问题的评审方复核。如果遗留问题到期未关闭且影响扩大，应回到阶段负责人处重新评估是否升级为阻断项，必要时暂停相关后续工作。跟踪动作可以借助 ONES 的文档关联任务与工作项管理承载，关闭状态和时限在同一处可见。
阶段验收和阶段关闭是一回事吗？
两者是前后衔接的两个动作。验收解决的是“本阶段产出是否达到约定标准”，输出验收记录和遗留问题清单；阶段关闭解决的是“本阶段收尾事项是否办完”，包括文档归档、资源交接、下一阶段启动条件确认等。验收通过是有条件进入下一阶段的前提，阶段关闭则标志本阶段正式结束。把两者合并记录，容易出现验收通过但归档缺失、交接未完成的情况，建议分别形成记录并相互引用。
小型项目阶段短、交付物少，还需要走完整的四步验收吗？
四步的实质动作建议保留，形式可以简化。交付物清单可以只有几行，评审可以由两三位相关人员以书面意见代替会议，验收记录可以是一页纸，遗留问题清单可以并入下一阶段的任务列表。需要保留的底线有三条：验收标准在阶段启动时约定、判定结论有书面记录、遗留问题有责任人和时限。项目规模小、参与人少时，评审与签署可以由不同角色分别承担，保持基本的核对关系。
验收标准在阶段中途发生变化，怎么处理？
先判断变化来源。如果是需求基线或合同范围发生正式变更，应走变更记录，同步更新阶段验收标准和交付物清单，并通知评审方，验收时按更新后的标准判定。如果是评审方在阶段末提出的新要求，且未经过变更流程，不应直接纳入本次验收判定，可以作为下一阶段的改进项登记。无论哪种情况，变更都要留下记录，避免验收时出现两套标准各说各话。
