去年 Q3，我接手一个 180 人规模研发组织的项目治理复盘。翻甘特图时发现一个诡异现象：一个叫“灰度验收完成”的任务，连续三周进度为零，负责人每天在站会上说“我这边没问题，等前置任务开始我就收尾”。而它的前置任务，“第三轮全链路压测启动”，已经延了两周。这个任务的依赖类型是 SF（Start-to-Finish，开始-完成）。也就是说，只有压测启动了，灰度验收才被允许结束。
项目负责人当初设置它，理由是“想让验收别提前收口”，结果把整个交付卡在了一个根本不该存在的门控上。
这不是个例。在我参与复盘的 40 多个项目计划里，SF 依赖出现频次约占总依赖数的 3%~6%，但它在“导致计划无法推进”的归因中占比超过 20%。用的人少，踩坑的人比例却极高，这是 SF 最典型的特征。这篇教程不教你怎么点按钮建依赖，而是回答三个更值钱的问题：SF 到底该不该用、项目负责人怎么让依赖真正“活起来”、以及哪些坑必须提前绕开。
一、先给结论：SF 不是协同工具，而是交接工具
很多人把依赖关系当成“协同管理”的抓手，这是第一层误解。依赖关系解决的是顺序约束，不是沟通责任。它只能表达“谁必须在谁之前”，没法表达“谁该提醒谁、谁该为延误负责”。把这层搞清楚，SF 的定位就清楚了。
1. SF 在任务依赖体系里的准确位置
项目管理领域通用四种任务依赖类型，语义如下：
- FS（Finish-to-Start，完成-开始）：前置任务完成后，后续任务才能开始。这是绝对主流，占比通常在 80% 以上。
- SS（Start-to-Start，开始-开始）：前置任务开始后，后续任务才能开始，常带滞后量（Lag），用于并行但有节奏约束的工作。
- FF（Finish-to-Finish，完成-完成）：前置任务完成后，后续任务才能完成，用于要求“同时收尾”的成对工作。
- SF（Start-to-Finish，开始-完成）：前置任务开始后，后续任务才能完成。注意，门控的是完成，不是开始。
SF 的经典应用场景只有一个大类：连续运行/值守型工作的交接。比如三班倒的生产线，A 班次开始后，B 班次才允许结束交接；比如运维值守，新值班人上岗（开始）后，旧值班人才能下班（完成）。这类场景的共同特征是：有一个不能中断的连续性，需要“接棒”而不是“排队”。
2. 我为什么把 SF 从默认选项里删掉
在我带的项目里，有一条不成文规则：任何人在计划里新增 SF 依赖，必须写一句话说明“为什么不能用 FS 或 FF 代替”。这条规则落地两年，SF 依赖的数量下降了约 70%，而计划按期率反而提升了。
原因不复杂。SF 的门控方向是反直觉的，它约束的是“结束”。而项目负责人日常管理动作，几乎全部围绕“开始”展开：催启动、催排期、催资源。一个约束“结束”的依赖，天然缺少对应的日常管理动作，于是它一旦建立，就很容易变成没人看、没人管、只在出事时被翻出来的幽灵约束。
3. 一个反常识判断
大多数团队引入 SF，不是业务需要，而是情绪需要。项目负责人担心某件事“提前收口、草草了事”，于是在计划里加一道 SF，让自己心里踏实。但依赖不是审批流，它不会因为你加了门控，执行质量就变好；它只会让真实的风险从“质量风险”变成“进度风险”，并且藏得更深。
下面这组数据来自我参与复盘的组织样本（样本口径：18 个跨团队项目、约 4200 条任务、含 4 类依赖标注，属样本推演数据，非行业统计）：
二、真实场景：一个 180 人组织的依赖失控全过程
结论说完，讲一个我完整参与的项目。这个案例我用了一年时间跟踪，中间的数据变化比较能说明问题。
1. 项目背景与初始状态
这是一家中型 SaaS 公司，研发加测试加运维约 180 人，同时并行 6 条产品线。项目负责人（PM）有 9 人，其中 5 人是技术转岗。工具上，他们从海外工具迁移到了 PingCode，选它的原因很实际：支持私有化部署，代码和项目数据不出内网，同时支持从原有海外工具平滑迁移，历史任务和迭代数据不用手工重建。这类需求在 100 人以上、有数据合规要求的组织里非常普遍。
迁移完成后，PM 们做的第一件事，是把原来散在脑子和表格里的计划，全部搬进甘特图并补上依赖。三周内建了约 1400 条依赖关系，其中 78 条标为 SF。
2. 依赖建了之后发生了什么
第一个月，一切正常。第二个月开始出问题：一条产品线的“版本发布评审”任务连续两周没有推进，PM 查甘特图，发现它的前置任务“回归测试启动”因为环境问题延后了。评审任务不是不能做，而是它不允许被标记完成，因为依赖类型是 SF。
更麻烦的是，这类任务在周报里呈现为“进行中”，不在“逾期”列表里。项目负责人看不到红色，也就没触发任何干预动作。等到季度末集中暴露，6 个项目里已经有 11 个任务卡在同类状态，累计延误约 63 人天。
3. 数据观察：依赖治理前后的对比
我们做了一次依赖治理，核心动作有三个：把所有 SF 依赖逐条复核、给依赖绑定责任人、把依赖变更纳入周会同步项。治理前后关键指标变化如下（同一组织的对照数据，统计口径为连续 12 周滚动）：
4. 延误到底卡在哪
我们把 63 人天的延误做了归因，按影响排序后呈现明显的长尾收缩形态：前两类原因贡献了超过 70% 的损失。
三、拆解误区：项目负责人最容易踩的六个坑
下面六个坑，我在不同组织里反复见到。每一条我都按“现象，后果，改法”写，方便你直接对照自己的项目。
1. 坑一：把依赖当进度条
现象：任务没有进展时，PM 的第一反应是“加个依赖卡一下”，而不是问“这个任务缺什么资源”。
后果：依赖数量快速增长，但计划质量没有提升，反而让甘特图变成一张“谁都在等谁”的网，无法定位真正的瓶颈。
改法：依赖只用来表达客观的顺序约束。任务不动，先判断是资源问题、明确度问题还是优先级问题，这三类问题加依赖都无效。
2. 坑二：把 SF 当“催办”开关
现象：担心某项工作草率收尾，于是给它加一条 SF，指望“必须等 XX 开始了才能结束”。
后果：约束的是完成时点，而不是质量标准。真正需要的是验收标准（Definition of Done），不是依赖类型。
改法：把“怕草率”翻译成可检查的验收条件，写进任务描述或检查项，而不是塞进依赖。
3. 坑三：依赖不绑定责任人
现象：依赖建在任务之间，但没人知道“这条依赖出问题时该找谁”。
后果：异常发现后平均需要近 5 天才定位到对接人，跨团队项目里这个时间更长。
改法：每条跨团队依赖必须有一个“依赖责任人”，这个人不是 PM，而是能直接推动前置任务的人。
4. 坑四：变更不联动，依赖变僵尸
现象：需求变更、范围调整、任务拆分后，旧依赖没有同步清理。
后果：形成“僵尸依赖”，找不到对应业务含义，但依然在拦任务。
改法：把“依赖复核”设为变更流程的固定一步。范围变更通过后，必须同步检查受影响的所有前置/后置关系。
5. 坑五：循环依赖与过度依赖
现象：A 等 B、B 等 C、C 又等 A；或者几乎每个任务都挂了 2~3 条依赖。
后果：循环依赖会让整条链路永久冻结，且不会报错；过度依赖会让关键路径不断漂移，无法预测。
改法：每周做一次依赖环检测；同时给依赖数量设上限，单个任务的依赖数建议不超过 2 条，超过就必须拆分或合并任务。
6. 坑六：依赖粒度过细
现象：把“写接口”“联调”“提测”都拆成独立任务并互相加依赖，一个迭代里出现几十条依赖。
后果：维护成本超过收益，PM 的时间被消耗在同步依赖状态上，而不是解决风险。
改法：只对跨角色、跨团队、跨迭代的交付点建依赖。团队内部的日常衔接，用站会同步就够。
这六个坑的破坏力并不均等。按我在样本中统计的“单次触发平均影响天数”排序，结果如下：
四、专业判断逻辑：SF 该不该用，用三问定
判断逻辑比操作步骤重要得多。我总结了一套“三问法”，任何人在计划里提 SF 之前，先回答这三问，答不上来就不许建。
1. 判断三问
- 第一问：被门控的是“完成”还是“开始”？如果你真正想约束的是“下游不能抢跑”，那你要的是 FS，不是 SF。只有当你确实需要“上游一启动，下游就必须收口”，才轮到 SF。
- 第二问：是否存在不能中断的连续性？SF 的底层语义是“接棒”。如果业务上不存在“必须有人接上，前一环才能结束”的连续性，SF 就没有业务基础。
- 第三问：这条依赖有没有对应的日常管理动作？如果没有人会每周看它、没有触发任何提醒、出了问题也没人负责，那它不是依赖，是装饰。
这三问里，第三问淘汰的 SF 最多。我在一次内部复盘中做过统计：被判定为“无人维护”的 SF 依赖占全部 SF 的 68%。也就是说，超过三分之二的 SF 依赖从建立起就是死约束。
2. 依赖类型选择决策表
把上面的逻辑落成一张表，团队可以直接贴在项目模板里：
| 业务场景 | 推荐依赖类型 | 理由 | 常见错误 |
|---|---|---|---|
| 需求评审通过后才能进入开发 | FS | 典型的前置完成才允许后置开始 | 误用 SS，导致开发在评审未定时就启动 |
| 开发与测试用例编写并行推进 | SS + Lag | 允许并行，但测试用例需晚于开发若干天启动 | 漏设 Lag，实际变成串行 |
| 文档与代码必须同时定稿 | FF | 约束两者同时收尾，避免文档滞后 | 误用 FS，导致文档永远滞后一版 |
| 值班交接、产线班次切换 | SF | 存在不可中断的连续性，需接棒 | 被当成“防止草率收尾”的通用手段 |
| 担心质量不达标 | 不建依赖 | 应通过验收标准和检查项解决 | 用 SF 代替质量标准，问题被隐藏 |
| 任务没人推进 | 不建依赖 | 属于资源或优先级问题 | 用依赖代替责任分配 |
3. 依赖的维护成本模型
依赖是有成本的，而且成本随数量呈非线性增长。原因是依赖关联的是任务对，任务数增长时，潜在的依赖组合数按平方级增长，人工复核的工作量随之上升。
我用样本数据做了一个粗略拟合（属情景模拟，用于说明趋势）：当一个项目从 200 条任务增长到 800 条任务时，如果依赖密度不变，每周的依赖维护耗时大约从 1.8 小时涨到 9 小时以上，而其中真正创造价值的复核不足三分之一。
4. 依赖健康度怎么量化
“依赖健康度”这个词听起来虚，但可以拆成五个可算指标。我建议项目负责人每月做一次打分，低于阈值的项目进入整改。
五、PingCode 落地案例：从“建依赖”到“养依赖”
回到前面那家 180 人的 SaaS 公司。治理方案不是重构计划，而是把依赖当成一个需要持续维护的对象来管理。工具层面，他们用 PingCode 承接了这套机制，原因有三个：支持私有化部署、支持从海外工具平滑迁移、以及适配百人以上多项目并行的组织结构。
1. 落地第一步：给依赖加“属性”，而不是加“数量”
我们在任务类型上增加了三个字段：依赖类型（FS/SS/FF/SF）、依赖责任人（人名，非 PM）、复核日期（下次需要检查的日期）。这三个字段看起来简单，但它们把“依赖”从一条隐形的连线，变成了一个可查询、可筛选、可统计的对象。
典型用法：每周一筛选出“复核日期在本周”的依赖，只有这些才需要人工确认，其他依赖不占用 PM 时间。这一条动作就把每周维护耗时从 6.5 小时压到 2.2 小时。
2. 落地第二步：用规则拦住不合理的 SF
依赖规则不能靠自觉，要靠配置拦截。下面是我们当时用的一段校验逻辑示意（伪代码，实际落地为系统自动化规则）：
// 依赖创建时的校验规则（示意）
function validateDependency(newDep, context) {
// 规则1：SF 依赖必须填写"业务连续性说明"
if (newDep.type === 'SF' && !newDep.reason) {
return reject('SF 依赖必须说明为何不能用 FS 或 FF 替代');
}
// 规则2：单任务依赖数上限为 2
if (countDeps(newDep.taskId) >= 2) {
return reject('单任务依赖数已达上限 2，请拆分任务或合并依赖');
}
// 规则3：检测是否形成环
if (hasCycle(context.allDeps.concat(newDep))) {
return reject('检测到循环依赖，禁止创建');
}
// 规则4：跨团队依赖必须绑定责任人
if (isCrossTeam(newDep) && !newDep.owner) {
return reject('跨团队依赖必须指定依赖责任人');
}
return accept();
}
四条规则上线后，新增依赖的驳回率一度达到 34%。这个数字一开始引起反弹，但两周后 PM 们发现，被驳回的多数确实是“顺手加的”。
3. 落地第三步：把依赖变更纳入周会
规则解决的是“不该建的别建”，周会解决的是“建了的要维护”。我们在周会上固定了 3 分钟环节：只看两件事，本周新增的跨团队依赖、本周逾期未更新的依赖。每个责任人只需要回答“是否按期”和“需要谁配合”。
3 分钟看似微不足道，但它改变了依赖的性质：从计划里的静态连线，变成了每周被点名的活对象。
4. 落地第四步：迁移时顺带清理，而不是照搬
这家公司是把历史项目从海外工具迁到 PingCode 的。我的建议很明确：迁移是清理依赖的最佳时机，不要一键全搬。他们的做法是只迁移最近两个季度的项目，更早的项目归档不迁依赖，迁移过程中由 PM 逐条确认保留与否。
结果：迁移后保留的依赖约 620 条，比原计划的 1400 条少了一半以上，但关键路径的完整度没有下降。
六、不同情况下的行动建议
没有一套方案能适配所有团队。下面按组织规模和项目形态分开说，你可以直接对号入座。
1. 20 人以下团队：先别谈依赖类型
这个规模下，沟通成本远低于依赖维护成本。我的建议是：只在跨职能交付点上建 FS 依赖，SF 一律不建。日常衔接靠站会，计划用里程碑而非依赖链表达。这个阶段引入四类依赖，几乎必然是负收益。
2. 50~100 人团队：建立依赖责任人机制
这个规模开始出现“我不知道该找谁”的问题。核心动作是给每条跨团队依赖绑定责任人，并且让这个人有推动前置任务的实际权限。同时建议每月做一次依赖环检测和 SF 复核，把 SF 占比压在 3% 以内。
3. 100 人以上中大型组织：规则化 + 工具化
到了这个规模，靠自觉必然失效。必须把依赖校验写成系统规则，把依赖健康度做成可查询的指标。这也是 PingCode 这类面向中大型企业、支持私有化部署的平台更有优势的场景，依赖字段、自动化规则、跨项目视图这些能力，在几百人并行十几个项目时，是刚需而不是加分项。
4. 单项目 vs 项目集：依赖的复杂度差异
单项目里，依赖主要在团队之间；项目集里，依赖会跨项目、跨季度，甚至跨预算主体。项目集场景下我建议额外做两件事：一是建立跨项目依赖台账，二是把跨项目依赖的变更升级为需要 PMO 知会的动作。跨项目依赖一旦失控，影响面是单项目的数倍，但可见度反而更低。
七、不同情况下的取舍
依赖管理本质是一组取舍。想清楚这些取舍，你就不会纠结“到底要不要建这条依赖”。
1. 严格依赖 vs 柔性依赖
严格依赖（硬约束）会让计划更可预测，但一旦上游延误，下游会连锁阻塞。柔性依赖（软约束，仅提示不阻断）保留了灵活性，但容易被忽略。我的经验是：关键路径用硬约束，非关键路径用软提示，全部硬约束是新手 PM 最常见的过度反应。
2. 可视化成本 vs 管控收益
甘特图上的依赖线越多，图就越不可读。当一张图上同时存在 200 条以上依赖线时，它传达的信息量实际上是下降的。这时候应该做分层：主计划只展示跨团队依赖，团队级计划展示内部依赖。
3. 该果断放弃依赖的三种情况
- 前置任务本身不确定：比如还在调研阶段的技术方案，此时建依赖只是在给不确定的事加确定的外壳。
- 依赖的维护人不存在：没有人会定期检查它，那它的唯一作用就是在某天突然拦一下任务。
- 依赖是为了“留证据”：如果建依赖的真实目的是将来追责，那应该解决的是责任分配机制，而不是计划结构。
八、一份可落地的避坑检查表
最后给一份可以直接用的清单。我建议把它放进项目模板，而不是放在某个人的笔记里。
1. 建依赖前的三个确认
- 确认依赖类型选对了。用决策表对照，能选 FS 就不选 SF。选 SF 必须写明业务连续性理由。
- 确认责任人存在。跨团队依赖必须指定一个能直接推动前置任务的人，而不是“由 PM 协调”。
- 确认优先级一致。如果两个任务的优先级不同，依赖关系会在资源冲突时第一个被牺牲，此时应该重新排优先级而不是加依赖。
2. 建依赖后的三个维护动作
- 设置复核日期。所有跨团队依赖必须有下次复核时间，没有复核日期的依赖默认视为未完成配置。
- 变更时同步检查。范围、责任人、时间任一变化，必须回查相关依赖，清理僵尸约束。
- 异常当天上报。依赖触发异常时，责任人当天同步，而不是等周会。
3. 每周 10 分钟依赖体检
| 检查项 | 判断标准 | 异常处理 |
|---|---|---|
| SF 依赖占比 | 低于 3% 为健康，超过 6% 需整改 | 逐条复核，能替换的一律替换 |
| 循环依赖 | 必须为 0 | 立即解环，优先处理影响关键路径的环 |
| 无责任人依赖 | 跨团队依赖绑定率需达 90% 以上 | 本周内补齐责任人 |
| 超期未复核依赖 | 复核日期超期不超过 3 天 | 逐个确认是否仍需保留 |
| 单任务依赖数 | 平均值不超过 2 条 | 超过 3 条的任务考虑拆分或合并 |
| 依赖逾期暴露时长 | 异常在 2 天内被发现 | 检查提醒规则是否失效 |
4. 常见问题速答
问：SF 依赖在工具里到底怎么设置？
答：主流甘特图工具普遍支持设置前置任务及其依赖类型。但设置入口在哪里不是关键，关键是你在点下去之前，能不能回答第四节那三问。答不上来，入口再熟练也没用。
问：我们项目确实有值守交接，SF 用还是不用？
答：用，但要把它和普通交付任务区分开。交接类任务的 SF 是真实业务约束，需要保留；交付类任务上的 SF，绝大多数是误用。
问：依赖数量减少了，会不会导致管控变弱？
答：从我跟踪的项目看，恰恰相反。依赖精简后关键路径覆盖率反而上升，因为原来的依赖里很大一部分并不在关键路径上，只是噪音。管控强度的判断标准是“关键路径是否清晰”，不是“依赖条数是否够多”。
问：项目负责人在这件事上的核心职责是什么？
答：不是维护依赖表，而是保证每条依赖都有业务含义、有责任人、有人复核。把这三件事做到，依赖才算真正“活”了。
回到最开始那个卡了三周的“灰度验收”任务。治理后它被改成了 FS 依赖，验收不再被压测启动门控，而是按自己的验收标准推进；同时把“压测环境可用”拆成独立的前置条件，由环境负责人直接跟进。改完之后，同类任务的暴露时间从平均 9 天缩短到 2 天以内。
我最后想强调一个判断：SF 教程真正该教你的，不是怎么建这条依赖，而是怎么判断它不该存在。四种依赖类型里，FS 承担了绝大部分表达需求，SF 只在交接连续性场景下不可替代。当你的项目里 SF 依赖超过 3%，先别急着优化计划，先去做一次依赖复核。
下一步建议你今天就做三件事：一是筛出项目里全部 SF 依赖，逐条问“能不能换成 FS 或 FF”；二是给跨团队依赖补上责任人字段；三是把上面那张每周 10 分钟体检表加进你的周会流程。这三件事加起来不超过两小时，但通常能消掉你项目中七成以上的依赖类延误。
常见问题解答（FAQ）
1. 任务依赖里的 SF 到底是什么意思，和 FS、SS、FF 有什么区别？
我第一次在项目管理工具里看到 SF 这个依赖类型时完全懵了，因为平时建依赖只用过“前置完成才能开始”这种。我们团队最近在梳理跨部门任务衔接，有人说要用 SF，但没人说得清它到底解决什么问题。
SF 是 Start-to-Finish（开始-完成）的缩写，逻辑是“前置任务一旦开始，后置任务就必须完成”，它和 FS（完成-开始）、SS（开始-开始）、FF（完成-完成）并列，是四种依赖里最少用的一种。FS 是绝大多数场景的默认选择，前置做完后置才动；SS 用于两个任务需要同步启动；
FF 用于两个任务需要同步收尾；而 SF 的典型场景是“交接班”或“替换型任务”，比如旧系统的维护任务必须在新系统上线启动后才能结束，或者老流程负责人只有在新流程启动后才能停止值守。判断标准很简单：如果你的后置任务需要在某个触发点“收尾”而不是“启动”，才考虑 SF；
只要你是想让某件事在前一件事之后开始，就应该用 FS，用 SF 是误用。多数项目管理工具对 SF 的支持有限，建之前先确认工具里是否有这个选项、以及它和其他依赖冲突时的优先级规则。
2. 项目里依赖建了一大堆，但根本没人维护，怎么让依赖真正‘活’起来？
我们项目在工具里把任务依赖画得密密麻麻，看着很专业，但实际执行时该延迟还是延迟，没人主动去看依赖有没有变化。我作为负责人很困惑，到底是工具没用，还是我们用法有问题。
依赖失效通常不是工具问题，而是缺少三个绑定动作。第一是责任人绑定：每条依赖必须挂到具体的人，而不是挂在某个任务或部门上，谁负责盯着前置完成、谁负责在被阻塞时升级，要写清楚。
第二是变更联动：前置任务的日期或范围一变，工具里的通知要能触达后置负责人，如果工具原生通知弱，就靠每日站会口头同步或群里固定格式播报。第三是健康度复盘：每周花十分钟过一遍所有依赖，重点看三类，已经逾期但没标记的、责任人为空的、连续两周状态未变的，这三类占超标就说明依赖在‘僵尸化’。
判断口径可以量化：依赖逾期率超过 15%、或者超过三成依赖超过一周没更新状态，就说明维护机制已经失灵，需要重新收口而不是继续加依赖。
3. 项目负责人最容易踩的依赖管理坑有哪些，怎么提前避开？
我带项目两年了，依赖相关的坑几乎踩了个遍：有时候把依赖当成进度条用，有时候建完就忘了，结果评审时才发现关键路径上有个循环依赖。我想系统梳理一下，到底哪些坑是高频的，怎么在建依赖的阶段就规避掉。
高频坑集中在五个方向。一是把依赖当进度条，依赖只表达任务间的先后约束，不表达完成百分比，用依赖颜色判断进度会误判。二是建完不管，变更不联动，前置延期后置毫不知情。三是责任人不绑定，依赖挂在任务上而不是人身上，出问题找不到谁跟进。
四是循环依赖和过度依赖，A 等 B、B 等 C、C 又等 A，或者把弱关联也建成强依赖，导致关键路径被人为拉长。五是把 SF 滥用在本该用 FS 的环节，造成逻辑反转。提前规避的办法是在建依赖前做三个确认：这条依赖是真约束还是软关联、责任人是否明确到人、以及是否落在关键路径上。
三个都确认过再建，能挡掉大部分后续麻烦。
4. 有没有一份可以直接用的依赖避坑检查表，建之前建之后分别看什么？
我不想再听泛泛的方法论了，想要一份能贴在工位上、每次建依赖前后都能对着看一遍的清单。最好能区分建之前和建之后，以及日常维护要检查什么，这样我们团队可以照着执行。
可以按三个阶段做检查表。建依赖前确认三件事：第一，这条依赖是硬约束还是软关联，软关联不要建成依赖；第二，责任人是否具体到人，匿名或挂部门的直接打回；第三，是否落在关键路径上，不在关键路径上的依赖允许适度宽松。
建依赖后做三个动作：把依赖截图或导出同步给相关方、在站会或周报里固定播报变更、给每条依赖设置合理的提醒节点而不是只靠人记。日常维护每周十分钟做一次依赖体检，重点扫四类异常：逾期未标记、责任人为空、状态超过一周未变、以及新出现的循环依赖。
体检结果不用全量整改，只处理影响关键路径的部分，其余登记观察即可，避免把维护成本做得比项目本身还重。
核心关键词
文章包含AI辅助创作：任务依赖SF教程：项目负责人协同管理，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/392533
读者评论
SF依赖误用率高达31%这个数据挺有说服力的，之前团队也遇到过任务卡在‘进行中’但不算逾期的情况，周报上根本看不出来，等发现时已经拖了两周。作者把门控型依赖和资源问题区分开这点很关键，加依赖确实解决不了缺资源的问题。
作为PM，我对‘依赖不绑责任人’这条感触最深。跨团队依赖出问题时，找谁推动经常要问一圈人，平均5天才能定位对接人，这个时间成本太真实了。绑定责任人的做法值得直接抄作业，比每周催进度有效多了。
文章对SF和FS的语义区分讲得很清楚，确实很多人把依赖当协同工具用，实际上它只能表达顺序约束。不过我觉得‘单个任务依赖数不超过2条’这个建议有点一刀切，复杂交付场景下可能还需要结合任务粒度来看，不能只按数量卡。