FF落地方案：研发团队开展任务依赖的效率提升案例解析

2024 年 3 月，我接手一个 40 人研发团队的效能诊断。打开他们的迭代看板，一个反差数据很扎眼：单个任务的完成率长期在 85% 以上，但整个迭代的准时交付率只有 52%。团队负责人的第一反应是"估算不准"，第二反应是"人不够"。但我让他们把最近三个迭代里所有"被阻塞超过 2 天"的任务拉出来，按阻塞原因归类，结果排第一的不是估算偏差，也不是人力不足，而是依赖没有在正确的时间被发现，46% 的阻塞时长，来自"我以为你会先做完，你以为我会先给接口"这类信息错位。

这篇文章要讲的 FF 落地方案，就是从这个诊断结果长出来的。FF 在本方案中指 Feature Flag（特性开关 / 功能开关），不是 Fast Forward，也不是某个内部框架的缩写。需要先说清楚的是：FF 本身只是解耦发布依赖的技术手段，它在整件事里的权重远没有很多人以为的那么高。真正让这个团队把准时交付率从 52% 拉到 81% 的，是围绕 FF 建立起来的一套依赖显性化机制。下面我把这套机制的判断逻辑、落地步骤、成本取舍，以及三个迭代内的实测变化完整拆开讲。

一、核心结论：任务依赖治不好，往往是把三种依赖混成了一种

我见过太多团队把"任务依赖"当成一个整体概念来管，开会讨论的是"依赖太多怎么办"，工具里建的是一个叫"依赖"的字段。这是最常见的方向性错误。研发团队里的依赖至少分三种形态，它们的成因、治理手段和可解耦程度完全不同，混在一起谈，结论必然是"没办法"。

1. 结构依赖：代码和架构决定的硬约束

结构依赖指的是，B 任务在物理上必须等 A 任务产出才能开工。最典型的例子是：前端页面要联调，必须等后端接口定义冻结；测试要跑端到端用例，必须等数据库表结构变更上线。这类依赖的根源在系统架构和模块边界，不在人的协作意愿上。

结构依赖的特点是不可消除，只能前移或拆细。你不能让前端不等接口，但你可以把接口定义从"开发完成后给"前移到"需求评审后给"，把一次大联调拆成三次小联调。FF 对结构依赖几乎无能为力，它不会让接口提前出现。

2. 资源依赖：同一个人的时间排在两个地方

资源依赖指的是，两个任务本身没有技术上的先后关系，但它们需要同一个执行者。比如 DBA 只有一个人，两个业务线都要改表；比如设计只有一个人，三条产品线都要出稿。这类依赖的根源是人力配置，不是流程设计。

资源依赖的典型症状是"任务本身没阻塞，但排期一直往后推"。团队复盘时容易误判为"执行力问题"，实际上是同一个资源被并行占用了。解这类依赖靠的是产能可视化和优先级排序，FF 同样不直接解决，但它可以通过减少"必须同时上线"的约束，把资源占用从串行释放成并行。

3. 发布依赖：明明可以各自上线，却被绑在一次发布里

这是 FF 真正发力的地方。发布依赖指的是，A 功能和 B 功能在技术上早已互不阻塞，但因为"要在同一个版本里对外发布""要一起过 UAT""要一起写发布说明"，被迫绑成一个交付单元。发布依赖是三种依赖里最"人造"的一种，也是投入产出比最高的一种。

它的隐蔽之处在于：它不体现在任何一张任务卡上。你在看板上看到的是 A 和 B 并列，看不出它们之间存在一道人为的绑绳。只有当你问"如果 A 明天就能上线，为什么不行"的时候，这根绳子才会暴露出来。

二、背景与真实场景：一个被依赖拖了 5 周的跨端需求

抽象讲依赖治理不容易有体感，我把那个 40 人团队的具体场景还原一下。这个场景后面第五节我会用同一套设定做落地推演，方便你对照。

1. 场景设定：一个本可以 3 周做完的需求

团队规模 40 人，分成三条业务线，共享一个前端组、一个测试组、一个 DBA。他们接的需求叫"会员权益中心改版"，涉及会员等级计算规则变更（后端）、权益展示页重构（前端）、权益核销流程改造（小程序端）、以及一批历史数据迁移（DBA）。

初版排期 3 周，实际交付用了 8 周。多出来的 5 周里，有 3 周以上不是在写代码，而是在等，等接口、等排期、等测试环境、等数据迁移窗口。

2. 依赖是怎么一步步"晚发现"的

第一个延迟出现在第 4 天。前端开始做权益展示页时发现，会员等级的计算规则后端还没定，只有一个模糊描述。前端只能先用假数据搭页面，等规则确定后再改一遍数据层。

第二个延迟出现在第 9 天。规则定了，但后端接口联调要等 DBA 改表；DBA 那个星期在支持另一条业务线的线上问题，改表排到了第 14 天。这 5 天里，前端和后端都在做"不依赖表结构"的部分，效率掉了一半。

第三个延迟出现在第 18 天。核心功能都做完了，测试组说要等小程序端一起提测，因为"权益核销流程要端到端跑才有意义"。小程序端因为另一个需求延期，又拖了 6 天。这 6 天里，后端和前端的功能其实是可测的。

三个延迟里，只有第一个是真正的结构依赖，第二个是资源依赖，第三个纯粹是发布依赖。如果第三次延迟被单独识别出来，用 FF 把后端和前端的部分能力先灰度给内部用户，测试可以提前 6 天开始，整个需求的交付周期至少能压缩 1 周。

3. 我们当时踩的三个坑

（1）依赖是在"开发中发现"的，不是在"排期时识别"的。团队没有依赖识别动作，依赖只能靠个人在做的过程中撞到，撞到了才上报。

（2）依赖的责任人是空的。任务卡上有"依赖事项"字段，但没有"依赖责任人"和"依赖承诺时间"，填了等于没填。

（3）依赖一旦形成，缺一个"是否必须"的复核环节。所有依赖都被默认为硬依赖，没人问过"这个依赖能不能解开"。

三、四个常见误区：为什么大多数团队的 FF 只停留在"上线开关"

在讲正确做法之前，先把错误做法拆干净。下面四个误区，我在过去两年接触的十几个团队里几乎每个都能对上号。

1. 误区一：把依赖管理等同于排期管理

排期管理回答的是"什么时候做完"，依赖管理回答的是"谁能先做完、做完后交给谁、如果没交上怎么办"。这两件事经常被合并成一次会议，然后用一张甘特图承载。

甘特图的问题是，它只画得出"我预期的时间顺序"，画不出"这个顺序是可以被改的"。依赖管理的核心产出不是时间表，而是一张"关系可变更清单"，哪些关系是硬的、哪些是软的、软的怎么变硬、硬的怎么前移。没有这张清单，排期只是把不确定性写成了确定的日期。

2. 误区二：FF 只是上线时的保险绳

这是最普遍也最可惜的误区。很多团队引入 FF 的动机是"上线出问题可以一键关掉"，所以 FF 的生命周期被设计成"发布前创建 → 发布后观察 → 稳定后删除"。整个过程里，FF 只在发布那一刻发挥作用。

但 FF 真正的价值发生在发布之前：它让"代码合并"和"功能对外可见"这两件事解绑，从而把原本必须串行的发布依赖，转成可以并行的开发行为。一个团队如果只在发布时用 FF，等于买了一把能开锁的钥匙，却只用它来压纸。

3. 误区三：依赖字段填了，责任人却是空的

这个误区看起来低级，但改善效果立竿见影。我们做过一次统计：在同一个团队里，把"依赖事项"字段的填写率从 43% 提到 92% 之后，阻塞任务数几乎没变；但把"依赖责任人 + 依赖承诺时间"两个字段的填写率从 11% 提到 85% 之后，阻塞时长中位数从 4.2 天降到 1.8 天。

原因很简单：没有责任人的依赖，是一条无人认领的消息；有责任人的依赖，是一条待办事项。前者会在群里被刷过去，后者会在每天早上出现在某人的待办列表里。

4. 误区四：只盯跨团队依赖，忽略同职能内部依赖

跨团队依赖因为"看起来更严重"而被重点关注，同职能内部依赖则容易被默认不存在。实际上，前端组内部两个模块共用一套组件、后端组内部两个服务共用一张缓存表，都是典型的同职能依赖，它们出问题的概率不比跨团队低，而且更难被外部发现。

同职能依赖的治理难点在于信息不对称更隐蔽：大家都觉得"我们自己人，随口说一声就行"，于是不留痕、不设期限、不做交接检查。等到联调时才发现，两边对这组件的理解完全不一样。

四、专业判断逻辑：依赖显性化的三层模型，以及 FF 的介入位置

现在讲方法论。我把依赖治理拆成三层能力，从下往上依次是关系显性化、责任显性化、节奏显性化。这三层不是并列关系，而是有严格顺序的，跳过下层直接做上层，工具上了也没人用。

1. 第一层：关系显性化，把"谁知道"变成"谁都能看到"

这一层要解决的是"依赖存不存在"的问题。做法是把依赖从人的脑子里、聊天记录里、口头承诺里，搬到结构化的数据里，并且定义清楚依赖的四个属性：

• 前置任务：必须要等的那个任务，指向唯一 ID，不写描述性文字
• 依赖类型：结构依赖 / 资源依赖 / 发布依赖，三选一，不允许留空
• 硬软属性：硬依赖（技术上不可绕过）还是软依赖（流程上人为约定）
• 最早可开工时间：前置任务做到什么程度，下游就能开工，这个字段是后面 FF 解耦的关键输入

很多团队只做前两项就停了，结果依赖图能画出来，但没人知道怎么用。"最早可开工时间"这个字段的价值在于，它把"必须等 B 全部做完"这种模糊描述，逼成了"B 的接口定义了就能开工"这种可操作的判断。80% 的发布依赖，都是在这个问题上被问出来的。

2. 第二层：责任显性化，每条依赖都要有人签字

第二层要解决的是"依赖失控了找谁"的问题。每条依赖必须有且只有一个责任人（前置任务负责人），并且有一个承诺交付时间。这个承诺时间不是任务截止时间，而是下游能开工所需的最小交付物时间。

这两者的区别非常关键。任务截止时间是"我做完了"，承诺交付时间是"别人能开始了"。一个后端任务可能还有 5 天才截止，但接口定义今天就能给，那承诺交付时间就是今天。把这两个时间分开，能让下游提前 3-5 天开工，这在两周一个迭代的节奏里就是 20% 以上的产能提升。

3. 第三层：节奏显性化，FF 真正介入的地方

第三层要解决的是"能不能不等"的问题。前两层做完之后，你会发现手头有一大批软依赖，它们的共同特征是：技术上早就可以开工或上线，只是被流程约定绑住了。FF 就是在这一层发力的。

一个功能被 FF 包起来之后，它有三种状态：代码合并但开关关闭（对用户不可见）、开关部分放量（对种子用户可见）、开关全量打开（对所有用户可见）。这三种状态的分离，把"发布"从一个时间点变成了一个过程。原本必须等整个版本一起发布的约束，就可以被拆成若干次独立的、可回滚的小发布。

4. 判断一个依赖该不该用 FF 解耦的四个问题

不是所有依赖都值得用 FF 解。FF 有成本，滥用会带来开关债（第八节详述）。我在实践中总结了四个问题，四个都答"是"才建议引入 FF：

1. 这个依赖是发布依赖而不是结构依赖吗？如果代码跑不起来，FF 开关打开也是报错，那就不是 FF 的问题。
2. 功能被隐藏时，系统仍然可用吗？如果新功能涉及数据结构变更，关闭开关可能导致旧数据读取失败，那需要配套的兼容层设计，成本会上升一档。
3. 这个开关的生命周期能明确吗？如果说不清"多久之后可以删掉"，那它大概率会变成永久开关债。
4. 收益能覆盖成本吗？如果一个依赖只绑了两天工期，为它引入一个 FF 并写测试、做清理，投入产出比是负的。

5. 一段可复用的 FF 定义代码

下面是我实际用过的一个 FF 定义结构（JSON 格式，字段名做了简化）。重点是每个开关都强制带 owner 和 expiry，这是防止开关债最有效的一招，如果创建开关时填不出过期时间，说明这个开关本身就没想清楚。

{
"flag_key": "member_benefit_v2_page",

"flag_type": "release",

"owner": "frontend-lead@team",

"created_at": "2024-05-06",

"expiry_date": "2024-07-15",

"cleanup_ticket": "DEBT-2291",

"default_value": false,

"rules": [

{ "target": "internal_user", "percentage": 100 },

{ "target": "beta_group",    "percentage": 10  },

{ "target": "all_user",      "percentage": 0   }

],

"dependency_unlock": [

{

"blocked_task": "TEST-E2E-018",

"unlock_condition": "flag=ON for internal_user",

"note": "内部灰度打开后，端到端测试可提前 6 天开始"

}

]

}

其中 dependency_unlock 字段是我自己加的，它的作用是把"这个开关解开了哪条依赖"写死在配置里。这样在复盘时可以直接统计：本迭代引入了 14 个开关，解开了 14 条发布依赖，其中 9 条节省了 3 天以上的等待。把收益和开关绑定，是让 FF 从"运维工具"变成"效能工具"的关键一步。

五、落地案例：40 人团队的 FF 依赖解耦四步推演

回到第二节那个 40 人团队的场景。下面是我给他们的实际落地方案，分四个阶段，全程 6 周。为保护团队信息，具体数字标注为示意性推演，但阶段划分和动作是真实的。

1. 阶段一：依赖盘点（第 1-2 周）

第一步不是上工具，是让所有人把手上任务的依赖写出来。我给了一个很笨但有效的办法：每人用一张纸，写下自己当前任务的"我在等谁"和"谁在等我"，然后贴在墙上，两天内贴满。

这一步的产出是一张全量依赖清单。这个团队最后贴出了 100 多条依赖，其中 43% 是发布依赖，31% 是资源依赖，26% 是结构依赖。有意思的是，在贴出来之前，团队负责人预估的发布依赖比例只有 15%，这就是依赖隐形化的代价：你对依赖类型的判断，可能和实际情况差三倍。

盘点时问三个问题，能快速区分依赖类型：

• "如果它今天做完了，我明天能开工吗？"，不能开工的是结构依赖
• "如果我加班做，它能提前吗？"，不能提前的是资源依赖（因为瓶颈在别人身上）
• "如果它做完了但不对外发布，我能先测吗？"，能测的是发布依赖

2. 阶段二：FF 分层设计（第 3 周）

第二步是把可解耦的发布依赖映射成 FF。这里最关键的动作是给开关分层，而不是给每个依赖配一个开关。开关数量失控是 FF 落地最常见的死法。

我们用的是四层分类法，每一层有不同的生命周期和清理规则：

这个团队最终识别出 31 条可解耦依赖，但只落地了 24 个开关，因为其中 7 条被判定为"为两天工期引入一个开关不划算"。主动放弃是这套方法的一部分，不是执行不到位。如果所有依赖都配开关，半年后你会有 200 个开关，没人知道哪个能删。

3. 阶段三：灰度与清理机制（第 4-5 周）

第三步是把开关用起来，同时把清理做成自动化。我要求三件事：

1. 每个开关创建时必须填 expiry_date 和 cleanup_ticket，两个字段任何一个为空，CI 流水线直接拒绝合并。
2. 灰度分三档固定：内部用户 100% → 种子用户 10% → 全量。不允许自定义乱七八糟的档位，减少认知负担。
3. 每周一自动生成开关健康报告，列出已过期未清理、超过 60 天未变更、owner 已离职的三类开关。

第 2 条看起来是限制，实际是提效。当灰度档位标准化之后，测试同学的用例设计可以直接按档位来，不需要每次问"这次灰度的口径是什么"。

4. 阶段四：复盘与机制沉淀（第 6 周）

第四步是把这次的经验变成下次的默认动作。我们沉淀了三样东西，都写进了团队的研发流程文档：

（1）依赖识别前置到需求评审。每个需求进入排期前，必须产出一张依赖清单，没有清单不允许进迭代。

（2）阻塞超 2 天自动升级。任务被标记阻塞满 2 天，自动通知依赖责任人及其主管，不需要人工提醒。

（3）每次迭代复盘统计"依赖解耦收益"。指标是"因 FF 解耦而提前开工的人天数"，这个数字让 FF 的投入有了说法，也让团队愿意继续维护这套机制。

六、工具承载：依赖关系必须变成"可计算的数据"

前面五节的机制，用白板和 Excel 也能跑。问题是它能撑多久。那个 40 人团队在用白板跑完第一个迭代之后就发现，依赖清单一旦超过 50 条，人工维护的准确性就崩了，没人知道某条依赖的上游任务昨天改过排期。

1. 为什么表格加群聊撑不过 100 人

我把工具能力的门槛分成三档，每档对应一个团队规模区间：

• 50 人以下：Excel + 每日站会足够。依赖数量少，人少，靠沟通能覆盖。
• 50-100 人：需要结构化承载。依赖必须作为任务对象的属性存在，而不是表格里的一行，否则改一处要手动同步三处。
• 100 人以上：需要依赖关系的自动传播和阻塞自动升级。一条依赖变更要能自动影响下游排期、自动通知相关人、自动进入报表。

分界线不在人数本身，而在依赖关系是否需要跨项目、跨迭代地被引用。当一个依赖的上游在下个季度、下游在本季度，靠表格维护必然出错。

2. 平台在依赖治理中的三个具体落点

我们最终选的是 PingCode。选它的原因不是功能多，而是它的对象模型能承载前面讲的这套机制。PingCode 主要服务中大型企业及 100 人以上组织，这正好对应上面第三档的门槛。具体有三个落点：

（1）依赖作为一等对象存在。在 PingCode 里，任务之间的依赖关系是可以被引用和查询的，不需要靠自定义字段拼凑。这意味着"某条依赖变更后，自动列出受影响的下游任务"这种操作，是做得到的。之前用表格时，这一步靠人肉筛。

（2）跨项目依赖的可视化。三条业务线、多个迭代并行时，最容易出问题的就是跨项目依赖。平台能把这些依赖收敛到统一视图里，避免了"每条业务线各自维护一份清单、彼此不知道对方改了"的情况。

（3）支持私有化部署，且支持 Jira 平滑迁移。这一条对中大型企业尤其关键。很多 100 人以上的团队不是不想换工具，而是历史数据迁不动、安全合规过不去。PingCode 支持私有化部署，数据留在自己机房里；同时在 Jira 迁移上做了较完整的字段映射和依赖关系保留，迁移过程中不需要重建全部历史依赖。在国产替代这个语境下，它是一个可以直接进入评估清单的选项。

3. 什么情况下该换平台，什么情况下不该换

我不想把这件事说成"必须换"。以下几种情况，我的判断是先别换工具：

• 依赖清单还不足 30 条：先把关系显性化的动作跑顺，工具换了也是白换
• 团队还没有"依赖责任人"这个概念：工具只是放大了机制，机制不存在时工具放大的是混乱
• 只需要解决单一项目的内部依赖：现有的任务看板加两个字段就能应付

以下情况，工具会成为瓶颈，值得评估更换：

• 依赖关系需要跨项目、跨迭代引用，且数量超过 80 条
• 存在安全合规要求，必须私有化部署
• 需要统计"依赖解耦收益"这类跨迭代指标，而现有工具只能导出原始数据手工算

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

方法论说得再完整，落到具体团队还是得看规模和历史包袱。下面按四种典型情况给出建议，你可以直接对照自己的处境。

1. 20 人以下团队：不要上 FF，先把责任显性化

这个规模的团队，沟通成本低，依赖数量通常不超过 30 条。引入 FF 的性价比极低，你为了省 2 天等待，增加了一套开关维护、测试矩阵和清理流程。

建议的动作只有一个：每天站会上，每人回答"我在等谁、谁在等我"。把这两个问题的答案写在共享文档里，坚持两周，你会发现 80% 的依赖问题自己消失了。如果两周后还有超过 5 条长期阻塞的依赖，再考虑引入 FF。

2. 20-100 人团队：补责任和承诺时间，按需引入 FF

这个区间是 FF 收益最明显的阶段。建议按顺序做三件事：

1. 把"依赖责任人"和"依赖承诺交付时间"变成任务卡的必填项，并在迭代准入时检查
2. 用第三节的三个问题区分依赖类型，统计发布依赖占比。占比超过 30% 才值得引入 FF
3. 引入 FF 时，从规模最大的那一条发布依赖开始，不要一次铺开

这个阶段最容易犯的错是"全面铺开"。我见过一个 60 人团队在一个迭代里上了 40 个开关，两周后没人说得清哪个开着哪个关着。从一条依赖试点，跑通清理机制，再扩到三条，比一次性上 40 条安全得多。

3. 100 人以上团队：机制和工具同时建，优先评估私有化能力

这个规模上，依赖治理已经不是流程问题，而是数据问题。你需要能回答"当前有多少条跨项目依赖未解决""哪些依赖的承诺时间已经逾期超过 3 天"这类问题，而这些靠人工统计是不可能的。

建议的动作：

• 把依赖作为一等对象纳入工具，而不是自定义字段
• 建立阻塞升级机制，超时自动通知，不依赖人的主动性
• 评估平台时优先确认三点：能否承载跨项目依赖、能否私有化部署、能否平滑迁移历史数据

这三点里，第三点经常被低估。一个 200 人团队的研发数据往往是几年积累下来的，迁移如果要从零重建依赖关系，实际推行阻力会远超预期。

4. 正在使用 Jira 的团队：先评估迁移成本，再决定路径

如果你的团队已经在用 Jira 并且运转良好，不要为了"国产替代"这个理由就贸然迁移。先做一件事：统计当前依赖关系的数量和复杂度。

如果依赖关系主要靠链接类型（blocks / is blocked by）承载，且数量在 200 条以内，迁移风险可控。如果依赖关系散落在自定义字段、描述文本和评论里，迁移会是一个需要专门立项的工程。这时候更应该关注的是迁移工具能否保留依赖关系本身，而不只是迁移任务标题和状态。

八、不同情况下的取舍：FF 不是免费的

前面七节都在讲 FF 的收益，这一节必须讲代价。我见过不止一个团队，因为 FF 用得太顺手，两年后系统里挂着 300 多个开关，没人敢删，也不敢动。

1. 三项隐性成本，必须提前算进去

（1）测试矩阵膨胀。一个开关有两个状态，两个开关有四个组合，五个开关理论上 32 种组合。实际不可能全测，于是每次发布都要做取舍：这次测哪几个组合？这个取舍过程本身就是成本，而且它会随着开关数量非线性上升。

（2）代码路径污染。开关关闭的代码路径长期存在，会让代码可读性快速下降。新加入的成员看到 if (flag) {...} else {...} 时，第一反应是"这个 else 分支还有人用吗"，而没人能给出确定答案。

（3）组合状态不可复现。线上出问题时，你不仅要知道当前代码版本，还要知道当前所有开关的状态。如果开关状态没有版本化记录，一次故障排查可能要花半天在"复现环境"上。

2. 什么时候宁可用硬依赖，也不要 FF

以下几种情况，我的建议是老老实实排硬依赖：

• 依赖的等待时间在 2 天以内：引入开关的成本高于等待成本
• 功能涉及不可逆的数据变更：比如数据迁移、存量数据格式变更，开关关不掉已经写坏的数据
• 功能无法在部分可见的状态下工作：比如必须全量开启才有业务意义的强一致性功能
• 团队还没有开关清理机制：没有清理机制的开关，等于给未来埋债

第三条经常被忽略。有些功能本质上是"全有或全无"的，硬要拆成灰度，反而制造出一堆中间状态，让业务逻辑变得难以理解和测试。

3. 一张取舍清单

我把上面的判断压缩成一张可以直接用的清单。每个依赖过一遍，六个问题里超过两个答"是"，就说明需要慎重：

九、总结与下一步：先显性化，再解耦，最后才谈工具

回到开头那个反差数据：85% 的任务完成率和 52% 的准时交付率。中间那 33 个百分点的差距，绝大部分不是靠加班补回来的，而是靠三件事：把依赖写出来、把责任挂上去、把能解开的发布依赖解开。

我的核心判断是：任务依赖管理的本质不是排期问题，而是协作不确定性的显性化问题。FF 是一件好工具，但它只作用在最后一环，它解不了结构依赖，也解不了资源依赖，它能做的是把那些"本来就不必绑在一起"的发布依赖剪开。如果一个团队连依赖清单都没有，引入 FF 只会让它多一个没人管理的开关列表。

所以我给出的执行顺序是固定的，不建议调换：

1. 第 1-2 周，只做依赖盘点。用纸和墙都行，目标是让所有人知道有多少条依赖、分别属于哪一类。
2. 第 3-4 周，补责任人和承诺交付时间。这一步不需要任何工具支持，但通常能带来 30% 以上的阻塞时长下降。
3. 第 5 周，筛选可解耦的发布依赖。用第四节那四个问题过一遍，把不值得解耦的主动剔除。
4. 第 6 周，从小范围开始引入 FF。先做 1-3 个，把清理机制跑通，再考虑扩大规模。
5. 第 8 周之后，再评估工具承载能力。当依赖超过 80 条、需要跨项目引用、或存在私有化部署要求时，才值得把工具选型提到台面上。

如果你现在就想动手，我建议今天先做一件最小的事：把你手上正在做的任务里，"我在等谁"和"谁在等我"这两个问题的答案写下来，发到团队群里。你会立刻收到两种反馈，一种是"我以为你早就做完了"，另一种是"这个不用等我，你可以先做"。这两种反馈，就是依赖治理全部的起点。