瀑布阶段验收要回答的核心问题是：本阶段交付物是否达到进入下一阶段的条件。可执行的做法是“验收准备—自检与预审—正式评审—结论签署—遗留项闭环”五步：先锁定验收范围、通过判据和准入条件，由交付方提交成果与证据，评审方逐项核对，形成通过、有条件通过或不通过的明确结论并签署，遗留项登记责任人和关闭时限，关闭后再放行。验收证据、评审记录和遗留项可以在ONES中随项目计划与文档一并承载。
要点总览（TL;DR）
- 阶段验收按五步执行：交付方自检并整理证据、评审方预审、正式评审会逐项核对、结论判定与签署、遗留项登记与关闭。
- 启动前先锁定三件事：本阶段验收范围与交付物清单、可核对的通过判据、开评审会的准入条件，并形成书面确认表。
- 结论分为通过、有条件通过和不通过；有条件通过要写明附加条件、责任人和复核方式，签署后结论才生效。
- 项目经理、交付负责人、评审方、质量角色和记录人各有明确交付物，判定与交付尽量分离。
- 验收是否闭环看四组条件：交付物与证据齐全、结论明确已签署、遗留项有责任人和时限、下一阶段放行条件成立。
阶段验收先定什么：范围、标准与准入条件
阶段验收最容易出问题的地方在评审会之前：范围没锁、判据模糊、前置工作没完成就开会，评审就会变成临时讨论标准。启动验收前，需要把三件事书面固化，并形成一份“阶段验收范围与标准确认表”，由项目经理组织、交付负责人和评审方共同确认。
本阶段验收范围与交付物清单
范围要写清“验什么、不验什么”。做法是以本阶段计划中的交付物为基准，逐项列出名称、版本、存放位置和责任人，同时明确本阶段不纳入验收的内容，避免评审时把后续阶段的工作拉进来讨论。交付物清单应覆盖三类：过程文档（如需求规格、设计说明）、可检查的成果（如原型、测试报告、可运行版本）和管理记录（如变更记录、问题清单）。
验收标准与通过判据的写法
判据要可核对，避免“基本满足”“质量良好”这类无法判定的表述。推荐写成“对象＋检查项＋判定方式”的结构，例如“需求规格说明书中的每条需求均有唯一编号、验收条件和优先级，抽查20条全部符合”。对每项交付物给出判定方式（文档走查、演示、抽样检查、测试结果核对），并事先约定整体结论规则，例如关键项全部通过且一般项不符合不超过约定数量，方可判定通过。
准入条件：哪些前置工作完成才能开评审
准入条件用于判断“是否具备开评审会的条件”，常见条目包括：交付物已按清单提交并完成版本冻结；交付方自检完成且自检记录可查；上一阶段遗留项已按约定关闭或取得豁免；评审所需环境和演示数据可用；评审方已提前拿到材料并有足够时间预审。准入条件不满足时，应推迟评审而不是在会上补材料，否则结论的可信度会下降。
验收计划与时间点的确定方式
验收时间点应挂在项目计划的阶段里程碑上，在阶段开始时就确定，而不是临近结束时临时约定。计划中写明评审日期、材料提交截止时间、预审时间窗、参会角色和结论输出时限。若阶段执行中出现范围变更，需同步更新验收范围与判据，并记录变更原因和确认人，保证评审时使用的是同一版标准。
验收操作五步：从自检到结论签署
五步流程的每一步都要有明确输入、动作、输出和完成标志，避免“开过会就算验收”的模糊状态。下表给出整体框架，后文逐项说明操作要点。
| 步骤 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、交付方自检 | 交付物清单、验收判据 | 逐项自查，整理证据 | 自检记录、证据清单 | 自检项全部有结论，证据可定位 |
| 二、预审或文档走查 | 自检记录、交付物 | 评审方提前核对，提出问题 | 预审问题清单 | 问题已反馈交付方并确认处理方式 |
| 三、正式评审会 | 预审问题清单、评审议程 | 逐项核对、演示、答疑、记录意见 | 评审意见记录 | 议程项全部走完，意见当场确认 |
| 四、结论判定与签署 | 评审意见记录、判据 | 按规则判定结论，签署确认 | 验收结论单 | 结论明确，各方签署完成 |
| 五、遗留项登记与关闭 | 验收结论单、遗留问题 | 登记责任人、时限，跟踪验证 | 遗留项台账、关闭记录 | 遗留项全部关闭或取得豁免 |
第一步：交付方自检并整理证据
交付负责人按验收判据逐条自检，每条给出“符合／不符合／不适用”的结论，并附证据位置，例如文档章节号、测试用例编号、演示录屏或系统截图。证据的作用是让评审方能够独立复核，而不是只听口头说明。自检发现的问题应在提交前修复或明确标注，带着已知问题进入评审并不违规，但隐瞒问题会直接损害验收结论的有效性。
第二步：预审或文档走查
评审方在正式会前完成材料走查，把能在会前解决的问题解决掉。预审输出一份问题清单，标注问题类型（缺项、错误、表述不清、证据不足）和期望处理方式。交付方逐条回应：接受并修改、说明理由、或转为评审会讨论项。预审的价值在于让正式评审聚焦判定，而不是把时间花在第一次读材料上。
第三步：正式评审会的组织与议程
评审会由项目经理组织，议程建议按“范围与判据确认—交付物逐项核对—预审问题复核—风险与遗留项讨论—结论建议”推进，每项设定时间。会上指定一名记录人，评审意见当场记录并复述确认，避免会后各说各话。涉及演示的交付物，提前准备环境和数据，演示失败本身也应作为评审事实记录，而不是会后补一句“当时是环境问题”。
第四步：结论判定与签署
结论按事先约定的规则判定，分为通过、有条件通过和不通过。有条件通过必须写明附加条件、责任人和复核方式，例如“补齐接口异常场景测试报告后复核，由评审方在三个工作日内确认”。结论单记录评审日期、参与人、判据版本、结论和签署，签署完成才算结论生效。结论判定不应在会后再反复修改，确需调整的按变更处理并留痕。
第五步：遗留项登记与关闭
所有未关闭事项进入遗留项台账，字段至少包括：问题描述、来源（预审或评审会）、责任人、关闭时限、验证方式和当前状态。关闭时由提出方或指定验证人确认，不能由责任人自行标记完成。是否阻断下一阶段需在验收规则中事先约定：影响本阶段核心交付物的问题应阻断，纯文档完善类问题可在下一阶段并行处理，但要有明确的关闭节点。
角色分工与各角色交付物
验收会上的职责不清，通常表现为交付方既解释又判定、评审方只提意见不签字、记录无人负责。把角色、职责和交付物在验收计划中写清楚，可以显著减少这类摩擦。下表为常见分工，团队可按规模合并角色，但判定与交付应尽量分离。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 项目经理 | 组织验收、锁定范围与判据、控制议程与时间、跟踪遗留项 | 验收计划、范围与标准确认表、遗留项台账 |
| 交付负责人 | 准备交付物与证据、完成自检、回应评审意见 | 交付物清单、自检记录、证据材料、问题回应 |
| 评审方（业务或技术评审人） | 预审材料、逐项核对判据、给出评审意见与结论 | 预审问题清单、评审意见、签署的结论单 |
| 质量角色 | 核对过程记录与证据完整性、验证遗留项关闭 | 证据完整性检查记录、遗留项关闭验证记录 |
| 记录人 | 记录评审意见、整理结论单、分发会议记录 | 评审意见记录、验收结论单、会议纪要 |
评审意见的记录与确认方式需要统一：每条意见包含提出人、对应判据条目、问题描述、处理结论（修改／接受／转遗留项）和确认状态。会上逐条复述确认，会后由记录人整理并在约定时限内分发，提出人对记录有异议时在分发后一个工作日内提出修正。这样结论单上的每一条都有可追溯的来源。
当验收证据、评审记录和遗留项需要多人协同维护时，可以把它们放进项目协作工具统一承载。ONES 支持瀑布项目管理过程和框架落地，用「项目计划」按阶段或交付物创建工作分解结构，并用里程碑标记验收等关键决策点；设置计划和里程碑基线后，可对比计划与执行的偏差，便于在验收前判断阶段是否按计划完成。验收材料可放在 ONES Wiki 中并与任务关联，遗留项则以工作项形式登记责任人和时限，形成从计划、证据到关闭记录的连贯链路。具体可用模块以实际开通版本为准。
示例：一个需求阶段验收的完整走查
以下为演示情景，用于说明五步流程如何落地，不代表任何真实项目。
示例背景与阶段范围
某内部系统建设项目完成需求阶段，进入需求阶段验收。验收范围包括：需求规格说明书、需求追溯矩阵、需求评审记录、原型说明。明确不纳入本次验收的内容为界面视觉稿和详细设计文档。通过判据约定为：每条需求具备唯一编号、验收条件和优先级；追溯矩阵覆盖全部需求；需求评审意见全部关闭或有明确处理结论。准入条件为：文档版本冻结、自检完成、上一阶段遗留项已关闭。
自检清单与证据材料
交付负责人自检后提交：需求规格说明书（版本V1.2，共86条需求）、追溯矩阵（覆盖86条）、需求评审记录（23条意见，21条已关闭，2条转为遗留项）、原型说明。证据以文档章节号和评审记录编号定位。自检结论为“符合”，同时主动标注两条未关闭意见及处理计划。
评审会上的判定过程
预审阶段，评审方抽查20条需求，发现3条缺少验收条件，列入预审问题清单。正式评审会上，交付方对3条需求当场补充验收条件并演示追溯矩阵的筛选方式；对2条未关闭意见，评审方确认其中1条影响需求范围，另1条为表述优化。按判据规则，关键项存在未关闭问题，不能判定为通过。
结论与遗留项处理
评审结论为“有条件通过”：补齐3条需求的验收条件并更新追溯矩阵，关闭影响范围的那条评审意见，由评审方在两个工作日内复核；表述优化类意见转为遗留项，责任人为交付负责人，时限为下一阶段第一周，由质量角色验证关闭。复核通过后结论单完成签署，项目进入设计阶段，遗留项在台账中持续跟踪。
验收完成检查：通过前逐项核对
判断一次阶段验收是否真正闭环，不看会议是否开过，而看下面四组条件是否同时满足。建议在结论签署前由项目经理和质量角色逐项核对，任一项不满足即视为未完成。
| 检查维度 | 核对项 | 判定标准 |
|---|---|---|
| 交付物与证据 | 清单内交付物是否全部提交且版本一致；每项判据是否有可定位的证据；自检记录是否完整 | 无缺项，证据可独立复核 |
| 结论 | 结论是否为通过／有条件通过／不通过之一；是否写明判据版本和评审日期；参与方是否签署 | 结论明确、可追溯、已签署 |
| 遗留项 | 每条遗留项是否有责任人、关闭时限和验证方式；阻断项是否已关闭或取得豁免 | 无无主遗留项，阻断项已处理 |
| 阶段放行 | 下一阶段的准入条件是否满足；范围变更是否已记录并确认；验收材料是否归档 | 放行条件成立，材料可查 |
四组条件中，遗留项和阶段放行最容易被忽略。遗留项没有责任人和时限，等于把问题带入下一阶段；放行条件没有核对，则可能出现“验收通过但下一阶段无法启动”的尴尬局面。把这张检查表作为结论签署前的固定动作，阶段验收才算真正完成。
常见问题
阶段验收会上发现交付物有缺项，应该当场判定不通过还是先补材料？
先看缺项是否属于准入条件。如果交付物清单内的关键成果未提交、版本未冻结或自检未完成，说明尚不具备开评审会的条件，正确做法是推迟评审、补齐后再开，而不是在会上边补边判。
如果缺项是在评审过程中新发现的，按事先约定的判据规则处理：影响本阶段核心交付物的，判定为不通过或有条件通过，并写明补齐内容、责任人和复核方式；属于文档完善类的，可转为遗留项，约定关闭时限。无论哪种处理，都要在结论单上留痕，避免会后口头补充。
有条件通过和遗留项有什么区别，实际操作中怎么区分？
有条件通过是验收结论的一种，表示本阶段整体可以放行，但附带了必须在约定时间内完成并复核的条件；遗留项是登记在台账中的未关闭事项，按约定决定是否阻断下一阶段。
区分方法是看影响范围：影响本阶段核心交付物、不处理就无法支撑下一阶段工作的，应写入有条件通过的附加条件，由评审方复核确认；表述优化、文档补充等不影响阶段放行的事项，登记为遗留项，明确责任人和关闭时限即可。两类事项都要有验证人，不能由责任人自行标记完成。
阶段执行中发生了范围变更，验收标准和判据要不要跟着改？
要改，而且要在评审前改完并留痕。范围变更后，验收范围、交付物清单和通过判据应同步更新，记录变更原因、确认人和生效版本，保证评审时使用的是同一版标准。
如果变更在评审会上才提出，应先确认变更是否已被正式批准。未批准的变更不进入本次验收范围；已批准的变更，按更新后的判据核对，并在结论单上注明判据版本。这样结论才有可追溯的依据，后续复盘时也能看清当时按什么标准判定。
遗留项没有在约定时限内关闭，还能进入下一阶段吗？
取决于验收规则中事先约定的阻断条件。影响本阶段核心交付物的遗留项应阻断放行，必须先关闭或取得正式豁免；纯文档完善类事项可以并行处理，但要有明确的关闭节点和跟踪人。
实际操作中，建议在结论签署前由项目经理和质量角色核对遗留项台账，确认每条都有责任人、时限和验证方式。超期未关闭的，要么升级处理，要么由评审方书面确认豁免并说明理由，不能默认放行。
小团队人手少，评审方和交付方可以是同一批人吗？
可以合并角色，但判定与交付应尽量分离。至少保证自检结论不由交付人自己签字确认，评审意见有独立记录人，结论单上的签署人能对判据负责。
人手确实紧张时，可以让同一人承担交付负责人和记录人之外的角色，但评审判定环节建议引入业务或技术侧的独立评审人。角色合并的情况应写进验收计划，说明谁在什么环节行使判定权，避免会上出现既解释又判定的情况。
