跨团队任务依赖配置的关键，是把依赖、交接与权限放在同一套规则里设计：依赖关系说明谁等谁，交接规则说明等什么、由谁验收，权限边界说明谁能改动这些约定。本文按“选依赖类型—建依赖关系—定交接规则—划权限—试点验证”的顺序展开，适用于在任务管理工具中落地跨团队协作的团队；ONES 可作为承载任务依赖、状态流转与权限配置的工具之一。
要点总览（TL;DR）
- 跨团队依赖配置要先把依赖类型选对：有明确交付物的交接用完成—开始阻塞型依赖，同步启动用开始—开始，收口环节用完成—完成，只对真实交付物建依赖。
- 配置按六步推进：统一任务粒度与状态口径、识别交接点、建立阻塞型依赖并写清完成条件、配置变更通知、处理循环依赖与超时升级、用一条真实链路验证。
- 交接规则要把交付内容、验收标准、验收人、截止时间固定成字段，完成标志与关闭任务权限分离，由验收人确认后才进入已完成。
- 权限按最小必要原则把改依赖、改状态、关闭任务分开授权，跨团队可见范围按字段开放，权限变更留痕。
- 上线前用检查清单核对依赖覆盖度、循环依赖、交接字段完整性、权限匹配与等待可视化，阻塞项先解决再扩大范围。
先定依赖模型：跨团队任务依赖有哪几种
配置依赖之前，先确认要建的是哪一种关系。依赖类型选错，后续的提醒、权限和验收规则都会跟着错位。跨团队场景中最常用的是完成—开始型依赖，其他类型只在时间上确实需要同步推进时使用。
| 依赖类型 | 含义 | 适用场景 | 配置要点 |
|---|---|---|---|
| 完成—开始（阻塞型） | 前置任务完成后，后置任务才能进入执行状态 | 需求交付研发、研发交付测试、设计稿交付开发等有明确交付物的交接 | 设置完成条件，前置未完成时后置任务保持阻塞状态 |
| 开始—开始 | 前置任务开始后，后置任务方可开始 | 两个团队需要同步启动的联调、并行准备 | 只约束启动时点，不约束完成时点，避免误当成阻塞关系 |
| 完成—完成 | 前置任务完成后，后置任务方可完成 | 发布任务需等待多个团队的收尾工作全部结束 | 用于收口环节，防止单方提前关闭任务 |
跨团队交接点与普通前后置依赖的区别在于责任主体。普通依赖发生在同一团队内部，改期和调整通常由团队负责人决定；跨团队交接涉及两个团队的交付与验收，需要额外记录交付物、验收人和完成标志，否则依赖只是一条线，无法约束实际交接。
依赖数量需要控制。只对真实交付物建依赖，例如一份接口文档、一个可测试的构建版本、一份验收报告；把每个任务都串成一条长链，会让关键路径失真，任何一处延期都会放大成整条链路的阻塞。判断标准是：这条依赖背后是否存在一次需要对方确认的交付，如果没有，用子任务或检查项表达即可。
配置步骤：从任务拆分到依赖上线
依赖配置可以按六步推进，每一步都有明确的输入、动作、输出和完成标志，便于逐项确认后再进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 统一任务粒度与状态口径 | 各团队现有任务清单 | 约定任务拆分到可交付的粒度，整理状态字典（待处理、进行中、待验收、已完成等） | 状态字典与任务粒度规范 | 各团队对同一状态的理解一致，任务粒度可对照 |
| 2. 识别跨团队交接点 | 状态字典、现有流程说明 | 标出每一次跨团队的交付动作，写明前置任务与后置任务 | 交接点清单 | 每个交接点都有明确的前置方与后置方 |
| 3. 建立阻塞型依赖 | 交接点清单 | 在工具中为后置任务添加前置依赖，设置完成条件 | 依赖关系图 | 前置未完成时，后置任务无法进入执行状态 |
| 4. 配置变更通知 | 依赖关系图、相关角色名单 | 设定依赖变更、前置延期时通知哪些人 | 通知规则 | 测试一次变更，相关角色能收到提醒 |
| 5. 设置冲突处理方式 | 依赖关系图 | 排查循环依赖，约定等待超时的升级路径与责任人 | 冲突处理规则 | 循环依赖清零，超时升级有明确接收人 |
| 6. 真实链路验证 | 一条正在进行的跨团队任务 | 按上述规则完整走一遍依赖建立、交接、验收 | 验证记录与问题清单 | 链路可跑通，问题已记录并分派 |
第三步的完成条件需要写具体。例如“接口文档已上传并通过研发负责人确认”比“文档完成”更可核验。第四步的通知对象应覆盖前置任务负责人、后置任务负责人和双方团队管理员，避免只通知到其中一方。第五步的循环依赖排查要在上线前完成，A 等 B、B 等 A 的结构会让两个任务同时卡住，通常需要拆出一个独立的交付任务来打破循环。
在工具层面，ONES Project 支持自定义需求状态与多种属性，可围绕项目计划、工作项和迭代安排协同工作，便于把状态字典和任务粒度规范落到具体工作项上；依赖关系的具体配置方式以实际版本为准。
交接规则：跨团队任务如何定义交付与验收
交接规则的作用是把“我通知你了”变成“交付物已提交、验收人已确认”。每个跨团队交接点都应有一份可填写的交接记录，字段固定、责任到人。
| 字段 | 填写要求 | 责任人 | 状态流转 |
|---|---|---|---|
| 交付内容 | 写明交付物名称、位置或附件，避免只写“已完成” | 前置任务负责人 | 提交后进入待验收 |
| 验收标准 | 可核验的条件，如“覆盖三个核心接口并通过联调” | 前置与验收方共同确认 | 验收标准变更需双方确认 |
| 验收人 | 具体到人，不写团队名称 | 后置团队负责人指定 | 验收人变更需管理员留痕 |
| 截止时间 | 与依赖的完成条件对应 | 双方负责人 | 延期需更新并触发通知 |
完成标志与任务关闭权限应当分离。前置任务负责人提交交付物后，任务进入待验收状态；验收人确认通过，任务才进入已完成。这样“完成”由验收方判定，避免交付方单方关闭任务导致后置团队在不知情的情况下被解除阻塞。
交接被退回时，任务回到进行中状态，责任归属前置任务负责人，退回原因写入交接记录。退回次数和原因可作为后续复盘依据。跨团队等待需要可视化：在任务上显示当前阻塞方、等待开始时间和已等待时长，让双方都能看到“谁在等谁、等了多久”，而不是靠会议追问。
ONES Wiki 支持文档关联任务，并支持插入 ONES Project 的工作项列表，交接记录和验收标准可以放在文档中与任务互相引用，便于验收人对照检查。
权限边界：谁能改依赖、改状态、关任务
权限设计遵循最小必要原则，把改依赖、改状态、关闭任务三类动作分开授权。三类动作混在一个角色里，跨团队约定就容易被执行方单方面改动。
| 角色 | 可执行动作 | 限制条件 |
|---|---|---|
| 任务负责人 | 更新自己任务的状态、提交交付物、发起依赖变更申请 | 不能自行关闭任务，不能删除他人建立的依赖 |
| 依赖发起方 | 新增依赖、申请修改或删除依赖 | 删除依赖需后置团队负责人确认 |
| 验收人 | 确认验收通过、退回交接 | 只能处理分配给自己的验收任务 |
| 团队管理员 | 调整依赖关系、变更状态字典、处理超时升级 | 操作需留痕，跨团队变更通知双方管理员 |
关闭任务的审批条件按任务类型区分：普通内部任务由负责人关闭即可；涉及跨团队交付的任务，需验收人确认后才能关闭。跨团队可见范围按字段开放，交付内容、验收标准、等待时长对协作团队可见，内部估算、人员成本等字段可限制在本团队内。
权限变更本身也要留痕。谁在什么时间调整了依赖、修改了验收人或变更了状态字典，都应记录在案，便于出现争议时回溯。ONES Project 拥有产品、项目、任务多层级权限，可按组织架构、用户组、项目角色灵活分配，适合把上述角色划分落到具体项目和任务上；具体权限项与可分配范围以实际版本和配置为准。
示例：一条跨团队依赖链的完整配置
以下为演示情景，用于说明依赖、交接与权限如何配合，不代表特定团队的真实项目。
场景设定：产品团队提出需求，研发团队开发，测试团队验收。三个团队在同一项目中协作，任务粒度统一为可交付的工作项。
- 产品团队创建“需求说明”任务，负责人为产品经理，完成条件为需求文档通过研发与测试负责人评审。
- 研发团队创建“接口开发”任务，添加完成—开始依赖，前置为“需求说明”；交接字段填写交付内容（接口文档与可测试构建）、验收标准、验收人（测试负责人）、截止时间。
- 测试团队创建“验收测试”任务，添加完成—开始依赖，前置为“接口开发”；验收人确认通过后，“接口开发”才进入已完成。
权限分配：产品经理可更新需求任务状态并提交交付物，不能关闭研发任务；研发负责人可发起依赖变更申请，删除依赖需测试负责人确认；测试负责人拥有验收通过和退回的权限；项目管理员负责处理超时升级并保留操作记录。
异常处理演示：若“需求说明”延期，系统按通知规则提醒研发与测试负责人，后置任务保持阻塞并显示已等待时长，管理员评估是否调整截止时间。若测试退回交接，“接口开发”回到进行中，退回原因写入交接记录，责任归属研发负责人，修复后重新提交验收。整个过程中，依赖关系不因单方操作而解除。
完成检查：依赖配置是否真的支撑了协作
配置完成后，用一张检查清单逐项核对，判断依赖设置是否可用。每项都应有明确负责人和通过标准。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 依赖覆盖度 | 全部真实交接点都有对应依赖，无遗漏 | 项目管理员 |
| 循环依赖 | 依赖关系图中无循环结构 | 项目管理员 |
| 交接字段完整性 | 每个交接任务都填写交付内容、验收标准、验收人、截止时间 | 各任务负责人 |
| 验收人明确性 | 验收人具体到人，无空缺 | 后置团队负责人 |
| 权限匹配 | 角色与可执行动作符合权限矩阵，关闭任务有审批条件 | 项目管理员 |
| 变更留痕 | 依赖与权限变更均有操作记录 | 项目管理员 |
| 等待可视化 | 可查询每个阻塞任务的等待方与等待时长 | 各团队负责人 |
| 试点验证 | 一条真实链路完整跑通，遗留问题已记录并分派 | 试点团队负责人 |
检查中发现的问题按影响分级处理：循环依赖和验收人空缺属于阻塞项，需在上线前解决；通知对象不全、字段填写不规范可在试点期内修正。试点链路的验证结果应形成简短记录，写明跑通了哪些环节、遇到哪些异常、遗留问题由谁跟进，作为后续扩大范围配置的依据。
常见问题
跨团队任务依赖应该建多少条才合适？
只对真实交付物建依赖，例如一份接口文档、一个可测试的构建版本、一份验收报告。判断标准是这条依赖背后是否存在一次需要对方确认的交付；如果只是同一团队内部的先后顺序，用子任务或检查项表达即可。把每个任务都串成长链会让关键路径失真，一处延期就放大成整条链路的阻塞。
前置任务延期了，后置团队怎么及时知道？
在配置依赖时就设定变更通知规则，通知对象覆盖前置任务负责人、后置任务负责人和双方团队管理员，避免只通知到一方。前置延期后，后置任务保持阻塞状态并显示当前阻塞方与已等待时长，双方都能看到“谁在等谁、等了多久”。通知规则上线前应实际触发一次变更验证，确认相关角色能收到提醒。
验收人一直不处理交接，任务会一直卡住吗？
需要提前约定等待超时的升级路径和接收人，通常由团队管理员接手评估：是调整截止时间、更换验收人，还是退回重做。验收人变更要留痕，避免责任不清。等待时长本身也应可查询，作为升级判断和后续复盘的依据。
任务负责人能不能自己关闭跨团队任务？
建议按任务类型区分：普通内部任务由负责人关闭即可；涉及跨团队交付的任务，需验收人确认后才能关闭。这样“完成”由验收方判定，避免交付方单方关闭任务，导致后置团队在不知情的情况下被解除阻塞。关闭任务的审批条件应写入权限矩阵并告知各团队。
配置完成后，怎么判断依赖设置是否真的有效？
用一条正在进行的真实跨团队任务完整走一遍依赖建立、交接、验收流程，并逐项核对：真实交接点是否都有对应依赖、依赖图中是否还有循环结构、交接字段是否填全、验收人是否具体到人、权限是否与角色匹配、变更是否留痕、阻塞任务的等待方与等待时长是否可查询。循环依赖和验收人空缺属于阻塞项，需在上线前解决；通知对象不全、字段填写不规范可在试点期内修正。
