2023 年我接手过一个挺典型的排期事故：两个研发小组，A 组做订单中心，B 组做结算网关，双方都以为自己可以先等对方把接口定义好，结果联调阶段互相等了 11 天。复盘时发现，问题不是没人负责，而是依赖关系从来没有被显性写下来。A 组以为 B 组知道要先出接口文档，B 组以为 A 组会先给字段清单。两个组长在群里都说过“等你们先”，但没有人把这条“等”变成一条任务依赖。
这件事让我重新理解了一个问题：产品经理做任务依赖，真正要管的不是“画一条线”，而是“把一条隐含的顺序约束变成可追踪的约定”。线只是结果，判断才是核心。什么时候该建依赖、建哪种依赖、建完之后谁维护、什么时候该拆掉，这四个问题比“在某个工具里怎么点”重要得多。
这篇内容我会按“判断，建立，维护，复盘”的主线，把任务依赖从 0 到 1 讲清楚。没有工具菜单式教程，也不把依赖类型当背诵题，而是给出一套产品经理可以直接用的判断逻辑和行动清单。
一、先给结论：依赖管理是决策，不是画线
如果你只记住一句话，我希望是这句：任务依赖的本质是顺序约束和风险传导，不是优先级排序。很多新人把“A 要在 B 之前做”和“A 比 B 重要”当成同一件事，这是两个完全不同的维度。顺序约束回答的是“谁必须先发生”，优先级回答的是“资源先给谁”。前者是逻辑问题，后者是资源问题。
1. 依赖关系到底在解决什么问题
一条任务依赖，本质上是在表达一个约束条件：后置任务的开始或完成，取决于前置任务的某个状态。这个状态可能是“已完成”“已开始”“已完成 80%”，也可能是“某个交付物已经产出”。如果这个约束不写下来，团队就会靠记忆和口头沟通来维持顺序，一旦人员变动、需求插入或排期压缩，约束就会失效。
产品经理的价值不在于把依赖图画得多漂亮，而在于提前识别哪些约束是硬的、哪些是软的，以及哪些约束不写出来一定会出事。依赖管理的第一步不是打开工具，而是判断“这条依赖不建立会怎样”。
2. 一条最实用的判断标准
我常用的判断标准很朴素：如果不建这条依赖，是否会导致返工、阻塞或验收失败？如果答案是“会”，那就是硬依赖，必须建；如果答案是“可能会，但可以通过并行和沟通解决”，那是软依赖，可以建但不必卡死；如果答案是“不会，只是我希望它先做”，那就不该建，那是优先级问题。
这条标准帮我砍掉了很多“假依赖”。有些产品经理为了安全感，把任务串成一条长链，结果团队失去了并行空间，排期反而更长。依赖不是越多越安全，过度依赖是一种隐性浪费。
3. 依赖管理的四个动作
我给团队培训时会把依赖管理拆成四个动作，顺序不能反：
- 判断：这条依赖是硬约束还是软偏好，是团队内还是跨团队。
- 建立：选择正确的依赖类型，写清前置交付物、责任人和验收标准。
- 维护：需求变更、人员调整、外部阻塞时，同步更新或废弃依赖。
- 复盘：看延期传导次数、跨团队阻塞时长、依赖清理率，而不是只看“图好不好看”。
很多团队只做第二步，甚至只做“在工具里连线”，前面不判断，后面不维护，依赖图很快就变成一张过期地图。下面这张图对比了依赖密度与团队交付表现的关系，可以帮我们理解“建得越多不一定越好”。
二、真实场景：依赖一乱，排期就崩
抽象地讲依赖很容易变成概念课。我更愿意从真实场景出发，因为产品经理的痛感通常来自具体事故。下面四个场景，是我在过去几年里反复见到的。
1. 跨团队互等：谁都以为对方先动
第一个场景就是开头提到的互等。A 组需要 B 组先提供接口文档，B 组需要 A 组先确认字段清单。双方在周会上都说“下周可以开始”，但没有人把这条依赖写进任何任务系统。到了下周，A 组在等文档，B 组在等清单，双方都觉得自己没有阻塞。
这类问题的根因不是沟通态度，而是跨团队依赖缺少显性载体。同一个团队内，两个人抬头就能问一句；跨团队时，信息在群聊、邮件、会议纪要里散落，没有人负责把“等”变成一条有责任人和截止时间的依赖。
2. 依赖被当成优先级：重要不等于前置
第二个场景更隐蔽。产品经理说“这个功能很重要，先做”，于是在工具里把很多任务设成“必须在前一个完成之后开始”。结果团队发现，重要任务 A 其实并不阻塞 B，B 完全可以并行开发，但依赖关系把它卡住了。
这种误用的代价是排期被拉长，团队还会觉得“我们明明很努力，为什么交付这么慢”。把优先级翻译成依赖，是用顺序约束解决资源问题，工具用错了。
3. 依赖图过期：需求变了，线还在
第三个场景是维护缺失。需求评审后建了一批依赖，两周后需求变更，某个前置任务被砍掉或拆成两个，但依赖关系没有同步更新。后置任务仍然挂着一个不存在的前置，负责人每天看到“被阻塞”，却找不到阻塞源。
我见过一个团队，依赖图上有 40 多条线，其中 12 条指向已经关闭的任务。产品经理每周要花两三个小时手工核对，团队成员逐渐不再信任依赖视图。依赖图一旦失去可信度，就会被弃用，比没有更糟。
4. 循环依赖：A 等 B，B 等 A
第四个场景是循环依赖。A 依赖 B，B 又依赖 A，排期直接死锁。成熟的项目管理工具通常会在保存时校验并拦截，但人工维护的表格、文档或聊天记录里，循环依赖很容易潜伏下来。下面这张图展示了四种典型依赖问题的发生频率和平均修复耗时，我用它来帮助团队判断优先治理哪一类。
三、常见误区拆解：产品经理最容易踩的六个坑
依赖管理做不好，通常不是工具能力不够，而是判断逻辑有偏差。我把最常见的六个误区列出来，每个都给出识别方法和纠正动作。
1. 误区一：依赖越多越安全
有些产品经理把依赖当成保险绳，觉得多连几条线，出问题时就能提前发现。但依赖的本质是约束，约束越多，团队的自由度越低。更麻烦的是，每一条依赖都需要维护成本，需求一变，维护量指数上升。
纠正动作：每条依赖建立前问一句“不建会怎样”。只有会导致返工、阻塞或验收失败的，才升级为硬依赖。
2. 误区二：只会用完成-开始
很多人只知道“前置完成，后置开始”这一种依赖。实际上常见的依赖类型有四种：完成-开始（FS）、开始-开始（SS）、完成-完成（FF）、开始-完成（SF）。FS 最常用，但并不是唯一选择。比如两个任务需要同时启动、各自推进，就适合用 SS；两个任务必须同时结束，适合 FF。
我并不是鼓励大家为了用而用。SF 在实际项目中极少使用，强行套用反而增加理解成本。选依赖类型的标准是“业务约束长什么样”，不是“哪种看起来高级”。
3. 误区三：把依赖和优先级混为一谈
这是新人最常犯的错误。优先级回答“先给谁资源”，依赖回答“谁必须先发生”。一个低优先级任务可能是高优先级任务的前置条件，一个高优先级任务也可能完全不阻塞别人。
纠正动作：在任务字段里把“优先级”和“依赖”分开管理。排期时先看依赖链，再按优先级分配资源，不要用依赖去表达重要性。
4. 误区四：跨团队依赖只靠口头对齐
跨团队依赖只靠会议纪要或群聊确认，短期看效率很高，长期看风险极大。人员一换、需求一插，口头约定就失效了。更关键的是，口头约定没有“被阻塞”的显性状态，产品经理无法在仪表盘上看到风险。
纠正动作：跨团队依赖必须有接口人、有交付物、有截止时间，并且写进双方都能看到的任务系统。接口人不是“传话的人”，而是对交付结果负责的人。
5. 误区五：建完不维护
依赖关系是有生命周期的。需求变更、架构调整、人员流动、外部供应商延期，都会让依赖图失效。如果没有人定期 review，依赖图会逐渐变成“历史遗迹”。
纠正动作：把依赖 review 放进迭代节奏，比如每两周一次，或者在需求变更评审时同步检查受影响的依赖链条。
6. 误区六：工具里画了线就算管了
工具能帮你记录和可视化，但不能替你判断。依赖管理真正的难点在于：判断哪些约束是硬的、哪些可以并行、哪些需要升级为跨团队风险。工具解决“看得见”，产品经理解决“判断得对”。
下面这张图把六个误区的影响面做了对比，维度包括排期延误、返工成本和团队信任损耗，方便你判断先改哪个。
四、专业判断逻辑：什么该建、什么不该建
误区讲完，接下来给一套可以直接用的判断逻辑。我的经验是，产品经理不需要成为项目管理专家，但必须掌握三个判断：硬约束还是软偏好、依赖类型选哪种、跨团队依赖怎么落。
1. 硬约束还是软偏好
硬约束是“不满足就会出错”的约束，比如接口未定义就无法联调、数据库表未建好就无法写入。软偏好是“希望先做，但并行也不致命”的约束，比如文案先定稿再开发，实际上开发可以先用占位符。
我把常见场景整理成一张对照表：
| 场景 | 约束性质 | 建议动作 |
|---|---|---|
| 接口文档未产出，联调无法开始 | 硬约束 | 建立 FS 依赖，明确接口人和交付时间 |
| UI 稿未定稿，前端可以先搭框架 | 软偏好 | 不建硬依赖，用并行任务加检查点 |
| 数据库表结构未评审，后端无法写核心逻辑 | 硬约束 | 建立 FS 依赖，评审通过作为前置条件 |
| 运营文案未确认，开发可先用占位内容 | 软偏好 | 不建依赖，在上线检查清单中校验 |
| 第三方支付渠道未开通，无法验收支付流程 | 硬约束 | 建立跨团队依赖，升级为外部风险跟踪 |
判断的关键不是“有没有关系”，而是“不满足会不会阻塞”。硬约束必须显性化，软偏好可以用检查点代替依赖。
2. 四种依赖类型的适用场景
四种依赖类型不是理论摆设，它们对应不同的业务约束。下面这张表是我给团队做培训时常用的版本：
| 类型 | 含义 | 典型场景 | 使用频率 |
|---|---|---|---|
| FS（完成-开始） | 前置完成后，后置才能开始 | 接口文档完成后再联调 | 最高 |
| SS（开始-开始） | 前置开始后，后置才能开始 | 两个模块需要同时启动联调 | 中等 |
| FF（完成-完成） | 前置完成后，后置才能完成 | 测试报告完成前，上线检查不能关闭 | 中等 |
| SF（开始-完成） | 前置开始后，后置才能完成 | 新系统启动后，旧系统才能下线 | 极低 |
我的建议是：默认用 FS，只有在业务约束明确要求“同时开始”或“同时结束”时才考虑 SS 和 FF，SF 尽量少用。依赖类型越简单，团队理解成本越低。
3. 关键路径上的依赖优先
不是所有依赖都同等重要。关键路径上的依赖一旦延期，会直接推迟整个交付时间；非关键路径上的依赖有一定缓冲，可以适当放宽。产品经理在排期时，应该优先识别关键路径，把最强的跟踪力度放在关键路径的依赖上。
识别方法不复杂：从项目开始到结束，找出最长的那条依赖链，这就是关键路径。注意，关键路径不是“任务最多的路径”，而是“耗时最长、没有缓冲的路径”。关键路径会随着排期变化而移动，所以需要定期重新计算。
4. 跨团队依赖的接口人机制
跨团队依赖的核心不是“多开会”，而是“明确接口人”。接口人需要具备三个条件：能对交付物负责、能协调本团队资源、能对延期风险提前预警。没有接口人的跨团队依赖，基本等于没有依赖。
我通常会在依赖记录里写清四件事：
- 前置交付物：具体是什么，不是“接口好了”这种模糊表达。
- 验收标准：达到什么程度算完成，避免扯皮。
- 接口人：姓名和角色，不是团队名。
- 截止时间：带缓冲的承诺时间，不是“尽快”。
5. 工具落地：字段、视图、自动校验
判断清楚之后，再落到工具。这里我建议把依赖当成任务的一个字段来管理，而不是画在图上就完事。字段里至少包含依赖类型、前置任务、接口人、交付物描述、当前状态。视图上要能按“被阻塞任务”和“阻塞他人任务”筛选，这样产品经理每天早上花五分钟就能看到风险。
自动校验也很重要，尤其是循环依赖。下面是一段伪代码，展示依赖保存时的基本校验逻辑，你可以把它交给研发同学在工具里实现：
function validateDependency(taskA, taskB, type) {
// 1. 不能依赖自己
if (taskA.id === taskB.id) {
return { ok: false, reason: "任务不能依赖自身" };
}
// 2. 检测循环依赖
if (hasPath(taskB, taskA)) {
return { ok: false, reason: "存在循环依赖，请调整任务顺序" };
}
// 3. 校验依赖类型是否合法
const allowedTypes = ["FS", "SS", "FF", "SF"];
if (!allowedTypes.includes(type)) {
return { ok: false, reason: "不支持的依赖类型" };
}
// 4. 校验跨团队依赖是否填写接口人
if (taskA.team !== taskB.team && !taskB.owner) {
return { ok: false, reason: "跨团队依赖必须指定接口人" };
}
return { ok: true };
}
这段代码的重点不是语法，而是把管理规则固化到工具里。能自动拦截的错误，不要靠人反复提醒。下面这张图展示了四种依赖类型在实际项目中的使用占比，可以帮助你判断团队是否过度依赖某一种类型。
五、具体案例与数据观察：中大型团队怎么把依赖管起来
前面讲的是通用逻辑，这一部分我用一个更贴近中大型组织的案例来说明。案例对象是一家 200 人左右的研发组织，产品、研发、测试、运维分布在四个团队，项目周期从三个月拉长到六个月后，跨团队依赖问题集中爆发。
1. 200 人组织的依赖复杂度
小团队的依赖靠沟通就能解决，因为每个人都知道别人在做什么。但当组织超过 100 人，信息开始分层，依赖链条会跨越产品、前端、后端、测试、运维多个角色。一个需求从评审到上线，平均经过 14 个任务节点，其中 5 到 7 条是跨团队依赖。
这个阶段最大的变化是：产品经理不再能靠记忆管理依赖，必须靠机制。机制包括统一的依赖字段、固定的 review 节奏、跨团队接口人名单，以及一个所有团队都能看到的依赖视图。
2. 从 Jira 迁移：依赖数据如何保留
这家组织原本使用 Jira 管理项目，依赖关系以“阻塞”链接的形式存在。迁移到 PingCode 时，他们最担心的是历史依赖数据丢失，导致正在进行的项目排期断裂。PingCode 支持 Jira 平滑迁移，可以把原有关联关系映射为任务依赖，保留前置任务、后置任务和依赖类型。
迁移过程中他们做了三件事：第一，先清洗历史依赖，把指向已关闭任务的无效链接清理掉；第二，把跨团队依赖补上接口人字段；第三，在迁移后第一周每天检查一次依赖视图，确认没有断链。迁移完成后，有效依赖从 380 条降到 214 条，减少了 43.7%，但跨团队阻塞的识别率反而提高了。
3. 私有化部署下的权限与审计
这家组织对数据安全要求较高，最终选择了 PingCode 的私有化部署。私有化部署带来的一个额外好处是：依赖变更可以纳入审计日志。谁在什么时候修改了哪条依赖、为什么修改，都有记录可查。
对于中大型企业来说，这一点很关键。跨团队依赖一旦出现争议，比如“我明明没有承诺这个时间”，审计日志可以提供事实依据。依赖管理不仅是排期工具，也是协作契约。
4. 三个月后的指标变化
迁移并运行三个月后，他们统计了几项指标：跨团队阻塞平均时长从 4.6 天降到 1.8 天；延期传导次数从每月 9 次降到每月 3 次；依赖清理率从不足 30% 提升到 82%；产品经理每周花在依赖核对上的时间从 6.5 小时降到 2 小时。
这些数字不是工具自动带来的，而是“判断逻辑 + 工具字段 + review 节奏”共同作用的结果。下面这张图对比了迁移前后的关键指标变化。
另外，他们还统计了依赖类型分布和阻塞来源。跨团队依赖占总依赖的 46%，其中第三方接口和外部供应商占跨团队阻塞的 38%。这说明跨团队依赖不只是内部协调问题，外部依赖需要单独升级为风险管理。
六、不同情况下的行动建议
依赖管理没有一刀切的做法。团队规模、项目类型、工具成熟度不同，行动重点也不同。下面按四种常见情况给出建议。
1. 10 人以下小团队：轻量记录，重沟通
小团队的优势是信息透明，劣势是没有人专门维护流程。我的建议是不要上复杂的依赖图，用一个共享任务列表加“阻塞”标记就够了。每条跨人依赖写清楚“谁等谁、等什么、什么时候要”，每天站会过一遍。
关键动作：
- 只记录真正会导致阻塞的依赖，不要把所有任务串起来。
- 站会上优先看“被阻塞任务”，而不是逐条汇报进度。
- 依赖变更当场改，不要留到周末统一整理。
2. 30 到 100 人团队：建立字段和节奏
这个阶段开始出现跨团队协作，口头沟通仍然有效，但需要机制兜底。建议在任务系统里建立依赖字段，每周做一次依赖 review，重点看跨团队依赖和关键路径依赖。
关键动作：
- 把依赖类型、前置任务、接口人、交付物设为必填字段。
- 每周一次 30 分钟的依赖 review，只处理有风险的依赖。
- 需求变更时，同步检查受影响的依赖链，避免依赖图过期。
3. 100 人以上中大型组织：机制优先，工具固化
超过 100 人后，依赖管理的复杂度会显著上升。这个阶段需要统一工具、统一字段、统一 review 节奏，并且把规则固化到系统里。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，在这类场景下比较适用。
关键动作：
- 建立跨团队接口人名单，每条跨团队依赖必须落到具体的人。
- 依赖 review 进入迭代节奏，每两周一次，输出风险清单。
- 用工具自动校验循环依赖和缺失接口人，减少人工提醒。
- 对第三方和外部供应商依赖单独建立风险台账。
4. 外部依赖：单独升级，不要混在内部任务里
外部依赖的特点是可控性差。第三方接口、供应商交付、资质审批，都不完全受团队控制。我的建议是把外部依赖单独标记，设置更长的缓冲时间，并准备备选方案。
关键动作：
- 外部依赖单独建任务，不要挂在内部任务下当子任务。
- 设置两个时间点：承诺时间和最晚可接受时间。
- 提前识别替代方案，避免单点依赖。
下面这张图对比了四类团队在依赖管理上的配置差异，可以作为你制定团队规范的参考。
七、不同情况下的取舍：依赖管理没有完美解
依赖管理的本质是在控制风险和保持效率之间做取舍。下面三个取舍，是产品经理最常遇到的。
1. 粒度取舍：细粒度可控，但维护成本高
依赖粒度越细，风险越早暴露，但维护成本也越高。把每个子任务都连上依赖，产品经理会陷入无休止的核对。我的建议是：按交付物建依赖，不按动作建依赖。“接口文档完成”是一个交付物，“写接口文档第三章”是一个动作，后者不值得单独建依赖。
2. 刚性取舍：硬依赖保证正确，软依赖保留并行
硬依赖会让排期更确定，但也会减少并行空间。软依赖保留灵活性，但需要更强的沟通和检查点。取舍标准是：错误代价高就刚性，错误代价低就软性。支付、权限、数据一致性相关依赖通常要刚性；文案、样式、非核心流程可以用检查点代替。
3. 自动化取舍：工具能兜底，但不能代替判断
自动化能校验循环依赖、提醒延期、生成依赖视图，但无法判断“这条依赖该不该建”。产品经理的价值恰恰在判断上。我的建议是：把规则性工作交给工具，把判断性工作留给自己。工具越自动，产品经理越要把时间花在跨团队对齐和风险预判上。
下面这张图用取舍矩阵的形式，展示了三个维度上的选择倾向和对应后果。
八、总结：依赖管理的本质是预期管理
回到开头那个等了 11 天的场景。如果当时有一条显性的依赖记录，写明“B 组提供接口文档”是“A 组开始联调”的前置条件，并且指定了接口人和截止时间，这 11 天大概率可以避免。问题不在于团队不努力，而在于没有人把隐含的顺序约束变成可追踪的约定。
我在这篇文章里想传递的独特观点是：任务依赖不是画线技术，而是产品经理的决策工具。它帮你识别哪些顺序不能乱、哪些风险会传导、哪些团队需要提前对齐。依赖图只是这些判断的可视化结果，不是目的。
如果你只带走一个行动，我希望是这个：下一次建依赖前，先问“不建这条依赖会怎样”。如果不会导致返工、阻塞或验收失败，就不要建。把省下来的时间用在跨团队对齐和关键路径跟踪上，收益会更高。
下一步，你可以做三件事。第一，把当前项目里的依赖导出来，逐条检查是否指向有效任务，清理过期依赖。第二，给所有跨团队依赖补上接口人和交付物描述。第三，约定一个固定的依赖 review 节奏，哪怕每周只花 30 分钟。坚持一个月，你会看到延期传导次数和跨团队等待时间的变化。
依赖管理的终点，不是一张完美的依赖图，而是一支对预期有共识的团队。图会过期，共识不会。
常见问题解答（FAQ）
1. 任务依赖关系到底该怎么建？什么情况下才真的需要拉一条依赖？
我刚接手一个跨端项目，研发说前端要等后端接口，我下意识就在排期表里把两条任务连了线。结果后面发现很多任务其实可以并行推进，被我连成一条链之后整体工期反而变长了。我就很疑惑：依赖关系到底应该按什么标准来建，是不是所有有先后顺序的任务都得连上？
先判断这条依赖是硬约束还是软偏好，再决定建不建。硬约束指不满足就无法开始，比如接口未联调完就无法做端到端验收、合同未签署就无法付款；软偏好指只是你希望按这个顺序做，比如希望先出视觉稿再做前端，但先做静态结构并不违规。硬约束必须建，软偏好优先靠沟通和迭代顺序解决，不要进依赖图。
判断方法是问三个问题：不满足它，对方是否完全无法开工？如果顺序反过来，返工成本是否显著？这个约束来自外部合同、法规或物理限制，还是来自内部习惯？只有前两问为是、且第三问指向外部因素时才建硬依赖。默认原则是最小依赖：能并行的任务保持并行，只有真正的前置产出被阻塞时才连线。
经验上，一个迭代内单个团队的任务依赖控制在总任务数的20%到30%比较健康，超过50%通常意味着排期被过度串行化，一旦上游延期就会连锁拖慢全局。另外要区分依赖和优先级，先做A再做B属于顺序约束，A比B重要属于优先级，两者不能混用，否则一旦优先级调整你就得重画整张依赖图。
2. 四种依赖类型FS、SS、FF、SF在真实项目里分别对应什么场景？我该怎么选？
看资料时经常看到FS、SS、FF、SF这套术语，我当时记住了，但一到实际排期就懵，不知道哪条连线该选哪种。有一次我把两个我以为是FS的任务连成SS，结果里程碑算出来比实际早了三天，被研发当场指出。所以我特别想知道：这四种类型到底在什么情况下用，怎么避免选错？
先记住默认值是FS（完成-开始），绝大多数前后置关系都用它，指的是前置任务完成后后置任务才能开始，比如开发完成才能测试、设计定稿才能切图。SS（开始-开始）用于两个任务需要同时启动但时长不同的场景，比如服务端开发和客户端联调需要同一时间开始，但服务端要早三天完成；
用SS时务必加上滞后量（Lag）或提前量（Lead），否则工具会认为两条任务完全同步。FF（完成-完成）用于两个任务必须同时收尾的场景，比如用户手册的更新必须和版本发布同一天完成，常用在文档、培训、合规类任务上。
SF（开始-完成）现实中极少使用，典型场景是交接班，只有下一班人到位，上一班才能离岗，项目管理中基本可以不用。选错类型最直接的后果是关键路径计算错误，因为不同类型的日期推算公式完全不同。
落地建议是：画依赖前先写下'前一条任务的什么状态，解锁了后一条任务的什么动作'，如果答案是完成后才能开始就用FS，必须同时开始就用SS，必须同时结束就用FF。
另外要注意工具支持差异：不同项目管理工具对四种类型的支持范围不一样，有的平台只支持FS和SS，选型或建图前先确认你的工具实际支持哪些类型，避免建完发现计算逻辑和预期不一致。
3. 跨团队依赖怎么管？接口人机制具体该怎么做才不会变成只开会不落地？
我们项目涉及三个团队，前端、后端和数据。每周的依赖对齐会我都开，会上大家都说没问题，会后照样互相等，延期了才发现根本没人跟进。我试过建共享文档，但维护两天就没人看了。我特别想知道：跨团队依赖到底靠什么机制能真正落地，接口人是不是只是个名义上的角色？
跨团队依赖靠的是机制而不是沟通意愿，核心是三件事。第一，给每条跨团队依赖指定一个唯一的接口人，不是对接群而是点名到人，接口人对这条依赖的交付时间和变更负责，并在依赖看板上署名。
第二，把依赖写进双方的迭代承诺而不是放在共享文档里，具体做法是上游团队在自己的迭代计划中显式列出'为X团队交付Y'的任务，下游团队在自己的计划中列出对应的等待项，两边都存在工具里，任何一方变更都会触发通知而不是靠人记得去文档里改。
第三，设立固定的依赖巡检节奏，建议每周一次、时长不超过30分钟，只过三类信息：本周到期的依赖是否按计划、下周新增的依赖有哪些、已经失效的依赖有哪些可以关闭。会议只做决策不做汇报，每条依赖必须当场明确状态和责任人。
判断机制是否有效的观察指标有三个：跨团队依赖平均阻塞时长（建议控制在3个工作日以内）、依赖变更提前通知率（提前3天以上通知应占多数）、因依赖导致的里程碑延期次数。如果连续两个迭代这三项都没改善，说明接口人是挂名的，需要把依赖的完成情况纳入接口人所在团队的迭代目标，而不是只靠个人责任心。
4. 依赖关系建完之后怎么维护？什么时候该把已经没用的依赖删掉？
我们项目的排期表是三个月前建的，里面密密麻麻全是连线。最近我整理时发现有些任务早都完成了，有些需求已经砍了，但依赖还在那儿挂着，关键路径算出来明显不对。我担心直接删会漏掉什么，可不删又一直影响判断。依赖关系到底多久 review 一次，废弃的标准是什么？
依赖图是会过期的资产，必须像清理待办一样定期清理，否则它会持续污染关键路径和延期预测。建议的维护节奏是：每个迭代结束时做一次增量清理，每个季度做一次全量 review。
增量清理只处理三类依赖：前置任务已完成的后置关联中已经不再需要等待的、任务被取消或需求被砍但依赖线还留着的、被重新排期导致时间逻辑已经不成立的。全量 review 的检查清单包括：每条依赖是否还能说清前置的什么产出解锁了后置的什么动作；
是否存在循环依赖，即A依赖B同时B依赖A，这类必须在工具里直接拦截，因为它会让排期算法死锁；是否存在大量滞后量为零的紧耦合依赖，导致任何微小延误都会立刻传导。判断一条依赖该不该删的标准很简单：把这条线去掉，后置任务是否还能按现在的排期正常开工？如果能，说明它已经不再构成约束，应当删除或降级为备注。
另外要注意一个容易被忽略的情况：删除依赖不等于删除沟通义务，跨团队约定还在的话，应该把它转化为检查项或验收标准，而不是继续挂在依赖图上让算法误判。
复盘时建议看两个数据，一是延期传导次数，即一次上游延期平均引发多少条下游任务跟着改期，二是被清理掉的无效依赖占比，如果每次 review 都能清出不少，说明建立时的准入标准需要收紧。
核心关键词
文章包含AI辅助创作：依赖关系怎么做？产品经理最佳实践：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/385636
读者评论
文章把依赖管理从工具操作中抽离出来，强调判断优先于画线，这一点很有共鸣。实际工作中确实有很多依赖是没必要的，过度串联反而拖慢并行度。不过跨团队依赖的显性化往往还涉及组织权限问题，不是产品经理单方面能推动的。
四种依赖类型的区分讲得清楚，但最让我有收获的是‘依赖不等于优先级’这个判断。以前经常把重要任务前置当成依赖来管，结果卡住了本可以并行的任务。建议再补充一下软依赖在敏捷迭代中怎么轻量记录，避免走回口头约定。
依赖图过期和循环依赖这两个坑太真实了。我们团队的工具里确实有指向已关闭任务的线，每周核对耗时不少。文章提出的定期review和依赖清理率指标有可操作性，但如果能给出一个具体的依赖健康度检查清单会更实用。