任务交接要完成的是责任、信息和访问条件的同时转移：交出方把任务目标、当前进展、依赖风险、截止时间和资料权限讲清楚，接收方复述确认并能独立说出下一步，任务负责人正式更新，交接才算生效。本文按范围判断、字段清单、执行步骤、角色分工、完整示例和完成检查六个环节展开，适用于研发与项目工作中的单项或小批量任务转交。
要点总览（TL;DR）
- 先按影响面、剩余工作量、外部依赖和截止紧迫度给任务定级：两项以上偏高走正式交接，四项都低可用简式交接，但负责人字段仍要更新。
- 交接单固定七类字段：目标与验收标准、当前状态、依赖与风险、待决问题、截止时间与里程碑、文档与权限位置、下一步建议动作，交出方按栏填写、接收方按栏核对。
- 执行顺序为提交交接单并预约说明、逐项讲解与提问、接收方复述、更新负责人与状态、确认人审核留痕；复述环节最能暴露理解偏差，不宜省略。
- 交出方对交接时点的信息真实性负责，接收方确认后即承接责任，确认人审核流程完整性；上下游依赖方需被知会新的对接人。
- 完成检查设三项阻断：责任未更新到接收方、关键资料或权限无法独立获取、遗留问题无人认领，任一项存在即视为交接未完成。
交接前先定范围：哪些任务需要正式交接
把所有任务都做成正式交接会拖慢节奏，全部依赖口头知会又会留下责任空档。可行的做法是先按四个维度给任务定级，再决定用哪种交接方式。影响面指任务失败会波及多少人、多少团队或多少外部交付物；剩余工作量指从当前状态到完成还需要多少投入；外部依赖指任务是否卡在其他人或其他团队的产出上；截止紧迫度指距离最近一个不可延后的时间点还有多久。
四项中任意两项偏高，就适合走正式交接：填写交接单、开说明会、接收方复述确认、确认人审核。四项都低的任务，用一条消息加简短记录即可，但仍要更新任务负责人，避免出现无人认领的状态。
| 任务类型 | 交接等级 | 典型触发时点 | 角色配置 |
|---|---|---|---|
| 临近截止、涉及对外交付的任务 | 正式交接 | 人员离岗、转岗、临时休假 | 交出方、接收方、确认人 |
| 剩余工作量大、跨多个环节的任务 | 正式交接 | 任务转派、阶段移交 | 交出方、接收方、确认人 |
| 依赖外部团队或供应商的任务 | 正式交接 | 任务转派、阶段移交 | 交出方、接收方、确认人，依赖方知会 |
| 影响面小、剩余工作少的日常任务 | 简式交接 | 临时请假、短期代办 | 交出方、接收方 |
触发时点需要在交接发生前就明确，常见的有五类：人员离岗（离职或长期调出）、转岗、休假、任务转派、阶段移交（如从开发阶段移交到测试阶段）。前三类通常有可预期的时间窗口，适合提前几天启动；任务转派和阶段移交往往发生在项目推进中，需要在决定转派的同时就确定交接日期。
角色上要区分三个人：交出方是当前对任务负责的人，接收方是接下来承担责任的人，确认人是审核交接是否完整、责任转移是否生效的人，通常由直属负责人或项目经理担任。确认人不宜由交出方或接收方兼任，否则审核环节失去意义。
交接信息清单：交出方必须写清的字段
交接信息遗漏大多不是因为交出方不愿意写，而是没有固定字段可依。把交接单的字段固定下来，交出方按栏填写，接收方按栏核对，遗漏会明显减少。以下字段可直接作为交接单模板使用。
| 字段 | 填写要求 | 常见遗漏 |
|---|---|---|
| 任务目标与验收标准 | 写清任务要达成什么结果，以及由谁、按什么标准判定完成 | 只写目标不写验收标准，接收方无法判断做到什么程度算完成 |
| 当前状态 | 分已完成、进行中、未开始三类列出具体事项，进行中的注明进度 | 用“基本完成”这类模糊描述，未说明剩余部分 |
| 依赖方与风险 | 列出任务依赖的人、团队或系统，标注已知风险和可能的影响 | 只写依赖名称，未写对接人和当前进展 |
| 待决问题 | 列出尚未有结论的问题、需要谁决策、期望何时有结论 | 把待决问题混在风险里，接收方误以为已有方案 |
| 截止时间与关键里程碑 | 写明最终截止时间和中间必须完成的时间点 | 只写最终截止，遗漏中间评审或提测节点 |
| 文档、账号与权限位置 | 给出文档所在位置、所需账号和权限的申请或移交方式 | 写了文档名但未给路径，权限未实际开通 |
| 下一步建议动作 | 用一至三条写出接收方接手后应先做的事 | 留空，接收方需要重新梳理优先级 |
填写时有两个要求值得强调。第一，状态描述要可核对，例如“接口联调完成 3 个，剩余 2 个待对方环境就绪”，比“进展顺利”有用得多。第二，权限字段要写到可操作的程度，注明接收方是否已具备访问条件；如果权限需要申请审批，把申请入口和预计时长一并写上，避免接收方接手后卡在访问环节。
交接单写完后，交出方应自查一遍：假设自己明天完全无法联系，接收方仅凭这张单子能否推进任务。如果答案是否定的，说明还有信息没有落到纸面。
交接执行步骤：从说明到接收确认
交接单写好只是准备完成，责任真正转移发生在说明与确认的过程中。以下五步按顺序执行，每一步都有明确的完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交交接单并预约说明 | 已填写的交接单 | 交出方把交接单发给接收方和确认人，约定说明时间 | 交接单初稿、说明会时间 | 接收方已收到交接单并确认参会 |
| 2. 逐项讲解与提问 | 交接单、相关文档 | 交出方按字段顺序讲解，接收方随时提问，疑点当场记录 | 疑点清单 | 所有疑点有答复或转为待决问题 |
| 3. 接收方复述 | 疑点清单 | 接收方用自己的话复述任务目标、当前状态、下一步动作和风险 | 复述记录 | 双方对关键事项理解一致，偏差当场纠正 |
| 4. 更新负责人与状态 | 确认后的交接单 | 在任务管理工具中把负责人改为接收方，更新协办人和状态字段 | 更新后的任务记录 | 任务负责人显示为接收方，原负责人转为协办或移出 |
| 5. 确认人审核留痕 | 交接单、复述记录、任务记录 | 确认人核对信息完整性与责任转移情况，记录审核结论 | 审核结论与交接记录 | 确认人给出通过结论，交接记录可追溯 |
第 3 步的复述是整套流程中最容易被省略、也最值得保留的环节。复述不是让接收方重复一遍交接单内容，而是让他说出“我接手后第一件事做什么、卡住时找谁、什么时间点必须交付什么”。交出方从复述中能听出理解偏差，当场纠正的成本远低于交接完成后返工。
第 4 步和第 5 步的顺序不宜颠倒。先在任务记录中完成负责人变更，再由确认人审核，审核对象才是真实的系统状态。如果只在交接单上签字而任务记录仍挂在原负责人名下，后续统计、提醒和考核都会指向错误的人。在任务管理工具中承载这一过程时，负责人字段变更、状态更新和交接记录会自然形成一条可追溯的链路，ONES 的任务管理可用于承载这类负责人变更与过程留痕，具体字段与操作方式以实际系统为准。
角色与交付物：谁在交接中做什么
交接出问题，很多时候不是流程缺失，而是角色边界模糊：交出方以为说明过就算完，接收方以为签了字就有人兜底，确认人以为只是走个形式。把每个角色的职责和产出写清楚，可以减少这类推诿。
| 角色 | 职责 | 交付物 | 边界说明 |
|---|---|---|---|
| 交出方 | 整理交接信息、完成说明、移交文档与权限 | 填写完整的交接单、已开通的访问权限 | 对交接时点的信息真实性负责，不对接收方接手后的执行结果负责 |
| 接收方 | 理解任务、提出疑问、复述确认、承接责任 | 疑点清单、复述记录、确认后的承接表态 | 确认后即成为任务负责人，后续进展由其汇报 |
| 确认人 | 审核交接完整性，判定责任转移是否生效 | 审核结论、交接记录 | 对流程完整性负责，不替代接收方执行任务 |
| 上下游依赖方 | 了解对接人变更，更新沟通与协作对象 | 知会确认或对接人更新记录 | 仅需知会与对接调整，不参与交接审核 |
依赖方知会常被忽略。任务换人后，外部团队仍按原对接人沟通，会出现信息发错人、进度对不上的情况。交出方在交接完成后应主动通知依赖方新的对接人，接收方则确认自己已进入相关沟通渠道。知会范围以任务实际涉及的外部接口为限，不必扩大到整个项目组。
示例：一次跨阶段任务交接的完整过程
以下为演示情景，用于说明字段如何落地，不涉及具体组织与真实人员。
情景设定：某功能模块的开发任务原由工程师 A 负责，因 A 转岗，任务移交给工程师 B，项目经理 C 担任确认人。任务处于开发后期，接口联调尚未完成，且依赖外部团队提供测试环境。
交接单填写示例：
- 任务目标与验收标准：完成模块开发并通过联调测试；验收标准为联调用例全部通过、代码评审通过、测试环境验证无阻断缺陷。
- 当前状态：已完成——核心功能开发、单元测试；进行中——接口联调，5 个接口中完成 3 个；未开始——性能验证。
- 依赖方与风险：依赖外部团队提供测试环境，对接人为对方测试负责人；风险为环境交付时间未确认，可能影响联调进度。
- 待决问题：性能验证的压测方案尚未确定，需项目经理 C 在本周内决策。
- 截止时间与里程碑：最终截止为下月末；中间节点为联调完成（本月第三周）、提测（本月第四周）。
- 文档、账号与权限位置：设计文档与接口文档位于项目文档库对应目录；代码仓库权限已为 B 开通；测试环境账号需向外部团队申请，预计一个工作日。
- 下一步建议动作：先确认测试环境交付时间，再推进剩余 2 个接口联调；同步向 C 确认压测方案。
交接说明与复述记录：A 按字段逐项讲解，B 提出两个疑点——剩余 2 个接口的对方对接人是否变化、压测方案未定时能否先做小范围验证。A 当场答复对接人未变，第二个问题转为待决问题记录。随后 B 复述：接手后第一件事是联系外部团队确认环境交付时间，本周内推动 C 确定压测方案，本月第三周完成联调。C 确认复述内容与交接单一致。
确认与状态更新结果：任务记录中负责人由 A 改为 B，A 转为协办人，状态字段更新为“联调中”；C 审核交接单、复述记录与任务记录后给出通过结论，交接记录归档。A 同步通知外部团队对接人变更。
完成检查：交接是否真正生效
交接做完不等于交接生效。以下清单用于事后核验，任一项未通过即视为交接未完成，需要补做后再确认。
| 检查项 | 核验方式 | 未通过时的补救 |
|---|---|---|
| 责任是否已更新到接收方 | 查看任务记录中的负责人字段 | 立即在系统中变更负责人，并通知相关方 |
| 信息、文档、权限是否可独立获取 | 由接收方在不求助交出方的情况下打开文档、登录系统 | 补齐文档路径，推动权限申请直至开通 |
| 遗留风险与待决问题是否有明确归属 | 逐条核对风险与待决问题的责任人和期望结论时间 | 为无归属项指定责任人，写入任务记录 |
| 接收方能否独立说出下一步动作 | 请接收方口头说明接下来的动作与时间点 | 重新做一次复述对齐，补齐缺失信息 |
| 依赖方是否已知会 | 确认外部对接人已收到变更通知 | 由交出方补发知会，接收方确认已进入沟通渠道 |
其中前三项属于阻断项：责任未更新、关键资料或权限无法独立获取、遗留问题无人认领，任何一项存在都意味着交接没有完成，后续进展无人真正负责。第四、五项虽不直接阻断任务推进，但会在一到两周内演变为沟通错位，建议在交接当周内完成核验。
检查通过后，把交接单、复述记录和审核结论一并归档到任务记录中。归档的价值在于后续追溯：当任务出现延期或质量问题时，可以回看交接时点的状态描述和待决问题，判断问题出在交接遗漏还是执行过程，而不是靠回忆还原当时的情况。
常见问题
交接说明会上接收方提的问题当场答不上来，应该怎么处理？
当场答不上来的问题不要用“回头再说”带过，应转为待决问题写入交接单，并同时写清三件事：由谁负责给出结论、期望何时有结论、在结论出来前接收方按什么方式推进。这样问题不会随着会议结束而消失，接收方接手后也知道该找谁、等到什么时候。
如果待决问题会影响任务的关键路径，确认人在审核时应把它作为交接条件之一，明确结论时间后再判定交接生效。
接收方已经口头答应接手，但任务系统里的负责人还没改，算交接完成吗？
不算。口头答应只说明接收方愿意承接，责任在系统中仍未转移。任务记录里的负责人字段决定了后续的提醒、统计和汇报指向谁，字段不改，延期和问题仍会算到交出方名下，接收方也可能因为没有提醒而漏掉节点。
正确顺序是先完成负责人变更和状态更新，再由确认人审核，审核对象才是真实的系统状态。发现字段未改时，应立即在系统中变更负责人并通知相关方，然后补做审核留痕。
短期休假三五天，也需要走完整的交接单和说明会吗？
通常不需要。影响面小、剩余工作少、没有外部依赖的短期代办，用一条消息说明当前进展、下一步动作和卡住时找谁，再更新任务负责人即可。判断标准是接收方能否仅凭这条记录推进任务，能则简式交接足够。
如果休假期间正好撞上对外交付节点，或任务卡在外部团队的环境、审批上，即使时间短也建议按正式交接处理，至少补齐依赖方对接人和权限信息。
交接完成后原负责人还需要继续跟进吗？
原负责人对交接时点的信息真实性负责，对接收方接手后的执行结果不再负责。交接生效后，原负责人通常转为协办人或移出任务，主要义务是在一段时间内回应接收方关于历史背景的询问。
如果原负责人因离岗完全无法联系，交接单的信息完整度就要按“明天起联系不上”的标准自查，把口头才知道的背景、历史决策原因尽量落到文档里。
跨团队交接时，对方团队的对接人也要参与确认吗？
依赖方参与的是知会与对接调整，不参与交接审核。交出方在交接完成后应主动通知外部团队新的对接人，接收方确认自己已进入相关沟通渠道，知会范围以任务实际涉及的外部接口为限。
如果任务的关键路径依赖外部团队的产出，建议把对方对接人、当前进展和交付时间写进交接单的依赖字段，并在完成检查时核对知会是否到位，避免出现信息仍发给原负责人的情况。
