SS流程与规范：项目成员任务依赖最佳实践关键指标

去年第四季度，我以外部流程顾问的身份，在一家约 300 人的软硬件混合研发企业做了一次为期六周的流程复盘。这家公司同时跑三条产品线，阶段门流程（Stage-Gate）已经执行了两年，评审文档齐全、模板规范，但交付准点率依然只有 61%。我们把过去 18 周所有延期任务拉出来逐条归因，发现排在第一位的不是估算偏差，也不是需求变更，而是"等"，等待上游交付、等待接口确认、等待另一个团队排期，这类等待贡献了 43% 的延期天数。

也就是说，他们的阶段门管住了"交付物是否达标"，却几乎没有管住"交付物之间的依赖关系"。这篇文章我想把这件事讲透：在 SS（阶段门）流程里，项目成员的任务依赖到底该怎么规范、怎么度量、怎么在失控之前就被拦住。

一、先给结论：依赖管理不是排期技巧，而是阶段门的准入条件

如果你时间有限，只看这一节就够了。下面五个结论是我在多个中大型研发组织里反复验证过的，它们和大多数流程文档里写的顺序恰好相反，不是"先有规范再谈指标"，而是"先定义依赖的交付物属性，指标才有意义"。

1. 依赖失控的根因，是依赖没有"交付物身份"

绝大多数团队把依赖当成一条连线，而不是一个可被验收的对象。连线没有责任人、没有截止时间、没有关闭判据，所以它在项目计划里天然是弱势信息。我在复盘时做过一个统计：那些被明确登记为独立工作项、有责任人和承诺日期的依赖，按时关闭比例是 87%；只画在甘特图连线上的依赖，按时关闭比例是 41%。差距不在难度，而在它是否拥有一个可以被追踪的身份。

这也是我建议所有团队做的第一件事：把依赖从"关系"升级为"工作项"。哪怕你暂时不做任何指标，只做这一步，交付准点率通常也能提升 10-15 个百分点。

2. 阶段门是拦截隐性依赖成本最低的节点

隐性依赖（团队自己都不知道自己在依赖别人）越晚被发现，修复成本越高。我的经验值是：在阶段门评审时发现，处理成本约 1 人天；进入执行阶段发现，约 4-6 人天；进入集成或测试阶段发现，约 12 人天以上。这条曲线陡峭到没有商量余地。

阶段门之所以是最优拦截点，是因为它天然具备三个条件：有固定的时间节奏、有强制的评审动作、有跨职能的参与人。你不需要再造一个会议，只需要把"依赖健康度"加进现有评审清单。

3. 指标不要超过五个，超过就没人看了

我见过一个团队的依赖看板有 18 个指标，结果三个月后没有任何人打开过它。指标的价值不在于覆盖率，而在于能不能直接触发一个动作。一个指标如果没有对应"越界之后谁做什么"，它就不该出现在看板上。

4. 跨团队依赖必须走显性升级，否则一定烂在现场

跨团队依赖的本质是两个团队的优先级冲突，而不是沟通问题。一线工程师之间"沟通"越顺畅，问题反而越容易被软性拖延，因为大家都不想把关系弄僵。所以跨团队依赖必须有一条明确的、不依赖人际关系的升级路径。

5. 依赖登记率上升时，短期进度看起来会变慢

这是最容易被误判的一条。当你开始强制登记依赖，团队会突然"多出"很多工作，阶段门看起来推进得更慢了。这是真实的，也是必要的阵痛。下面这张图是我在一家客户现场记录到的对比：登记动作带来的可见成本很小，而被拦截掉的隐形返工很大。

6. 一套最小可行的指标组合

下面这张表是我建议的起步配置。五个指标，每个指标都有明确的采集点和越界动作。注意：这些阈值是我的经验建议值，不是行业标准，你应该根据自己的历史数据校准基线后再用。

二、背景与真实场景：依赖是怎么一步步失控的

1. 先做术语澄清：本文说的"SS"到底指什么

这是必须放在前面说清楚的事，因为"SS"在项目管理语境里至少有两个完全不同的含义，混用会导致整篇规范失效。

• 含义一：阶段门流程（Stage-Gate，阶段-阶段推进）。项目按阶段划分，每个阶段结束设一道门，通过评审才能进入下一阶段。本文标题里的"SS流程"指的就是这个。
• 含义二：开始-开始依赖（Start-to-Start）。这是任务依赖四种类型中的一种，表示 B 任务必须等 A 任务开始之后才能开始。

换句话说，本文讨论的是"在阶段门流程中，如何规范地管理任务依赖"，而 SS 依赖（开始-开始）本身只是被管理对象之一。我在给企业做内训时，会强制要求他们在任何一份流程文档的第一页写清楚这个区分，否则一定会出现"我说的是阶段门，你理解的是依赖类型"的扯皮。

2. 一个 18 周项目的依赖失控时间线

下面这条时间线来自我前面提到的那家客户，我做了脱敏和合并处理。它非常有代表性，因为大多数依赖失控都不是突发事件，而是一连串"看起来都不严重"的小妥协累积出来的。

注意第 18 周的复盘结论："需求变更多"。这是我在现场遇到最多的错误归因。我们把 18 周的阻塞事件按时间轴拉出来后，可以清楚看到依赖类阻塞在累积，而且累积曲线和关键路径浮动消耗曲线几乎同步。

3. 四种依赖类型在阶段门中的分布与风险差异

四种依赖类型（FS 完成-开始、SS 开始-开始、FF 完成-完成、SF 开始-完成）在阶段门流程中的风险完全不同，但大多数团队用同一套管理方式对待它们，这是典型的能力错配。

三、拆解常见误区：五个我每周都能见到的错误动作

1. 误区一：把依赖画在甘特图上就算管理了

连线是可视化，不是管理。管理需要四个要素：谁负责、什么时候交、交给谁、怎么算完成。甘特图的连线只回答了"存在关系"，其余三个都没回答。

我在客户现场做过一个对照实验：同一个团队，先用纯连线管理两个迭代，再把依赖改造成独立工作项管理两个迭代。结果连线版有 34% 的依赖在迭代末期才被发现"其实没完成"；工作项版这个比例降到 9%。不是人变认真了，是信息结构变了。

2. 误区二：用"多沟通"解决跨团队依赖

这是最善意也最有害的建议。跨团队依赖的冲突本质是资源优先级冲突，沟通能让双方"理解"，但不能让双方"改变排期"。当一个依赖需要靠两个负责人的私人关系来推动时，它就已经脱离流程控制了。

我的判断标准很简单：如果一个跨团队依赖连续两周没有状态变化，就不要再去沟通了，直接升级。沟通解决的是信息差，升级解决的是优先级差，两者不能互相替代。

3. 误区三：指标越多越专业

我见过 18 个指标的看板，也见过 3 个指标却跑得很好的团队。区别在于后者每个指标都绑定了一个决策动作。前者的问题是，当 18 个指标里有 6 个同时飘红时，管理者会本能地选择忽略，因为无法行动。

一个可操作的检验方法：把你的指标清单拿给一线负责人看，问"这个数字变红了，你明天会做什么"。如果他说不出来，删掉它。

4. 误区四：把 SS 依赖当作 FS 依赖来排期

这是我在技术团队里见过的最隐蔽的错误。FS 依赖的排期逻辑是"串行"，A 完成后 B 开始，天然有缓冲。SS 依赖是"并行起步"，一旦上游延后开始，下游要么停摆、要么在没有输入的情况下硬做。

更麻烦的是，SS 依赖通常带有提前量（lead），比如"测试环境搭建开始后 3 天，自动化用例编写开始"。这个"3 天"是一个强约束，而不是一个建议值。但在甘特图里，它常常被表现为两根平行的条，看起来毫无风险。

5. 误区五：阶段门评审只看交付物，不看依赖健康度

阶段门评审清单里通常有"需求文档是否完整""测试报告是否齐全""风险是否识别"，但很少有"下一阶段的入向依赖是否已全部确认"。结果是，评审通过得漂漂亮亮，进入下一阶段第二天就全体卡住。

四、专业判断逻辑：依赖治理的四层判定

我不建议用"依赖管理成熟度模型"这类分层框架，因为太抽象。我用的是一个四层速判法，每一层只有一个问题，任何一个答案是"否"，这条依赖就不具备可管理性。

1. 第一层：可登记性，它有没有一个独立身份

判断问题：这条依赖有没有独立的编号、标题、责任人和承诺日期？如果没有，它就不是被管理对象，只是计划文档里的一条注释。

实操上，我要求依赖工作项的标题必须写成"【依赖】供给方 → 需求方：交付内容"的格式，例如"【依赖】算法组 → 客户端组：模型推理接口 v2 联调包"。这个格式强制写清楚了方向，避免出现"双方都以为对方在等自己"的经典僵局。

2. 第二层：可问责性，责任人是不是唯一

判断问题：这条依赖有没有唯一的责任人？注意是唯一。我见过大量依赖写的是"算法组负责"，这在组织上等于没人负责。

责任人必须是具体的人，而不是团队。如果供给方是一个外部供应商，责任人应该是内部对接人。

3. 第三层：可验收性，关闭判据是不是客观

判断问题：这条依赖的关闭，能不能用一句话客观判定？"接口文档交付完成"不是客观判据，"接口文档已上传至指定位置且需求方确认可解析"才是。

我在现场推的一个做法是：每条依赖必须写"关闭判据"字段，且该字段不允许出现"基本""大致""初步"这类词。这个约束看起来吹毛求疵，但它把大量后期争议提前消灭了。

4. 第四层：可升级性，有没有一条不依赖关系的路径

判断问题：如果这条依赖连续两个检查周期没有进展，谁会介入？介入的触发条件是时间还是事件？

可升级性是四层里最容易被跳过的一层，也是最致命的一层。我的建议是把它写进流程规范：跨团队依赖连续 48 小时无状态更新，自动升级至项目级依赖看板；连续 120 小时无进展，升级至 PMO 或产品线负责人。用时间触发，而不是用"感觉不对劲"触发。

5. 四层判定的速判表

五、关键指标体系：公式、阈值与计算示例

这一节是全文最难写的部分，因为大多数文章在这里只会给一个指标名字，而不给计算口径。我下面给出的每一个公式，都是我在实际项目中跑过的，并且我会明确标注哪些是我的经验建议值，哪些是可推导的。

1. 依赖识别率 DRI

这个指标回答"我们有没有把依赖找全"。它的难点在于分母，你怎么知道"真实依赖总数"？答案是：用阶段门评审后的复盘数据反推。

DRI = 阶段门评审前登记的依赖数 / 阶段门评审后确认的真实依赖总数 × 100%
示例：

某阶段门评审前登记依赖 27 条

评审中新增 5 条，评审后两周内因阻塞事件补充识别 3 条

真实依赖总数 = 27 + 5 + 3 = 35 条

DRI = 27 / 35 × 100% = 77.1%

1% 意味着有近四分之一的依赖是"事后才发现"的。我的经验阈值是 DRI ≥ 90%，低于 80% 说明依赖梳理方法本身有问题，而不是团队不认真。

这里有一个常见误用要提醒：不要用"新发现的依赖数"作为分子去美化指标。有些团队会把"评审中新增的 5 条"算作识别成果，这会让 DRI 虚高。评审中新增的依赖，本质上仍然是"计划阶段没识别到"。

2. 依赖延迟率 DDR

这个指标回答"上游承诺靠不靠谱"。它比整体进度偏差更敏感，因为它聚焦在依赖这个具体行为上。

DDR = 因上游未按承诺日期交付、且导致下游启动延迟的依赖数 / 已到期依赖总数 × 100%
注意：只统计"导致下游启动延迟"的依赖。

如果上游延迟但下游用缓冲吸收了，不计入分子，但应单独记录为"风险吸收"。

示例：

某迭代已到期依赖 42 条

其中 5 条延迟且造成下游启动延迟

DDR = 5 / 42 × 100% = 11.9%

建议阈值 DDR ≤ 10%。但要小心一个陷阱：如果这个数字长期低于 3%，通常不是因为你做得太好，而是因为依赖登记时就把日期写得很宽松，或者分子被有意漏统计。这时候应该去看"依赖承诺日期与任务计划开始日期的平均间隔"，如果间隔超过一周，说明承诺日期在注水。

3. 关键路径浮动消耗率 CPFB

这是我最看重的一个指标，因为它反映的是"余量"，而不是"结果"。结果指标总是滞后的，余量指标可以提前预警。

CPFB = (关键路径计划总浮动 – 当前剩余总浮动) / 关键路径计划总浮动 × 100%
示例：

阶段门开始时关键路径计划总浮动 = 16 个工作日

阶段门中点检查时剩余总浮动 = 6 个工作日

CPFB = (16 – 6) / 16 × 100% = 62.5%

我的经验阈值是：阶段门中点时 CPFB ≤ 50%。超过 50% 意味着你消耗缓冲的速度快于消耗进度，后面会非常被动。超过 70% 时，不要指望靠加班追回来，应该立刻冻结新增范围或重排关键路径。

这里必须澄清一个常见误解：CPFB 不是越低越好。如果你在中点时 CPFB 只有 10%，说明你的计划浮动留得过多，估算极度保守，组织在为不存在的不确定性付费。健康区间大致是 30%-50%。

4. 阻塞时长中位数 BST

这个指标回答"出了问题多久能解开"，反映的是组织的响应能力，而不是计划能力。

BST = 所有依赖类阻塞事件从标记为"阻塞"到解除阻塞的耗时的中位数
为什么用中位数而不用平均值：

一个持续 3 周的阻塞会把平均值拉高到失真，

中位数更能反映"典型情况"。

建议分两组统计：

团队内依赖 BST ≤ 8 工时

跨团队依赖 BST ≤ 24 工时

示例（某月度数据）：

团队内阻塞事件 18 起，耗时中位数 6.5 工时 → 达标

跨团队阻塞事件 9 起，耗时中位数 41 工时 → 超标 71%，需查升级路径

跨团队 BST 超标是最常见的信号，且几乎总是指向同一个原因：升级路径没有走通，或者根本没有升级路径。我在现场排查时，第一个问题永远是"这条依赖有没有触发过升级"，答案通常是"没有，我们私下解决了"。

5. 跨团队依赖升级率 DER

这个指标的存在意义，是检测升级机制是被使用了还是被绕过了。它本身不是好坏指标，而是一个诊断指标。

DER = 触发过正式升级流程的跨团队依赖数 / 跨团队依赖总数 × 100%
健康区间（经验值）：10% – 20%

低于 10%：升级机制形同虚设，团队在隐忍，风险在积累

高于 20%：依赖责任归属定义不清，本应在团队内解决的问题被上推

我在两个不同的组织里看到过这两个极端。一个组织的 DER 是 4%，表面上"团队协作很好"，但半年内爆发了三次重大延期；另一个组织的 DER 是 37%，PMO 每天都在处理本不该上来的依赖冲突，实际是因为依赖责任人写的是团队而非个人。

6. 五个指标之间的关系与看板搭建

这五个指标不能孤立看，它们构成一条因果链：DRI 低 → 隐性依赖多 → 后期阻塞多 → BST 升高 → CPFB 快速消耗 → 延期。反过来说，如果你发现 CPFB 异常但 DRI 和 DDR 都正常，那问题可能出在估算或范围管理上，而不是依赖管理上。

看板搭建上，我的建议是分两层：

1. 项目层看板（周更）：DDR、BST、当前 CPFB，以及待关闭依赖清单。受众是项目组全员。
2. 组织层看板（月更）：DRI、DER、跨项目依赖收敛点分布。受众是 PMO 和产品线负责人。

不要把这五个指标放在同一个看板上给同一批人看，那会让每个指标都失去焦点。

六、案例与数据观察：把指标跑进真实项目

1. 我跟踪的 12 个迭代样本说明

数据来源说明：下面这组数据来自我在两家客户现场的跟踪记录，时间跨度是 2023 年 Q4 到 2024 年 Q3，共计 12 个迭代周期，涉及 6 个研发团队、约 180 人。样本量不大，不足以得出普适结论，但有两点我认为值得参考：一是趋势的一致性，二是这些数据是我从工作项记录和评审纪要里逐条扒出来的，不是问卷自评。

有几个细节值得单独说。第一，交付准点率的改善明显滞后于指标改善。第 1-3 迭代时 DRI 已经提升了 12 个百分点，但准点率只动了 2 个百分点。原因是团队需要时间适应新的登记节奏，前几个迭代会在执行中不断返工补登记。如果管理者在这个阶段动摇，治理就会半途而废。

第二，DDR 的下降速度快于 DRI 的上升速度，说明"承诺日期显性化"这个单项动作的收益很高，性价比优于"把依赖找全"。如果你的资源只够做一件事，先做承诺日期显性化。

第三，第 7 迭代之后所有指标都进入平台期，继续投入的边际收益明显下降。这时候应该转向别的杠杆，比如估算精度或范围控制，而不是继续加码依赖治理。

2. 用工具把指标自动化：以 PingCode 为例

指标能不能持续跑下去，很大程度上取决于采集成本。手工统计五个指标，一个 PMO 每周要花 8-12 人时；一旦人员变动或项目压力上来，统计就会中断。所以我在这两家客户那里，都推动他们把指标采集做成了系统能力。

这里我用 PingCode 举例，因为这两家客户最终选择的都是它，而且我参与了配置过程，有一手观察。需要说明的是，PingCode 主要服务中大型企业及 100 人以上组织，这一点和本文讨论的场景比较匹配，人少的团队其实用表格就够了，不必上系统。

我实际配置过的几个关键点：

1. 把依赖做成独立的工作项类型，而不是一个字段。 这样它才有状态流转、有责任人、有截止日期，才能被统计。如果用普通字段记录依赖，你会得到一个无法流转的死数据。
2. 用跨项目关联建立依赖方向。 供给方是 A 项目的任务，需求方是 B 项目的任务，两个方向都要可见。这是跨团队依赖可管理的前提。
3. 用自定义字段承载"关闭判据"和"承诺日期"。 这两个字段是 DDR 和 DRI 的计算基础，必须结构化，不能写进描述文本里。
4. 用报表功能做项目层看板。 周更的 DDR、BST、待关闭依赖清单，取决于工作项的过滤条件是否设置正确。

另外两个在选型阶段值得考虑的点：PingCode 支持私有化部署，这对研发数据不能出内网的硬件和制造业客户是硬需求；同时它支持从 Jira 平滑迁移，对于正在做工具切换的团队，迁移成本是一个实实在在的决策因素，国产替代的场景下这一点尤其重要。当然，具体能力会随版本和部署方式变化，建议在 POC 阶段用自己的真实数据实测一遍，不要只看宣传材料。

3. 三个容易做错的配置细节

（1）依赖工作项的"完成"状态不要和"下游确认"合并。 供给方标记完成、需求方确认可用，这是两个动作。合并之后，DRI 会虚高，因为大量依赖会停在"已完成但未确认"的模糊状态里。

（2）不要让依赖工作项进入迭代的燃尽图。 依赖是约束，不是产出。把它算进迭代工作量会导致进度失真，团队会为了让曲线好看而提前关闭依赖。

（3）承诺日期不要用"计划开始日期"自动填充。 我见过太多团队这么做，结果是 DDR 永远是 0，因为承诺日期就是计划日期，系统永远判定"准时"。承诺日期必须由供给方手动确认。

4. 数据观察：工具接入前后的对比

下面是其中一家客户在完成依赖工作项配置并运行 4 个迭代后的观察数据。需要说明的是，这些数字受工具配置质量影响很大，同一种工具在不同团队的表现可能差一倍以上，所以请把它当作参考区间而非基准值。

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

依赖治理没有通用方案，组织规模、交付节奏、合规约束都会改变最优解。下面按场景给出建议，你可以直接对号入座。

1. 50 人以下团队：不要上系统，先把承诺日期写出来

这个规模下，团队之间的信息传递成本很低，靠一张共享表格 + 每周 15 分钟依赖巡检就够了。我见过不少 30 人团队花半年时间推行依赖管理系统，最后失败，原因不是工具不好，而是管理开销超过了协作复杂度本身。

这个阶段唯一必须做的动作是：所有跨人依赖必须写明承诺日期，且承诺日期由供给方确认，不能由需求方代填。 这一条做到位，DDR 通常能降到 15% 以内。

2. 100-500 人 / 多团队：建立四层判定 + 五个指标

这是本文讨论的主场景。这个规模的特点是团队之间已经出现了"看不见的墙"，靠人际沟通无法覆盖。建议的动作顺序是：

1. 先在 1-2 个试点项目里把依赖改造成独立工作项，跑 2 个迭代看数据。
2. 把四层判定（可登记、可问责、可验收、可升级）写进阶段门评审清单。
3. 把五个指标中的 DDR 和 BST 先上线，这两个采集成本最低、见效最快。
4. 第 3 个迭代后再加入 DRI 和 CPFB，因为这两个需要历史数据做基线。
5. DER 最后加，因为它需要升级机制先跑稳定。

3. 500 人以上 / 多产品线：处理依赖收敛点

这个规模下最突出的问题不再是单条依赖的管理，而是依赖收敛点，多个团队同时依赖某一个中间交付物，形成单点瓶颈。我前面提到的第 12 周场景就是典型：三个团队同时等同一个中间件版本。

收敛点的治理方式和普通依赖不同。你需要：建立收敛点清单，按依赖它的团队数量排序；为每个收敛点指定一个不隶属于任何一个使用方的负责人；在阶段门评审中单列"收敛点风险"项；以及给收敛点设置比普通任务更早的交付日期，我的经验值是提前 1.5 倍浮动量。

4. 强监管或硬件制造场景：把依赖与实物节点绑定

硬件和强监管场景的依赖有一个特点：它有物理时间约束，不可压缩。软件延迟可以加班，样机打样延迟无法加班。所以在这类场景里，依赖管理的重点从"提前识别"转向"提前锁定"。建议把依赖的承诺日期与采购、生产、认证的实际周期绑定，并在阶段门评审中单独检查那些浮动时间为零的依赖。

5. 已经在用 Jira 的团队：先评估迁移成本再决定

这是个现实问题。如果你的团队已经在 Jira 上有大量历史数据、自定义工作流和插件依赖，贸然切换的代价可能超过收益。我的建议是分两步走：先评估现有工具能不能支撑四层判定和五个指标（大概率是可以的，只是配置工作量大）；如果确实要换，优先选择支持平滑迁移的方案，把历史数据的可保留性作为硬性评估项。

如果决定做国产替代，PingCode 是一个值得放进 POC 名单的选项，因为它同时满足私有化部署和 Jira 迁移这两个条件，这两点恰好是这个阶段最容易被卡住的地方。

八、不同情况下的取舍

前面讲的是"该做什么"，这一节讲"必须放弃什么"。依赖治理的每一个选择都有代价，不承认代价的方案基本都落不了地。

1. 治理粒度 vs 执行成本

依赖登记得越细，信息越完整，采集成本也越高。我在现场看到的最常见错误是"一刀切要求所有依赖都登记到最细粒度"，结果是团队怨声载道，三个月后集体阳奉阴违。

我的取舍建议：只对跨团队依赖和关键路径上的依赖做强制细粒度登记，团队内部的依赖可以放宽到"有责任人 + 有承诺日期"即可。 这个规则把强制要求从 100% 的依赖压缩到约 35%，但覆盖了约 80% 的延期风险。

2. 集中式依赖看板 vs 分散式团队自管

集中式看板的好处是全局可见，坏处是容易变成"PMO 的看板"，团队不认账。分散式的好处是团队有所有权，坏处是跨团队依赖会漂移。

我的取舍是分层：跨团队依赖集中到项目级看板，团队内依赖留在团队自己的看板。 这个分界线要写进流程规范，并且要有一个明确的判断标准，依赖方和被依赖方是否属于同一个团队。

3. 私有化部署 vs SaaS

这是一个非技术问题被包装成技术问题的典型场景。私有化部署的优势是数据可控、可深度定制、适合受监管行业；代价是运维成本、升级滞后、初始投入高。SaaS 反过来。

我的判断逻辑只有一个问题：你的研发数据里有没有不允许出内网的内容？ 如果有，这根本不是取舍问题，是合规约束，SaaS 直接出局。如果没有，再按成本和运维能力权衡。

4. 指标数量 vs 指标可信度

每增加一个指标，采集成本上升，同时每个指标的可信度会下降，因为团队会开始"优化指标"而不是"优化问题"。我在一个客户那里见过 DDR 长期保持在 2% 以下，深入排查后发现，供给方习惯性地把承诺日期填得比实际能力晚两周，这样永远不会"延迟"。

取舍建议：指标不超过五个，并且每个季度做一次"指标可信度审计"，随机抽取 10 条记录，人工核对数据是否真实反映事实。审计发现造假，不要惩罚团队，而要改指标设计，因为造假通常是指标设计逼出来的。

5. 三个我必须提醒的取舍底线

（1）不要为了指标好看而牺牲依赖的真实登记。 一个团队如果因为怕 DDR 难看而不登记风险依赖，这个指标就已经失效了。

（2）不要在阶段门评审里用依赖健康度做绩效考核。 一旦挂钩绩效，所有数据都会失真。依赖指标应该用来触发动作，而不是用来评价人。

（3）不要指望依赖治理能解决所有延期。 从我的样本看，依赖类原因解释了约 57% 的延期天数，剩下的 43% 需要别的杠杆。把依赖治理做到 90 分就够了，剩下的精力应该投到估算和范围管理上。

九、落地检查清单

这一节的清单可以直接打印出来用。我按阶段门前、每周巡检、阶段门后三个场景组织，每一条都对应一个具体动作和产出物。

1. 阶段门前的依赖评审清单（10 项）

2. 每周依赖巡检清单（5 项）

1. 检查已到期未关闭依赖： 统计数量与占比，计算本周 DDR。超过阈值时逐条给出延迟原因分类（能力 / 优先级 / 需求变更 / 外部因素）。
2. 检查 48 小时内无状态更新的跨团队依赖： 触发升级动作，不要等到下周。
3. 检查当前关键路径浮动剩余值： 计算 CPFB，连续两周上升超过 10 个百分点时预警。
4. 检查新增依赖： 本周新增的依赖中，有多少是"本应在计划阶段识别"的，这部分直接影响 DRI 分母。
5. 检查阻塞事件： 统计本周阻塞事件数与解除耗时中位数，跨团队 BST 超标时排查升级路径是否被绕过。

3. 阶段门后的依赖复盘清单（4 项）

1. 对照真实依赖总数，计算本期 DRI， 并列出所有"事后发现"的依赖，逐条分析为什么没被提前识别。
2. 统计本期延期任务的归因分布， 明确依赖类原因占比。如果这个比例低于 20%，但项目实际延期严重，需要检查归因是否失真。
3. 回顾升级机制的触发情况， 计算本期 DER，并抽取 3 条未升级的依赖，访谈当事人为什么选择不升级。
4. 更新下一阶段的检查项， 把本期暴露的新类型依赖补充进评审清单。这一步是让流程自我进化的关键，不能省。

十、结语：依赖管理的本质是降低信息不对称

这篇文章我想说的核心观点只有一个：依赖治理不是流程问题，而是信息结构问题。 当依赖只是一条连线，它就只承载了"存在关系"这一个信息；当它成为一个有责任人、有承诺日期、有客观关闭判据、有升级路径的工作项，它才承载了足够让组织做出决策的信息量。

我见过太多团队把精力花在优化流程模板上，却不肯把依赖改成独立工作项；也见过太多管理者盯着延期结果追责，却不肯在阶段门中点检查浮动消耗。这两件事的顺序如果搞反了，投入越多，挫败感越强。

如果你准备开始，我的建议是按这个顺序走：第一步，本周就把所有跨人依赖的承诺日期补上，由供给方确认；第二步，下一个阶段门评审加入前面那 10 项清单；第三步，跑满 3 个迭代后，再引入 DDR 和 BST 两个指标；第四步，等到升级机制稳定运行，再加 DRI、CPFB 和 DER。 不要一次性全上，也不要指望两个迭代见效，按我跟踪的 12 个迭代样本，真正的拐点出现在第 6 到第 9 个迭代之间。

最后提醒一句：依赖指标只能用来触发动作，绝不能用来评价人。一旦挂钩考核，你得到的所有数字都会变成修饰过的答案，而真实的依赖风险会重新沉回水面之下，比治理之前更隐蔽。