SF最佳实践：实施团队任务依赖协同管理，常见问题

三月底，一条代号 SF 的实施交付线在客户验收前一周炸了。不是技术问题：三个下游任务在等同一个上游数据接口，接口负责人以为交付节点是月底，下游团队以为月中就要；测试环境被另一条并行线占着，没人知道该找谁仲裁；等到项目经理把依赖关系画出来，关键路径上只剩 4 天缓冲，而剩余工作量按人天折算需要 11 天。最后的结果是分两批上线，第一批砍掉了两个非核心模块，返工 6 个人天，客户满意度从预期的 9 分掉到 7 分。

这类事故我在过去几年里见过太多次。它们的共同点不是团队不努力，恰恰相反，出事的那条线往往是加班最多的。问题出在：大家都在管任务，但没有人管任务之间的依赖。任务能被看见，依赖却经常只存在于某个人的脑子里、某次站会的口头承诺里、某个微信群的接龙里。

这篇文章我把过去几年在实施交付线里踩过的坑、用过的机制、以及最终沉淀下来的模板和指标，完整写出来。文中提到的数据来自我们内部对 6 条交付线的脱敏复盘统计，属于小样本，只用于说明趋势，不代表行业普查结论；凡是示意数据我都会标注清楚。

一、先给结论：依赖协同失败，九成不是执行力问题

先把我最核心的判断放在前面：任务依赖协同管理的失败，绝大多数不是态度问题、不是沟通问题，而是机制缺位问题。你让一群很努力的人用错误的方式协作，他们只会更快地撞墙。

1. 三个反常识结论

第一个结论：依赖管理的瓶颈不在“看见”，而在“承诺”。大部分团队其实能看到依赖，通过甘特图、通过项目经理的脑子、通过站会上的口头同步。但“看见”不等于“有人认领”，更不等于“有人给出可被追踪的日期”。没有 Owner 和承诺日期的依赖，本质上是一条没有接线的高压线，看着存在，实际不通电。

第二个结论：依赖的破坏力集中在交付后期释放。因为依赖问题在早期表现为“进度正常”，直到上游延期穿透了下游的全部缓冲，才会集中爆发。这就是为什么很多项目在前 70% 时间里看起来风平浪静，最后 30% 突然变成救火现场。

第三个结论：度量口径的值钱程度，远高于工具选型。我见过团队换了三套工具，阻塞时长依然降不下来；也见过团队只靠一张结构化表格加一个每周 30 分钟的依赖同步会，把按期关闭率从 38% 拉到 70% 以上。工具是放大器，口径是电源。没电的时候，放大器再贵也没用。

2. 一张自检表：你的团队处在哪一级

下面这张表是我用来快速判断一条交付线依赖治理成熟度的自检工具，你可以直接对着自己团队打分。四个层级的区别不在于“有没有工具”，而在于“依赖有没有被结构化和被承诺”。

我的经验是：从 L1 到 L2 的收益最大，也最难。因为 L1→L2 要求每个依赖必须有一个具名的承诺人，这直接触碰了组织里的责任边界。很多团队卡在这一步，不是技术做不到，而是没人愿意在系统里写下一个可能被打脸的日期。

3. 本文说的 SF 指什么，边界在哪里

必须先澄清一个高频混淆点。本文中的 SF，指的是我们内部对一条 CRM 类实施交付线的场景代号，同类场景包括 Salesforce 类 CRM 实施、企业内部交付系统落地、以及跨部门业务系统上线。它不是一个通用的方法论缩写。

如果你的团队里 SF 指别的东西，比如某个自研系统的代号、某条交付产品线，把文中所有对象替换成你的对应角色即可，机制层面完全通用。但有一点必须避免：不要把 SF 和 SFIC 协同治理模型混为一谈。后者是一套协同治理的分析框架，有它自己的概念边界和来源，需要回到原始文献核实后再引用。我见过不止一篇文章把两者硬拼在一起，读起来很唬人，落地时全是空的。

本文讨论的边界也很明确：只讲实施交付团队内部和跨团队的任务依赖协同，不讲供应商合同、不讲商务层面的依赖。范围收窄，方案才能具体。

二、真实场景：一条 SF 交付线的依赖失控全过程

抽象地讲依赖管理没意义，我们把一条真实的线拆开看。这条线大约 40 人，包含产品、实施、集成、测试四类角色，交付周期 14 周，上线目标是替换客户原有系统的一个核心业务模块。

1. 项目背景与角色分工

团队结构上，产品负责需求确认与验收标准，实施负责配置与数据迁移，集成负责与客户第三方系统对接，测试负责验证。听起来清楚，但问题在于：四类角色之间没有任何一份显式的依赖清单。所有依赖关系都隐含在“流程应该这样走”的默认假设里。

比如数据迁移需要客户提供历史数据，历史数据的清洗又依赖集成团队打通客户的数据接口，而接口权限的审批要走客户的 IT 流程，这条链条上有三个不同组织的人，但没有任何一个地方记录着“谁在等谁、等到什么时候”。

2. 时间线复盘：依赖是怎样一步步爆炸的

把事故拆成时间线之后，问题就非常清楚了。这条线不是某一个环节崩了，而是四个环节各自延一点点，最后叠加在一起炸掉。

1. 第 3 周：集成团队发现客户接口权限审批需要走 IT 流程，口头说要“提前准备”，但没有进入任何登记表，也没有承诺日期。
2. 第 6 周：产品确认了验收标准，但变更了三个字段口径，实施团队已经按旧口径配了一半，返工 4 人天，此时缓冲还剩 9 天。
3. 第 9 周：客户 IT 审批通过，比预期晚了两周。集成团队开始对接，但测试环境被另一条并行线占用，排队等待 5 天。
4. 第 12 周：集成完成，测试时间被压缩到 4 天，测试团队提出压缩不可接受，问题升级到交付负责人，但此时已经没有重排空间。
5. 第 13 周：决定分批上线，砍掉两个非核心模块，关键路径上仅剩 4 天缓冲，实际需要 11 天工作量。

注意第 1 步和第 3 步：这两处都不是“工作没做”，而是工作在等待状态里空转。等待是不产生任何产出的时间，而恰恰是最容易被忽略的成本。我们内部统计过一个口径，在这类交付线里，任务的平均阻塞时长能占到项目总周期的 15%-25%。

3. 事后的四个可量化信号

复盘时我们提炼出四个早期信号，它们比“进度是否正常”更早发出预警。如果你在项目里看到其中两个以上同时出现，基本可以判断依赖治理已经失效。

• 信号一：依赖平均等待时长超过 3 个工作日。说明上游响应没有约束，等待正在成为常态。
• 信号二：超过 30% 的依赖没有具名 Owner。说明责任边界模糊，出问题时只能靠催。
• 信号三：计划重排在单个里程碑周期内超过 2 次。说明排期不是基于依赖推导出来的，而是拍出来的。
• 信号四：升级请求的平均响应时长超过 24 小时。说明没有仲裁机制，问题在组织内部漂移。

这条线在事故前的第 6 周，四个信号全部命中。如果当时有人看这些指标，其实还有 6 到 8 周的窗口可以补救。这就是度量的价值：它不能阻止问题发生，但能把你从“事后震惊”变成“事前预警”。

三、拆解八个最常见误区

下面这八个误区，是我在实施交付线里反复见到的。它们的共同特征是：看起来都很合理，甚至听起来很专业，但落地之后会让依赖治理彻底空转。

1. 误区一：把依赖问题当成“沟通问题”

这是最普遍也最有害的一个。一旦把依赖失控归因为“沟通不畅”，解决方案自然就变成“加强沟通”“多对齐”“拉个群”。

但沟通解决的是信息传递，不解决承诺与责任。真正的依赖问题往往是这样：信息早就传到了，对方也知道你在等，但对方没有义务在某个具体日期之前给你。这不是沟通问题，这是缺乏承诺机制。加强沟通只会让催得更勤，等待时间未必缩短。

2. 误区二：只在站会上口头同步依赖

站会是同步“我昨天做了什么、今天做什么、有什么障碍”的地方。它的时间尺度是 24 小时，而依赖的时间尺度往往是 1 到 3 周。用 24 小时的机制去管 3 周的问题，必然失真。

更麻烦的是口头同步不可追溯。三周后你说“我早在那次站会上提过了”，对方说“我当时理解为下周才要”，双方都没有证据。依赖必须落到一个可以被查证的载体上，哪怕它只是一张共享表格。

3. 误区三：依赖没有 Owner，只有“催”

“催”是一种没有结构的活动。它的效果取决于双方关系、当时的忙碌程度、以及谁更能扛。这三点都不稳定。

正确的做法是给每个依赖指定两类角色：请求方（Requester）和承诺方（Committer）。请求方负责描述依赖内容、期望日期和影响范围；承诺方负责给出可兑现的日期，并在无法兑现时主动发起升级。注意，这里的承诺方通常是上游任务的负责人，而不是某个“协调岗”。

4. 误区四：所有依赖都当“高优先级”

当所有依赖都是 P0，就没有依赖是 P0。我见过一份依赖清单上有 47 条依赖，其中 31 条标着“紧急”。这种清单的实际作用是让读者放弃阅读。

依赖的优先级应该由是否落在关键路径上决定，而不是由提出者的着急程度决定。一条不在关键路径上的依赖，延期两周可能对交付日期毫无影响；一条在关键路径上的依赖，延期两天就可能吃掉全部缓冲。

5. 误区五：依赖登记表变成“僵尸表”

登记表刚建立时大家很积极，两周之后没人更新，一个月之后彻底失效。原因通常有三个：字段太多填不动、更新没有反馈、以及没有人在会上真正使用它。

我的建议是字段控制在 7 个以内，且每个字段都必须在某个固定会议上被使用一次。如果一个字段从来没有人读，就删掉它。表格的价值在于被使用，而不在于完整。

6. 误区六：用甘特图代替依赖治理

甘特图擅长表达时间跨度，不擅长表达依赖链的传导。当上游延期 3 天，甘特图上显示的是条形块右移，但下游到底哪几个任务会受影响、缓冲会被吃掉多少、是否需要重排，图上看不出来。

更关键的是，甘特图通常是项目经理一个人维护的。它反映的是管理者的理解，而不是团队成员的承诺。依赖治理要求的是每个承诺方自己维护自己的承诺状态，这一点甘特图天然做不到。

7. 误区七：多设备、多系统下没有单一事实源

现实中依赖信息经常散落在四个地方：项目管理系统里的任务、聊天群里的接龙、邮件里的确认、以及某个人本地的表格。每一处都只有部分真相。

这时候团队会出现一种典型症状：同一个依赖在不同人嘴里有不同状态。产品说“已经确认了”，实施说“还没收到”，集成说“我以为上周就完成了”。这不是谁在说谎，而是没有单一事实源。所有依赖协同的前提，是先约定一个唯一可信的状态存放位置。

8. 误区八：概念混用，把不同框架硬拼在一起

最后一个误区是概念层面的。有些文章会把 SF 场景、SFIC 协同治理模型、以及各类执行力方法论混在一起讲，读起来内容很丰富，落地时无从下手。原因很简单：这些框架的抽象层级不同，解决的问题也不同。

我的建议是做减法：先把 SF 场景下的依赖类型、负责人、承诺日期、升级路径这四件事做扎实，再考虑引入更上层的治理框架。抽象框架只有在具体机制跑通之后才有价值，否则只是给混乱披上一层术语外衣。

四、专业判断逻辑：依赖协同的三层模型

讲完误区，说方法。我把依赖协同拆成三层：可识别、可承诺、可升级，外加一层贯穿始终的度量。这三层是递进关系，跳级做基本都会失败。

1. 第一层：可识别，依赖登记与类型划分

识别的第一步是定义依赖类型。按约束方式分，常见有四类：完成，开始（上游完成后下游才能开始，最常见）、开始，开始（两边同时开始但需要同步节奏）、完成，完成（必须同时完成）、开始，完成（上游开始后下游才能收尾，最少见但最容易漏）。

按资源性质分，还可以分成信息依赖（等需求口径、等接口文档）、审批依赖（等客户或合规审批）、环境依赖（等测试环境、等数据）、人员依赖（等某个特定专家有空）。这个分类的实用价值在于：不同依赖类型的解决动作完全不同。审批依赖要靠提前发起流程，环境依赖要靠资源排队规则，人员依赖要靠备份人选。

识别方法上，我常用的有四种组合：依赖矩阵（角色 × 角色的交付物对应表）、接口清单（系统间的数据流向清单）、里程碑反推（从验收日往前推每个环节的最晚开始时间）、跨团队访谈（每个角色说出“我在等谁”和“谁在等我”）。

2. 第二层：可承诺，Owner、承诺日期与影响面

承诺不是一句“我尽量”，而是一组结构化信息：谁承诺、承诺什么、承诺到什么时候、如果做不到会影响什么。这四个要素缺任何一个，承诺就不可追踪。

重点说“如果做不到会影响什么”。很多团队登记依赖时只写“需要接口文档”，不写影响面。等到延期时，没人能判断这条依赖的严重程度。正确写法是把它和下游任务、里程碑、以及客户可见的交付物挂钩。比如“该接口文档延迟 3 天，将导致数据迁移任务启动延后，直接影响验收批次一的上线时间”。

一旦影响面写清楚，优先级和升级必要性就自动浮现了，不需要靠谁嗓门大来争。

3. 第三层：可升级，升级路径与响应 SLA

升级机制是三层里最容易被跳过的，也是最容易见效的。它的设计其实很简单，只需要定义三件事：什么条件下升级、升级给谁、多长时间内必须响应。

什么条件下升级：我的经验是用“缓冲消耗比例”作为触发条件，而不是用“延期天数”。比如承诺日期还剩 3 天但完成度低于 60%，或者依赖延期已经吃掉了下游里程碑 30% 以上的缓冲，就自动触发升级。这个口径比“延期超过 2 天”更贴近实际风险。

升级给谁：必须明确到角色而不是人。一级升级给双方的团队负责人，二级升级给交付负责人或项目委员会。关键是每一级都要有裁决权，而不是只做传声筒。

4. 贯穿层：度量口径怎么定才不会被玩坏

度量最容易犯的错误是选了可以被轻易美化的指标。比如“依赖关闭率”，只要把登记表里的依赖删掉，关闭率就是 100%。所以指标必须成对出现，一个是效率指标，一个是质量指标。

我在实际项目里用的六个核心指标是：依赖登记完整率、Owner 明确率、承诺日期覆盖率、按期关闭率、平均阻塞时长、升级平均响应时长。前三个是过程指标，后三个是结果指标。只看结果指标你会不知道为什么好或坏，只看过程指标你会陷入为填表而填表。

五、具体案例与数据观察：用 PingCode 搭一条依赖治理链路

讲完方法，讲工具落地。这一节我用 PingCode 作为示例来说明完整链路，它是面向中大型企业、主要服务 100 人以上组织的研发与项目管理平台，支持私有化部署，也支持从 Jira 平滑迁移，是我在实际交付线里见过落地成本比较低的一类选择。

需要说明：下面提到的字段设计和自动化规则是可运行的思路示例，不同组织的工作项模型会有差异，具体配置请以你们实际环境为准。

1. 为什么用平台而不是共享表格

共享表格在 L1 阶段很好用，团队 30 人以内、单项目的时候完全可以跑。但一旦出现三个问题，就必须换平台：跨项目依赖变多、需要按角色做权限隔离、以及需要自动化提醒和超时升级。

表格做不到这三点。它无法自动判断“承诺日期还剩 3 天但状态未变”，也无法把依赖关系和里程碑、迭代、版本关联起来。依赖治理的自动化程度，直接决定了它能撑住的团队规模。

2. 依赖登记：用工作项类型加自定义字段落地

核心思路是把“依赖”做成一个独立的工作项类型，而不是任务上的一个标签。独立工作项才能有自己的负责人、状态、日期和流转规则。字段设计上控制在 7 个左右，下面是我用的一版结构：

依赖工作项字段设计（示例）
—

dependency_id 依赖编号 自动生成，如 DEP-0142

dep_type 依赖类型 枚举：完成-开始/开始-开始/完成-完成/信息/审批/环境

requester 请求方 指向提出依赖的下游任务负责人

committer 承诺方 指向上游任务负责人（必填，不允许为空）

committed_date 承诺日期 必填，不允许填写区间或“尽快”

impact_scope 影响面 关联下游任务 + 里程碑 + 验收批次

buffer_consumption 缓冲消耗比例 自动计算，超过 30% 触发升级标记

status 依赖状态 未承诺/已承诺/进行中/已交付/已延期/已关闭

其中有两个字段是我强烈建议设为必填的：承诺方和承诺日期。允许这两个字段为空，等于允许依赖不成立。buffer_consumption 这个自动计算字段是我认为最有价值的一处设计，它把“延期严重不严重”从主观判断变成了可计算的值。

3. 依赖可视化：跨项目视图与关键路径

登记之后要能看见。单项目的依赖清单意义有限，真正有价值的是跨项目的依赖视图，把所有团队的依赖集中到一个看板，按承诺日期排序，用颜色区分缓冲消耗比例。

我通常配三个视图：第一个是“本周到期依赖”，用于日会跟进；第二个是“缓冲消耗超 30% 依赖”，用于周度风险评审；第三个是“无 Owner 或无日期依赖”，用于治理健康度检查。第三个视图特别重要，它是防止登记表退化成僵尸表的关键，每周把所有字段缺失的依赖拉出来，就能立刻看出谁在敷衍填表。

4. 升级与自动化：让超时依赖自己浮出来

依赖治理最大的敌人是沉默。一条依赖卡住了，但没人主动说，它就会一直卡到爆炸。自动化规则的作用就是打破沉默。下面是一组可以照搬的思路示例：

依赖自动化规则示例
—

规则1 承诺日期前3天且状态未变

动作：向 committer 和 requester 发送提醒，标记“临期依赖”

规则2 超过承诺日期仍未交付

动作：状态自动置为“已延期”，buffer_consumption +Δ，推送至团队负责人

规则3 buffer_consumption > 30%

动作：自动创建升级记录，通知交付负责人，纳入当周风险评审

规则4 依赖创建后24小时内无 committer

动作：回退至 requester 并提示“请指定承诺方”，计入 Owner 明确率分母

规则5 依赖关闭时 committer 与 committed_date 为空

动作：不允许关闭，阻断流转

规则 4 和规则 5 是我最推荐的两条。规则 4 用轻微的不便逼出责任分配，规则 5 用流程阻断保证数据完整。没有阻断机制的数据治理，最后都会变成自愿填表。

5. 数据观察：治理前后六个指标的变化

在一条 60 人左右的交付线上，我们把上面这套机制跑了两个完整迭代周期，约 10 周。下面是治理前后六个指标的变化，属于我们内部脱敏统计，样本单一，只用于说明机制效果的量级。

有一点要诚实说明：按期关闭率从 31% 到 72%，其中一部分来自统计口径的变化，因为治理前有大量依赖根本没被登记，分母偏小且偏向容易的项目。但即便扣除口径影响，阻塞时长的下降是实打实的，因为它直接反映在里程碑准时率上（该线从 54% 提升到 86%）。

6. 私有化部署与 Jira 迁移中的依赖管理注意点

对 100 人以上的组织来说，工具选型往往会被两个现实约束绑住：数据合规要求和历史系统迁移。PingCode 在这两点上的做法比较适合中大型组织，支持私有化部署，也支持从 Jira 平滑迁移。

但迁移过程本身会产生新的依赖风险，这一点很少有人提前规划。我踩过的坑是：迁移期间字段映射不完整，导致依赖信息丢失，团队在过渡期两头维护，反而比迁移前更乱。

我的建议是分三步走。第一步只迁移任务和状态，不动依赖字段；第二步在新平台上建立独立的依赖工作项，与旧系统并行运行 2 到 3 周做交叉验证；第三步确认依赖数据一致后再切换，旧系统转为只读。迁移不是一次性动作，而是有过渡期的过程。

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

同一套机制，在不同规模和组织约束下落地方式完全不同。下面按四种典型情况给建议，你可以直接对号入座。

1. 团队 30 人以下、单项目：先跑轻量版本

这个规模不要上平台，也不要设计复杂流程。最小的可行方案是：一张依赖登记表（7 个字段以内）+ 每周一次 30 分钟的依赖同步会 + 一个共享的依赖看板。

唯一的硬约束是：承诺方和承诺日期不允许为空。这一条守住了，依赖治理就成立了。其余都可以先放松，等团队习惯了再逐步加规则。

我见过不少小团队一上来就照搬大厂流程，结果两周后全员放弃。流程的复杂度必须匹配组织的容错能力。

2. 团队 100 人以上、多项目并行：必须平台化

超过 100 人、同时跑多个项目时，共享表格一定会失效。原因是跨项目依赖的数量会呈非线性增长：3 个项目之间的依赖组合远多于 3 条单线依赖之和，人工维护必然遗漏。

这个阶段要做的三件事：把依赖做成独立工作项类型、建立跨项目依赖视图、配置超时自动升级。像 PingCode 这类面向中大型组织的平台本身就提供了跨项目视图和自动化能力，落地成本比自研低得多。

另外，这个规模一定要设依赖协调人这个角色，可以兼职，但必须有。他的职责不是催任务，而是每周检查依赖健康度指标、推动升级、以及在复盘时给出重排建议。

3. 强合规或数据敏感场景：把部署方式当成前置条件

金融、医疗、政务类的实施交付线，数据不能出内网。这种情况下的行动顺序要调整：先确认部署形态是否满足合规要求，再谈功能。

具体要提前确认四件事：是否支持私有化部署、依赖数据的存储与审计日志是否完整、权限模型能否做到按项目和角色隔离、以及后续版本升级是否可以在内网完成。如果部署形态不满足，功能再好也用不上。

4. 正在从 Jira 或其他系统迁移：过渡期要单独治理

迁移期的依赖管理是个独立课题。建议在过渡期采用“双登记”策略：新旧系统同时登记依赖，但以新系统为唯一事实源，旧系统只做数据备份参考。

同时把过渡期拉长到 2 到 4 周，不要试图一周切完。这段时间团队效率会下降，这是正常的，把它写进计划比假装它不存在要好得多。

5. 30/60/90 天落地节奏

最后给一个可执行的节奏。不要想着一周之内把所有机制建起来，依赖治理是组织习惯的改变，需要时间沉淀。

1. 第 1-30 天：建立依赖工作项和 7 个字段，跑通登记动作。目标是把依赖登记完整率做到 80% 以上，不追求指标改善。
2. 第 31-60 天：上线自动化提醒和超时升级，开始每周风险评审。目标是 Owner 明确率超过 90%，升级平均响应时长降到 12 小时以内。
3. 第 61-90 天：接入指标看板，把六个指标纳入迭代复盘。目标是平均阻塞时长下降 30% 以上，里程碑准时率提升 15 个百分点以上。

七、不同情况下的取舍

依赖治理没有唯一正确答案，只有取舍。下面五组取舍是我在实际项目里反复权衡过的，把判断依据写出来供你参考。

1. 重流程还是轻流程

重流程的好处是数据完整、可追溯、跨团队一致；代价是填写负担和抵触情绪。轻流程的好处是上手快、阻力小；代价是数据质量不稳定、跨团队口径难统一。

我的判断标准是看依赖的跨团队比例。如果一个项目里超过 40% 的依赖是跨团队依赖，就必须走重流程，因为跨团队协调的失败成本远高于填写成本。如果大部分依赖在团队内部闭环，轻流程完全够用。

2. 自研还是采购平台

自研的优势是贴合业务、字段随需定制；劣势是维护成本和迭代速度。采购平台的优势是能力成熟、有持续迭代和迁移路径支持；劣势是部分个性化需求需要妥协。

判断依据是依赖治理在你的组织里是不是核心竞争力。对绝大多数实施交付团队来说，它不是核心竞争力，那就不值得自研。把工程资源留给真正产生差异化的地方。

3. 全量登记还是只登记关键路径

全量登记的好处是完整，坏处是噪音大、维护成本高，容易把团队拖进“为填表而填表”。只登记关键路径的好处是聚焦，坏处是可能漏掉一些看似边缘、实际会连锁的依赖。

我的折中做法是：所有跨团队依赖全量登记，团队内部依赖只登记影响里程碑的。这个口径能把登记量压到原来的 40% 左右，同时不丢失关键信息。等团队习惯了，再考虑扩大到全量。

4. 高自动化还是人工确认

自动化程度越高，响应越快，但误报和漏报的处理成本也越高。比如自动升级规则设计得太激进，每天推送几十条通知，团队很快就会全部忽略。

我的建议是分阶段提高自动化程度。第一个月只做提醒不做升级；第二个月加超时升级；第三个月再加缓冲消耗自动升级。每加一条规则，观察两周误报率，超过 15% 就调整阈值。

5. 统一平台还是保留多工具

统一平台的好处是单一事实源，跨项目视图和度量口径一致；坏处是迁移成本和过渡期效率损失。保留多工具的好处是各团队用自己顺手的工具；坏处是依赖信息割裂，跨团队视图基本做不出来。

我的判断是：如果跨团队依赖占比超过 30%，统一平台几乎是被迫的选择。因为依赖协同的本质上要求所有人看到同一份数据，多工具并存会从根上破坏这个前提。

八、结语：从“催任务”到“管依赖”

回到开头那条 SF 交付线。事故发生之后我们做的最重要的一件事，不是换了工具，也不是加派人手，而是承认一个事实：我们一直在管理任务，从来没有管理过任务之间的关系。任务是可以靠努力完成的，关系只能靠机制解决。

如果这篇文章只能留下一句话，我希望是这句：依赖协同的核心不是让信息流动得更快，而是让承诺变得可追踪、让延期变得可升级。信息早就流动了，缺的是约束。

具体到下一步，我建议你做三件小事，不用等工具，不用等预算：

1. 今天先把当前项目里所有跨团队依赖列出来，写成清单，每一条都标上“我在等谁”。如果列不出来，说明依赖从未被识别，这就是最大的风险。
2. 给每一条依赖补上承诺方和承诺日期，并且把这条规则固化成不可为空。这一条做到了，你就已经从业余水平跨到 L2。
3. 在下一次迭代复盘时，只看一个指标：平均阻塞时长。不要一次看六个，先把这一个指标的口径定下来，连续观察三个迭代，你就会看到依赖治理的真实收益。

至于工具，等你发现表格撑不住了再考虑。真正决定成败的是机制，而不是平台。平台只是让机制在 100 人以上规模仍然跑得动的那根杠杆，先有机制，杠杆才有支点。