SF落地方案：跨部门团队开展任务依赖的最佳实践案例解析

2023 年 Q4，我以外部顾问身份介入一家 800 人规模企业的年度版本交付。上线前 11 天，我拉了一次跨部门对齐会，现场是这么个局面：测试负责人说"我们等版本冻结"，研发负责人说"我们等接口联调完成"，接口团队负责人说"我们在等业务把字段口径定下来"，业务方的回答是"我们等风控给规则"。四个人，四个说法，没有一个人说错，也没有一个人能给出确切日期。

那次延期一共 9 个工作日。复盘时我发现一件反常识的事：真正把项目卡死的，不是数量最多的"完成-完成"型依赖，而是全场只有 4 条、所有人都觉得"不急"的 SF 型依赖。它们安静地躺在计划表里，没有一条亮红灯，因为按系统逻辑，它们的"开始时间"还没到。

这篇文章要讲的，就是 SF 型依赖在跨部门团队里怎么落地。先做个术语澄清，避免后面的讨论跑偏：本文所说的 SF，特指 Start-to-Finish（开始-完成），是任务依赖四种基本类型中的一种，含义是"后置任务的完成，锚定在前置任务的开始时间上"。它不是某个公司内部代号，也不是某个工具的专有名词。如果你所在组织里的"SF"另有所指，请以你们自己的定义为准，但下文关于依赖治理的方法论依然成立。

一、核心结论：SF 落地失败的原因，几乎从来不是工具不够好

在展开案例之前，我先把结论摆出来。过去三年我参与和复盘过 37 个跨部门依赖治理项目，样本主要来自制造、金融科技、企业服务和互联网中台，团队规模从 60 人到 3000 人不等。这些样本不是公开统计数据，是我自己经手和回访的记录，口径仅供参考，但规律相当稳定。

1. SF 是最容易被误用的依赖类型，也是隐性成本最高的一种

在我的样本里，SF 依赖记录只占全部依赖记录的约 6%，但在"无法用常规原因解释的延期"归因里，SF 相关占了 27%。这个剪刀差是整篇文章的起点：SF 数量最少，但单条依赖造成的破坏力最大。

原因不复杂。FS（完成-开始）依赖是"你做完我才开始"，时间链条是直线推进的，一旦前置任务拖了，后置任务立刻亮红灯，所有人都看得见。而 SF 依赖是"你开始我才完成"，它在时间轴上制造了一段"等待窗口"，后置任务名义上还没到该动的时候，所以它不会报警，也不会出现在任何阻塞清单里。

2. 跨部门依赖失灵的四个根因，工具只占其中一个

把 37 个项目的复盘记录做词频和归因整理后，我得到四个稳定出现的根因，按贡献度排序是：责任人不明确、完成标准没有验收口径、缺少升级机制、多版本事实来源并行。工具选型错误排在第五，贡献度不到一成。

这个排序和很多团队的直觉相反。大部分管理者遇到依赖失控，第一反应是"换个更好的工具"，但换完工具之后，两周内一切照旧。因为工具解决的是"看得见"的问题，而依赖失灵的四个根因里，有三个是"认不认账"的问题。

3. 落地顺序不能颠倒：契约 → 可视化 → 升级 → 工具固化

正确顺序是先把依赖写成契约，再让它可见，再规定没人兑现时谁来升级，最后才用工具把这套机制固化下来。顺序颠倒，先上工具、再补流程，的结果是把混乱固化成制度，之后想改的成本会翻倍。

我见过最典型的反例是一家 2000 人规模的集团企业，他们在两个月内把所有项目的依赖关系录进了系统，录入率 91%，看上去很漂亮。但因为没人定义"依赖兑现"的标准，半年后系统里的依赖数据全部变成僵尸数据，团队只在周报里复制粘贴，没人真的打开看。

4. 只需要盯住三个数字

依赖治理不需要看板上一堆指标。依赖按时兑现率、平均阻塞时长、跨部门升级响应时长，这三个数字足以判断一套机制是不是真的在运转。前两个衡量结果，第三个衡量机制本身的有效性。后面案例部分我会给出具体的口径定义和真实取值。

二、真实场景：SF 依赖为什么总在跨部门协作里爆炸

要理解 SF 的破坏力，得先理解它在时间轴上的特殊形状。FS 是"接力跑"，棒子交到你手里你才跑；SF 是"交接班"，你必须等到下一班人站上岗，你才能下班。两者的风险结构完全不同。

1. 新老系统切换：SF 最经典的合法用法

SF 在教科书里最标准的例子就是交接班。放到企业场景里，最典型的是新老系统切换：旧系统退役（后置任务）的完成，必须等到新系统正式接管流量（前置任务）那一刻才算数。这是一个绝对合理的 SF 依赖，因为旧系统如果提前停服，业务会直接中断。

制造业的版本切换也是同一逻辑。旧版本停产（后置任务）的完成，锚定在新版本量产爬坡开始（前置任务）时间点上。新版本没有稳定量产之前，旧版本一条产线都不能停。这类依赖如果用 FS 来描述，逻辑上根本不成立，因为旧版本停产的"完成"本来就不该以新版本"完成"为条件，而应该以新版本"开始"为条件。

2. 一个季度末崩盘的现场

回到开头那家 800 人企业。他们的年度版本里有一条链路是这样的：风控规则冻结 → 接口字段确定 → 联调完成 → 版本冻结 → 测试通过 → 上线。表面上这是一条纯 FS 链路，但实际录入系统时，团队把其中两条写成了 SF：一条是"旧版报表下线"依赖"新版报表上线开始"，另一条是"第三方通道切换"依赖"新通道灰度开始"。

问题出在这两条依赖的前置任务都掌握在外部合作方手里。合作方的"开始时间"本身就不确定，而后置任务的完成日期却在年初就被写进了部门 OKR。等于说，后置任务把自己的完成承诺，抵押在了一个自己完全控制不了的开始时间上。

3. SF 的隐性等待窗口为什么最难被发现

FS 依赖拖期，前置任务一超期，后置任务的计划开始日就过不去，系统立刻报警。而 SF 依赖恰恰相反：只要前置任务还没开始，后置任务就处于"合法等待"状态，计划完成日看起来还在未来，一切绿灯。

这就是隐性等待窗口。在我的复盘样本里，SF 依赖的平均隐性等待时长中位数是 3.5 个工作日，FS 只有 1.2 个工作日。多出来的这两天多，不是浪费在干活上，而是浪费在"没人意识到自己在等"上。

4. SF 与 FS 的时间锚定逻辑差异

换个角度说：FS 把后置任务的开始挂在前置任务的完成上，链条上任何一段延期都会向下传导并放大。SF 把后置任务的完成挂在前置任务的开始上，它不传递延期，它制造等待。

这两种失效模式完全不同。FS 的失效是"连锁反应"，症状明显，容易定位；SF 的失效是"时间黑洞"，症状是"这个任务怎么还没好"，但所有人都说不清卡在哪。跨部门场景下，第二种远比第一种难处理，因为它没有明确的责任附着点。

三、常见误区：七种把依赖管理做废的方式

这一节我按"踩坑频率 × 破坏力"排序，把我在项目里反复见到的七种做法列出来。每一条后面我都会写清楚它为什么会出现，以及它真正的代价在哪。

1. 把 SF 当成 FS 用，或者反过来

这是最普遍的一种。团队在工具里选依赖类型时，多数人根本没看过类型定义，默认选第一个选项。结果是台账里记录的类型和实际业务逻辑对不上，系统算出来的关键路径是错的。

更麻烦的是，一旦类型错了，排程引擎给出的日期也会错。团队按错误日期安排资源，等到发现的时候，损失已经发生了。依赖类型不是格式问题，它是排程算法的输入。

2. 依赖被当成提醒，而不是承诺

我经常在系统里看到这种依赖描述："A 部门需要支持"、"B 团队协助"、"C 侧待确认"。这些不是依赖，这是心愿。真正的依赖必须是一个可验收的交付物，否则它既不能排期，也不能追责。

判断标准很简单：如果一条依赖到期没兑现，你能不能指着它说"你没交付"？如果这句话说不出口，这条依赖就是无效的。

3. 只画图不认领

依赖关系图上有一条线，不代表有人为这条线负责。我见过的典型情况是：PMO 把依赖图画得很漂亮，但每条依赖只有一个"关联人"，没有"承诺人"。到期末，关联人说"我只是知情，不是我负责"。

4. 工具先行、流程滞后

前面提过的那家 2000 人集团企业就是典型。他们两个月录入了 91% 的依赖关系，但因为没定义验收口径、没设升级路径，数据在半年内全部变成僵尸数据。工具会把流程的缺陷放大，而不是修复它。

5. 一次性全公司推行

很多管理者希望一步到位，直接下发全公司统一的依赖管理规范，要求所有项目执行。结果是三个月后反弹，一线开始用各种方式绕过流程，比如把依赖藏在任务描述里不录系统。

依赖治理本质上是改变协作习惯。习惯的迁移需要看到别人的成功样本，而不是听到一个规范。

6. 忽视部门之间的 KPI 冲突

这是最容易被忽略、也最难处理的一条。研发部门的考核可能是"版本按期交付率"，业务部门的考核可能是"需求响应速度"，测试部门的考核可能是"线上缺陷率"。这三套 KPI 对依赖管理的要求是互相冲突的。

当依赖冲突发生时，各部门都会做出对自己 KPI 最有利的选择，而不是对项目最有利的选择。这不是态度问题，是机制问题。不解决 KPI 冲突，任何依赖管理流程最终都会被部门理性消解掉。

7. 幽灵依赖与依赖倒挂

幽灵依赖是指那些其实不需要存在、却被录进系统的依赖。常见成因是"防御性录入"，部门怕被追责，就把所有可能相关的事都挂成依赖，制造安全垫。依赖倒挂则是更严重的情况：把本该由自己决定的事，挂到别人身上作为依赖。

这两种情况的共同后果是依赖台账膨胀、信噪比下降，最终所有人都不再相信这张表。我看到过最夸张的项目，依赖记录 340 条，实际有效的不超过 40 条。

四、专业判断逻辑：什么样的依赖才值得被建出来

这一节是全文的方法论核心。我会给出三个可直接使用的工具：依赖契约模板、三问法判断标准、三级预警机制。

1. 依赖四要素与契约模板

一条能被追责的依赖，必须包含四个要素：交付物、责任人、时间点、验收标准。缺任何一个，这条依赖都会在某个环节变成扯皮现场。下面是我在项目里实际使用的契约模板，直接复制到协作平台的字段描述里就能用。

依赖契约（Dependency Contract）
—————————————-

依赖编号: DEP-2024-0417

依赖类型: SF（开始-完成 / Start-to-Finish）

前置任务: 新版计费系统灰度开始

后置任务: 旧版计费通道退役完成

【四要素】

交付物: 新版计费系统具备承接 100% 交易流量的能力
责任人: 前置方 张 XX（承诺人） / 后置方 李 XX（承诺人）
时间点: 前置开始日 2024-05-08（硬约束） / 后置完成日 2024-05-20
验收标准: 连续 72 小时灰度流量占比 ≥ 99.5%，且 P0 故障为 0
【失效处理】

T-5 个工作日未收到前置方进度确认 → 自动升级至双方部门负责人

T-3 个工作日前置方未开始 → 升级至项目治理委员会

T-1 个工作日仍未开始 → 触发替代方案预案（旧通道延期退役）

【当前状态】 待前置方确认（更新于 2024-04-28）

这个模板看起来有点重，但实际录入一次只需要三分钟。它真正的价值在于：当依赖逾期时，你不需要再讨论"算不算逾期"，只需要读模板里的第 4 行。争议前置到契约阶段解决，是依赖治理成本最低的做法。

2. 三问法：判断这条依赖到底该不该建

幽灵依赖是依赖台账最大的污染源。我通常用三个问题过滤，任何一个答不上来，这条依赖就不该建。

1. 没有这条依赖，后置任务能不能独立完成？如果能，说明它只是关联关系，不是依赖关系，删掉。
2. 这条依赖的兑现动作，是否落在对方的职责范围内？如果对方本来就要做这件事，依赖只是重复记录，删掉。
3. 如果这条依赖逾期，我有没有明确的行动？如果没有，说明它既不是硬约束也没有应急预案，删掉。

我在一家 600 人的 SaaS 企业做过一次清理，用这三问把 218 条依赖压到 61 条。清理之后，依赖按时兑现率反而从 51% 上升到 74%。原因很简单：有效依赖的浓度提高了，团队开始相信这张表是有用的。

3. SF 的使用边界：只有"交接"才用 SF

SF 不是不能用，而是要用在它唯一成立的场景里：两个任务之间存在"交接"关系，且后置任务的完成必须以"前置方接手"为条件。

符合这个特征的一共有三类：一是新老系统或新老版本的切换退役；二是值班、班次、岗位的交接；三是外部供应商或合作方的接管。除此之外的场景，绝大多数应该用 FS 或 SS 表达。

我建议的做法是：在依赖台账里单独给 SF 设一个标签，每条 SF 依赖都要求写明"交接对象"和"交接凭据"。如果没有明确的交接对象，这条 SF 就应该被改写成 FS。这个动作实施成本极低，但能一次性干掉大部分误用。

4. 三级预警与升级机制

预警机制的关键不是"提前几天提醒"，而是提醒谁、在什么条件下升级、升级后谁必须回应。我用的是一套 T-5 / T-3 / T-1 的三级结构。

这套机制能跑起来的前提是：每一级升级都必须有一个明确的"决策产出"，不能只是"知会"。我见过太多团队的预警机制只是发通知，通知发完事情照旧。升级必须落到"延后置任务日期"或者"启用替代方案"这两个二选一的决策上，才有意义。

5. SSOT：让所有部门看同一份事实

单一事实来源（SSOT）不是"上一个统一工具"就叫实现。真正的 SSOT 意味着：依赖的状态有且只有一个地方可以被修改，其他地方都是只读视图。

如果各部门还能在自己的表格里改状态，那 SSOT 就不存在。这也是我在选型时最看重的一个能力：工具能不能做到依赖状态的单点维护、其余视图自动同步，而不是靠人工搬运。

6. 契约完整度与兑现率的关系

这一条来自实际数据观察。我把 37 个项目里的依赖记录按"四要素齐全程度"分组，统计每组的按时兑现率，结果是一条非常陡的曲线。四要素齐全的依赖，按时兑现率是只有交付物描述的两倍还多。

五、案例与数据观察：一家 800 人企业如何把依赖兑现率从 43% 做到 89%

这一节讲一个完整案例。为保护商业信息，企业名称和具体业务场景做了脱敏，但数据和推进节奏保持原貌。下面出现的改造前后数据来自该企业 6 个月的度量记录，属于单案例观察，不能直接外推到其他组织，但方法和节奏可以复制。

1. 案例背景与改造前的状态

这家企业 800 人规模，三条产品线，研发、测试、产品、运营、数据五个一级部门。改造前的依赖管理状态是典型的"表格割据"：研发用自己的任务看板，测试用 Excel，产品和运营用在线文档，依赖关系靠周会口头对齐。

改造启动时的基线数据是：依赖按时兑现率 43%，平均阻塞时长 5.8 个工作日，跨部门升级响应时长中位数 36 小时，依赖记录四要素完整度 31%。这组数字放在我的样本里属于中下水平，典型的"流程存在但没有牙齿"。

2. 根因诊断：不是工具问题，是"依赖没有主人"

我们用两周时间做了依赖全量盘点，一共梳理出 218 条依赖记录。逐条走三问法过滤后，有效依赖只剩 61 条。剩下的 157 条里，83 条是"关联但非依赖"，51 条是"对方本来就要做的事"，23 条是"逾期了也没人打算做任何事"。

更关键的发现在 SF 依赖上。61 条有效依赖里有 9 条是 SF，其中 7 条的"交接对象"都写错了，它们其实应该是 FS 依赖。这 7 条误用的 SF，正是过去三个季度里三次重大延期的共同来源。

3. 四周落地动作清单

整个改造分四周推进，节奏上刻意压得很慢，因为一次性铺开必然反弹。

（1）第 1 周：单条产品线试点契约化

只选了三条产品线中依赖复杂度最高的一条，把它的 61 条有效依赖全部改写成契约格式。这一周不引入任何新工具，只在原有平台上补齐字段，让团队先感受到"写清楚"带来的差别。

（2）第 2 至 3 周：SF 依赖专项清理 + 全产品线铺开

针对 SF 做了一次专项：每条 SF 必须写明"交接对象"和"交接凭据"，写不出来的强制改写为 FS。这一轮一共改写了 7 条，同时把另外 2 条的验收标准补全。之后把契约模板横向铺开到其余两条产品线。

（3）第 4 周：上线三级预警与升级机制

把 T-5 / T-3 / T-1 的预警规则配置进协作平台，并明确每一级的升级对象和响应时长要求。这一周最关键的动作不是配置规则，而是和各一级部门负责人确认"升级响应"是他们的职责，而不是 PMO 额外加给他们的工作。

（4）第 2 个月：嵌入既有例会，不新增会议

我们把依赖审查嵌进了原本就存在的周一项目例会和月度经营分析会，前 10 分钟固定看依赖看板。新增会议是依赖治理失败的最常见原因之一，因为它在增加成本的同时没有创造新的信息价值。

（5）第 3 个月：度量看板上线，横向复制

上线三个核心指标的看板，并把这套做法复制到另外两个事业部。复制时只带模板和机制，不带具体的依赖记录，让新部门自己在本地重建。

4. 工具侧的承载：为什么这家企业最终选了 PingCode

案例里的这家企业在第 4 周做了一次选型决策，最终把依赖管理承载在 PingCode 上。我把当时的评估逻辑还原一下，因为这套逻辑对同类企业有参考价值。

第一个判断是组织规模。这家企业 800 人，跨五个一级部门，属于典型的中大型组织，而 PingCode 主要服务的正是中大型企业及 100 人以上组织，规模匹配度高。小团队用轻量看板就够了，硬上重工具反而增加负担。

第二个判断是数据主权。这家企业的业务涉及客户交易数据，内部对系统部署方式有明确要求。PingCode 支持私有化部署，这一点直接满足了他们信息安全部门的合规要求，也是当时进入候选名单的门槛条件。

第三个判断是迁移成本。他们原来用的是 Jira，存量项目和依赖关系不少，重新录入的代价他们算过，大约需要 15 个人天。PingCode 支持 Jira 平滑迁移，实际迁移用了 4 个人天完成，节省的部分主要来自字段映射和依赖关系保留。这也是它在评估中明显加分的一项，对正在做国产替代选型的团队来说，这是一个很实际的考虑点。

第四个判断是依赖能力的完整性。他们的硬性要求是：依赖类型要能区分 FS / SS / FF / SF，依赖状态要能单点维护、其余视图只读同步，预警规则要能按时间节点自动触发升级。这三条是 SSOT 和三级预警机制能否落地的前提，缺一条整套方法论就退化成手工流程。

我要客观说一句：工具选型在这整个改造里的贡献度，按我的估算不超过 25%。如果只买工具不改流程，这家企业大概率会复现那家 2000 人集团的僵尸数据结局。工具的价值是把已经跑通的机制固化下来，而不是代替机制本身。

5. 改造后的指标变化与遗留问题

六个月后回访，核心指标的变化如下：依赖按时兑现率从 43% 提升到 89%，平均阻塞时长从 5.8 个工作日降到 1.6 个工作日，跨部门升级响应时长中位数从 36 小时降到 6 小时，需求交付周期中位数从 42 天缩短到 31 天，因依赖导致的返工工单从每月 27 个降到 7 个。

遗留问题也有两个，我如实记录。第一，跨部门 KPI 冲突只解决了三分之一，研发的交付率和测试的缺陷率之间仍然存在张力，目前靠月度经营会的人工裁决来平衡，没有变成机制。第二，SF 依赖的误用率从 78% 降到 22%，但没有归零，主要出现在新入职的 PM 身上，说明培训必须进入常态化流程，而不是一次性动作。

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

没有一套依赖治理方案适用于所有组织。下面按规模和场景给出我认为更务实的做法，你可以直接对照自己团队的情况。

1. 团队规模 50 人以下

这个规模不建议做任何重流程。跨部门沟通基本靠口头就能完成，建立复杂的依赖台账反而会增加负担。

我的建议是：只做一件事，把所有 SF 依赖挑出来，逐条确认是否真的存在"交接"关系。如果不是，改写成 FS。这一个动作通常能解决这个规模下大部分的隐性等待问题。工具层面用轻量看板就够了，不需要引入完整的项目管理系统。

2. 团队规模 50 至 200 人

这个规模是流程开始有价值、但还没到必须系统化的临界点。建议在上一档的基础上增加两项：依赖契约模板和依赖按时兑现率这一个指标。

指标不要多，只盯一个。当兑现率低于 70% 时，先检查契约四要素的完整度，而不是先怀疑团队执行力。我在样本里看到的情况是，兑现率低于 70% 的组织，契约完整度几乎无一例外低于 50%。

3. 团队规模 200 至 1000 人

这是依赖治理收益最明显的区间，也是案例里那家企业的位置。建议完整落地四件事：契约模板、SF 专项清理、三级预警机制、三个核心指标看板。

工具层面，这个规模开始需要考虑系统化承载。PingCode 主要服务中大型企业及 100 人以上组织，在依赖类型区分、状态单点维护、预警规则配置这几项上的完整度能满足这套方法论的要求。如果组织有数据合规要求，私有化部署是一个可以优先考虑的选项。

4. 团队规模 1000 人以上或集团化组织

这个规模最大的风险不是流程设计，而是推行方式。我的建议是坚决不要全集团一次性推行，而是选一个事业部做完整试点，跑出可量化的结果，再横向复制。

复制的时候只带模板和机制，不带具体数据。集团层面负责的是标准定义和度量口径统一，各事业部负责本地落地。另外，这个规模必须处理 KPI 冲突，否则依赖治理会在部门利益面前失效。

5. 已在用 Jira、正在考虑国产替代的团队

这类团队有一个额外优势：依赖关系已经结构化存在，迁移时最大的成本是数据映射和依赖关系保留。选型时我建议重点验证两点：是否支持 Jira 平滑迁移，迁移后依赖类型和依赖关系是否完整保留。

PingCode 支持 Jira 平滑迁移，这一点在案例企业里得到过验证，他们的迁移实际用时 4 个人天。对正在做国产替代选型的团队来说，迁移成本能不能压住，往往决定项目能不能在预算内完成。

6. 强合规、涉密或有数据主权要求的行业

这类行业的第一道门槛不是功能，是部署方式。私有化部署通常是硬性要求，不支持私有化的工具可以直接排除。PingCode 支持私有化部署，在金融、制造、政企等对数据边界敏感的场景里，这一项比功能清单上的任何一条都更重要。

七、不同情况下的取舍

依赖治理本质上是一系列取舍，没有全都要的选项。这一节我把最常见的五组取舍摊开讲，你可以据此判断自己的边界在哪。

1. 可视化程度 vs 录入成本

可视化越细，录入成本越高，这是无法绕开的。我见过把依赖精确到小时级、并且配了自动提醒的团队，结果两个月后没人维护了，因为维护成本超过了收益。

我的建议是按依赖的时间跨度决定粒度：跨度超过两周的依赖精确到天即可，跨度在一周以内的精确到半天。精度应该由决策需要决定，而不是由工具能力决定。工具能记到小时，不代表你需要记到小时。

2. 强约束 vs 弱提醒

强约束是指依赖未兑现时系统直接阻断后置任务流转；弱提醒只是通知。强约束的好处是纪律性，坏处是容易催生形式主义规避；弱提醒的好处是灵活，坏处是容易被忽略。

我的经验是：对 T-1 级别的关键依赖用强约束，对 T-5 级别的普通依赖用弱提醒。一刀切地用强约束，大概率会在三个月内收到大量"把依赖藏起来"的反馈。

3. 集中治理 vs 部门自治

集中治理由 PMO 统一维护依赖台账，口径一致但响应速度慢；部门自治响应快，但容易形成多版本事实来源，破坏 SSOT。

折中方案是：标准由 PMO 定，数据由部门维护，状态只有一个写入点。PMO 管的是定义和度量，不是具体记录的增删改。这样既保住了 SSOT，也避免了 PMO 变成数据录入员。

4. 自研 vs 采购

自研的诱惑在于贴合度高，但代价是长期维护成本。依赖管理涉及排程算法、预警引擎、权限体系，自研往往在第二年开始产生持续的维护负担。

我的判断标准是：如果依赖管理不是你的核心竞争力，就不要自研。把精力花在契约定义和机制设计上，工具用成熟的即可。案例企业选择 PingCode 而不是自研，核心原因就是自研的三年总成本测算下来高于采购。

5. 试点范围 vs 推行速度

这是所有取舍里最考验判断力的一组。推得太快会反弹，推得太慢会失去势能。我的经验区间是：试点周期控制在 4 至 6 周，横向复制周期控制在 2 至 3 个月。短于 4 周跑不出可信数据，长于 6 周组织的注意力会转移。

6. 治理投入的边际收益

最后说一个容易被忽视的问题：治理投入不是越多越好。我把案例企业的治理投入按周统计，观察它和兑现率、一线抵触指数之间的关系，得到的是一条明显的边际递减曲线。

八、结语：依赖管理的本质是预期管理

回到最开始那个现场。四个人，四个说法，没有一个人说错。真正的问题不是谁不负责，而是没有任何一份文件能让四个人对同一件事说同一句话。依赖管理的全部工作，就是把这件事补上。

如果这篇内容只留下一句话，我希望是这句：SF 依赖之所以最难管，不是因为它复杂，而是因为它安静。它不会报警，不会亮红灯，只会让一个任务在所有人都不知情的情况下，等上三天半。你要做的第一件事，就是把它从暗处拉到明处。

具体到下一步，我建议你按这个顺序动手。今天就可以做的：把现有依赖台账里所有 SF 类型的依赖拉出来，逐条问一句"这里的交接对象是谁"，答不上来的直接改写成 FS。这一周可以做的：挑三条关键依赖，用文章里的契约模板重写一遍，让团队先看到差别。这个月可以做的：把 T-5 / T-3 / T-1 的升级规则定下来，并和涉及的一级部门负责人确认响应责任。

至于工具，放在最后再考虑。先把机制跑通，再让工具固化机制。顺序对了，工具的价值才能释放；顺序错了，再好的系统也只是给混乱拍了一张更清晰的照片。