瀑布项目的相邻阶段衔接，靠一份可核验的阶段交接单完成：上一阶段把交付物、评审结论、遗留问题和变更记录整理成输出包，下一阶段据此逐条核对准入条件，在阶段评审会上判定放行或挂起，并以书面记录归档。本文给出交接单字段、四步确认流程、角色分工、填写示例和完成检查清单，适用于单项目内的阶段衔接。
要点总览（TL;DR）
- 相邻阶段确认靠一份阶段交接单：上一阶段交出交付物、评审记录、遗留问题清单和变更记录，下一阶段据此逐条核对准入条件。
- 准入条件要写成可判定、有证据、有责任人的条目，每条条件在交接单中注明由哪份输出物作为证据。
- 确认按四步推进：冻结输出包并自检、下一阶段预审准入条件、评审会逐条判定、放行或挂起并登记遗留项与补齐期限。
- 非关键条件缺失且不影响下一阶段主体工作启动时可有条件放行；涉及安全、合规、核心功能正确性的关键条件缺失宜挂起。
- 交接闭环的判断标准是交付物有版本与基线、条件逐条有结论、遗留项有责任人和期限、放行记录已归档可追溯。
阶段交接要确认哪些输入、输出与准入条件
相邻阶段确认的对象可以归为两类：上一阶段交出的输出包，和下一阶段进入前必须满足的准入条件。输出包是证据，准入条件是判定规则，两者通过交接单逐条对应。交接单填不清楚，评审会就只能凭印象表态；字段设计到位，判定才有依据。
输出包建议固定为四类内容。第一类是交付物，包括文档、设计、代码、测试用例等实际产物，每项标注版本号和基线标识。第二类是评审记录，包括评审方式、参与人、评审意见和最终结论，结论要写明“通过”“有条件通过”或“未通过”。第三类是遗留问题清单，列出未关闭事项、影响范围、责任人和计划关闭时间。第四类是变更与偏差记录，说明本阶段发生的需求变更、计划偏差及其审批情况。
准入条件的写法决定它能否被判定。一条合格的准入条件应满足三点：可判定，即能给出明确的通过或不通过结论；有证据，即指明用哪份交付物或记录来证明；有责任人，即明确谁负责提供证据、谁负责核验。例如“关键需求已评审通过”比“需求基本明确”可判定，“待澄清项均有责任人和关闭期限”比“问题已处理”可核验。
下表给出阶段交接单的字段结构，可直接作为模板使用。
| 字段 | 内容要求 | 提供方 | 核验方 |
|---|---|---|---|
| 交付物清单 | 名称、版本号、基线标识、存放位置 | 上一阶段负责人 | 下一阶段负责人 |
| 评审记录 | 评审时间、参与人、意见、结论 | 上一阶段负责人 | 项目经理 |
| 遗留问题清单 | 问题描述、影响、责任人、关闭期限 | 上一阶段负责人 | 质量或配置管理角色 |
| 变更与偏差记录 | 变更内容、审批结论、对计划的影响 | 上一阶段负责人 | 配置管理角色 |
| 准入条件条目 | 条件描述、证据来源、核验责任人 | 下一阶段负责人 | 评审会集体判定 |
| 判定结论 | 放行、有条件放行或挂起，附理由 | 评审组织者 | 项目经理确认 |
输入输出与准入条件的对应关系要写进交接单：每条准入条件后面注明由哪份输出物作为证据。这样评审时逐条对照即可，避免出现“条件写了但找不到证据”的情况。
按四步完成一次相邻阶段确认
确认动作有固定的先后顺序，跳过任何一步都会让判定失去依据。四步流程如下，每步都说明输入、动作、输出和完成标志。
第一步：上一阶段冻结输出包并自检。输入是本阶段全部工作产物和过程记录。动作是整理交付物清单、补齐版本与基线标识、汇总评审意见和遗留问题、登记变更。输出是一份完整的输出包和自检结论。完成标志是上一阶段负责人签字确认输出包不再变动，后续修改走变更流程。
第二步：下一阶段负责人预审准入条件。输入是输出包和事先约定的准入条件清单。动作是逐条核对证据是否齐全、是否满足判定标准，对存疑条目提出书面意见。输出是预审意见，标明哪些条件已满足、哪些存疑、哪些明显不满足。完成标志是预审意见提交给评审组织者，并附上需要会上讨论的问题清单。
第三步：阶段评审会逐条判定并记录结论。输入是输出包、预审意见和准入条件清单。动作是评审会逐条过条件，确认证据、给出结论，对争议条目当场讨论。输出是会议结论和放行记录，写明每条条件的判定结果和理由。完成标志是结论形成书面记录，参会角色确认无异议。
第四步：放行或挂起，登记遗留项与补齐期限。输入是评审会结论。动作是满足全部关键条件的直接放行；部分非关键条件未满足的，可做有条件放行，同时把未满足项登记为遗留项，指定责任人和补齐期限；关键条件不满足的，挂起下一阶段启动，待补齐后重新评审。输出是放行记录或挂起通知，以及遗留项跟踪清单。完成标志是下一阶段负责人收到放行结论，遗留项进入跟踪台账。
有条件放行和挂起的区别在于风险大小。非关键条件缺失、且不影响下一阶段主体工作启动的，可以有条件放行；涉及安全、合规、核心功能正确性的关键条件缺失，宜挂起处理。两种处理都要留下书面记录，口头同意不构成放行依据。
角色分工与各角色的交付物
交接责任悬空，通常是因为角色和交付物没有对应清楚。相邻阶段确认涉及四类角色，各自的动作和产出如下表。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 上一阶段负责人 | 整理交付物、组织自检、汇总遗留问题 | 输出包、自检结论 |
| 下一阶段负责人 | 核对准入条件、提出预审意见 | 准入条件预审意见 |
| 项目经理或评审组织者 | 组织评审会、主持逐条判定、记录结论 | 会议结论、放行记录 |
| 质量或配置管理角色 | 核对基线、登记变更与遗留项、维护跟踪台账 | 基线记录、变更登记、遗留项台账 |
分工中有两个容易忽略的点。一是下一阶段负责人要参与准入条件的制定，不能只在评审会上被动接受结论，否则条件可能脱离下一阶段的实际需要。二是质量或配置管理角色要在评审前完成基线核对，评审会上再补登记会让放行记录缺少版本依据。
当项目使用 ONES 承载阶段管理时，交接所需的记录可以落在同一套工作项和文档中。ONES 瀑布项目管理解决方案支持按项目阶段分解计划、为任务设置前后置依赖，并用里程碑标记重要决策点（F2）；项目计划和里程碑可设置基线，用于对比计划与执行的偏差并追溯变更（F3）。交接单、评审结论和遗留项可以借助 ONES Wiki 的文档关联任务能力与工作项对应（F5），使放行记录和遗留项状态在下一阶段仍可追溯。这些能力承载的是记录与追溯，交接单字段和判定规则仍需项目团队自行约定。
示例：需求阶段转入设计阶段的确认过程
以下为演示情景，用于说明交接单如何填写和判定，不代表任何具体项目的真实数据。
某项目需求阶段结束，准备转入设计阶段。上一阶段负责人整理的输出包包括：需求规格说明书（版本 V1.2，已打基线）、需求评审记录（评审结论为“有条件通过”）、待澄清项清单（3 项，其中 1 项涉及外部接口协议）、以及一次需求变更的审批记录。自检结论为输出包冻结，后续修改走变更流程。
下一阶段负责人对照准入条件逐条预审，结果如下表。
| 准入条件 | 证据 | 预审结论 |
|---|---|---|
| 关键需求已评审通过 | 需求评审记录，结论“有条件通过” | 满足，附条件 |
| 待澄清项均有责任人和关闭期限 | 待澄清项清单 | 2 项满足，1 项缺关闭期限 |
| 需求基线已建立 | 基线记录 V1.2 | 满足 |
| 需求变更已审批 | 变更审批记录 | 满足 |
评审会逐条判定后给出结论：需求基线已建立、变更已审批，设计阶段的主体工作可以启动；外部接口协议澄清项不影响总体设计开展，做有条件放行，指定该项责任人为需求负责人，补齐期限为五个工作日，纳入遗留项跟踪；另一项缺关闭期限的待澄清项当场补上期限后关闭。若外部接口协议属于设计的前置输入且无法在期限内补齐，则应改为挂起，待澄清完成后再启动设计评审。
这个例子说明两种处理的差别：有条件放行保留了推进节奏，但必须把未满足项转成可跟踪的遗留项；挂起则暂停下一阶段启动，适用于关键输入缺失的情形。判定结论要写进放行记录，注明理由和后续动作。
完成检查：交接是否真正闭环
一次阶段确认是否完成，可以用下面的清单逐项核对。全部通过，说明交接闭环；有任意一项不通过，应回到对应步骤补齐。
- 交付物齐全，每项有版本号和基线标识，存放位置可访问。
- 评审记录完整，包含参与人、意见和明确结论。
- 每条准入条件都有对应证据和判定结论，没有“待定”条目留在记录中。
- 未满足项已登记为遗留项，有责任人、补齐期限和跟踪方式。
- 变更与偏差已登记，审批结论可查。
- 放行记录或挂起通知已归档，下一阶段负责人已确认收到。
- 下一阶段可以依据归档记录追溯本次交接的证据和结论。
检查时特别关注两类常见缺口：一是准入条件写了但没有证据支撑，评审结论只能靠口头说明；二是遗留项登记了但没有进入跟踪台账，补齐期限到期无人核对。前者要在预审阶段拦下，后者要在放行后由质量或配置管理角色定期检查。把这两类缺口堵住，相邻阶段的衔接才算真正闭环。
常见问题
准入条件写成什么程度才算可判定？
一条可判定的准入条件要同时具备三个要素：能给出明确的通过或不通过结论、指明用哪份交付物或记录作为证据、明确谁提供证据和谁核验。例如“关键需求已评审通过”可以判定，“需求基本明确”无法判定。写条件时把证据来源直接附在条件后面，评审会上逐条对照即可，避免出现条件写了却找不到证据的情况。
有条件放行和挂起应该怎么选？
判断依据是缺失条件对下一阶段的风险大小。非关键条件缺失、且不影响下一阶段主体工作启动的，可以做有条件放行，同时把未满足项登记为遗留项，指定责任人和补齐期限。涉及安全、合规、核心功能正确性的关键条件缺失，宜挂起下一阶段启动，待补齐后重新评审。两种处理都要留下书面记录，口头同意不构成放行依据。
下一阶段负责人应该在什么时候介入？
介入时间要早于评审会。下一阶段负责人应参与准入条件的制定，并在收到输出包后做预审，逐条核对证据是否齐全、是否满足判定标准，对存疑条目提出书面意见。只在评审会上被动接受结论，条件容易脱离下一阶段的实际情况，预审意见也能让评审会集中讨论真正有争议的条目。
遗留项登记之后由谁跟踪，跟踪到什么程度算关闭？
遗留项一般由质量或配置管理角色维护跟踪台账，定期核对补齐期限。关闭的标准是补齐动作已完成、证据已归档、原准入条件重新判定为满足。仅有责任人承诺或口头说明不算关闭。若补齐期限到期仍未完成，应在台账中标注并提交项目经理决定是否影响下一阶段继续推进。
用工具承载交接记录时，哪些内容仍需团队自行约定？
工具承载的是记录与追溯，例如在 ONES 中，项目计划可按阶段分解任务并设置前后置依赖，里程碑可标记决策点，计划和里程碑可设置基线用于对比偏差与追溯变更；交接单、评审结论和遗留项可借助 ONES Wiki 的文档关联任务能力与工作项对应。交接单包含哪些字段、准入条件如何判定、放行由谁拍板，这些规则仍需项目团队自行约定并在评审会上执行。
