SF流程与规范：实施团队任务依赖风险控制关键指标

2023年我接手过一个 Salesforce 实施项目的复盘，项目原计划 6 个月上线 Sales Cloud + Service Cloud，最终延期 47 天。里程碑复盘会上，所有人的第一反应都是"某某任务没做完"。但把 486 条任务记录拉出来重建依赖网络后，真正的原因浮出水面：关键路径上有 9 个任务实际处于"等待他人交付"的状态，而它们在自己的任务清单里全部显示为"进行中"。没有一个任务被标记为阻塞，也没有人升级。

项目缓冲不是被某一个任务吃掉的，是被 11 天接口定义确认、4 天环境就绪、6 天 UAT 数据准备一点点啃光的。

这件事之后，我把团队内部的依赖管理口径全部重做了一遍，从"依赖登记表"到"阻塞时长看板"到"升级 SLA"，用 12 个 SF 实施项目做对照观察。这篇文章就是那套方法的完整拆解：SF 实施中任务依赖风险到底该盯哪几个指标、每个指标怎么算、阈值定在哪、什么时候必须升级。文中的 SF 特指 Salesforce 平台实施，如果你是其他系统的实施团队，机制通用，把平台术语替换即可。

一、先说核心结论：依赖风险控制的本质，是管理承诺而不是管理任务

大部分实施团队的管理动作都落在"任务"上：任务拆解、任务分配、任务完成率、任务延期率。这套逻辑有个隐含假设，任务是自包含的。但在 SF 实施里，几乎没有哪个任务真正自包含。

配置依赖需求确认，开发依赖接口定义，联调依赖对方系统就绪，UAT 依赖测试数据和环境，上线依赖审批和数据清洗。任务的完成度不取决于执行者的努力程度，而取决于上下游的交付承诺是否兑现。

基于这 12 个项目的对照观察，我给出三条结论，后面所有章节都是围绕它们展开的。

1. 依赖风险必须用先行指标管，不能用延期率管

项目延期率、里程碑达成率、缺陷逃逸率，这些都是结果指标。等到它们变红，损失已经发生。依赖风险真正可干预的窗口，在"承诺"和"阻塞"这两个环节。我跟踪的样本里，一个依赖在承诺日期前 3 天就被识别为高风险的项目，最终平均延期 2.1 天；而在承诺日期当天才发现问题的依赖，平均拖累下游 8.7 天。预警提前量直接决定了损失大小。

2. 依赖不是任务的一种属性，而是一条独立的交付链

把依赖做成任务的一个下拉字段，是绝大多数工具化失败的起点。依赖是 A 团队向 B 团队做出的、有明确交付物、日期和验收标准的对外承诺。它需要自己的登记表、自己的所有者、自己的状态机和自己的升级路径。混在任务表里，它永远会被"任务完成度"这个更强势的指标淹没。

3. 每个指标必须绑定一个管理动作，否则就是装饰

我在早期版本里统计过 14 个指标，做了一面大屏，结果三周之后没人看。后来砍到 6 个，每个指标对应一个明确动作，登记、预警、升级、复盘，才开始真正起作用。指标的价值不在"看得见"，而在"看完之后必须做点什么"。

下面进入具体的背景和场景。要理解为什么依赖链会断，得先看清楚 SF 实施里的依赖到底长什么样。

二、背景与真实场景：SF 实施的依赖链是怎么一步步断掉的

1. SF 实施中的四类依赖，风险特征完全不同

做依赖管理的第一步不是建表，是分类。因为不同类型的依赖，可干预程度和干预手段完全不一样。我把样本里的 486 条依赖记录做了归类，得到下面四类。

硬依赖（Hard Dependency）：上游不交付，下游物理上无法开始。典型场景是接口联调必须等对方系统的 API 规格冻结。硬依赖没有并行余地，只能通过提前冻结、并行准备来压缩影响。

软依赖（Soft Dependency）：逻辑上应该等，但可以先用假设值推进，后期返工对齐。典型场景是页面布局依赖字段清单，字段没定死可以先按 80% 的把握搭结构。软依赖的风险不是延期，是返工。

外部依赖（External Dependency）：交付方不在项目组的直接管理范围内，比如客户的 IT 部门、第三方 SaaS 厂商、监管接口方。这类依赖的难点在于你无法直接分配任务，只能通过承诺和升级推动。

资源依赖（Resource Dependency）：同一个专家被多条任务线同时占用，比如唯一的集成架构师既要做接口设计又要参加 UAT 支持。资源依赖的表现形式是"等待某人有空"，容易被误判为个人效率问题。

2. 依赖风险的三个特征：传导性、隐蔽性、跨团队性

传导性是依赖风险最致命的地方。一个 46 人的 SF 实施项目里，我在依赖网络图上看到过一个节点延迟 1 天，通过三级传递影响了 7 个下游任务、累计 19 人天的等待。单看每个任务，延期都在可接受范围内；合起来看，整个迭代节奏被打乱。

隐蔽性来源于任务状态的粗糙。一个任务处于"进行中"，可能是真的在做，也可能是"我在等，但我不敢标阻塞，因为标了显得我没在推进"。我在项目里做过一次匿名调查，31% 的顾问承认自己曾经把阻塞任务标成进行中，理由是"不想在站会上被追问"。这是管理问题，不是工具问题。

跨团队性决定了它不能被单团队内部消化。SF 实施项目通常涉及业务方、实施方、集成方、客户 IT、第三方产品方，至少四到五个组织单元的接口。跨团队的信息差和优先级差，是依赖风险的主要放大来源。

3. 一个真实的依赖链断裂复盘

回到开头那个延期 47 天的项目。重建依赖网络之后，我们看到了一条清晰的断裂路径。客户方的 MDM 系统接口规格原定在迭代 2 结束时冻结，实际延迟了 11 天。这 11 天里，实施方的集成顾问没有可做的事情，但他没有标记阻塞，而是转去做了一些次要的配置工作。

规格冻结之后，接口开发比原计划晚了 4 天启动，开发完成时间顺延 8 天。测试环境因为准备资源被另一个项目占用，又晚了 4 天就绪。最后 UAT 数据准备的脚本依赖接口返回结构，又晚了 6 天。四个环节叠加，项目缓冲 20 天全部消耗完，还额外占用了 47 天的进度。

整个过程里，没有任何一个环节"错得离谱"。每个环节都只是晚了几天到两周，每个环节都有说得过去的理由。依赖管理的核心难点正在这里：它防的是"处处合理，整体崩盘"。

三、常见误区拆解：六个让依赖管理失效的做法

在推行依赖管理的过程中，我见过也犯过大量错误。下面六个误区，是我认为破坏力最强的，每一条后面都给出对应的纠正动作。

1. 误区一：把依赖当成任务的一个属性字段

很多团队在任务表里加一个"前置任务"字段，就认为依赖管理做完了。问题在于，任务的所有者是执行者，依赖的所有者是承诺方。这两个角色完全不同。

当你把依赖塞进任务表，它就只能继承任务的生命周期，分配给谁、什么时候开始、什么时候完成。而依赖真正需要的字段是：谁向谁承诺、承诺交付什么、承诺日期是几号、验收标准是什么、违约影响谁。纠正动作是把依赖登记表独立出来，任务表里只保留一个指向依赖编号的链接字段。

2. 误区二：只统计结果指标，不做先行预警

里程碑延期率、关键路径延误天数、上线后缺陷逃逸率，这三个指标几乎每个项目周报都有。但它们全都是滞后的。当你看到里程碑延期率上升，已经没有干预空间了。

正确做法是建立"识别，承诺，阻塞，升级，返工"这条指标链，每一环都有先行指标。识别环节看依赖识别及时率，承诺环节看承诺日期偏差，阻塞环节看阻塞时长，升级环节看升级 SLA 达成率，返工环节看依赖引发的返工率。

3. 误区三：指标越多越好，做出大屏就算落地

我在 2022 年做过一个 14 指标的大屏，做出来的时候很有成就感。三周之后，没有任何一个项目经理在会上引用过它。原因很简单：指标太多，没有指向任何决策。

指标的设计原则应该是反向的，先问"如果这个指标变红了，我们会做什么"，回答不出来的指标就不该上报表。一个必须绑定一个动作，绑定不了的删掉。

4. 误区四：没有验收标准的依赖

依赖登记表上写"提供接口文档"，这句话等于什么都没说。文档给到什么程度算完成？Swagger 描述还是含错误码和示例报文？字段命名的规则是否有约定？

我见过最典型的一次纠纷：集成方交付了接口文档，开发方认为字段类型描述不清无法开工，集成方认为交付已按约定完成。双方都觉得自己占理，因为没有验收标准。依赖的验收标准必须写成可判定的形式，最好能对应一个具体的测试用例。

5. 误区五：跨团队依赖没有承诺日期，只有"尽快"

当依赖方是客户 IT 部门或第三方厂商时，句子里最容易出现"尽快""本周内""过两天"。这些模糊表达的背后是没有人真正做出承诺。

我现在的做法是：所有跨组织依赖必须有签字级别的承诺日期，且日期必须落到具体某一天。如果对方不愿意给日期，那就意味着这条依赖处于高风险状态，应该直接进入升级清单。

6. 误区六：升级机制写在制度文档里，从来没被触发过

制度文档里写着"重大问题可向上级升级"，实际上没人升级。因为升级被默认为一种"告状"行为，会破坏合作关系。

要让升级机制真正运转，必须做三件事：定义明确的升级触发条件（比如阻塞超过 3 个工作日自动升级）、定义明确的升级路径和时限、把升级从"人际行为"变成"流程行为"。当升级是规则的自动执行，而不是某个人的主观判断时，它才不会伤和气。

四、六个关键指标：定义、公式、数据源、阈值与动作

下面这六个指标是我从 14 个压缩到 6 个之后的最终版本。每一项都给出我实际使用的口径。需要强调的是，这些口径是我们团队在 SF 实施场景下的自定标准，不是行业统一规范。不同项目规模、不同交付阶段应该调整阈值，但指标的定义方式可以复用。

1. 依赖识别及时率（Dependency Identification Timeliness）

定义：在计划阶段或迭代启动前被识别并登记的依赖占全部依赖的比例。

公式：依赖识别及时率 = 计划/迭代前登记的依赖数 ÷ 全周期发现的依赖总数 × 100%

数据源：依赖登记表创建时间戳 + 迭代启动时间戳。

建议阈值：成熟团队 85% 以上，一般团队 70% 以上，低于 60% 说明计划阶段的需求澄清和架构评审不充分。

触发动作：低于 70% 时，在下一个迭代的计划会前增加一次跨团队依赖梳理工作坊，时长控制在 90 分钟内，输出物是当面的依赖清单而非邮件征集。

为什么这个指标重要：它衡量的不是依赖多不多,而是团队对自身交付网络的认知清晰度。我在样本里看到的相关性很明确，依赖识别及时率从 68% 提升到 88% 的项目，平均延期天数从 12.4 天降到 4.1 天。

2. 关键路径依赖阻塞时长（Critical Path Blocking Duration）

定义：关键路径上的任务因依赖未满足而实际处于等待状态的总时长，按依赖条数和使用人天两个口径统计。

公式：单条依赖阻塞时长 = 预计开始可工作日 − 实际开始工作日（仅统计已标记为阻塞状态的天数）

数据源：依赖状态机的"阻塞开始时间"和"阻塞解除时间"字段。这个字段必须是显式录入的，不能靠事后推断。

建议阈值：单条依赖连续阻塞超过 3 个工作日触发预警，超过 5 个工作日强制升级。关键路径上的依赖阈值应更严格，建议砍半。

触发动作：达到预警线时，依赖所有者在每日站会上必须复述阻塞原因和预计解除时间；达到升级线时，自动进入升级流程，不依赖个人判断。

关键细节：这个指标最大的落地障碍是"主动标记阻塞"。我采用过两个办法：一是把阻塞标记从"负面信号"改为"风险管理行为"，在月度复盘里公开表扬最早暴露阻塞的人；二是在站会模板里固定一问"你今天有没有在等别人的东西"，把它变成常规问题而不是异常报告。

3. 承诺日期偏差（Commitment Date Variance）

定义：依赖方最初承诺的交付日期与实际交付日期之间的偏差天数。

公式：承诺日期偏差 = 实际交付日期 − 首次承诺日期（取绝对值前先保留正负号，正数代表延迟）

数据源：依赖登记表的"首次承诺日期""变更后承诺日期""实际交付日期"三个字段。这里有个重要原则：承诺日期变更必须留痕，不允许直接覆盖原值。

建议阈值：单条依赖偏差不超过 2 个工作日可接受；偏差 3-5 个工作日需要给出书面原因；超过 5 个工作日进入依赖方履约评估。

触发动作：连续两个迭代内同一依赖方出现 3 次以上超阈值偏差，需要在项目周会上做专项沟通，讨论是否调整协作方式或增加资源。

为什么用"首次承诺"而不是"最新承诺"：如果只看最新承诺日期，依赖方可以通过不断推迟承诺来"消灭"偏差。用首次承诺日期做基准，偏差就变成了衡量承诺质量的指标，而不是衡量执行的指标。

4. 依赖密度与跨团队耦合度（Dependency Density）

定义：单位任务涉及的依赖数量，以及单个任务跨越的组织单元数量。

公式：依赖密度 = 依赖总数 ÷ 任务总数；耦合度 = 涉及两个以上团队的任务数 ÷ 任务总数

数据源：依赖登记表 + 任务表中的责任团队字段。

建议阈值：这是相对指标，没有绝对标准。我的观察是 SF 实施项目中依赖密度通常在 0.4-0.9 之间，超过 1.2 说明任务拆解过细或架构耦合过高。耦合度超过 40% 需要警惕。

触发动作：依赖密度持续高于 1.2 的模块，应该重新审视架构设计，考虑是否可以通过服务封装、接口抽象降低耦合，而不是靠加强协调来硬扛。

我的判断：依赖密度是六个指标里最容易被忽视、但长期价值最高的一个。它衡量的是系统设计质量，而不只是管理效率。一个依赖密度长期居高不下的 SF 实施项目，通常意味着集成架构本身需要重构。

5. 升级 SLA 达成率（Escalation SLA Achievement）

定义：超过阈值未解决的依赖，在规定时限内完成升级的比例。

公式：升级 SLA 达成率 = 按时完成升级的依赖数 ÷ 应升级的依赖总数 × 100%

数据源：依赖登记表的"应升级时间戳""实际升级时间戳""升级到位层级"。

建议阈值：我使用的分级标准是，P0 级依赖 4 小时内升级到项目经理，P1 级 1 个工作日内，P2 级 2 个工作日内。整体达成率目标 90% 以上。

触发动作：达成率低于 80% 时，不要先指责执行者，先检查升级路径是否清晰、被升级方是否有响应义务。大量案例中升级失效的原因是"升级上去之后没人接"。

6. 依赖引发返工率（Dependency-Driven Rework Rate）

定义：因依赖信息不清、变更未同步、验收标准缺失导致的返工工作量占总工作量的比例。

公式：依赖返工率 = 依赖相关返工人天 ÷ 总投入人天 × 100%

数据源：缺陷或变更单上的根因分类字段。关键是把根因分类做细，至少区分"需求变更""依赖不清""技术缺陷""环境问题"四类。

建议阈值：10% 以下为健康，10%-20% 需要关注，超过 20% 说明依赖管理存在系统性问题。

触发动作：当某类依赖反复引发返工，说明该类依赖的登记粒度或验收标准定义有问题，需要在下一个迭代调整模板。

这六个指标构成了完整的先行链条。识别及时率管入口，阻塞时长和承诺偏差管过程，依赖密度管结构，升级 SLA 管机制有效性，返工率管最终损耗。

五、把指标嵌入 SF 流程规范：四个阶段看不同的东西

一套指标用到底，是依赖管理失效的常见原因。SF 实施的不同阶段，依赖的形态和风险侧重完全不同。下面是我在实际项目中使用的分阶段口径。

1. 需求与设计阶段：重点是识别和冻结

这个阶段的核心动作是依赖识别和关键规格冻结。关注的指标主要是依赖识别及时率和依赖密度。

具体落地做法包括三个动作。一是在需求评审的准出条件里加入"依赖清单已提交"，没有清单的需求不允许进入开发排期。二是在架构评审时同步确认接口冻结时间点，把接口规格冻结作为一个独立里程碑管理。三是为每一类依赖指定一个项目内的对接人，避免出现"这条依赖归谁跟进说不清"的情况。

这个阶段最容易被忽略的是外部依赖的早期建联。客户 IT 部门和第三方厂商的响应周期通常比内部团队长 2-3 倍，如果等到开发阶段才去对接，时间上根本来不及。

2. 配置与开发阶段：重点是阻塞可见和承诺兑现

进入开发阶段，依赖从"纸面清单"变成"每日等待"。这个阶段的主指标是阻塞时长和承诺日期偏差。

我使用的节奏是：每日站会固定一问阻塞状态，每周更新一次依赖看板，每两周做一次承诺履约回顾。看板上只呈现三类信息，红黄绿状态、责任人、下一步动作和预计解除时间。

这里有个反直觉的经验：开发阶段最不该做的是追求依赖登记表的字段完整度。我见过团队为了填全 18 个字段，把每条依赖的登记时间拉长到 20 分钟，结果大家开始敷衍填表。字段精简到 6-8 个核心项，登记时间控制在 3 分钟以内，数据质量反而更高。

3. 测试与 UAT 阶段：重点是环境就绪和数据就绪

测试阶段的依赖形态发生了变化，主要矛盾从"人"转向"物"，测试环境、测试数据、外部系统连通性。

这个阶段我专门加两个指标：环境就绪率和数据就绪率。环境就绪率 = 按计划时间可用且版本正确的测试环境数 ÷ 计划需要的环境数；数据就绪率 = 可用的测试数据集数 ÷ 计划数据集数。

为什么单独拆出来？因为测试阶段的延期经常被误算成"测试工作效率问题"。实际上大多数测试延期源于等待环境或等待数据。把等待时间和测试执行时间分开统计，责任归属才清楚。

4. 上线与 Hypercare 阶段：重点是切换依赖和回滚依赖

上线阶段是依赖风险最集中的时候。数据迁移、接口切换、权限配置、审批流程，任何一环卡住都可能造成上线回滚。

这个阶段的做法是把依赖清单转化为切换检查表，每一项标注负责人、确认时间点和失败预案。特别要明确两类依赖：回滚依赖（如果上线失败，回滚需要哪些系统配合、需要多长时间窗口）和支持交接依赖（Hypercare 期间的支持责任从实施方转给客户运维的时点和条件）。

我在一个项目里见过因为没有明确回滚依赖，上线失败后回滚窗口错过，最终导致业务停机 6 小时。这个教训直接促成了我们把回滚依赖列为上线准入的强制检查项。

六、红黄绿阈值与升级机制：让规则自动运行

1. 阈值规则怎么定

阈值的核心原则是"跟影响面挂钩"，而不是一刀切。我使用的规则是三维打分：影响的下游任务数、预计阻塞天数、是否在关键路径上。

具体判定如下。绿灯：非关键路径，阻塞不超过 2 个工作日，下游影响任务不超过 2 个。黄灯：关键路径但阻塞不超过 3 个工作日，或非关键路径但下游影响超过 5 个任务。红灯：关键路径阻塞超过 3 个工作日，或预计影响上线里程碑，或涉及外部组织且无明确承诺日期。

这套规则在项目启动时就要和所有参与方对齐，并写进项目协作约定。阈值的争议必须在平静期解决，不能在红灯亮起时争论"这算不算严重"。

2. 升级路径与时限

我的升级路径设计是四层：依赖负责人 → 项目经理 → PMO 或交付负责人 → 项目指导委员会。每一层有明确的响应时限和决策权限。

第一层由依赖负责人在每日站会上提出，24 小时内无法解决则自动进入第二层。第二层由项目经理协调资源或调整排期，2 个工作日内无法解决进入第三层。第三层由 PMO 跨项目调配资源或推动客户方决策，3 个工作日内无法解决进入第四层。

关键原则是自动升级，不依赖个人判断。只要超过时限，系统或流程就推动它向上走，不取决于当事人是否愿意"再等等"。

3. 会议节奏与指标挂钩

指标要活下去，必须出现在固定的会议议程里。我的安排是三个层次。

每日站会看阻塞，15 分钟，只讨论新增阻塞和临近阈值的高风险依赖，不复述已完成工作。每周风险会看趋势，45 分钟，重点看承诺偏差分布和升级 SLA 达成率，识别重复出现问题的依赖方。每个迭代做一次依赖复盘，90 分钟，重点看依赖引发返工率和识别及时率，输出物是下一迭代的模板调整。

七、模板与看板落地：让指标变成每天能用的东西

1. 依赖登记表的最小字段集

我最终使用的依赖登记表只有八个字段，登记时间控制在 3 分钟内。字段太多会导致填写敷衍，太少会丢失关键信息。

字段清单如下：依赖编号、依赖描述（交付物是什么）、上游责任方与责任人、下游受影响方、首次承诺日期、验收标准、依赖类型（硬/软/外部/资源）、当前状态。

这里要特别强调验收标准的写法。不要写"提供接口文档"，要写"提供包含全部字段类型、错误码、示例请求响应报文的接口文档，并通过下游开发方的一次性验签"。能被判定的标准才是标准。

2. 风险评分公式

为了让红黄绿判定可计算，我用一个简单的评分公式。这个公式不需要精确，它的作用是让排序有依据。

依赖风险分 = 下游影响任务数 × 权重1
+ 已阻塞天数 × 权重2

+ 是否关键路径 × 权重3

+ 是否跨组织 × 权重4

建议权重（可根据项目阶段调整）：

权重1 = 1.0（影响面是首要因素）

权重2 = 1.5（阻塞时长是最强信号）

权重3 = 2.0（关键路径具有一票否决性）

权重4 = 1.5（跨组织依赖协调成本高）

判定参考：

风险分 < 8 → 绿灯

8 ≤ 风险分 < 15 → 黄灯

风险分 ≥ 15 → 红灯，强制升级

我实际用下来的经验是，这个公式最大的价值不是算得准，而是让团队在"这条依赖该不该升级"这个问题上有一个共同语言，减少争论成本。

3. 一页纸依赖看板的设计

看板要能在一屏之内看完，超过一屏就会失去日常使用价值。我的看板只放四块内容：当前红灯依赖清单、本周新增高风险依赖、升级中的依赖及其停留层级、上周依赖指标趋势。

每一条红灯依赖只显示五项：依赖编号与简述、上游责任人、承诺日期、已阻塞天数、下一步动作。不显示任务进度百分比，因为依赖没有"进度"这个概念，它只有"交付了"和"没交付"两种状态。

4. 工具选型与落地载体

依赖管理能不能长期跑下去，很大程度上取决于它有没有一个顺手的载体。用 Excel 管依赖在 20 人以下的小项目里勉强可行，一旦进入多团队、多迭代、跨组织的中大型 SF 实施，很快就会失控，版本混乱、权限不清、看板靠手工更新。

我现在的做法是把依赖登记和任务管理放在同一个平台里，通过字段联动自动生成看板。这里以 PingCode 为例说明落地方式：它支持在任务之外独立建立依赖对象，配置上下游关系字段和状态机，并且能把阻塞时长、承诺偏差这类指标直接做成看板视图，不需要手工汇总。

对于中大型企业来说，PingCode 的一个实际价值是它主要服务 100 人以上组织，对多团队、多项目并行的场景支持比较完整。SF 实施往往不是孤立项目，而是和企业内其他数字化项目共享资源和环境，这种跨项目的依赖冲突需要工具层面能横向看到。

另外两个在选型时值得关注的点是私有化部署和迁移成本。支持私有化部署意味着依赖数据、客户信息和接口规格可以留在企业内网，这对金融、政企类 SF 实施项目是硬性要求。支持 Jira 平滑迁移则关系到落地阻力，很多团队已经在 Jira 里积累了大量任务和依赖关系，如果迁移需要重建数据结构，推行新流程的成本会陡增。这一点在国产替代的选型评估中权重很高。

需要说明的是，工具只能解决"数据在哪里"和"看板怎么自动生成"，解决不了"愿不愿意标记阻塞"。后者是管理问题，我在前面第三节和第四节都专门讨论过。先有机制，再谈工具，顺序不能反。

八、不同情况下的行动建议与取舍

前面讲的是一套完整机制，但完整机制不等于每个项目都该一次性全上。项目规模、组织成熟度、剩余周期不同，投入产出比完全不同。下面按三种典型情况给出建议。

1. 50 人以下、单一团队主导的项目

建议动作：只做两件事。第一，建一张依赖登记表，八字段版本，放在团队现有的协作工具里。第二，每日站会固定一问"你今天在等谁的东西"。

取舍：不要做红黄绿看板，不要做升级 SLA，不要统计六个指标。小团队的信息传递靠面对面就够，上复杂的指标体系只会增加负担。这个规模下唯一必须建立的习惯是主动暴露阻塞，其他都是次要的。

2. 100-300 人、多团队并行的实施项目

建议动作：六个指标里先上三个，依赖识别及时率、关键路径阻塞时长、承诺日期偏差。这三个合起来能覆盖大部分延期风险，而且采集成本相对较低。同时建立红黄绿阈值和三层升级路径。

取舍：依赖密度和耦合度可以先不做，因为它对应的是架构层面的调整，周期长、见效慢，更适合作为季度级议题。升级 SLA 达成率可以在机制运行一个季度后再引入，早期数据没有参考价值。

这个规模的项目必须解决一个问题：依赖信息的跨团队同步。我见过太多项目，每个团队内部都有清晰的依赖清单，但团队之间的信息是断的。解决方式不是靠更多的会议，而是靠一个所有团队都写入、都读取的统一载体。

3. 多供应商参与的大型项目（300 人以上）

建议动作：六个指标全上，并且把依赖管理写进供应商合同的交付条款。升级路径必须延伸到项目指导委员会，因为跨供应商的资源冲突只能在高层级解决。

取舍：这个规模下最大的成本不是工具，是协调。我的经验是把依赖管理的责任明确到每个供应商的项目经理，并且在合同中约定依赖承诺日期偏差的考核方式。没有合同约束的跨组织依赖，最后一定会变成反复推诿。

这里还有一个容易被忽略的取舍：要不要把依赖数据对客户完全开放。我的判断是开放性应该分层次，进程类和承诺类信息对客户开放，内部资源冲突和人力评价类信息保留在实施方内部。全开放会导致团队为了"好看"而隐瞒真实阻塞，这比信息不透明更危险。

九、总结：依赖管理防的不是延期，是"处处合理但整体崩盘"

回到开头那个延期 47 天的项目。如果重来一次，我认为真正需要改变的不是任何一个环节的执行效率，而是四件事。第一，接口规格冻结必须作为独立里程碑管理，且它有明确的负责人和升级路径。第二，阻塞必须被显式标记，且标记阻塞不会带来任何负面评价。第三，跨组织依赖必须有具体到某一天的承诺日期，没有日期的依赖直接进升级清单。第四，阈值的判定规则必须在项目启动时就达成共识。

这四件事没有一个需要额外的技术投入，但都会改变项目的走向。

依赖管理的独特之处在于，它处理的是那些"每个人都没做错，但结果错了"的情况。它需要一套先行指标，让风险在还来得及干预的时候暴露出来。它需要一个自动升级机制，让升级变成流程行为而不是人际行为。它需要一个足够顺手的载体，让这些指标能每天被看到、被使用。

如果你现在正在推进一个 SF 实施项目，我建议下一步不要急着建大屏，而是先做三件事。

第一，翻出最近一个月的任务记录，找出所有实际处于等待状态但从没被标记为阻塞的任务。这个数字本身就是一个诊断结论，如果比例超过 15%，说明你的团队缺少暴露阻塞的安全感，机制问题比工具问题更紧迫。

第二，拿八字段的依赖登记表，找两到三个跨团队的关键依赖试点填写，重点检查验收标准能不能被判定。填不出来的，就是后续最容易产生返工的依赖。

第三，跟所有参与方对齐红黄绿的判定规则和升级时限。这一步必须在项目还平静的时候做完。等到红灯亮起再讨论规则，讨论的就不再是规则，而是责任了。

依赖管理不是把项目管得更紧，而是把风险看得更早。早期暴露的每一条阻塞，成本都远低于后期追赶的每一天。