瀑布项目相邻阶段的交接，靠一份可核对的“阶段交接单”落地：本阶段交付什么、由谁验收，下一阶段启动前必须具备哪些输入、逐条满足哪些准入条件，都在阶段评审会上逐项确认并留下记录。本文覆盖单项目内相邻阶段的输入输出梳理、准入条件编写、确认流程与完成检查，不涉及组织级流程制度设计。
要点总览（TL;DR）
- 把相邻阶段交接做成一份可核对的“阶段交接单”：输出清单、输入清单、准入条件三部分放在一起，评审时逐项确认。
- 输入输出清单以阶段为单位，标注交付物编号、接收方、用途、责任人和必须/可选，并用对照表保证下一阶段每项必须输入都有来源。
- 准入条件写成能给出“是/否”结论并附证据的条目，例如“需求规格说明书 V1.2 已通过评审，未关闭意见为 0 条”，避免“基本完成”这类表述。
- 确认流程固定为提交、核对、处理未通过项、记录生效四步，由下一阶段负责人主导核对，未通过项区分阻断性与非阻断性并登记责任人和期限。
- 交接完成用检查清单收尾：清单完整、条件逐条有结论、遗留项有责任人和期限、记录可追溯。
先定阶段边界：输入输出清单怎么列
阶段交接混乱，多数源于边界没定清。列清单时，以“阶段”为单位，把本阶段要交出的东西和下一阶段要接收的东西分开写，再建立对应关系。清单不是交付物目录的复制，它要回答三个问题：交什么、交给谁、用来做什么。
建议每个阶段维护两张表：输出清单（本阶段产出）和输入清单（下一阶段所需）。两张表通过“交付物编号”对应，确保下一阶段的每项必须输入，都能在本阶段输出中找到来源。
| 字段 | 说明 | 示例 |
|---|---|---|
| 交付物编号 | 唯一标识，便于跨表引用 | REQ-OUT-03 |
| 交付物名称 | 具体文档、数据或实物 | 需求规格说明书 |
| 来源阶段 | 产出该交付物的阶段 | 需求分析阶段 |
| 接收方 | 下一阶段的使用角色或团队 | 设计组、测试组 |
| 用途 | 接收方用它做什么 | 作为概要设计的功能依据 |
| 责任人 | 对该交付物质量负责的人 | 需求负责人 |
| 必须/可选 | 缺失是否阻断下一阶段启动 | 必须 |
| 状态 | 草稿、已评审、已基线 | 已基线 |
区分必须输入与可选输入是关键一步。必须输入缺失时，下一阶段不得启动；可选输入缺失时，可由接收方评估影响后决定是否带条件启动，并在交接记录中注明。这个区分要在清单阶段就写清楚，避免评审会上临时争论。
输出清单与下一阶段输入清单的对应关系，建议用一张对照表维护：本阶段每个输出对应下一阶段哪几项输入，下一阶段每项必须输入对应本阶段哪个输出。出现“下一阶段有输入、本阶段无输出”的情况，说明边界有遗漏，需要补充交付物或调整阶段划分。
准入条件怎么写才可判定
准入条件的作用是回答“满足什么才能进入下一阶段”。写法上把握一条：每条条件都能由指定角色在评审会上给出“是/否”结论，并能追溯到具体证据。做不到这一点的条件，需要改写或拆细。
常见的准入条目类型包括：
- 文档评审类：如“需求规格说明书已完成评审，评审意见全部关闭”，附评审记录编号。
- 基线冻结类：如“需求基线已冻结，冻结版本号为 V1.2”，附基线记录。
- 缺陷阈值类：如“严重级别缺陷关闭率 100%，一般级别缺陷剩余不超过 5 个”，附缺陷清单。
- 资源到位类：如“设计组 3 名成员已分配至本项目并确认投入时间”，附人员安排记录。
- 环境就绪类：如“开发环境与测试环境已部署并通过连通性验证”，附验证记录。
要避免“基本完成”“大致就绪”“相关文档已准备”这类表述。它们无法判定，也无法追责。改写方法是补上对象、状态、数量和证据来源，例如把“需求文档已完成”改为“需求规格说明书 V1.2 已通过评审，未关闭意见为 0 条”。
准入条件与阶段出口条件是一体两面：出口条件描述本阶段“做完什么”，准入条件描述下一阶段“具备什么才能开始”。实践中可以把出口条件作为准入条件的主要来源，逐条转换，再补充下一阶段特有的准备项（如人员、环境）。两者都写进同一份交接单，评审时一并核对，避免出口通过但准入缺项的情况。
阶段交接的确认流程与角色分工
确认流程固定为四步：提交、核对、处理未通过项、记录生效。每一步都有明确的责任人和产出，交接才算闭环。
| 步骤 | 责任人 | 动作 | 产出 |
|---|---|---|---|
| 提交 | 本阶段负责人 | 按清单整理交付物，填写交接单，标注每项状态和证据位置 | 交接单初稿及附件 |
| 核对 | 下一阶段负责人、质量角色 | 逐项核对输入是否齐全、准入条件是否满足，记录“通过/不通过/带条件通过” | 逐项核对结论 |
| 处理未通过项 | 本阶段负责人 | 登记未通过项、责任人和完成期限，整改后提交复评 | 遗留项清单及复评记录 |
| 记录生效 | 项目经理或阶段负责人 | 确认全部必须项有结论，签署交接单或在系统中更新阶段状态 | 生效的交接记录 |
核对环节建议由下一阶段负责人主导，因为他们是输入的使用者，最清楚缺什么。质量角色负责检查证据是否真实、条件是否按规则判定。项目经理不替代逐项核对，只对争议项和带条件通过项做裁决。
未通过项要区分阻断性和非阻断性。阻断性项未关闭，下一阶段不得启动；非阻断性项可带条件启动，但必须在交接记录中写明条件、责任人和关闭期限，并在下一阶段首次例会上跟踪。复评只针对未通过项，不必重走全部核对。
确认结果的生效时点要写清楚：以交接单签署日期为准，或以系统中阶段状态变更时间为准。生效后，交接单作为阶段文档归档，后续变更通过变更记录追加，不直接修改原记录，保证可追溯。
在工具承载上，ONES 的项目计划支持按阶段分解工作并设置任务前后置依赖，里程碑可标记阶段决策点；阶段交付物可放在 ONES Wiki 中并与任务关联，评审结论和遗留项则随工作项状态与记录留存。具体配置方式以实际使用版本为准。
一个需求阶段到设计阶段的交接示例
以下为演示情景：某系统开发项目从需求分析阶段进入概要设计阶段，参与角色包括需求负责人、设计负责人、质量角色和项目经理。
需求阶段输出清单（节选）：
| 编号 | 交付物 | 接收方 | 用途 | 必须/可选 | 状态 |
|---|---|---|---|---|---|
| REQ-OUT-01 | 需求规格说明书 V1.2 | 设计组 | 功能设计依据 | 必须 | 已评审、已基线 |
| REQ-OUT-02 | 需求跟踪矩阵 | 设计组、测试组 | 追溯需求与设计、用例 | 必须 | 已更新 |
| REQ-OUT-03 | 需求评审记录及意见关闭清单 | 质量角色 | 证明评审完成 | 必须 | 意见全部关闭 |
| REQ-OUT-04 | 业务流程图 | 设计组 | 辅助理解业务场景 | 可选 | 草稿 |
设计阶段准入条件（逐条）：
- 需求规格说明书 V1.2 已通过评审并冻结基线，未关闭评审意见为 0 条。——证据：评审记录、基线记录。
- 需求跟踪矩阵已覆盖全部已确认需求条目，覆盖率 100%。——证据：跟踪矩阵。
- 需求阶段严重级别缺陷已全部关闭，一般级别遗留不超过 3 个且有处理计划。——证据：缺陷清单。
- 设计组 3 名成员已确认投入时间，设计负责人已指定。——证据：人员安排记录。
- 设计模板与编码规范已发布至项目文档库。——证据：文档库链接。
评审结论与遗留项处理：评审会上，前三条判定通过；第四条因一名设计成员投入时间未确认，判定为阻断性未通过，责任人为主管，期限为两个工作日内；第五条通过。项目经理记录带条件项：业务流程图作为可选输入，设计组可先行启动，但需在概要设计评审前补齐。两日后复评，第四条满足，交接单签署生效，设计阶段正式启动。
交接确认的完成检查
阶段交接是否真正完成，用以下清单逐项核对，全部为“是”才算闭环：
- 输入输出清单已覆盖本阶段全部必须交付物，且每项标注了接收方、用途和责任人。
- 下一阶段每项必须输入都能在本阶段输出中找到对应来源，无孤立输入。
- 准入条件逐条有明确结论（通过、不通过、带条件通过），无“待定”项。
- 每条准入条件都附有证据位置，且证据可被核对人直接查看。
- 未通过项和带条件项均登记了责任人、关闭期限和跟踪方式。
- 交接单已由提交方和核对方确认，生效时点明确。
- 确认记录已归档，后续变更通过追加记录体现，原记录未被覆盖。
这份清单也可作为阶段评审会的议程底稿：会前由提交方自检，会上由核对方逐项确认，会后由项目经理检查记录完整性。把检查动作固定在每次交接中，相邻阶段的输入输出和准入条件才能稳定执行，而不是依赖个人经验。
常见问题
准入条件写成“需求文档已完成”为什么不行，应该怎么改？
“需求文档已完成”无法判定，也无法追责：评审会上没人能给出明确的“是/否”结论，事后也找不到证据。改写时补上对象、状态、数量和证据来源，例如改成“需求规格说明书 V1.2 已通过评审，未关闭意见为 0 条，证据为评审记录与基线记录”。这样每条条件都能由指定角色在评审会上直接判定，并追溯到具体文档。
下一阶段负责人认为某项必须输入缺失，但本阶段负责人认为影响不大，怎么处理？
按清单上预先标注的“必须/可选”属性处理：必须输入缺失时，下一阶段不得启动，由本阶段负责人登记整改责任人和期限后复评；可选输入缺失时，由接收方评估影响，可以带条件启动，但要在交接记录中写明条件、责任人和关闭期限。清单阶段就把必须与可选写清楚，能避免评审会上临时争论。争议无法达成一致时，由项目经理对争议项做裁决并记录理由。
阶段交接确认的生效时点以什么为准，后续发现遗漏怎么办？
生效时点要在流程里事先约定：以交接单签署日期为准，或以系统中阶段状态变更时间为准，二者选其一并保持一致。生效后交接单作为阶段文档归档，后续发现遗漏或发生变更时，通过追加变更记录体现，原记录保持不动，保证可追溯。这样复评和审计时能看清每个结论是在什么时点、基于什么证据做出的。
用工具承载阶段交接时，ONES 能覆盖哪些环节？
ONES 的项目计划支持按阶段分解工作并设置任务前后置依赖，里程碑可标记阶段决策点；阶段交付物可放在 ONES Wiki 中并与任务关联，评审结论和遗留项随工作项状态与记录留存。ONES Wiki 支持文档关联任务，也支持在文档中插入工作项列表。这些能力可以承载交接单、交付物和确认记录的存放与关联，具体配置方式以实际使用版本为准。
小项目阶段少、人员少，还需要完整的交接单和评审会吗？
可以简化形式，保留判定动作。阶段少、人员少时，交接单可以只保留必须输入、准入条件和结论三列，评审会可以并入阶段例会，由下一阶段负责人当场逐项确认。需要保留的是：每项必须输入有来源、每条准入条件有结论和证据、未通过项有责任人和期限。规模扩大或阶段间依赖变复杂时，再恢复完整的清单字段和独立评审会。
