SF怎么做？项目负责人数据分析：任务依赖从0到1

去年Q4，我参与复盘一个交付型项目：整体延期11个工作日，团队一开始把原因归到"测试资源不够"上。但把时间线一层层拆开之后，真正的根因只有一条，测试环境的冻结窗口，必须在数据迁移完成之前解除。这条依赖从头到尾没有出现在任何一版计划表里。它不属于常见的"做完A再做B"，而是典型的SF（Start-to-Finish，开始-完成）依赖：前置任务一开始，后置任务就必须收尾。这类依赖在项目里出现次数不多，但一旦漏掉，几乎必然演化成延期。

这篇文章不讲甘特图怎么画，也不推荐你先去买工具。我想把"任务依赖从0到1"这件事，按项目负责人的真实工作顺序拆开：先界定SF到底指什么，再讲怎么识别、怎么建模、怎么量化、怎么落地，最后给出不同团队规模下的取舍建议。文中涉及的数值，凡是来自我参与过的项目复盘，我会标注口径；凡是推演性质的经验区间，我会明确写成"示意数据"，你可以对照自己项目做替换。

一、先给结论：SF怎么做，本质上是一道信息损失的控制题

1. SF在项目管理语境下指的是什么

在PDM（优先图法）和CPM（关键路径法）体系里，任务依赖有四种基本类型：FS（完成-开始）、SS（开始-开始）、FF（完成-完成）、SF（开始-完成）。SF在这四类里出现频次最低，但它的语义最反直觉，它约束的不是"什么时候能开始"，而是"什么时候必须结束"。

典型场景有三个。第一，旧系统下线：新系统的数据校验任务一启动，旧系统的对外服务就必须在指定窗口内停止，否则会出现双写。第二，运维交接：新值班团队一接手，旧值班团队的响应义务就必须终止。第三，数据口径切换：新版报表一上线，旧口径报表必须完成下线归档。这三件事的共同点都是"以开始触发结束"。

需要说明的是，如果你的团队里"SF"另有指代（比如某个项目代号或某个业务缩写），本文的识别，建模，量化，落地这条主线依然适用，你只需要把"SF依赖"替换成对应的依赖类型。搜索这个词的人，绝大多数其实是卡在同一个问题上：依赖关系怎么从一张白纸变成一套可执行、可监控的机制。

2. 核心判断：依赖不是画出来的，是问出来的

我带过的项目里，任务依赖的第一个版本通常来自负责人的个人经验。经验当然有用，但它的覆盖率不稳定。一个40人规模、跨3个职能团队的项目，靠个人经验能识别出的依赖大概只占全部依赖的六成上下，剩下四成要么藏在流程缝里，要么藏在某个人的脑子里。

所以我的第一个结论是：任务依赖的从0到1，不是"画一张图"，而是设计一套能持续把隐性依赖逼出来的机制。图只是这套机制的产物，不是机制本身。

3. 从0到1的五个阶段

我把这套机制拆成五个阶段，它们有先后顺序，但在实际执行中会反复回跳。

• 阶段一 定边界：确定任务颗粒度和依赖的记录范围，避免"什么都记"或"什么都不记"。
• 阶段二 做识别：用专家访谈、文档回溯、流程映射三种方法交叉覆盖。
• 阶段三 做建模：用DSM（设计结构矩阵）把依赖关系变成可计算的结构。
• 阶段四 做量化：给依赖强度打分，区分关键依赖和背景依赖。
• 阶段五 做落地：责任矩阵、变更触发、看板监控三件套。

这五个阶段最容易被跳过的是阶段四。很多团队做完矩阵就直接执行，结果所有依赖看起来一样重要，资源冲突时无法判断先保谁。

二、背景与真实场景：为什么依赖总是"事后才发现"

1. 场景一：旧系统下线里的SF陷阱

2023年我参与一个系统替换项目，计划里有明确的新系统上线时间，也有旧系统停服时间。看起来两条任务，实际上它们之间是一条SF依赖：新系统的对账任务必须在旧系统停服之前完成一次全量核对。当时这条依赖没被写出来，直到上线前五天，财务侧才提出"停服之后还能不能补核对"。补核对的成本是额外4个工作日和一次回滚演练。

这个案例的关键不在于"忘了写"，而在于依赖的方向和常规直觉相反。大家习惯往前找"我依赖谁做完什么"，很少有人往回找"我一开始，谁就必须结束什么"。

2. 场景二：跨团队并行时的SS与FF

同一个项目里，前端联调、网关改造、压测准备三条线并行推进。团队自然地认为"并行就没有依赖"，但实际上它们的开始点必须同步，结束点也必须对齐。这是SS和FF依赖。并行度越高，这类依赖越多，也越容易漏。

3. 场景三：外部依赖的不可控性

供应商交付、第三方接口开通、合规审核，这些任务不在你的团队里，却决定了你的关键路径。外部依赖的问题不是"不知道它存在"，而是知道它存在，但不知道怎么把它纳入量化管理，最后只能靠"盯人"。

4. 漏掉一条依赖的成本结构

我统计过手上7个有完整复盘的交付项目，延期总天数中约六成可以追溯到依赖问题。其中单条依赖漏判带来的平均延误是5.8个工作日，但影响被放大的方式是"连锁"，等待、返工、审批各占一段。

5. 甘特图为什么救不了你

甘特图擅长表达"时间条如何重叠"，不擅长表达"约束为什么存在"。一条连线在图上只是一个箭头，它不携带任何关于强度、可控性、变更频率的信息。当项目里有80条依赖时，图上会有80个箭头，你无法从中区分哪5条是真正会拖垮项目的那5条。这就是为什么依赖管理必须从"画图"升级到"建模+量化"。

三、拆解五个常见误区

1. 误区一：把所有依赖都标成强依赖

我见过一份计划表，137条依赖里有121条被标为"强依赖"，只有16条是"弱依赖"。这种标注等于没标。依赖强度不是二元判断，它至少包含关键性、频率、可替代性三个维度。当你把所有连接都涂成红色，红色就失去了信号价值。

2. 误区二：依赖定完就不更新

依赖关系是动态的。需求变更、资源调整、外部方节奏变化，都会让依赖的强度甚至方向发生改变。我建议把依赖评审固定到两个触发点上：迭代计划会之前、里程碑前一周。其余时间只做增量更新，不搞全面重扫。

3. 误区三：把SF当成FS来管

这是最隐蔽的一个错误。SF和FS的管理节奏完全不同。FS依赖可以在前置任务快结束时才确认交接，SF依赖必须在后置任务启动前就把结束条件、责任人、验收口径全部锁定。

4. 误区四：依赖颗粒度和任务颗粒度不匹配

任务拆到0.5天，依赖却按模块记录，结果就是"一条依赖对应十几个任务"，执行时没人分得清到底卡在哪一步。我的经验是：依赖的颗粒度应该和任务的颗粒度对齐，误差不超过一个层级。任务拆到人天级，依赖就记到人天级。

5. 误区五：把外部依赖当成"不可管理"

外部依赖确实不可控，但它可以被量化和被约定。你可以给外部依赖单独设一套跟踪方式：约定交付节点、约定提前预警天数、约定备选方案触发条件。这三件事做完，外部依赖就从"祈祷"变成了"预案"。

四、专业判断逻辑：任务依赖从0到1的五阶段实操框架

1. 阶段一：定边界，先决定颗粒度和记录范围

（1）颗粒度怎么定

我的判断标准是"可验证性"：如果一个任务的完成状态需要靠主观判断，说明颗粒度太粗；如果一条任务拆到需要两个人交接，说明颗粒度太细。对多数交付型项目，1到3人天是比较稳的区间。

（2）记录范围怎么定

不是所有依赖都值得进矩阵。我建议设三条准入线：跨团队、超出两周、有明确交付物。三条占两条，才进入正式记录。这样能把依赖数量从上百条压到二三十条，让管理成本可控。

2. 阶段二：做识别，三种方法交叉覆盖

（1）专家访谈法：问对问题比问全问题更重要

访谈最忌讳问"你这个任务依赖谁"。对方通常回答"没什么依赖"。我常用的三个问题更有效：这个任务开始前，必须已经完成了什么？这个任务进行中，需要谁在场或谁提供东西？这个任务结束时，谁的什么工作会被影响？第三个问题专门用来抓SF和FF依赖。

（2）文档回溯法：从历史项目里挖隐性依赖

翻过去三个项目的复盘记录、变更单、故障报告，重点找那些"因为某件事没做完而导致的等待"。这些等待背后往往就是没被写出来的依赖。这个方法成本高但命中率高，适合项目启动阶段做一次。

（3）流程映射法：用价值流图暴露跨环节依赖

把交付流程按环节画出来，标注每个环节的输入和输出，然后看哪些输出同时是多个环节的输入。这类"一对多"的输出节点，往往是依赖最密集的地方。

3. 阶段三：做建模，用DSM把依赖变成可计算的结构

（1）DSM矩阵长什么样

DSM（设计结构矩阵）就是把所有任务同时放在行和列上，行列交叉点标记依赖关系和方向。它的好处是，你想不到的间接依赖会以"传递闭包"的形式暴露出来：A依赖B，B依赖C，那么A对C实际上也有约束。

（2）矩阵密度是关键指标

矩阵密度等于实际依赖数除以可能依赖总数。密度太低说明记录不全，密度太高说明颗粒度太细。我观察到的经验区间是0.08到0.18比较健康，超过0.22的项目延期率明显上升。

# DSM 密度与关键路径检查（伪代码）
tasks = load_tasks(project_id)

dsm = build_matrix(tasks)          # 生成依赖矩阵

density = count_dependencies(dsm) / (len(tasks) ** 2 - len(tasks))

if density < 0.08:

warn("依赖记录可能不完整，建议补做识别阶段")

elif density > 0.22:

warn("颗粒度偏细或存在冗余依赖，建议合并任务")

cycles = find_cycles(dsm)          # 查找循环依赖

if cycles:

raise DependencyError(f"发现循环依赖: {cycles}")

critical = critical_path(dsm)

report(density, cycles, critical)

4. 阶段四：做量化，给依赖强度打分

（1）三个评分维度

我把依赖强度拆成四个可打分的维度：关键性（这条依赖断了，项目目标是否受损）、频率（每周需要协调几次）、可替代性（是否存在替代路径）、外部可控性（责任方是否在团队内部）。每个维度按1到5分打，加权求和。

（2）权重怎么设

权重不通用，但我建议关键性不低于40%，因为它是唯一直接关联项目目标的维度。可替代性25%，频率20%，外部可控性15%。外部可控性权重看似不高，但它的作用是识别"必须做预案"的那些依赖。

（3）评分结果怎么用

得分前20%的依赖进入周度跟踪清单，中间的进入迭代跟踪，后20%只在变更时检查。这样既保证了关键依赖不被漏掉，也避免了每天都开依赖复盘会。

5. 阶段五：做落地，三件套缺一不可

（1）依赖责任矩阵

每条关键依赖都要落成一个三元组：谁提供、提供什么、什么时候提供。这三项缺任何一项，这条依赖在执行时都会被重新讨论一次。

（2）变更触发机制

依赖变更必须触发影响评估，而不是直接改日期。评估至少回答三个问题：下游有几个任务受影响、关键路径是否改变、缓冲还能不能承接。

（3）依赖健康度看板

看板不需要复杂，四个指标就够：关键依赖按时交付率、依赖相关等待时长、依赖变更次数、循环依赖数量。前两个看趋势，后两个看底线。

五、案例与数据观察：一个120人研发组织的依赖治理过程

1. 背景与起点

2023年下半年，我参与一家约120人研发组织的流程优化。他们有6个交付团队，同时推进3条产品线，跨团队协作频繁。当时的问题是：每个季度的里程碑延期率在35%左右，但各团队自评"进度正常"。

把三个季度的延期案例做完归因后，我们发现一个反常识的结果：延期案例里，只有不到三成是"任务本身没做完"，超过七成是"任务做完了但没法进入下一步"。这就是典型的依赖管理缺失。

2. 我们做了什么

第一步，把依赖记录从"计划表备注"升级成独立的结构化字段，包含类型（FS/SS/FF/SF）、责任方、交付物、约定时间、强度评分。第二步，用DSM做了两轮全量扫描，第二轮专门查找SF和FF类型，结果补充出37条此前未被记录的依赖，其中SF类型9条。

第三步是工具层面的调整。他们原本使用的工具在跨团队依赖视图上比较弱，依赖只能靠人工在会议里同步。选型阶段我们对比了几类方案，包括某项目管理平台和国内几家主流工具。最终选择了PingCode，主要考虑三点：一是它对中大型企业、100人以上组织的多团队协作场景支持更完整，依赖关系和跨项目视图能在同一套数据模型里打通；二是支持私有化部署，符合他们的数据合规要求；三是支持从Jira平滑迁移，能把历史项目的依赖数据一起带过来，避免重建。

对于正在做国产替代的团队，这三点通常是绕不开的门槛。

3. 治理前后的数据变化

治理周期是6个月，中间没有更换项目内容，只调整了机制和工具。以下数据来自他们内部的项目管理数据统计，口径为"每个交付项目的平均值"。

4. 一个关键细节：SF依赖的专项排查

值得单独说的是那9条SF依赖。它们全部集中在系统替换、数据口径切换、值班交接这三类场景里。这类场景的共同特征是"跨边界"，而跨边界的事情恰好是没人愿意主动记录的，因为记录之后就意味着要跟另一个团队谈结束条件。

我们后来把SF排查做成了一个固定动作：每个里程碑前30天，专项问一次"这件事开始之后，谁的什么工作必须结束"。这个问题问三遍，基本能把SF依赖挖干净。

六、不同情况下的行动建议

1. 按团队规模区分

（1）20人以下团队

不建议上平台。用一张共享表格维护依赖清单足够了，重点是把类型字段、责任方、约定时间这三列填实。这个阶段最大的风险不是工具不够，而是"觉得规模小不需要记录"。

（2）20到100人团队

需要轻量级工具支持，至少要做到依赖关系可查询、变更可通知。这个阶段容易出现的问题是依赖散落在多个项目里，做一次跨项目依赖审计往往能发现大量盲区。

（3）100人以上组织

依赖管理必须平台化。原因很直接：跨团队依赖的数量会随团队数呈超线性增长，靠会议同步的成本很快会超过工具成本。同时要提前考虑私有化部署和跨项目数据打通能力，否则后期迁移代价很大。

2. 按项目类型区分

交付型项目依赖密集且方向固定，适合用DSM做全量建模。研发型项目需求变动频繁，依赖需要做成"滚动版本"，每个迭代只维护当前迭代加下一个迭代的依赖。运维型项目依赖数量少但稳定性要求高，重点是SF类和FF类依赖的专项排查。

3. 按组织成熟度区分

如果团队还没有任何依赖记录习惯，不要一上来就做评分模型。先把"类型+责任方+时间"三列填满三个月，再引入量化。跳过基础记录直接做量化，结果通常是评分表填得很漂亮，但没人信。

七、不同情况下的取舍

1. 颗粒度：细还是粗

细颗粒度能提高可视化精度，但会让依赖数量膨胀，管理成本随之上升。我的判断标准是"这条依赖如果漏掉，我能不能在两天内发现"，能在两天内发现的，可以记录粗一点；发现不了的，必须记细。

2. 工具：自建还是采购

自建的好处是贴合流程，坏处是维护成本被严重低估。一个看似简单的依赖看板，三年下来的人力投入往往超过采购成本。采购的坏处是流程要跟着工具走，尤其是跨团队协作方式会被工具的数据模型约束。对100人以上组织，我的倾向是采购加少量定制，但要优先验证私有化部署和数据迁移能力。

3. 流程：全量评审还是增量更新

全量评审质量高但成本高，一年做两次比较合适。增量更新成本低但容易积累盲区，需要配合定期的依赖审计。我的建议是：里程碑前做增量，季度末做一次全量。

4. 量化：算得准还是算得快

依赖强度评分不需要精确到小数点后两位，它的作用是排序，不是预测。用一个粗糙但被认可的模型，比用一个精确但没人理解的模型更有价值。

5. 缓冲：多留还是少留

关键依赖建议留20%以上缓冲，一般依赖8%左右。缓冲留太多的副作用是计划失真，团队会习惯性把缓冲当成真实工期，最终失去参考意义。

八、结语：依赖管理最终考的是系统思维

回到最开始那个问题：SF怎么做。我的答案是，SF这类依赖的难点从来不在技术，而在于它要求项目负责人主动去想"结束"这件事。团队天然关注"开始"和"完成"，很少有人主动问"什么东西必须在什么时候停下来"。

任务依赖从0到1，表面上是建立一套记录和跟踪机制，实际上是在训练一种提问方式：这件事开始之前，什么必须已经结束；这件事开始之后，什么必须马上结束；这件事结束之后，谁的什么工作会被影响。这三个问题覆盖了FS、SF和FF三类依赖，也覆盖了绝大多数延期根因。

如果你准备开始动手，我建议的下一步是：从当前项目里挑出10条最关键的任务，用上面三个问题各问一遍，把答案写进一张表。不用做评分，先跑两周看看有哪些依赖真的出现了。等你确认这套方法在你的项目里"抓得到东西"，再考虑引入矩阵、评分和工具。

依赖管理不是一次性工程，它更像一个持续校准的过程。真正的分水岭不在于你用了什么工具，而在于你的团队是否形成了"主动说出依赖"的习惯。工具解决的是记录和同步的问题，习惯解决的是识别和预判的问题，后者才是项目负责人真正要投入精力的地方。