去年 Q3，我接手过一个 27 人研发团队的效能复盘。他们用的是某项目管理工具，依赖关系配置得整整齐齐，每个任务下面都能看到清晰的前置任务链路。但那个季度，他们的版本交付准时率只有 41%。我花了两天时间把他们的任务依赖图导出、逐条比对，发现了一个让我意外的结论：导致排期崩塌的不是依赖没设，恰恰是依赖设得太多、太满、太理所当然。
这篇文章不讲"什么是前置任务"这种任何人打开工具帮助文档就能查到的东西。我要讲的是研发团队在设置任务依赖时最容易踩的坑，以及一个反常识的判断：前置任务依赖设错了，比完全不设更危险，因为它给了团队一种"排期很严谨"的错觉，掩盖了真正的阻塞风险。
一、核心结论：依赖管理的本质不是管控，是减少等待浪费
先把结论放在前面，后面再用案例和数据展开论证。
第一，前置任务依赖只在三种情况下值得设置：强交付约束、跨团队外部依赖、合规或质量门禁。 其余场景下，用协作提醒或并行拆解比设依赖更有效。
第二，每条强依赖都必须有唯一责任人，否则依赖就只是一条装饰性的连线。 我在复盘那个 27 人团队时发现，他们 68% 的跨团队依赖没有指定唯一责任人。
第三，依赖变更的通知链比依赖本身更重要。 前置任务延期时，如果下游负责人不能自动收到通知，这条依赖的价值等于零。
第四，工具选型时，重点看的不是"能不能设依赖"，而是"依赖变更后能不能自动通知、能不能看到关键路径、能不能做依赖健康度分析"。
这四条结论背后，是我在多个研发团队观察到的同一个规律：依赖管理的目标不是增加管控点，而是缩短等待时间。 如果一条依赖没有减少等待，反而增加了协调成本，那它就是在制造浪费。
二、背景与真实场景：一个排期崩塌的连锁链
1. 从一条前端等接口的任务说起
那个 27 人团队的项目结构是这样的：后端先提供 API 接口文档，前端基于接口文档开发页面，测试等前端页面完成后再做联调测试，最后运维等测试通过后部署上线。
看起来非常合理，对吧？但问题出在：后端 API 文档的完成时间被设定为 Sprint 第 5 天，而前端页面开发被设为 API 文档的前置后置任务，必须在第 5 天之后才能开始。实际上，前端完全可以在第 1 天就基于接口约定做 Mock 数据开发。
一条本可以并行的任务，因为依赖设置不当，变成了串行等待。
更严重的是，后端 API 文档在第 5 天没有完成，延期到了第 8 天。按工具里的依赖链，前端开发从第 8 天才开始，测试从第 15 天才开始，上线从第 20 天才开始。整条链路因为一个节点的 3 天延期，最终导致版本延期 9 天。
2. 依赖链越长，末端延期放大效应越明显
我专门追踪过这个团队的依赖链长度与延期放大倍数之间的关系。当依赖链长度为 2-3 个任务时，前置延期 1 天，末端的实际延期大约是 1.2 天。当依赖链长度为 4-6 个任务时，前置延期 1 天，末端延期会放大到 2.5 天左右。当依赖链超过 7 个任务时，前置延期 1 天，末端延期可能超过 4 天。
原因是每次任务交接都需要沟通、确认、切换上下文，这些隐性成本在长依赖链上会层层累积。
3. 团队当时的状态：工具很规范，协作很混乱
这个团队在工具里维护了完整的依赖关系，每次 Sprint Planning 都会花 1.5 小时讨论任务依赖。但站会上没有人打开依赖视图，没有人检查关键路径是否变化，前置任务延期后下游负责人往往是通过群聊才知道的。
工具里设了依赖，站会没人看，这是最隐蔽也最致命的坑。 它让团队产生一种"我们做了依赖管理"的错觉，但依赖关系从未真正进入日常决策循环。
三、拆解常见误区：研发团队最常踩的 5 个坑
1. 坑一：所有任务都设前置，关键路径无限拉长
症状： 打开项目视图，几乎每个任务都有前置任务，任务之间像锁链一样环环相扣。Sprint 里 80% 的任务在第一天无法启动，因为都在等前置任务。
原因： 团队把"有先后逻辑"等同于"必须设依赖"。但实际上，很多任务只是逻辑上有先后关系，执行上完全可以并行或提前准备。
解法： 用"交付物是否必须等待"来过滤依赖。如果下游任务的启动不依赖前置任务的最终交付物，就不设强依赖。比如前端开发不依赖后端 API 文档的最终版，只需要接口约定，那就不该设强依赖。
2. 坑二：前置任务变更后，下游负责人毫不知情
症状： 前置任务延期了，但下游负责人是在站会上被问到才发现的。或者前置任务提前完成了，但下游没有及时启动，白白浪费了时间窗口。
原因： 依赖关系只存在于工具里，没有和通知机制打通。依赖变更没有触发任何提醒，下游负责人不会主动去检查别人任务的进度。
解法： 设置依赖变更的自动通知规则。前置任务的预计完成时间变更、状态变更、负责人变更，都应自动通知所有下游任务负责人。这不是"锦上添花"的功能，而是依赖管理能否落地的关键。
3. 坑三：把"协作"当成"依赖"，导致排期僵化
症状： 两个任务之间只需要定期同步进度，却被设成了强依赖。结果一方不动，另一方只能干等。
原因： 团队没有区分"强依赖"和"弱依赖"。强依赖是必须等待交付物才能开始，弱依赖是需要同步但可以并行推进。
解法： 在工具中用不同类型的链接区分强依赖和弱依赖。强依赖用阻塞链接，弱依赖用关联链接。站会上只重点检查强依赖，弱依赖做常规同步即可。
4. 坑四：跨团队依赖没有唯一责任人
症状： 依赖了另一个团队的任务，但对方团队没有明确谁负责这个交付物。出了问题找不到人，催进度不知道催谁。
原因： 跨团队依赖往往以"团队"为单位设置，而不是以"个人"为单位。但团队不会交付，个人才会交付。
解法： 每条跨团队依赖必须指定唯一责任人，而且这个责任人要出现在下游团队的依赖视图里。没有唯一责任人的依赖，应该被视为未确认依赖，不能进入 Sprint 排期。
5. 坑五：工具里设了依赖，但站会没人看
症状： 依赖关系在 Sprint Planning 时讨论得很充分，但进入执行后，站会只过任务状态，不过依赖风险。前置任务延期了，但站会没有触发任何预警。
原因： 依赖管理没有嵌入日常站会流程。站会看的是任务板，不是依赖视图。依赖关系变成了"计划阶段的产物"，而不是"执行阶段的工具"。
解法： 站会固定增加一个环节：检查关键路径上的强依赖状态。只看三个问题：前置任务是否按计划推进？下游任务是否已准备好启动？有没有新的阻塞风险？
四、专业判断逻辑：前置任务依赖的决策框架
1. 判断要不要设依赖的 4 个问题
每次准备设置一条前置任务依赖时，我会让团队先回答四个问题。四个问题全部答"是"，才值得设强依赖。
- 下游任务的启动是否必须等待前置任务的最终交付物？ 如果只是需要接口约定、设计稿初稿或环境准备，就不需要等最终交付物。
- 前置任务延期是否会导致下游任务无法启动？ 如果下游可以先做 Mock、先写测试用例、先准备环境，就不构成强依赖。
- 这条依赖是否在关键路径上？ 如果不在关键路径上，设成弱依赖或提醒即可。
- 这条依赖是否有明确的唯一责任人？ 如果没有，先解决责任人问题，再设依赖。
2. 强依赖必须满足的 3 个条件
即使四个问题的答案都是"是"，我还会要求强依赖必须同时满足以下三个条件：
- 交付物可验证： 前置任务的完成标准是明确的、可验证的，不是"差不多完成了"。
- 时间窗口可承诺： 前置任务的负责人对完成时间有明确承诺，而不是"尽量"。
- 变更可通知： 前置任务的时间或状态变更能自动通知到下游负责人。
三个条件缺一个，这条依赖就应该降级为弱依赖或普通提醒。不满足条件的强依赖，只是在制造虚假的确定性。
3. 依赖变更时的通知链设计
依赖变更的通知链应该覆盖三个层面：
第一层是下游任务负责人。 前置任务变更后，第一时间通知下游负责人，让他们重新评估启动时间和排期。
第二层是项目经理或 Scrum Master。 他们需要判断这次变更是否影响关键路径，是否需要调整 Sprint 目标。
第三层是相关方。 如果变更影响到版本发布或跨团队协作，需要同步给相关方。
在 PingCode 中，这个通知链可以通过自动化规则配置实现。前置任务的预计完成时间变更后，系统可以自动触发通知给下游任务负责人，同时更新关键路径视图。这是我在评估项目管理工具时非常看重的一个能力。
4. 关键路径膨胀的预警信号
当出现以下信号时，说明关键路径可能正在膨胀，需要立即检查依赖设置：
- Sprint 第一天可启动任务占比低于 40%；
- 平均依赖链长度超过 5 个任务；
- 站会上超过 3 个任务因为等待前置任务而无法推进；
- 同一 Sprint 内出现 2 次以上依赖变更且未触发通知。
五、具体案例与数据观察：PingCode 在依赖管理上的实践
1. 一个中大型研发团队的依赖治理过程
我参与过一个 120 人规模的研发组织的依赖治理项目，他们当时正在从 Jira 迁移到 PingCode。这个组织有 8 个 Scrum 团队，跨团队依赖非常频繁，迁移前的版本交付准时率大约在 55% 左右。
迁移前，他们在 Jira 中使用的是阻塞链接来表示依赖。问题在于，阻塞链接只记录了依赖关系，没有和通知机制、关键路径视图打通。跨团队依赖的变更往往通过邮件和群聊传递，信息延迟严重。
迁移到 PingCode 后，他们重点做了三件事：
- 区分强依赖和弱依赖。 只对必须等待交付物的任务设置强依赖，其余用关联链接。结果强依赖数量从平均每个 Sprint 23 条降到 9 条。
- 配置依赖变更自动化规则。 前置任务的预计完成时间变更后，自动通知下游任务负责人和项目经理。
- 站会固定检查关键路径。 每个团队的站会固定花 5 分钟检查关键路径上的强依赖状态。
治理后的第一个完整季度，他们的版本交付准时率从 55% 提升到 74%。更重要的是，Sprint 第一天可启动任务占比从 38% 提升到 69%，团队不再陷入"第一天都在等"的状态。
2. PingCode 在依赖管理上的关键能力
在这个项目中，PingCode 的几个能力对依赖治理帮助很大。
第一是依赖类型的区分。 PingCode 支持设置不同类型的任务链接，团队可以清晰区分强依赖和弱依赖。这比所有依赖都用同一种链接表示要清晰得多。
第二是自动化规则。 前置任务的状态变更、时间变更可以触发自动通知，通知范围可以配置到下游任务负责人、项目经理或指定角色。这解决了"变更后下游不知情"的核心痛点。
第三是关键路径视图。 PingCode 支持在项目视图中查看关键路径，团队在站会上可以直接打开这个视图检查依赖状态，而不需要手动梳理。
第四是 Jira 平滑迁移能力。 这个组织从 Jira 迁移时，通过 PingCode 的迁移工具保留了历史任务数据和依赖关系，迁移过程中没有出现依赖丢失的问题。对于考虑国产替代的中大型研发组织来说，这一点非常关键。
第五是私有化部署支持。 这个组织有数据合规要求，PingCode 支持私有化部署，满足了他们的安全审查要求。这也是很多中大型企业在选型时的硬性条件。
3. 不同工具的依赖管理能力对比
我整理过主流研发管理工具在依赖管理上的能力差异。这里用中性描述对比，帮助选型时做判断。
| 能力维度 | Jira | PingCode | 某项目管理平台 | 某项目管理工具 |
|---|---|---|---|---|
| 依赖类型区分 | 支持阻塞链接和关联链接 | 支持多种任务链接类型 | 支持基础依赖设置 | 支持基础依赖设置 |
| 依赖变更自动通知 | 需通过插件或自动化规则配置 | 内置自动化规则，配置灵活 | 部分支持 | 部分支持 |
| 关键路径视图 | 需插件支持 | 内置关键路径视图 | 部分版本支持 | 有限支持 |
| 跨团队依赖管理 | 支持，配置较复杂 | 支持，跨项目依赖视图清晰 | 基础支持 | 基础支持 |
| 私有化部署 | 支持，成本较高 | 支持，国产化适配好 | 部分支持 | 有限支持 |
| Jira 迁移能力 | ， | 支持平滑迁移，保留依赖关系 | 部分支持 | 有限支持 |
| 适用团队规模 | 中大型团队 | 中大型企业及 100 人以上组织 | 中小型团队 | 中小型团队 |
这张表不是说某个工具一定更好，而是说不同工具对依赖的建模方式不同，选型时重点看"依赖变更能否自动通知""能否看到关键路径""能否做依赖健康度分析"这三个能力。 如果团队规模在 100 人以上，跨团队依赖频繁，建议优先考虑支持私有化部署、有成熟 Jira 迁移路径、自动化规则灵活的工具。
六、不同情况下的行动建议
1. 5-15 人小团队：先做减法，再做自动化
小团队的优势是沟通成本低，劣势是每个人都在多任务并行。我的建议是：
- 只对跨团队依赖和外部依赖设置强依赖，团队内部任务尽量用协作提醒；
- 站会上固定花 2 分钟检查强依赖状态；
- 不要追求依赖图的完整性，追求关键路径的清晰性。
小团队不需要复杂的依赖管理工具，但需要明确的依赖责任人。
2. 15-50 人团队：建立依赖分级和站会检查机制
这个规模是依赖问题开始显现的临界点。建议：
- 明确区分强依赖和弱依赖，并在工具中用不同类型链接表示；
- 配置依赖变更的自动通知，至少覆盖下游任务负责人；
- 站会固定检查关键路径，每个 Sprint 做一次依赖健康度回顾。
这个阶段重点是让依赖管理进入日常循环，而不是停留在计划阶段。
3. 50-100 人团队：跨团队依赖需要专门治理
这个规模跨团队依赖会成为主要阻塞源。建议：
- 每条跨团队依赖必须有唯一责任人，且责任人要出现在下游团队的依赖视图里；
- 建立跨团队依赖的周度对齐机制，而不是等到站会才发现问题；
- 用工具的关键路径视图监控跨团队依赖的累积风险。
这个阶段可以考虑引入支持跨项目依赖视图和自动化通知的项目管理平台。
4. 100 人以上组织：依赖管理需要平台化和数据化
这个规模依赖管理已经不是单个团队的问题，而是组织级效能问题。建议：
- 统一依赖管理规范，明确强依赖的设置标准和责任人规则；
- 用平台化工具统一管理跨团队依赖，支持私有化部署和数据合规；
- 建立依赖健康度指标，定期做组织级复盘；
- 如果正在考虑从 Jira 迁移，选择支持平滑迁移、保留依赖关系的国产替代方案。
PingCode 在这个规模段有比较明显的适配性，它主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移。如果团队正在做国产替代选型，可以把依赖管理能力作为重点评估项。
七、不同情况下的取舍
1. 工具能力 vs 团队习惯：先改习惯，再上工具
很多团队在依赖管理出问题后，第一反应是换工具。但我的观察是：如果团队没有依赖分级意识和站会检查习惯，换什么工具都一样。
正确的顺序是先在现有工具里建立依赖分级和站会检查机制，验证有效后再考虑工具升级。工具解决的是效率和自动化问题，不是意识和习惯问题。
2. 依赖管控 vs 团队自主：管控越细，僵化越快
依赖管理有一个微妙的平衡：管控太松，阻塞风险不可见；管控太细，排期僵化，团队失去自主调整空间。
我的判断标准是：只管控关键路径上的强依赖，其余依赖交给团队自主协调。 项目经理的精力应该花在关键路径上，而不是每条依赖都过问。
3. 自动化通知 vs 信息过载：通知要精准，不要泛滥
自动通知很好用，但配置不当会造成信息过载。如果每条依赖变更都通知所有人，团队很快会忽略通知。
建议只对强依赖的关键变更配置自动通知，通知范围限定在下游任务负责人和项目经理。弱依赖的变更用周报汇总即可。
4. 依赖完整性 vs 排期灵活性：不是所有依赖都要画出来
有些团队追求依赖图的完整性，恨不得把所有任务关系都画出来。但依赖图的价值在于识别关键路径和阻塞风险，不在于完整性。
我宁可要一张只有 8 条强依赖但关键路径清晰的图，也不要一张有 30 条依赖但分不清主次的图。
5. 国产替代 vs 现有工具：迁移成本和依赖数据保留是关键
如果团队正在考虑从 Jira 迁移到国产工具，依赖数据的保留是重点评估项。迁移过程中如果依赖关系丢失，治理成果会大打折扣。
PingCode 支持 Jira 平滑迁移，能够保留历史任务数据和依赖关系。对于有国产替代需求的中大型组织，这一点值得重点验证。但迁移决策不应该只看工具功能，还要评估团队的迁移成本和适应周期。
八、从明天站会开始做的 3 件事
1. 审查当前 Sprint 的依赖关系，标记强依赖和弱依赖
打开当前 Sprint 的任务列表，逐条检查依赖关系。问自己：这条依赖是否必须等待最终交付物？下游任务是否可以提前启动？
把必须等待的标为强依赖，其余标为弱依赖。你会发现问题：很多你以为的强依赖，其实只是弱依赖。
2. 为每条强依赖指定唯一责任人
逐条检查强依赖，确认每条依赖都有唯一责任人。责任人必须是个人，不能是团队或角色。
如果某条依赖找不到唯一责任人，说明这条依赖还没有真正被确认。要么找到责任人，要么把它从 Sprint 中移除。
3. 设置依赖变更的自动通知规则
在项目管理工具中配置自动化规则：前置任务的状态变更、预计完成时间变更，自动通知下游任务负责人。
如果当前工具不支持自动化通知，退而求其次：在站会上固定检查关键路径上的强依赖状态，手动同步变更。但手动方式不可规模化，团队规模扩大后必须升级到自动化。
站会依赖检查清单（5 分钟版）：
关键路径上的强依赖，前置任务是否按计划推进？
是 → 继续
否 → 下游任务是否需要调整启动时间？
今天是否有任务因为等待前置任务而阻塞？
有 → 阻塞任务是什么？责任人是谁？预计何时解除？
无 → 继续
过去 24 小时是否有依赖变更未同步？
有 → 立即同步给下游负责人
无 → 结束
这份清单可以直接复制到站会模板里，坚持执行两周，你会明显感觉到依赖风险从"事后救火"变成"事前预警"。
九、结语：依赖管理的本质是减少等待浪费
回到开头那个 27 人团队的案例。他们的核心问题不是不会设依赖，而是把依赖当成了管控工具，而不是减少等待的工具。
前置任务依赖管理的目标，是让团队清楚知道"我在等什么""谁在等我""等待是否可以被消除"。 如果一条依赖没有减少等待，反而增加了协调成本，它就应该被重新审视。
我见过太多团队在依赖管理上走向两个极端：要么完全不设依赖，阻塞风险不可见；要么设得太满，排期僵化。真正有效的依赖管理，是在两者之间找到平衡：只管控关键路径上的强依赖，只对必须等待的交付物设依赖，只让有唯一责任人的依赖进入排期。
如果你现在就想行动，建议从明天站会开始，做三件事：审查当前 Sprint 的强依赖、为每条强依赖指定唯一责任人、配置依赖变更的自动通知。坚持两周，你会看到首日可启动任务占比明显提升，站会从"过状态"变成"管风险"。
如果你正在做工具选型或国产替代评估，建议把依赖管理能力作为重点评估项，特别是依赖变更自动通知、关键路径视图、跨团队依赖管理和 Jira 迁移能力。对于 100 人以上的中大型研发组织，PingCode 在这些维度上有比较完整的支持，可以作为选型对比的参考之一。
依赖管理的终点，不是画出一张完美的依赖图，而是让团队把等待时间降到最低。这件事，工具能帮上忙，但真正起决定作用的，是团队对依赖的判断逻辑和站会上的那 5 分钟检查。
常见问题解答（FAQ）
1. 研发任务到底要不要设前置依赖，怎么判断哪些必须设、哪些不该设？
我们团队十来个人，之前排期全靠口头对齐，结果经常出现前后端互相等的情况。后来有人说干脆所有任务都串起来，但我又担心这样排期会变得特别僵，改一个任务全链路都得跟着改。到底有没有一个靠谱的判断标准？
核心判断标准是看"不设依赖会不会产生返工或返工成本"。强依赖只在三种情况下才必须设：一是物理上无法并行，比如测试必须等开发提测、联调必须等接口就绪；二是后置任务的输入物完全来自前置任务的产出，没有替代方案；三是前置任务一旦变更，后置任务必须重做。
反过来，如果两个任务只是"建议按顺序做"但可以并行、或者可以先用 Mock 数据开工，就不要设强依赖，改用里程碑对齐或每日站会口头同步即可。实操建议：每个 Sprint 规划时先列出所有任务，逐条问"如果前置任务延期三天，后置任务能不能先动"，答案是不能的才设为强依赖，其余全部标为弱依赖或不设依赖。
这样关键路径不会被无意义的链接拉长，排期也不会一动全动。
2. 前置任务延期了，下游负责人却没收到通知，这种情况怎么从机制上避免？
我们用的是某项目管理工具，任务之间的依赖关系都设了，但上周一个后端接口任务卡了四天，前端和测试完全不知道，等发现的时候整个迭代都废了。依赖是设了，但没人主动去看，站会也没人提这个事。这种信息断层到底该怎么补？
关键是把"依赖变更通知"从人工查看变成系统自动推送。具体做三件事：第一，在工具里开启依赖变更的自动通知规则，当前置任务的状态变为"阻塞""延期"或"重新打开"时，自动 @ 所有下游任务的负责人和项目经理；第二，在每日站会上固定加一个"依赖健康检查"环节，只看红色预警的依赖项，不超过三分钟；
第三，为每条强依赖指定唯一的"依赖责任人"，通常是前置任务的负责人，由他负责在预计延期超过半天时主动同步下游。如果工具不支持自动通知，退而求其次的做法是在迭代看板上加一列"被阻塞任务"，每天站会由项目经理逐条确认状态。核心原则是：依赖的信息不能靠"谁想起来谁去看"，必须有明确的触发条件和推送对象。
3. 跨团队的前置依赖没有唯一责任人，扯皮的时候怎么定责？
我们是中台团队，经常要依赖另一个业务线先交付接口，但对接的人今天一个明天一个，出了问题两边都说不清是谁的责任。前置任务挂在对方团队名下，可对方负责人说不知道这事，这种情况怎么破？
跨团队依赖最大的坑就是"任务在对方的看板上，但责任没有落到具体的人头上"。解法是在建立跨团队依赖时强制补齐三个字段：唯一对接人姓名、承诺交付时间、以及变更时的同步责任人。具体做法是：发起依赖的一方在自己的项目管理工具中创建一条外部依赖任务，指定对方的唯一对接人作为"依赖负责人"；
双方在迭代规划会上口头确认一次，并由发起方把确认结果写在任务描述里；一旦对方延期，系统自动通知的是这个唯一对接人而不是整个团队。如果对方团队不愿配合，就升级到双方主管层面明确优先级和排期。
判断依据很简单：同一条跨团队依赖上如果超过一个对接人，或者对接人不固定，就一定会出扯皮，必须在规划阶段就定死到人。
4. 前置任务依赖设多了，关键路径越拉越长，有什么预警信号和收缩方法？
我们一开始觉得设依赖是好习惯，后来越设越多，现在一个上线任务前面串了七八层，任何一环出问题整条链路都得等。老板问为什么交付越来越慢，我觉得可能就是依赖设太密了。这种情况有什么明显的信号，又该怎么减下来？
三个预警信号说明依赖已经设过头了：一是关键路径上的任务数超过总任务数的百分之四十；二是同一批任务里超过三条依赖属于"可以并行但被强行串行"；三是迭代中因为等前置任务而空转的任务超过两个。
收缩的方法分三步：第一步，把当前迭代所有强依赖列出来，逐条问"取消这条依赖，最坏结果是什么"，如果最坏结果只是顺序不好看而不是返工，就降级为弱依赖；第二步，对可以并行但需要同步的任务，改用"同步点"代替"前置依赖"，比如约定每天下午四点对齐一次进度，而不是让一个任务等到另一个任务完成；
第三步，为关键路径上的每个强依赖设置"最长等待时间"，超过就触发替代方案，比如用 Mock 数据先开工。判断依据是：依赖管理的目标是缩短等待浪费，不是把所有任务都锁死在一条链上，串行任务越多，交付周期越长。
核心关键词
文章包含AI辅助创作：任务依赖前置任务教程：研发团队协同管理，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/434811
读者评论
文章把依赖泛滥和排期僵化的关系讲得很透，特别是依赖链越长延期放大越明显的数据，我们团队就吃过这个亏。不过样本量只有12个团队，结论的普适性还有待验证。
变更通知那部分很实用，我们团队现在就是靠群聊发现依赖延期，平均要滞后一两天，站会才发现问题。但文章说工具自动通知覆盖率只有18%，感觉实际落地还要考虑工具成本和团队习惯。
跨团队依赖必须指定唯一责任人这点我完全认同，团队不会交付，个人才会交付。但文章对弱依赖和强依赖的区分标准还可以再细化，否则一线执行时还是容易混淆。