400-188-1518瀑布阶段交接单模板：字段与签字项清单
瀑布阶段交接单用来记录上一阶段交付了什么、下一阶段接收了什么、谁确认可以进入下一阶段。本文提供一张可直接复制使用的空白交接单，并逐字段说明填写口径、划分必填与选填、给出完整填写示例，最后说明模板如何随项目裁剪和持续维护。
Table of Contents
要点总览（TL;DR）
- 瀑布阶段交接单按四组字段组织：基本信息、交付物与准入准出核对、遗留问题与风险依赖、签字确认，空白模板可直接复制使用。
- 必填项包括交接单编号、阶段与交接双方、交付物名称与验收结论、遗留问题责任人及期限、移交人与接收人签字；关联评审、影响范围、外部依赖等可按项目裁剪。
- 签字项按角色设置：移交人确认交付物完整，接收人确认已核对并接受遗留问题安排，阶段负责人确认准出准入成立，质量或评审代表确认验收有依据，签字前须完成对应核对。
- 可核验的关键是交付物清单与验收结论一一对应、遗留问题有责任人和期限、签字与核对项绑定，而非签字数量多少。
- 模板需版本管理，字段增删和签字角色调整应升版留痕；已归档交接单保持原样，新项目从最新版本复制空白表。
可复制空白交接单模板
下面这张表按四组内容组织：基本信息、交付物与准入准出核对、遗留问题与风险依赖、签字确认。可以直接复制到文档或表格工具中，按行填写；行数不够时在组内追加，保持组名和字段名不变。
| 组别 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | 交接单编号 | |
| 项目名称 | ||
| 移交阶段 → 接收阶段 | ||
| 移交方（角色/姓名） | ||
| 接收方（角色/姓名） | ||
| 交接日期 | ||
| 关联评审/里程碑 | ||
| 二、交付物与准入准出核对 | 交付物名称 | |
| 交付物版本/存放位置 | ||
| 验收标准 | ||
| 验收结论（通过/有条件通过/不通过） | ||
| 准出条件核对结果 | ||
| 准入条件核对结果 | ||
| 三、遗留问题与风险依赖 | 遗留问题描述 | |
| 影响范围 | ||
| 责任人 | ||
| 计划关闭期限 | ||
| 外部依赖（供方/其他团队/环境） | ||
| 四、签字确认 | 移交人签字 / 日期 | |
| 接收人签字 / 日期 | ||
| 阶段负责人签字 / 日期 | ||
| 质量或评审代表签字 / 日期 | ||
| 归档位置与归档日期 |
交付物有多项时，第二组按“一项交付物一行”展开，验收结论逐项给出，避免整张单只有一个笼统的“已验收”。
每个字段记录什么、怎么填
字段填错最常见的原因是口径不统一：同一列有人写结论、有人写过程描述。下表给出每个字段的含义、填写口径和示例值，填表人照此填写即可，不必再靠口头约定。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 交接单编号 | 唯一标识，便于检索和归档 | 项目代号-阶段代号-序号 | CRM-P2P3-001 |
| 项目名称 | 所属项目 | 与立项名称一致 | 客户关系管理系统二期 |
| 移交阶段 → 接收阶段 | 交接发生在哪两个阶段之间 | 使用项目阶段命名，不用“前期/后期”等模糊说法 | 需求分析 → 系统设计 |
| 移交方 / 接收方 | 交接双方的责任人 | 写角色加姓名，角色与项目分工表一致 | 需求负责人 张明 / 设计负责人 李华 |
| 交接日期 | 完成交接的日期 | YYYY-MM-DD，与签字日期可不同 | 2025-03-14 |
| 关联评审/里程碑 | 本次交接对应的关口 | 填写评审名称或里程碑名称 | 需求评审通过、M2 设计启动 |
| 交付物名称 | 本阶段实际移交的成果 | 一项一行，写可核验的对象名称 | 需求规格说明书、原型文件 |
| 交付物版本/存放位置 | 确认接收的是哪个版本 | 版本号加存放路径或文档链接 | V1.3，项目文档库/需求/规格书 |
| 验收标准 | 判断交付物合格的依据 | 引用评审 checklist 条目或明确条件 | 覆盖全部一级需求，评审意见已闭环 |
| 验收结论 | 对该项交付物的判定 | 只填“通过/有条件通过/不通过”，条件另记遗留问题 | 有条件通过 |
| 准出条件核对结果 | 上一阶段能否结束 | 逐条对照准出清单，写“满足/未满足” | 4 项满足，1 项未满足（见遗留问题 1） |
| 准入条件核对结果 | 下一阶段能否启动 | 逐条对照准入清单，写“满足/未满足” | 3 项满足 |
| 遗留问题描述 | 未关闭事项 | 写事实和当前状态，不写“尽快处理” | 接口字段定义待第三方确认 |
| 影响范围 | 遗留问题影响哪些工作 | 指向具体交付物或任务 | 影响接口设计文档第 3 章 |
| 责任人 / 期限 | 谁在何时关闭 | 写姓名和日期，期限可核验 | 王强，2025-03-21 |
| 外部依赖 | 交接后依赖的外部条件 | 写清供方、团队或环境 | 第三方支付网关联调环境 |
| 签字项 | 角色对本次交接的确认 | 签字加日期，签字前完成对应核对 | 接收人 李华 2025-03-14 |
字段之间存在对应关系：交付物清单决定验收结论的行数，验收结论为“有条件通过”或“不通过”时，必须在遗留问题区出现对应条目；遗留问题的责任人与期限又构成下一阶段准入核对的输入。填写时按“交付物—验收结论—遗留问题—准入核对”的顺序推进，可以避免结论与问题脱节。
必填项、选填项与签字项划分
必填项缺失时交接不能成立；选填项按项目情况裁剪；签字项则与核对动作绑定。三类分开管理，填表人不会因为字段多而漏掉关键项。
必填字段清单
- 交接单编号、项目名称、移交阶段与接收阶段、交接日期。
- 移交方与接收方的角色和姓名。
- 交付物名称、版本或存放位置、验收结论，每项交付物一行。
- 准出条件核对结果；准入条件核对结果在下一阶段启动前补齐。
- 遗留问题描述、责任人、计划关闭期限（无遗留问题时填“无”）。
- 移交人、接收人签字及日期。
选填字段及裁剪条件
- 关联评审/里程碑：项目未设正式评审节点时可省略，但需在项目计划中能找到对应关口。
- 验收标准：交付物已有独立验收清单时可只写引用编号。
- 影响范围、外部依赖：小型项目、无外部供方时可省略。
- 质量或评审代表签字：项目规模小、未设独立质量角色时，可由阶段负责人兼签并在备注中说明。
签字角色与签字含义
| 签字项 | 签字人 | 签字确认的内容 | 签字前置条件 |
|---|---|---|---|
| 移交人 | 上一阶段负责人或交付物作者 | 交付物清单完整、版本正确，遗留问题已如实登记 | 交付物已放入约定位置，验收结论已填写 |
| 接收人 | 下一阶段负责人 | 已核对交付物与验收结论，接受遗留问题的处理安排 | 逐项确认交付物可获取，遗留问题有责任人和期限 |
| 阶段负责人 | 项目经理或阶段关口负责人 | 准出与准入核对结果成立，同意进入下一阶段 | 准出条件核对完成，未满足项已有处置结论 |
| 质量或评审代表 | 质量角色或评审组代表 | 验收过程符合约定标准，结论有依据 | 评审记录或验收记录可查 |
签字顺序建议为移交人、接收人、质量或评审代表、阶段负责人。签字后交接单归档，作为阶段关口证据；后续若发现交付物问题，可回溯到具体签字项和核对记录。
一份填好的交接单示例
以下为演示情景，用于说明字段如何落地，不代表真实项目数据。
背景：某企业内部系统项目从需求分析阶段进入系统设计阶段，需求评审已通过，但接口字段定义仍待第三方确认。
| 组别 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 交接单编号 | CRM-P2P3-001 |
| 项目名称 | 客户关系管理系统二期 | |
| 移交阶段 → 接收阶段 | 需求分析 → 系统设计 | |
| 移交方 | 需求负责人 张明 | |
| 接收方 | 设计负责人 李华 | |
| 交接日期 | 2025-03-14 | |
| 关联评审/里程碑 | 需求评审通过、M2 设计启动 | |
| 交付物与核对 | 交付物名称 | 需求规格说明书；交互原型 |
| 版本/存放位置 | V1.3，项目文档库/需求/规格书；原型 V2.0，设计库 | |
| 验收标准 | 覆盖全部一级需求，评审意见已闭环 | |
| 验收结论 | 规格书：有条件通过；原型：通过 | |
| 准出条件核对 | 4 项满足，1 项未满足（接口字段定义） | |
| 准入条件核对 | 3 项满足，设计启动所需输入已具备 | |
| 遗留问题与风险 | 遗留问题描述 | 接口字段定义待第三方确认 |
| 影响范围 | 影响接口设计文档第 3 章 | |
| 责任人 / 期限 | 王强，2025-03-21 | |
| 外部依赖 | 第三方支付网关联调环境 | |
| 处置结论 | 设计阶段先完成其余模块，接口设计在字段确认后补充 | |
| 签字确认 | 移交人 | 张明 2025-03-14 |
| 接收人 | 李华 2025-03-14 | |
| 质量或评审代表 | 评审组 陈静 2025-03-14 | |
| 阶段负责人 | 项目经理 赵磊 2025-03-15 | |
| 归档 | 项目文档库/阶段交接/CRM-P2P3-001，2025-03-15 |
这份示例的可核验之处在于：验收结论“有条件通过”与遗留问题一一对应，遗留问题有责任人和期限，阶段负责人在确认处置结论后才签字。归档后，该交接单可作为阶段评审的输入，也便于后续追溯接口字段问题的处理过程。
在项目管理工具中承载这类交接记录时，可以把交接单作为文档关联到对应阶段的工作项，让交付物清单、遗留问题与项目计划中的任务保持同一套对象。ONES Wiki 支持文档关联任务，并可在文档中插入 ONES Project 的工作项列表，适合把交接单与阶段任务放在一起维护；ONES 的项目计划支持按阶段分解工作、设置里程碑和前后置依赖，便于把交接关口对应到计划节点。具体签字审批与字段配置方式以实际产品配置为准。
模板的裁剪与维护方法
模板要能长期使用，需要明确三件事：什么情况下可以删字段、改动如何留痕、交接单与阶段评审如何衔接。
按项目规模裁剪字段
- 小型项目（单一团队、交付物少于 5 项）：保留基本信息、交付物与验收结论、遗留问题、移交人与接收人签字；质量代表签字可由阶段负责人兼签。
- 中型项目（跨团队协作）：增加准入条件核对、外部依赖、质量或评审代表签字。
- 大型或受监管项目：保留全部字段，并增加评审记录编号、变更记录引用，签字项不得合并。
裁剪的前提是必填项不减少；删减选填项时，在模板版本记录中写明删减原因和适用项目范围。
模板版本与变更记录
模板文件本身应有版本号和变更记录表，记录变更日期、变更内容、发起人和生效范围。字段增删、签字角色调整、验收结论选项变化都属于需要升版的变更；仅修改示例文字可不升版。已归档的交接单保持原样，不随模板升版回改。
与阶段评审、准入准出清单的衔接
交接单的准出核对结果应引用阶段准入准出检查清单的条目编号，评审记录作为验收结论的依据。评审未通过的阶段不进入交接签字环节；评审有条件通过的，条件必须转化为遗留问题条目，再进入签字。这样交接单、评审记录和检查清单三者可以互相印证。
归档与复用方式
交接单按“项目—阶段”归档，编号规则保持稳定，便于按项目检索全部关口记录。新项目启动时从最新版本模板复制空白表，不直接修改历史归档文件；项目结束后可将本项目实际使用的字段裁剪方案整理为模板变体，供同类项目复用。
常见问题
交接单上的验收结论填了“有条件通过”，后续怎么跟踪才算闭环？
“有条件通过”意味着交付物可以移交，但条件必须转化为遗留问题条目，写清描述、影响范围、责任人和计划关闭期限，并在准入核对时作为输入逐条确认。条件关闭后，可在原交接单上补充关闭记录或关联新的核对记录，保持交接单、评审记录与检查清单三者可互相印证。评审未通过的阶段不进入交接签字环节。
项目没有独立的质量角色，质量或评审代表签字怎么处理？
小型项目、未设独立质量角色时，可由阶段负责人兼签，并在备注中说明兼签原因和验收依据来源。兼签不改变签字含义：签字人仍需确认验收过程符合约定标准、结论有依据，评审记录或验收记录可查。若项目受监管或交付物涉及对外承诺，建议保留独立评审代表签字，不合并签字项。
交接单和阶段准入准出检查清单是什么关系，能否只保留其中一份？
两者作用不同：检查清单是逐条核对条件的标准，交接单是记录本次交接事实和签字确认的受控表单。交接单的准出核对结果应引用检查清单的条目编号，验收结论以评审记录为依据。只保留检查清单会缺少交接双方确认和签字留痕；只保留交接单则核对依据不完整。建议两份配合使用，交接单归档为阶段关口证据。
交接单在项目管理工具中怎么承载，签字和归档如何留痕？
可以把交接单作为文档关联到对应阶段的工作项，让交付物清单、遗留问题与项目计划中的任务保持同一套对象。ONES Wiki 支持文档关联任务，并可在文档中插入 ONES Project 的工作项列表，适合把交接单与阶段任务放在一起维护；ONES 的项目计划支持按阶段分解工作、设置里程碑和前后置依赖，便于把交接关口对应到计划节点。具体签字审批与字段配置方式以实际产品配置为准。
模板裁剪后，历史项目的交接单需要跟着改吗？
不需要。已归档的交接单保持原样，不随模板升版回改，以保证关口证据的原始性。字段增删、签字角色调整、验收结论选项变化属于需要升版的变更，应在模板版本记录中写明变更日期、内容、发起人和生效范围；仅修改示例文字可不升版。新项目从最新版本模板复制空白表，裁剪方案可整理为模板变体供同类项目复用。
