跨团队任务交接时，依赖关系最容易出现两种问题：前置任务说不清交付什么，后置团队不知道什么时候能开始；一旦卡住，双方又找不到该找谁确认。这张任务依赖关系表把“谁依赖谁、依赖什么、什么时候需要、卡住时找谁”集中到一行记录里，模板包含依赖编号、前后置任务、依赖类型、期望就绪时间、状态、双方负责人、交付物、验收标准和确认时间等字段，可直接复制到表格工具中使用。
要点总览（TL;DR）
- 跨团队交接用一张依赖关系表记录“谁依赖谁、依赖什么、什么时候需要、卡住找谁”，每个依赖关系占一行。
- 核心字段包括依赖编号、前置任务、后置任务、依赖类型、期望就绪时间、当前状态、双方负责人、交付物、验收标准和确认时间。
- 跨团队交接建议按完整必填组合填写，交付物和验收标准写得可检查，能减少交接后的返工和争议。
- 模板可按团队规模与交接频率增减字段，状态更新绑定已有例会节奏，依赖变更时保留原记录而非直接删除。
可复制空白模板：任务依赖关系表
下面是一张空白依赖关系表，表头已按跨团队交接场景设置完整。使用时把表格复制到 Excel、在线表格或项目文档中，每个依赖关系占一行；同一对任务存在多种依赖时拆成多行记录，便于分别跟踪状态和确认时间。
| 依赖编号 | 前置任务 | 后置任务 | 依赖类型 | 期望就绪时间 | 当前状态 | 阻塞原因 | 前置方负责人 | 后置方负责人 | 交付物 | 验收标准 | 确认时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队使用在线表格，可以把“依赖类型”“当前状态”两列设置为下拉选项，减少填写口径不一致。依赖类型常用取值包括“完成—开始”“完成—完成”“开始—开始”；当前状态常用取值包括“待确认”“进行中”“已就绪”“已阻塞”“已取消”。这些取值不是固定标准，团队按实际交接方式统一即可。
字段说明：每个字段记录什么、怎么填
字段说明与上面的表头一一对应。填写时把握一个原则：让没有参加交接沟通的人，也能通过这一行判断依赖是否成立、当前进行到哪一步、下一步该找谁。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 依赖编号 | 这条依赖关系的唯一标识 | 建议用“项目缩写-序号”形式，如“支付-D01”，便于在沟通和会议中直接引用 |
| 前置任务 | 被依赖的一方需要完成的任务 | 写任务名称并附任务编号（如有），名称要能对应到具体工作项，避免只写“接口开发”这类笼统描述 |
| 后置任务 | 依赖前置任务才能推进的任务 | 同样写任务名称和编号；一个后置任务依赖多个前置任务时，拆成多行分别记录 |
| 依赖类型 | 前后置任务之间的约束方式 | 按团队约定填写，如“完成—开始”表示前置完成后后置才能开始；类型要能解释为什么后置任务必须等待 |
| 期望就绪时间 | 后置方希望前置交付物可用的时间 | 写具体日期，必要时精确到时间；这个时间由后置方提出、双方确认，不单方面填写 |
| 当前状态 | 依赖关系当前所处的阶段 | 从团队统一的状态取值中选择，每次状态变化时更新，并同步给双方负责人 |
| 阻塞原因 | 依赖无法按期望时间就绪的具体原因 | 状态为“已阻塞”时必填，写清卡在哪个环节、需要什么支持；状态正常时留空 |
| 前置方负责人 | 负责交付前置任务的人 | 写到具体人名，不写部门或岗位统称；该人对交付物和就绪时间负责 |
| 后置方负责人 | 接收交付物并推进后置任务的人 | 写到具体人名；该人负责验收和确认，发现交付物不满足标准时及时反馈 |
| 交付物 | 前置方需要交出的具体成果 | 写可检查的对象，如“接口文档 v1.2”“测试环境账号清单”，避免写“相关资料”这类无法验收的描述 |
| 验收标准 | 后置方判断交付物可用的条件 | 写可核验的条件，如“接口联调通过”“文档覆盖全部字段并有示例”；标准在交接前确认，避免交付后反复返工 |
| 确认时间 | 双方对依赖内容达成一致的时间 | 记录双方确认交付物、就绪时间和验收标准的时间；后续变更时保留原确认时间并追加变更记录 |
| 备注 | 补充信息 | 记录沟通渠道、关联文档位置、特殊约束等；内容多时指向具体文档，不在此列堆叠长文 |
这张表聚焦工作项层面的依赖安排。项目整体里程碑如何排布、人员容量是否冲突，属于另外的管理动作，不在本表字段范围内；依赖表只回答“这一项交接是否清楚、是否就绪”。
必填与选填：哪些字段不能空
必填字段的判断标准是：缺失后，交接双方无法独立判断依赖是否成立或下一步该做什么。跨团队交接涉及两个不同团队，信息不对称更明显，必填范围应比团队内部依赖更严格。
| 类别 | 字段 | 理由与适用情形 |
|---|---|---|
| 必填 | 依赖编号 | 没有编号，依赖无法在会议、消息和文档中被准确引用，讨论容易指向不同对象 |
| 必填 | 前置任务、后置任务 | 缺少任一端，就无法确定依赖发生在哪两个工作项之间 |
| 必填 | 依赖类型 | 决定后置任务何时可以启动，缺失会导致双方对“能不能开始”理解不一致 |
| 必填 | 期望就绪时间 | 没有时间约束，依赖无法进入排期，也无法判断是否延误 |
| 必填 | 当前状态 | 状态是日常跟踪的入口，缺失后只能靠逐个询问了解进展 |
| 必填 | 前置方负责人、后置方负责人 | 跨团队场景下双方各需一个明确联系人，卡住时才知道找谁 |
| 必填 | 交付物 | 不写清交付什么，后置方无法判断收到的东西是否完整 |
| 必填 | 验收标准 | 跨团队缺少共同上下文，验收标准是减少返工的关键依据 |
| 必填 | 确认时间 | 记录双方何时达成一致，后续出现分歧时可回溯 |
| 条件必填 | 阻塞原因 | 状态为“已阻塞”时必填；正常推进时可留空 |
| 选填 | 备注 | 用于补充沟通渠道、关联文档位置等；信息简单时可留空 |
跨团队交接的最低必填组合可以概括为：编号、前后置任务、依赖类型、期望就绪时间、状态、双方负责人、交付物、验收标准、确认时间。团队内部依赖频率低、双方熟悉彼此工作时，可以适当精简备注和部分说明性内容；一旦涉及跨团队、跨部门或外部供应商，建议按完整必填组合填写。必填字段缺失带来的风险很具体：没有交付物和验收标准，交接容易变成“先给一版再说”；没有双方负责人，阻塞时消息在群里转几圈仍无人处理；没有确认时间，后续对就绪时间产生分歧时缺少依据。
填写示例：一次跨团队任务交接的完整记录
以下为演示情景，不对应任何具体组织。某产品团队的后置任务“订单页改版联调”需要等待平台团队完成“订单查询接口升级”，双方通过依赖表记录这次交接。
| 依赖编号 | 前置任务 | 后置任务 | 依赖类型 | 期望就绪时间 | 当前状态 | 阻塞原因 | 前置方负责人 | 后置方负责人 | 交付物 | 验收标准 | 确认时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 订单-D01 | 订单查询接口升级（平台-218） | 订单页改版联调（产品-305） | 完成—开始 | 2025-06-18 | 进行中 | 平台团队 张明 | 产品团队 李倩 | 接口文档 v2.0、联调环境地址与测试账号 | 订单页所需 6 个查询场景在联调环境返回正确；文档含请求参数与错误码示例 | 2025-06-05 | 联调环境由平台团队维护，问题在双方对接群同步 | |
| 订单-D02 | 订单页改版联调（产品-305） | 支付回归测试（测试-412） | 完成—开始 | 2025-06-25 | 待确认 | 产品团队 李倩 | 测试团队 王涛 | 联调通过的订单页版本及变更说明 | 订单主流程与退款流程在测试环境可正常走通 | 2025-06-06 | 回归范围以变更说明列出的影响面为准 |
第一行体现了一次典型的跨团队依赖：前置方是平台团队，后置方是产品团队，交付物和验收标准写得足够具体，后置方收到接口文档后可以自行核对是否满足 6 个查询场景。第二行把同一交付链条继续向后传递，产品团队从接收方变成前置方，测试团队成为后置方，确认时间记录在依赖建立之初，而不是等到交付当天才补。
如果第一行在 6 月 16 日发现联调环境未准备好，应把状态改为“已阻塞”，在阻塞原因中写“联调环境部署延迟，预计 6 月 19 日可用”，并同步给李倩调整后置任务安排。这样一行记录同时承担了进度跟踪和交接沟通两个作用。
调整与维护方法：让依赖表随任务推进保持可用
模板拿到后不必原样照搬。字段增减应围绕交接频率和信息缺口来决定：团队规模小、双方长期协作、交接内容稳定时，可以合并“前置方负责人”和“后置方负责人”为单一对接人列，或省略备注；跨团队交接频繁、涉及多个供应商或外部合作方时，建议增加“升级联系人”“依赖建立日期”“变更记录”等字段，把异常上报路径也写进表里。
维护节奏上，建议把依赖表的更新和团队已有的例会或交接节点绑定，而不是单独增加一套流程。可行的做法包括：
- 每日或每次站会前，由各依赖的双方负责人更新“当前状态”和“阻塞原因”，会上只讨论状态为“已阻塞”或临近期望就绪时间的记录。
- 每周核对一次“期望就绪时间”和“确认时间”，对时间已变更但未重新确认的记录，要求双方补充确认。
- 依赖交付完成时，把状态改为“已就绪”，并由后置方负责人按验收标准确认后，再启动后置任务。
依赖发生变更或取消时，不建议直接删除原行。更稳妥的方式是把状态改为“已取消”或新增一行记录变更后的依赖，并在备注中注明原依赖编号和变更原因。这样后续复盘时能看清依赖链条如何演变，也避免已经通知过的相关方因记录消失而误判。
当依赖表从个人表格迁移到团队协作工具时，记录方式和状态流转需要保持衔接。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应；依赖表可以作为项目文档存放，并通过页面模板库一键创建制式化模板，减少每次新建时字段不一致的情况。文档中还可以嵌入任务进度和报表，让依赖记录与工作项进展保持在同一处查看。依赖表本身解决的是交接信息是否清楚，工具承载的是这些信息如何被持续更新和共享，两者配合使用，跨团队交接的确认和跟踪会更顺畅。
常见问题
依赖关系表里的“依赖类型”怎么选，团队内部需要统一到什么程度？
依赖类型用来解释后置任务为什么必须等待前置任务。常见取值有“完成—开始”“完成—完成”“开始—开始”，团队按实际约束选择即可。统一程度以“双方看同一行能得出相同结论”为准：至少约定每种类型的含义和适用场景，并在表格中设置为下拉选项，避免同一约束被写成不同说法。如果一次交接同时存在多种约束，拆成多行分别记录，比在一行里混合描述更容易跟踪。
前置任务延期，后置方应该改期望就绪时间还是新增一条记录？
两种做法对应不同情况。如果只是时间调整、依赖内容不变，直接更新“期望就绪时间”，并在备注中写明原时间和调整原因，同时要求双方重新确认。如果依赖的交付物、验收标准或范围也发生变化，建议新增一行记录新的依赖，把原行状态改为“已取消”并注明关联编号。这样既保留了变更轨迹，也避免已经按原时间安排工作的相关方误判。
团队规模小、交接不频繁，这张表可以精简到什么程度？
可以合并双方负责人为单一对接人列，省略备注，保留依赖编号、前后置任务、依赖类型、期望就绪时间、状态、交付物和验收标准。精简的前提是双方长期协作、对彼此工作方式熟悉，且交付物容易判断是否可用。一旦交接涉及跨部门、外部供应商或验收标准存在分歧，建议恢复完整字段，尤其是双方负责人和确认时间，这两项在出现争议时最直接有用。
依赖表放在文档里维护，和放到项目协作工具里维护，分别适合什么情况？
文档适合依赖数量少、参与方固定、以说明和确认为主的场景，复制模板即可开始填写。依赖数量多、状态需要频繁更新、要与任务进展对照查看时，放到协作工具里更省力。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，并提供页面模板库一键创建制式化模板，文档中还可嵌入任务进度和报表。团队可以先用文档模板统一字段口径，再把稳定使用的表迁移到项目文档中持续维护。
依赖表需要和项目整体进度计划合并成一张表吗？
不必合并。依赖表回答的是工作项之间“这一项交接是否清楚、是否就绪”，项目整体里程碑排布和人员容量冲突属于另外的管理动作。两张表可以互相引用：进度计划中的关键节点对应到依赖表的期望就绪时间，依赖表出现阻塞时反馈给进度管理调整安排。保持分工能让依赖表聚焦交接信息，不会因为塞入过多排期和资源字段而难以维护。
