任务交接的关键，是把一项在办任务的责任、上下文和后续动作完整转移到接手人身上，并留下可核验的记录。交接范围不清、接手人没有确认，是交接后任务停滞的常见原因。本文按“交什么、怎么交、谁来做、如何确认、怎么留痕”的顺序，给出一套可直接套用的字段清单、四步流程和完成检查表，交接记录可以随任务一并留存于任务管理工具中。
要点总览（TL;DR）
- 任务交接的本质是责任转移：接手人能在没有原负责人持续指导的情况下独立推进任务，交接才算成立。
- 交接记录按八个字段组织：任务目标与验收标准、当前进度、未完成事项与下一步、依赖与协作方、风险与已知问题、权限与资料位置、截止时间与关键节点、双方角色。
- 交接按四步推进：确定范围与接手人、填写交接记录、接手人复述确认、在任务系统中切换负责人与状态。
- 原负责人、接手人、主管三方各有交付物，主管的批准是责任变更生效的依据。
- 交接记录应随任务留存，负责人变更、状态流转与评论记录形成可追溯链路，便于后续查阅和复盘。
任务交接要转移哪些内容
任务交接的本质是责任转移，信息告知只是其中一部分。原负责人把任务交出去之后，接手人应当能够独立判断下一步做什么、遇到问题找谁、什么时间交付什么结果。判断一次交接是否成立，看接手人能否在没有原负责人持续指导的情况下推进任务，而不看交接文档写了多少页。
为了让交接内容可核对，建议按固定字段组织交接记录。字段固定下来，交接双方就有了共同的检查口径，也方便后续查阅。
| 交接字段 | 需要写清的内容 | 常见遗漏 |
|---|---|---|
| 任务目标与验收标准 | 这项任务要达成什么结果，由谁验收，验收依据是什么 | 只写“完成需求开发”，没有验收口径 |
| 当前进度与已完成部分 | 已完成的工作、产出物位置、当前所处环节 | 产出物散落在个人目录，接手人找不到 |
| 未完成事项与下一步 | 剩余工作项、建议的推进顺序、最近一个动作 | 只列事项，不说明先后和优先级 |
| 依赖与协作方 | 依赖的内部团队、外部供应商、接口人及其当前状态 | 依赖已延期但未在交接中说明 |
| 风险与已知问题 | 已暴露的风险、待决策事项、历史遗留问题及影响 | 把风险留在原负责人脑中，未书面化 |
| 权限与资料位置 | 系统账号权限、文档库路径、数据来源、关键联系人 | 权限未开通，接手人无法访问资料 |
| 截止时间与关键节点 | 最终交付时间、评审或上线等关键节点 | 只写最终截止日，遗漏中间评审节点 |
| 接手人与原负责人角色 | 接手人姓名与职责范围，原负责人在交接后的支持方式与期限 | 原负责人退出后无人可问，或长期不退出 |
这八个字段构成一份最小可用的交接记录。任务复杂度高时可以在字段下补充附件和链接，字段本身不建议删减，尤其是风险、权限和角色三项，它们决定了接手人能否真正接住任务。
按四步完成一次任务交接
交接可以按四个步骤推进，每一步都有明确的输入、动作、输出和完成标志。四步走完，责任才算完成切换。
第一步：确定交接范围与接手人
输入是原负责人手上的任务清单。动作是逐项判断哪些任务需要交出、哪些可以收尾关闭，并为每项待交接任务指定接手人。输出是一份交接任务列表，包含任务名称、接手人和计划交接时间。完成标志是每项待交接任务都有明确接手人，且接手人已知悉交接安排。这一步由原负责人发起，主管或任务发起人确认接手人是否具备承接条件。
第二步：填写交接记录
输入是任务现状，包括进度、产出物、依赖和风险。动作是按上一节的八个字段逐项填写，把口头信息转为书面记录，并附上资料位置和权限说明。输出是一份结构化的交接文档。完成标志是八个字段均有内容，没有留空或写“待补充”。填写过程中发现的信息缺口，应当在这一步补齐，而不是留给接手人自行摸索。
第三步：当面或书面确认
输入是已填写的交接记录。动作是由接手人复述任务目标、当前进度、下一步动作和主要风险，原负责人对偏差进行纠正；接手人提出的疑问逐条记录并给出答复。输出是一份确认记录，包含复述要点、疑问清单及答复。完成标志是所有疑问都有明确答复，接手人明确表示可以承接。复述环节是确认接手人真正理解的手段，走过场的“收到”不构成确认。
第四步：责任切换
输入是确认记录。动作是在任务管理系统中变更任务负责人，更新任务状态，原负责人转为支持角色并约定支持期限。输出是系统内的责任变更记录。完成标志是任务负责人已显示为接手人，原负责人的支持方式和期限已写明，相关协作方已知悉负责人变更。至此，交接流程结束，后续推进由接手人负责。
交接中各方角色与交付物
交接涉及三方：原负责人、接手人，以及主管或任务发起人。三方职责不同，交付物也不同，缺任何一方的动作，交接都容易出现断点。
| 角色 | 主要职责 | 交付物 | 完成时点 |
|---|---|---|---|
| 原负责人 | 整理任务现状，如实暴露风险，移交资料与权限，答复接手人疑问 | 交接记录、资料与权限清单、疑问答复 | 确认环节开始前完成记录填写，确认环节结束前完成答复 |
| 接手人 | 核对交接信息，提出疑问，复述目标与下一步，承接后续执行 | 复述要点、疑问清单、确认意见 | 确认环节结束时给出明确承接意见 |
| 主管或任务发起人 | 确认接手人具备承接条件，裁定交接中的争议，批准责任变更 | 接手人确认意见、责任变更批准 | 责任切换前完成批准 |
三方职责中，主管的角色容易被忽略。当接手人能力或时间不足、交接双方对任务范围存在分歧时，需要由主管裁定，否则交接可能停在“已告知但未承接”的状态。主管的批准也是责任变更生效的依据，尤其在任务涉及对外承诺或关键节点时。
示例：一个需求开发任务的交接
以下为演示情景。某需求开发任务原由A负责，因人员调整转交给B，任务处于开发中、尚未提测阶段。
按字段填写的交接记录如下：
- 任务目标与验收标准：完成订单导出功能开发，支持按时间范围导出，由产品经理C验收，验收依据为需求文档中的功能清单。
- 当前进度与已完成部分：接口开发完成约七成，导出模板已定稿，代码在feature/export分支，需求文档与接口文档位于项目文档库对应目录。
- 未完成事项与下一步：剩余分页导出逻辑和大数据量导出测试；建议先完成分页逻辑，再联调测试环境。
- 依赖与协作方：依赖测试环境的数据准备，接口人为测试负责人D；导出模板的最终样式待设计确认。
- 风险与已知问题：大数据量导出存在超时风险，尚未确定分页方案；设计确认可能延后，影响提测时间。
- 权限与资料位置：代码仓库权限已开通，测试环境账号需B自行申请，申请入口在团队文档中。
- 截止时间与关键节点：本周五完成开发自测，下周二提测，下周五上线评审。
- 接手人与原负责人角色：接手人B负责后续开发与提测；A在两周内提供技术支持，每周可安排一次同步。
确认环节中，B复述：目标是完成订单导出功能并在下周二提测，当前接口开发七成，下一步先做分页导出逻辑，主要风险是大数据量超时和设计确认延后，测试环境账号需要自己申请。A补充说明分页方案已有两个备选，会在同步中给出建议。B提出测试数据量级是否明确，A答复参照需求文档中的上限值，并记录为待确认事项。双方确认后，任务负责人在系统中变更为B，任务状态更新为“开发中”，A在任务评论中注明支持期限，协作方C和D收到负责人变更通知。
交接完成检查清单
交接是否真正完成，可以逐项核对以下检查项。任何一项不满足，都应视为交接未完成，需要补齐后再切换责任。
- 八个交接字段均有实质内容，没有留空或“待补充”。
- 接手人已完成复述，复述内容与原负责人说明一致，偏差已纠正。
- 接手人提出的疑问全部有答复，未决事项已明确责任人和解决时间。
- 接手人已能访问所需系统权限和资料，实际打开验证过，而非仅口头告知已开通。
- 任务管理系统中负责人已变更为接手人，任务状态与实际情况一致。
- 原负责人的支持方式与期限已写明，协作方已知悉负责人变更。
- 遗留风险均有明确承接人，没有“无人负责”的风险项。
出现以下情况时应当阻断交接：关键字段缺失且短期内无法补齐；接手人明确表示无法承接或复述出现重大偏差；权限未开通导致接手人无法开展下一步工作。此时应由主管介入，调整接手人或推迟责任切换时间，避免出现名义上已交接、实际上无人推进的状态。
把交接记录放进任务管理流程
交接记录如果只存在于聊天记录或个人文档中，后续查阅和责任追溯都会变得困难。更稳妥的做法是把交接记录作为任务的一部分随任务留存，让交接信息与任务本身处在同一处。
具体衔接方式有三点。其一，交接记录以文档或任务描述的形式挂在任务下，接手人推进任务时可以直接查阅，不必再向原负责人索要背景。其二，负责人变更、状态流转和评论记录形成一条可追溯的链路，谁在什么时间接手、任务处于什么状态、支持期限到何时，都能在任务历史中查到。其三，交接中的待确认事项可以作为任务下的子项或评论跟进，避免确认环节的疑问在交接结束后被遗忘。
在ONES中，这类管理动作可以依托任务本身完成：变更任务负责人实现责任切换，通过状态流转反映任务所处阶段，用评论记录确认过程和支持约定，用文档承载交接记录与资料位置。交接信息与任务同处一处，后续查阅时不需要跨系统拼凑。对于交接频繁的团队，可以把交接字段整理为固定模板，在每次交接时复用，减少字段遗漏。
把交接纳入日常任务管理后，交接就不再是一次性的口头沟通，而是任务生命周期中的一个可查节点。团队在复盘延期任务时，也能据此判断问题出在交接环节还是执行环节。
常见问题
交接时原负责人还需要继续跟进多久？
支持期限没有统一标准，取决于任务的复杂度和接手人的熟悉程度。常见做法是在交接记录中写明支持方式与期限，例如两周内提供技术咨询、每周安排一次同步。期限的设定原则是覆盖接手人独立推进第一个关键节点的周期：关键节点过去、接手人已能自行处理问题，支持即可结束。期限过长会让责任边界模糊，过短则可能让接手人在遇到遗留问题时无处可问。
接手人一直不确认，交接卡住了怎么办？
先区分原因。如果是信息缺口导致接手人无法判断，应由原负责人补齐字段后再次确认；如果是接手人时间或能力不足，属于承接条件问题，需要主管介入，调整接手人或推迟责任切换时间。在接手人明确表示可以承接之前，任务负责人不应变更，否则会出现名义上已交接、实际上无人推进的状态。主管的裁定和批准是这一环节的兜底机制。
口头交接很清楚，还需要写交接记录吗？
建议保留书面记录。口头沟通适合快速对齐，但任务周期一长，当时的说明容易被遗忘或记错，后续查阅时也无从追溯。书面记录不必很长，按八个字段逐项写清即可，重点是风险、权限和双方角色这三项，它们直接决定接手人能否独立推进。记录挂在任务下，接手人推进时可以直接查阅，不必反复向原负责人确认背景。
任务只完成了一小部分，也要按完整流程交接吗？
流程可以简化，字段不宜删减。任务刚开始时，进度和已完成部分的内容较少，但目标与验收标准、依赖、风险、截止时间仍然需要写清，否则接手人无法判断方向。可以省去的是繁琐的附件整理和多次同步，把确认环节压缩为一次复述即可。判断标准仍是接手人能否独立推进下一步，与任务完成了多少无关。
交接后发现关键信息遗漏，责任怎么算？
交接完成后，任务责任已转移到接手人，但遗漏信息的补充仍应由原负责人配合完成，尤其是在支持期限内。更稳妥的做法是在交接检查时把字段完整性作为阻断条件：关键字段缺失且短期内无法补齐的，不进行责任切换。如果遗漏在交接后才暴露，接手人应及时提出，原负责人补充说明，必要时由主管确认是否影响交付节点。复盘时可将此类问题归入交接环节而非执行环节。
