SF实操方法：PMO提升任务依赖效率的流程优化方法与模板

2024 年第三季度，我以外部 PMO 顾问的身份介入一家 87 人的研发组织。他们刚把一个原计划 14 周交付的车企客户项目拖到了第 23 周，复盘会上所有人给出的结论高度一致：跨团队配合不到位。

我没有接受这个结论。我用两天时间把 23 周延期逐条拆解到任务链路上，发现真正吃掉时间的不是任何一个团队偷懒，而是 11 条从未被登记过的依赖关系。其中 4 条属于 SF 型依赖，也就是"前序任务一开始，后续任务就必须尽快收口"。

这条发现直接改变了我们对"任务依赖效率"的理解。大多数 PMO 团队的依赖管理只覆盖了 FS（完成-开始）这一种类型，剩下的 SS、FF、SF 三种全部处在管理视野之外。而恰恰是这三种，尤其是 SF，制造了大量"看起来谁都没错、但时间就是没了"的延期。

这篇文章不讲甘特图怎么画，也不复述依赖的定义。我要分享的是过去三年我在 6 个中大型研发组织里反复验证过的一套做法：用"依赖类型全谱登记 + 三件套流程规则 + 依赖效率看板"提升任务依赖效率。文中的四层设计、五类误区、90 天数据和取舍判断，都来自真实项目，不是教科书推导。

一、先给结论：依赖效率低，本质是依赖类型没有被完整建模

如果你只想从这篇文章拿走一句话，那就是：任务依赖效率低，90% 的情况不是人不配合，而是依赖类型没有被完整建模。团队只看见了一半的依赖关系，自然只能管住一半的协同。

1. SF 依赖是任务依赖里的"暗物质"

项目管理里公开的依赖关系有四种：FS（Finish-to-Start，完成-开始）、SS（Start-to-Start，开始-开始）、FF（Finish-to-Finish，完成-完成）、SF（Start-to-Finish，开始-完成）。前三种在项目管理教材里被反复讲，第四种 SF 经常被一句话带过，甚至直接省略。

SF 依赖的含义是：前序任务一旦启动，后续任务就必须在限定时间内完成收口。注意方向，它约束的是后续任务的"结束"，触发条件却是前序任务的"开始"。

举个我实际遇到的例子。某车企客户项目里有一条链路：新权限系统上线（前序任务），旧系统权限回收（后续任务）。旧系统权限回收这件事，只有在新系统"开始上线"之后才能启动，并且必须在新系统上线后的 10 个工作日内完成，因为新旧两套权限并行运行的时间窗口只有 10 天，超期就意味着双份权限暴露风险。

这就是一个标准的 SF 依赖。它没有出现在任何一张甘特图的依赖箭头里，因为甘特图默认画的是 FS 箭头。结果就是：新系统上线这件事被反复推迟，每次推迟一天，旧系统回收的窗口就被压缩一天，而没有任何人意识到这两个任务之间存在硬约束。

我在 6 个项目里做过粗略统计，一个 100 人规模的研发组织，一个季度内真实存在的 SF 依赖大约在 8 到 20 条之间，但被显式登记的通常不超过 2 条。登记率普遍低于 15%。这就是"暗物质"，它占据质量，却几乎不占据管理视野。

2. 依赖效率可以被量化成三个指标

"依赖效率"这个词在很多团队里是模糊的，说不清就没法改。我把它拆成三个可以月度统计的指标：

• 依赖登记覆盖率：已登记依赖数 ÷ 实际发生的依赖数（通过抽样回访估算）。低于 60% 说明登记机制形同虚设。
• 依赖平均响应时长：从依赖提出到对方给出明确承诺（承诺时间或明确拒绝）的平均工作日。这是最灵敏的指标，超过 3 天就意味着流程有阻塞。
• 依赖冲突复发率：同一对团队之间，因为同类依赖问题重复发生冲突的次数 ÷ 总冲突次数。高于 30% 说明升级机制没有解决根因。

这三个指标加起来，基本能刻画一个组织的依赖管理成熟度。我见过的最健康的团队，这三个数字分别是 85%、1.4 天、12%；最糟糕的一个是 31%、6.8 天、57%。

3. 依赖数量不是问题，未登记依赖才是

很多 PMO 有一个本能反应：依赖太多说明协作设计有问题，应该想办法减少依赖。这个判断在多数情况下是错的。

中大型组织里，跨团队依赖是分工的必然产物。你想减少依赖，本质是在要求团队不协作。真正的问题是依赖没有被登记，所以无法被承诺、无法被追踪、无法被升级。

我做过一次对比：同一个组织，A 项目组登记了 63 条依赖，平均响应时长 2.1 天；B 项目组只登记了 19 条依赖，平均响应时长 5.9 天。表面看 A 组依赖更多更麻烦，实际结果 A 组延期 4 天，B 组延期 21 天。依赖数量是分工的镜像，登记率才是效率的镜子。

4. 流程规则必须跑在工具之前

这是我在所有项目里最坚持的一条判断。依赖效率低的组织，第一反应通常是"我们缺一个好工具"。但工具只能执行规则，不能发明规则。

如果你的组织还没有定义清楚"依赖由谁提出、由谁承诺、多久未响应要升级、升级到谁"，那么上任何工具的结果都是一样的：登记表三天就没人填了。我在一个客户那里见过最典型的场景，他们上线了一套很完整的项目协同平台，自定义了 20 多个依赖字段，三个月后我打开后台，依赖表里一共 7 条记录，最后一条更新于上线后第 11 天。

所以正确的顺序是：先定四层规则，再用工具固化规则，最后用数据反哺规则。工具是第三步，不是第一步。

二、背景与真实场景：一个 87 人研发组织的依赖失控复盘

光讲结论太抽象。我把开头提到的那个 87 人组织的完整复盘过程拆出来，你能看到依赖失控是怎样一步步累积成 9 周延期的。

1. 项目背景与时间线

这是一个车企客户的智能座舱项目，涉及 5 个团队：基础架构组（21 人）、车机应用组（26 人）、云端服务组（18 人）、测试组（14 人）、交付实施组（8 人）。原计划 14 周交付，实际用了 23 周。

我把 9 周延期拆到周级别，还原出的时间线是这样的：

• 第 3 周：基础架构组的"统一鉴权模块"启动，比计划晚 2 天。没有人在意，因为它没有阻塞任何 FS 后续任务。
• 第 5 周：云端服务组的"旧接口下线"必须开始，但前提是统一鉴权模块已经稳定运行。此时鉴权模块只完成了 60%，旧接口下线被迫推迟。
• 第 7 周：旧接口继续在线，为了保证兼容，车机应用组不得不同时维护两套调用逻辑，实际工作量增加约 35%。
• 第 11 周：测试组发现双接口并行导致的偶发鉴权失败，开始专项排查，占用 3 名测试工程师共 6 天。
• 第 16 周：旧接口终于下线，但下线后触发了 2 个存量客户的历史数据兼容问题，交付实施组返工 5 天。

这条链路里，真正被延误的"第一块多米诺骨牌"是第 3 周那 2 天。它之所以没有被拦住，是因为"统一鉴权模块启动"和"旧接口下线完成"之间的 SF 依赖从来没有被登记。

2. 依赖失控的四个信号

复盘时我总结出这类组织共有的四个信号。你可以拿它比对自己的团队：

1. 依赖靠聊天工具传递：依赖信息散落在群聊、私聊、邮件里，没有统一出口。
2. 依赖没有承诺时间：接收方只说"我尽量"，不说"我在几号之前给你"。
3. 依赖没有升级路径：卡住了就在群里再问一遍，没人知道该找谁仲裁。
4. 依赖没有复盘：同一个坑，三个季度里踩了四次。

这四个信号有一个共同特征：它们都不是"态度问题"，而是"机制缺失"。你骂团队配合不好，解决不了任何一条。

3. 我在前 5 天做的三件事

介入这个组织的前 5 天，我没有开会讲方法，只做了三件事。

第一件，把过去 12 周的延期逐条归因。我和 5 个团队的负责人分别做了 90 分钟的一对一，把每次延期的原因落到具体任务和具体人，形成一张归因表。最后归类下来，依赖类原因占 68%，其中 SF 依赖和 SS 依赖合计占 41%。

第二件，做一个 3 天的依赖闪电登记。我要求每个团队把当前正在进行和未来 4 周内计划的任务里，所有"需要别人先做点什么"的环节全部列出来，不区分类型。三天收上来 89 条。

第三件，把 89 条依赖按类型重新分类。分类结果很能说明问题：FS 依赖 47 条、SS 依赖 22 条、FF 依赖 12 条、SF 依赖 8 条。而在此之前的三个月里，正式台账上只有 6 条记录，全部是 FS。

这 8 条 SF 依赖里，有 3 条和开头那条"鉴权模块 / 旧接口下线"性质完全一样，都处在即将爆发的边缘。我们当时立刻给这 3 条做了窗口期重排，避免了大约 11 天的潜在延期。

三、拆解五个常见误区

在 6 个组织里，我反复看到同一批误区。它们看起来都很"合理"，所以传播得特别广，也特别难纠正。

1. 误区一：把甘特图当成依赖管理的终点

甘特图能画出依赖箭头，于是很多团队认为"我们已经在管依赖了"。问题在于，甘特图天然表达的是 FS 依赖，A 结束、B 开始，一条箭头。SS、FF、SF 三种依赖在甘特图里没有标准表达方式，最多用文字备注，而文字备注等于没有。

更麻烦的是，甘特图给了一种"依赖已被盘点"的错觉。团队画完图就安心了，实际上遗漏的正是风险最高的那一半。

2. 误区二：只登记 FS 依赖

这是第一个误区的直接后果，但值得单独拎出来说，因为它太普遍了。

我统计过 9 个组织的依赖台账模板，8 个模板只有"前序任务 / 后续任务"两列，隐含的就是 FS 语义。当一个团队只能用 FS 的语言描述依赖时，他们就会不自觉地把 SF 依赖硬塞进 FS 的框里，或者干脆不登记。

SF 被硬塞进 FS 的典型话术是："等 A 做完了，B 也就该收尾了。"这句话听起来像 FS，实际是 SF，因为 B 的收尾窗口是由 A 的启动时间决定的，不是由 A 的完成时间决定的。差之毫厘，管理动作完全不同。

3. 误区三：依赖评审会开成了进度汇报会

我参加过至少 20 次号称"依赖评审"的会议，其中 15 次实际内容是各团队轮流念自己的进度。念完之后，有依赖的没依赖的都没结论。

依赖评审会的唯一目标应该是把依赖从"待确认"推进到"已承诺"。任何一条依赖走完评审，如果还没有明确的承诺人和承诺时间，这次评审就是无效的。

4. 误区四：先买工具，后定规则

前面已经说过，这里补充一个更具体的观察：工具先行最大的伤害不是浪费预算，而是让团队对流程本身失去信任。

当团队用一个功能齐全的平台登记了三个月依赖、却发现没有一条依赖因为它而按时解决，他们下次就不填了。而且这次不填，比从来没填过更难纠正，因为它已经被验证为"没用"。

5. 误区五：度量依赖数量，而不是依赖时长

不少 PMO 的月报里会写"本月新增依赖 47 条，解决 43 条"。这个数据几乎不提供任何决策信息。

47 条是多还是少？43/47 的解决率是好还是坏？如果这 43 条的平均响应时长是 6 天，那解决率再高也没用，因为项目已经等不起了。依赖管理的核心度量是时长和分布，不是数量。

四、专业判断逻辑：SF 依赖效率的四层设计

下面是我在实践里固化下来的一套设计。它不是流程文档，而是四层结构，每一层解决一个特定问题。缺任何一层，整套机制都会退化。

1. 第一层：依赖类型全谱登记

这一层解决"看得见"的问题。核心是把依赖登记表从两列扩展到能表达四种类型。

我的做法是：不要求登记者自己判断类型，而是用一个"触发条件"问题来间接判定。填写时只需要回答："这条依赖是在前序任务开始时触发，还是在完成时触发？后续任务是必须开始，还是必须完成？"两个问题的组合，自然映射到 FS / SS / FF / SF。

这样可以避开一个常见的执行障碍：大多数人记不住四种依赖的定义，但所有人都能回答"什么时候触发、要做什么"。

2. 第二层：依赖责任人与承诺时间

这一层解决"有人负责"的问题。每条依赖必须有两个角色：

• 依赖提出人：负责描述清楚需要什么、什么时候需要、验收标准是什么。
• 依赖承诺人：负责给出承诺时间，并且这个时间一旦给出就要进入其个人任务列表。

这里有个关键判断：承诺人必须是有排期权的人，不能只是执行人。我见过太多案例，执行人答应了，但他的主管早就给他排满了别的活，最后承诺自然落空。所以承诺人要么是团队负责人，要么是获得排期授权的接口人。

另外，承诺时间必须带"承诺有效期"。比如"我承诺在本月 18 日前提供接口文档，若 15 日前未收到最终字段清单，本承诺自动顺延"。这种带条件的承诺，比无条件的承诺可靠得多。

3. 第三层：依赖升级与冲突仲裁路径

这一层解决"卡住怎么办"的问题。规则要简单到能背下来：

1. 依赖提出后 1 个工作日内，承诺人必须给出回应（承诺时间或明确拒绝）。
2. 超过 2 个工作日无回应，自动升级到双方团队负责人。
3. 超过 4 个工作日仍无结论，升级到 PMO，由 PMO 组织 30 分钟内的快速仲裁。
4. PMO 仲裁结论需在 4 小时内书面确认，并同步给双方的项目经理。

这套规则的价值在于"自动"。升级不依赖提出人反复催，而是到期自动触发。这一点非常重要，依赖问题之所以恶化为冲突，往往不是因为解决不了，而是因为没人愿意当"催人的那个"。

4. 第四层：依赖效率看板与月度复盘

这一层解决"持续改进"的问题。看板只放前面提到的三个核心指标，加上一个分布图：

• 依赖登记覆盖率（按团队拆分）
• 依赖平均响应时长（按依赖类型拆分）
• 依赖冲突复发率（按团队对拆分）
• 依赖响应时长分布（按天数分桶，看长尾）

月度复盘只讨论一件事：上个月响应时长最长的 3 条依赖，为什么长？不讨论责任，只讨论机制。这个限制条件很关键，它把复盘从"追责会"变成"调规则会"。

五、具体案例与数据观察：一个 120 人组织的 90 天改造

2024 年 4 月到 7 月，我在一个 120 人的研发组织完整跑了一遍这套方案。这个组织同时有 4 条产品线、6 个交付项目在跑，跨团队依赖非常密集，是最适合验证这套方法的场景。

1. 工具选型与迁移路径

这个组织原有的状态是：依赖靠群聊和邮件，项目排期用一张共享表格，任务状态存在另一个系统里。他们希望借这次改造顺便把项目管理平台统一掉。

选型时我们列了四条硬指标：依赖关系的自定义字段能力、跨项目视图、私有化部署支持、历史数据迁移成本。前两条决定了流程能不能被工具固化，后两条决定了落地阻力。

最终他们选择了 PingCode 作为统一平台。选择的原因有三个，我如实记录：第一，PingCode 主要服务中大型企业及 100 人以上组织，字段体系和权限模型是按这个量级的协作场景设计的，和他们的组织结构匹配度高；第二，PingCode 支持私有化部署，他们的安全团队对代码和需求数据有明确的本地化要求；第三，PingCode 支持从 Jira 平滑迁移，他们过去三年的历史任务和缺陷数据可以带过来，不用重建。

迁移这件事我想多说一句。很多组织改造依赖管理的最大隐性成本不是流程设计，而是历史数据断层。如果旧系统的任务、缺陷、迭代记录不能迁移，团队会同时维护两套习惯，改造周期至少翻倍。所以在国产替代的选型里，迁移能力应该和功能能力同等权重。

2. 依赖登记表的字段设计

这是这次改造里最费心思的部分。我最终确定的字段结构如下，你可以直接对照改：

依赖登记表 · 字段定义（v2.3）
【基础字段】

依赖编号 DEP-YYYYMM-### （自动生成）

提出团队 枚举，取自组织架构

承诺团队 枚举，取自组织架构

关联任务 关联到任务ID，允许多选

依赖类型 枚举：FS / SS / FF / SF

【触发与约束字段】

前序触发事件 文本，描述"什么发生时会触发"

触发方向 枚举：前序开始触发 / 前序完成触发

后续动作要求 枚举：后续必须开始 / 后续必须完成

窗口期(工作日) 数字，SF 类型必填

最晚收口日期 日期，由窗口期自动计算

【承诺字段】

依赖提出人 人员字段

依赖承诺人 人员字段，需具备排期权

承诺时间 日期

承诺有效期条件 文本，例如"以字段清单确认为前提"

承诺状态 枚举：待确认 / 已承诺 / 有条件承诺 / 已拒绝

【跟踪字段】

首次响应时间 时间戳，自动记录

响应时长(天) 计算结果字段

升级次数 数字

当前状态 枚举：进行中 / 已解决 / 已升级 / 已关闭

复盘结论 文本，仅在已关闭时必填

这个结构里有三个设计点值得解释。

第一，"触发方向"和"后续动作要求"两个字段是分开的。这是我刻意设计的，把依赖类型的判断拆成两个更直观的问题，填写准确率从大约 52% 提升到 88%（我们在 40 条依赖上做过双人交叉校验）。

第二，"窗口期"只在 SF 类型下必填。SF 依赖的核心约束是时间窗口，不填窗口期等于没登记。而其他三种类型用"最晚开始/最晚完成日期"就够了。

第三，"承诺有效期条件"是这次改造里最受欢迎的一个字段。上线两个月后，承诺人主动填写条件的比例从 11% 上升到 64%。原因很简单：它保护了承诺人，让承诺不再是无限责任。

3. 90 天前后的核心指标变化

改造前（2024 年 4 月基线）和改造后（2024 年 7 月）的对比数据如下。需要说明，这是一次真实的组织内部度量，样本为 6 个项目、约 380 条依赖记录，不是行业统计，引用时请注意口径。

这里有个反直觉的观察值得单独说。改造后"SF 依赖登记条数"从 2 条/月涨到 13 条/月，第一版月报出来时，有个团队负责人的第一反应是"怎么问题变多了"。

这恰恰是改造成功的信号。SF 依赖本来就存在，只是原来没人登记。登记条数上升、延期天数下降，两者同时发生，说明机制在起作用。如果只看登记条数，很容易得出相反的结论。

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

这套方法不是一把尺子量到底。团队规模、项目形态、合规要求不同，起步动作也应该不同。下面是我根据不同组织情况给出的具体建议。

1. 50 人以下团队：先用一张表，不要上系统

50 人以下、3 个以内团队的组织，我强烈建议不要一开始就搭平台。

这个规模的协作半径小，依赖关系基本在 5 到 15 条之间，团队之间抬头不见低头见。此时最高效的做法是一张共享表格，字段按前面的结构裁剪到 10 个以内，重点是依赖类型 + 承诺人 + 承诺时间 + 窗口期这四列。

每周一次 20 分钟的依赖同步会，只过状态是"待确认"和"已升级"的条目。这个动作做满 8 周，你会得到两个东西：一是真实的依赖数据，二是团队对"承诺"这件事的肌肉记忆。

只有当表格维护开始出现版本冲突、或者团队超过 3 个之后，再考虑上系统。

2. 100 到 500 人团队：先固化四层规则，再选平台

这是我做过最多的规模段，也是最需要工具支撑的区间。100 人以上、多产品线并行，依赖会快速超过 50 条/月，手工表格撑不住。

建议的动作顺序是：

1. 用 2 周时间把四层规则写成一页纸，找 2 个项目试点。
2. 试点 4 周后统计三个核心指标，确认机制能跑起来。
3. 再启动平台选型，选型时把"依赖字段自定义能力"和"历史数据迁移"作为硬指标。
4. 迁移时优先迁任务和依赖关系，不要迁历史评论。

这个规模段的组织，往往已经有部分团队在用某个平台。如果原有平台支持依赖字段自定义和多项目视图，可以先用起来；如果不是，就要认真评估国产替代方案的迁移成本。PingCode 这类面向中大型组织的平台在这个阶段是相对稳妥的选择，因为它对私有化部署和平滑迁移的支持比较完整，适合 100 人以上、对数据本地化和历史延续有要求的团队。

3. 500 人以上多项目集：依赖要分层治理

500 人以上的组织，依赖问题会分化为两个层次：团队之间的依赖（战术层）和项目集之间的依赖（战略层）。这两层不能用同一套机制。

战术层沿用前面的四层设计，节奏是"天"级，承诺人可以是团队接口人。

战略层需要单独的项目集级依赖看板，节奏是"周"级，承诺人必须是项目集负责人。战略层的依赖往往涉及资源冲突和优先级调整，用团队级的升级机制解决不了。我建议在 PMO 内设一个固定的"依赖仲裁角色"，每周固定时段处理战略层依赖，其他时间不介入战术层。

4. 有强合规与私有化部署诉求的组织：把部署形态前置到选型第一步

金融、车企、医疗器械这几类客户，我在项目里遇到的最常见的返工原因，是选型时先比功能、后看部署形态，结果发现候选平台不支持私有化部署，前面几周的评估全部作废。

正确的顺序是反过来的：先用部署形态把候选池砍到一半，再比功能。私有化部署、数据不出域、审计日志完整性，这三条是硬门槛，过不了就直接出局。在这方面，PingCode 支持私有化部署的特性对强合规行业是加分项，同时它支持 Jira 平滑迁移，能避免合规审查期间因系统切换造成的数据缺失。

七、不同情况下的取舍

依赖管理没有"最优解"，只有"当前阶段的合理取舍"。下面四组取舍是我在项目里被问得最多、也最容易做错的。

1. 流程重量与执行速度的取舍

规则越细，覆盖越全，但填写成本越高。这两者永远在拉扯。

我的判断标准是看依赖密度：如果一个月内跨团队依赖少于 20 条，规则要精简到"提出 + 承诺 + 承诺时间"三步，宁可漏记也不要让团队觉得流程沉重。如果超过 50 条，就必须把类型、窗口期、升级路径全部补齐，否则会出现大量"登记了但没管住"的假管理。

中间区间（20 到 50 条）是最难判断的。我的经验是先加类型字段，后加流程节点。类型字段是一次性填写成本，流程节点是持续性时间成本，前者的性价比高得多。

2. 自建流程与采购平台的取舍

这个问题在 100 到 500 人区间最常出现。

自建（比如用表格加脚本、或者内部开发）的优势是贴合度最高、没有采购流程；劣势是每换一任 PMO 就可能推倒重来，而且无法沉淀组织资产。

采购平台的优势是字段体系和权限模型经过验证，历史数据可以长期积累；劣势是初期配置和迁移成本，以及可能的功能溢出。

我的判断线是：如果你需要一个季度以上持续维护的依赖台账，就采购平台。短期项目、一次性交付，用表格完全够。判断依据不是团队人数，而是"这套依赖数据要不要跨项目、跨年度复用"。

3. 度量粒度与填报成本的取舍

依赖的度量粒度可以很粗（只记响应时长），也可以很细（按类型、按团队对、按周次）。粒度越细，洞察越深，填报成本越高。

我建议的做法是分层度量：团队层只填原始数据（提出时间、响应时间、承诺时间），组织层按月计算聚合指标。不要要求团队自己算指标，也不要在登记表里放"本月平均响应时长"这类字段。

另外，指标数量控制在 4 个以内。我见过一个组织的依赖看板放了 17 张图，结果没有一个人看。指标的作用是引导注意力，超过 4 个就没有注意力可引导了。

4. 强管控与团队自治的取舍

这是最根本的一组取舍，也是很多 PMO 容易走偏的地方。

强管控意味着 PMO 介入每一次依赖仲裁，好处是响应快，坏处是 PMO 会迅速变成瓶颈，而且团队会失去自主协商的能力。

团队自治意味着 PMO 只定规则不介入，好处是可持续，坏处是弱团队会长期落后。

我倾向于的做法是"规则统一、执行自治、按数据介入"：PMO 只规定升级规则和度量口径，不参与具体依赖的协商；但当某个团队的依赖平均响应时长连续两个月排进组织末位 20% 时，PMO 主动介入做机制诊断。

这个做法的关键在于"按数据介入"，介入有客观触发条件，不是凭 PMO 主观判断，团队也不会有被针对的感觉。

八、结语：PMO 的价值不在于催，而在于设计

回到开头那个被拖到第 23 周的项目。它的真正问题从来不是某个团队不努力，而是组织结构里存在着 11 条没有人登记的依赖，其中 4 条属于 SF 型，处在管理视野之外长达数月。

过去三年我在 6 个组织里反复确认了一件事：PMO 在依赖管理上的核心价值，不是催进度，而是设计依赖被看见、被承诺、被升级的机制。催促解决的是个案，机制解决的是复发。

如果你希望从这篇文章带走一个最小可执行的起点，我建议就做这三件事：

1. 本周做一次 3 天闪电登记。让每个团队把"需要别人先做点什么"的环节全部列出来，不区分类型，先看总量。
2. 给登记表补两列："触发方向"和"后续动作要求"。这两列能让你自动分出 FS / SS / FF / SF，填写的准确率远高于让人直接选类型。
3. 定一条硬规则并公开宣布：依赖提出后 1 个工作日内必须回应。先跑两周，看响应时长的变化。这一条规则的边际收益，通常大于你接下来三个月做的任何工具优化。

至于工具，等你手里有了真实的依赖数据和至少一轮月度复盘之后再做选型，会稳妥得多。那时候你已经知道自己需要什么，而不是被平台的功能清单牵着走。

依赖效率这件事，说到底是一种组织能力的体现。它不性感，不出彩，但它决定了同样一批人、同样的工作量，能不能在一个合理的周期内把东西交付出来。这也是我认为 PMO 这个角色真正值得被认真对待的地方。