依赖关系流程与规范：产品经理任务依赖制度设计关键指标

去年第三季度，我带的一个跨部门项目上线延期了11天。复盘会上每个人都拿得出证据：设计说需求冻结晚了3天，开发说设计稿交付晚了5天，测试说提测晚了4天，运维说发布窗口需要重排。所有依赖在项目管理工具里都登记着，红色标记一路飘红，但没有任何一个环节的负责人，真正为"这个依赖什么时候解决"负过责。

那场复盘让我确认了一件事：依赖管不好，通常不是因为团队没有记录依赖，而是因为团队只记录了依赖。记录只是把风险可视化，制度才是把风险关掉。这两件事之间隔着责任、时限和升级机制，而大多数团队恰好只做了第一件。

这篇文章不谈"什么是任务依赖"这种教科书内容。我想讲的是我在这几年带项目、做流程改造过程中真正用过、也踩过坑的一套方法：怎么把依赖拆成可管理的两类，怎么用责任、时限、升级三要素搭出制度骨架，以及用哪五个指标判断这套制度到底有没有在工作。

一、先把结论说清楚：依赖制度的核心不是流程图

如果你只想从这篇文章里拿走一句话，那就是：依赖管理制度化的目标，不是让依赖消失，而是让每一个依赖在失控之前被看见，并且有一个明确的人、在一个明确的时间点之前、对它负责。下面四条是我在多个团队反复验证后沉淀下来的核心结论。

1. 结论一：先分硬依赖和软依赖，再谈制度

大部分依赖制度失败的第一原因，是把所有依赖用同一套规则管。硬依赖是客观的顺序约束，比如"提测之后才能开始系统测试"，这种依赖违反不了，只能等待；软依赖是资源和信息约束，比如"设计稿还没最终定稿，但开发可以先搭框架"。

硬依赖需要流程节点锁定，软依赖需要沟通机制和缓冲设计。用硬依赖的锁死方式去管软依赖，团队会为了走流程而走流程；用软依赖的宽松方式去管硬依赖，项目就会在关键路径上悄悄延期。这个区分不做，后面所有的制度和指标都会失真。

2. 结论二：责任、时限、升级，三要素缺一不可

我见过的最常见的"依赖管理制度"，是一张画得很漂亮的泳道流程图，贴在飞书文档里，半年没人打开。它失效的原因很简单：流程图只回答了"谁在什么时候把东西交给谁"，没有回答"如果没交，会发生什么"。

真正能运转的制度只有三个要素：每个依赖有且只有一个负责人，每个环节有明确的时间窗，超时后由制度自动触发升级而不是靠个人胆量去催。三要素里缺任何一个，制度都会退化成一张没人看的表。

3. 结论三：指标只留五个，但口径必须能自动采集

指标的作用是验证制度是否在运行，不是给人做汇报用。我建议初期只留五个：依赖识别率、依赖阻塞时长、依赖准时交付率、升级响应时间、跨团队依赖闭环率。这五个指标覆盖了"看得见、等得短、交得准、升得快、闭得掉"五个环节。

但比指标数量更重要的是口径。如果一个指标需要人工每周花两小时统计，它活不过三个月。指标的定义字段必须落在依赖登记的结构化字段里，最好能直接从系统里出数。

4. 结论四：制度的目标不是消灭依赖，而是让依赖可见

有些团队管理者会误解，以为依赖管理制度做好了，依赖就会变少。这是错的。产品越复杂、组织越大的团队，依赖只会更多。制度能做到的是：依赖被提前识别、被明确归属、被量化跟踪，从"没人知道在等谁"变成"所有人都知道还差谁的哪一件事"。

下面这张图是我所在团队在制度上线前后，用同一口径回溯统计的对比，能比较直观地看出制度真正改变的是什么。

二、真实场景还原：依赖为什么总是"记录了却没解决"

抽象地讲依赖管理很难有效。我把上面提到的那个延期11天的项目，按时间线还原一遍，你会发现每个环节看起来都合理，但结果就是崩了。

1. 一个典型的依赖链条是怎么崩的

这个项目的关键路径大概是这样的：

• 8月5日，需求评审通过，产品经理在系统里登记了7条依赖，其中3条跨团队。
• 8月7日，设计稿需要定稿，但用户中心那边还没确认实名认证接口的字段范围，设计卡住了。
• 8月12日，开发开始搭框架，但订单中心和用户中心的接口契约还没定，只能先写Mock。
• 8月16日，设计稿终于定稿，比原计划晚了5天，开发排期没有顺延，直接压缩了联调时间。
• 8月22日，提测晚4天，测试压缩用例，漏掉了一个边界场景。
• 8月29日，上线前回归发现缺陷，发布窗口重排，最终延期11天。

复盘时最扎心的一点是：这7条依赖全都登记了，但登记的字段只有"依赖描述"和"计划完成日期"，没有负责人，没有确认时限，也没有超时后的升级路径。也就是说，这7条依赖只是一张清单，不是一套制度。

我在这次复盘后统计了整个季度427条依赖记录，发现依赖从"登记"到"真正被解决"之间，最大的时间消耗不是业务工作量，而是等待确认和等待归属。

2. 依赖的四种类型，产品经理只需要记住两组

项目管理体系里通常讲四种依赖类型，这里用产品经理能听懂的语言重述一遍：

（1）完成-开始（FS）：A完成后B才能开始。比如"接口联调完成后才能做集成测试"。这是最常用的一种，占实际项目的绝大多数。

（2）开始-开始（SS）：A开始后B才能开始。比如"数据迁移开始后才能开始双写校验"。

（3）完成-完成（FF）：A完成后B才能完成。比如"服务端灰度完成后，客户端灰度才能收尾"。

（4）开始-完成（SF）：A开始后B才能完成，实际项目中极少使用，产品经理基本可以忽略。

但我更想强调的不是这四种。因为在实际团队里，懂FS、SS、FF并不能帮你解决任何纠纷，真正影响制度设计的是第二组分类：硬依赖和软依赖。硬依赖有客观的物理或逻辑顺序，违反它一定出错；软依赖只是"当前状态下更顺"，通过调整资源、并行设计或提前约定接口，是可以解耦的。

比如"设计稿定稿后才能开发"在多数团队被当成硬依赖，但如果前端和后端在需求阶段就对齐了接口契约和视觉规范，开发完全可以先做逻辑层和Mock联调。这就是典型的软依赖被误当硬依赖处理，白白拉长了关键路径。

3. 依赖阻塞到底卡在哪里

我在两个团队里做过同一件事：把每个季度所有依赖的阻塞原因做归类统计。结果高度一致，真正因为"工作量大做不完"导致的阻塞很少，绝大多数阻塞来自信息不同步和责任不明确。

顺带说一句，同样这批样本按依赖来源拆开看，跨团队依赖的准时交付率明显低于团队内依赖。这也解释了为什么依赖制度的重点应该放在跨团队场景。

三、四个常见误区，让依赖管理变成形式主义

我复盘过很多"制度推行失败"的案例，失败模式高度集中在四个误会上。这四个误区如果不提前识别，写再多规范也没用。

1. 误区一：把任务依赖和人员依赖、资源依赖混为一谈

这是最普遍的概念混用。任务依赖是任务之间的顺序约束，人员依赖是"这件事只有某个人能做"，资源依赖是"这个环境/预算/设备被占用了"。三者的解决手段完全不同：任务依赖靠流程锁定，人员依赖靠知识备份和接力，资源依赖靠排期和预算。

之所以要分开，是因为它们对指标的影响方式不同。如果一个团队把"某位架构师太忙"也算成任务依赖，那依赖准时交付率就会被无关因素拉低，指标失去诊断价值。我通常的做法是：只把有明确交付物的跨任务约束登记为任务依赖，人员可用性、环境占用单独用另一类字段记录。

2. 误区二：只画流程图，不定义责任和时限

流程图解决的是"正常路径长什么样"，但依赖管理的痛点恰恰在异常路径。一个依赖没被按时确认，流程图不会告诉你下一步该做什么。

我判断一份依赖规范是否合格的检验方法是：把流程图里的所有箭头去掉，只留文字，看能不能回答"超时了谁来找我"。如果回答不了，这份规范就是装饰品。

3. 误区三：所有依赖都按硬依赖管，制度一刀切

有些团队为了"规范"，要求所有依赖都必须走统一的确认流程，包括那些本可以通过接口契约提前解耦的软依赖。结果是流程成本急剧上升，团队开始绕开流程私下沟通，制度反而被架空。

正确的做法是差异化：硬依赖用强流程锁定并纳入关键路径管理，软依赖用轻量确认加缓冲时间处理。制度设计的水平，体现在对不同类型的依赖给出不同的强度，而不是统一强度。

4. 误区四：用依赖数量考核个人

这是最有破坏性的一个误区。一旦依赖数量被纳入个人绩效，团队的理性选择就是少报、晚报、把依赖拆成不记录的口头沟通。指标看上去变好了，风险却全部沉到水下。

依赖类指标只应该用来诊断流程，不应该用来考核个人。如果要考核，考核的应该是"依赖被识别出来的及时性"和"承诺后的准时交付率"，而不是"依赖发生了多少条"。

下面这张图对比了硬依赖和软依赖在常见管理手段上的适配程度，能帮你在设计制度时避免一刀切。

四、专业判断逻辑：责任、时限、升级三要素怎么定

讲完误区，进入我认为最关键的一节。依赖制度能不能落地，取决于这三要素的具体定义是否清晰到可以执行。

1. 责任：一个依赖只能有一个负责人

"共同负责"在依赖管理里等于"没人负责"。我的规则很硬：每条依赖必须指定一个依赖负责人，而且只能有一个。这个负责人不一定是解决依赖的人，而是"负责推动这条依赖被解决"的人。

这里有个容易混淆的点：依赖方和被依赖方都可能觉得自己没有义务。我的处理方式是拆成两个角色：依赖提出人负责把需求描述清楚并在解决后验收；依赖负责人负责推动被依赖方给出承诺时间和实际交付。两个角色都只有一个具体的人，不写团队名。

2. 时限：提出、确认、解决三段时间窗

只有"计划完成日期"是不够的。我把每条依赖拆成三个时间点：提出时间（登记时刻）、确认时限（被依赖方必须给出"能不能做、什么时候做"的答复）、解决时限（承诺交付时间）。

确认时限是最容易被忽略、但收益最大的一个字段。大量依赖的阻塞不是卡在做，而是卡在"答不答应"。明确规定"硬依赖提出后4个工作小时内必须确认"，能把大量模糊等待变成明确结论。

解决时限我建议由被依赖方给出，而不是由提出方指定。理由很简单：承诺的时限才有人负责，被指派的时限只会被解释。

3. 升级：靠制度触发，不靠个人胆量

升级机制是整套制度里最难的部分，因为它涉及人际成本。我见过太多团队在规范里写了"必要时升级"，结果从来没有人升级过，因为"必要时"是个主观判断，而升级意味着可能得罪平级同事。

我的做法是把升级变成系统动作：确认时限超时自动通知依赖负责人和其直属主管；解决时限超时自动通知双方团队负责人；再超时则通知项目决策人。升级不是"我去告状"，而是"系统按规则发出提醒"，人际成本会大幅下降。

4. 依赖登记表应该有哪些字段

上面三要素最终都要落到字段上，否则就是空谈。下面是我实际在用的一套依赖登记字段，可以直接作为设计参考：

{
"dependency_id": "DEP-2024Q3-0417",

"description": "订单中心需要用户中心提供实名认证状态查询接口",

"deliverable": "接口文档 + 联调环境可用的接口",

"type": "hard",

"raised_by": "订单中心-张AAA",

"raised_at": "2024-08-12T10:20:00+08:00",

"owner": "用户中心-李BBB",

"ack_deadline": "2024-08-12T18:00:00+08:00",

"ack_at": "2024-08-12T15:40:00+08:00",

"resolve_deadline": "2024-08-16T18:00:00+08:00",

"resolved_at": "2024-08-16T11:05:00+08:00",

"status": "resolved",

"escalation_path": ["依赖负责人", "双方团队负责人", "项目决策人"],

"escalation_level": 0,

"impact": "影响迭代A的关键路径，延迟1天将导致上线顺延",

"related_iteration": "Sprint-24.17"

}

注意其中的 ack_deadline 和 ack_at 这两个字段。它们的存在本身就在告诉团队：确认这件事是有时限的，而且会被记录。仅这一条，就能消掉相当一部分"消息发出去两天没回音"的隐性阻塞。

不同类型依赖的时间窗建议如下，这套基准是我在100人量级的研发组织里调过几轮后相对稳定的版本。

五、五个关键指标及计算口径

制度上线后，如果没有指标，你无法判断它是在工作还是已经空转。我只保留五个指标，原因是一个季度能真正被人看懂、被行动跟进的指标，五个已经是上限。

1. 依赖识别率

定义：在某个统计周期内，被提前登记并进入跟踪的依赖数，占实际发生依赖总数的比例。这个指标回答的是"我们看得见多少"。

计算口径最难的是分母。实际发生依赖总数可以通过复盘补充法估算：在迭代复盘时，统计那些"事后才发现是依赖"的事项，加上已登记的数量作为分母。这个口径不完美，但足以看出趋势。

参考阈值：成熟团队建议做到75%以上。这个指标低于60%，说明登记机制没有被真正使用，后面四个指标都不用看了。

2. 依赖阻塞时长

定义：依赖从"提出"到"被解决"的平均等待时长，可以进一步拆成"等待确认时长"和"等待交付时长"。

为什么要拆开？因为两者的改进手段完全不同。等待确认长，说明确认时限和升级机制没起作用；等待交付长，说明排期或资源分配有问题。如果不拆开，你只会看到一个笼统的"平均3.8天"，却不知道该改哪里。

参考阈值：硬依赖的平均阻塞时长建议控制在2个工作日以内，软依赖控制在5个工作日以内。

3. 依赖准时交付率

定义：在已解决的依赖中，实际解决时间不晚于承诺解决时间的比例。

这里要特别强调一点：分母用的是"承诺时间"，不是"最初计划时间"。很多团队一开始会混淆这两个概念，导致指标虚低。承诺时间是依赖负责人自己给出的，用它做分母，责任才对得上。

参考阈值：80%以上算健康，低于65%说明承诺本身随意，需要重新校准承诺机制。

4. 升级响应时间

定义：从系统触发升级，到被升级对象首次给出有效响应的时间。

这个指标是整套制度能否长期运转的关键。因为如果升级之后没人理，团队很快就会学会"升级没用"，制度随即崩塌。升级响应时间是衡量管理者是否真正支持依赖制度的唯一硬指标。

参考阈值：硬依赖相关升级建议不超过2工作小时给出首次响应，软依赖不超过4工作小时。

5. 跨团队依赖闭环率

定义：跨团队依赖中，最终被明确标记为已关闭（交付物被验收，或有明确的取消结论）的数量占比。

为什么强调"闭环"而不只是"完成"？因为大量跨团队依赖的真实结局是"不了了之"，需求变了、优先级降了、双方都默契地不再提。没有被明确关闭的依赖会持续占据团队心理带宽，也会让统计失真。

参考阈值：建议90%以上。低于80%说明存在大量悬空依赖，需要专门做一次清理。

下面这张表把五个指标的完整口径集中列出，方便直接复制到你的规范文档里。

如果指标要能自动跑出来，基础是字段规范。下面这段是可直接参考的取数口径示例：

-- 依赖准时交付率与平均阻塞时长
SELECT

COUNT(*)                                                AS resolved_total,

ROUND(100.0 * SUM(CASE WHEN resolved_at THEN 1 ELSE 0 END) / COUNT(*), 1) AS on_time_rate,

ROUND(AVG(EXTRACT(EPOCH FROM (resolved_at - raised_at)) / 3600.0), 1) AS avg_block_hours,

ROUND(AVG(EXTRACT(EPOCH FROM (ack_at - raised_at)) / 3600.0), 1)      AS avg_ack_hours

FROM dependency

WHERE status IN ('resolved', 'closed')

AND raised_at >= :period_start

AND raised_at AND type IN ('hard', 'soft');

-- 升级响应时间

SELECT

ROUND(AVG(EXTRACT(EPOCH FROM (first_response_at - escalated_at)) / 3600.0), 1) AS avg_escalation_hours

FROM dependency

WHERE escalated_at IS NOT NULL

AND first_response_at IS NOT NULL

AND escalated_at >= :period_start;

这两个查询加起来就能覆盖指标2、3、4。指标1需要人工补充复盘数据，指标5只需要换个 where 条件。指标体系的可用性，取决于取数成本，而不是指标有多全面。

六、以 PingCode 为例：100人以上组织怎么把制度变成配置

前面讲的是制度设计逻辑，接下来讲落地。制度能否长期运行，很大程度上取决于它是否被写进了团队每天使用的工具里。如果依赖管理靠一张独立的表格，它一定会被日常工具挤掉。对100人以上的中大型组织来说，这一点尤其明显。

1. 为什么中大型组织更需要平台而不是表格

20人团队用一张共享表格管依赖是可以的，因为所有人都认识彼此有明确的沟通路径。但组织规模过百之后，会出现三个变化：跨团队依赖占比显著上升、责任人流动性增加、依赖信息的更新频率超过人工维护能力。

PingCode 主要服务中大型企业及100人以上组织，这个定位正好对应了依赖制度最难推行的组织阶段。制度在20人团队靠默契，在100人以上组织只能靠系统。这也是我在给这类组织做流程设计时，会优先考虑平台化落地的原因。

2. 把五个关键字段落到工作项上

我在 PingCode 里设计依赖字段时的原则是：不新建一套系统，而是把依赖字段挂到已有的工作项上，让团队在自己每天都在用的界面里完成登记。

具体做法是把前面那套字段映射成工作项的自定义属性，包括：

• 依赖类型：枚举值（硬依赖/软依赖），用于区分后续流程强度。
• 依赖负责人：人员字段，强制唯一，不允许填团队名。
• 确认时限：日期时间字段，由系统按依赖类型自动填入默认值。
• 解决时限：日期时间字段，由被依赖方填写承诺时间。
• 升级状态：枚举值（未触发/一级/二级），由自动化规则更新。

字段设计的经验是：凡是需要人工判断的字段，一定要给默认值；凡是需要人工填写的必填字段，数量不能超过三个。超出这个范围，登记动作就会开始被拖延和敷衍。

3. 用自动化规则替代人工催促

升级机制最难的是触发性。靠人记得去催，等于制度没有落地。我在配置时会把三条规则写进自动化：

1. 依赖创建后，若在确认时限内未被确认，自动通知依赖负责人及其直属主管，并把升级状态置为一级。
2. 到达解决时限当天仍未解决，自动通知双方团队负责人，升级状态置为二级。
3. 依赖解决后，自动通知提出人验收，并在超时未验收时提醒关闭或重开。

这三条规则的价值不在于提醒本身，而在于它把"催"这个动作从人际行为变成了系统行为。在我推行过的团队里，仅"自动升级"这一条，就显著改变了软依赖被无限期搁置的情况。

4. 迁移与部署：国产替代场景下的两个现实考虑

我在帮一些中大型组织做依赖制度落地时，遇到过两个很实际的问题。第一个是历史数据迁移：很多团队原本用 Jira 管理研发流程，依赖关系散落在链接字段和描述文本里，重新登记成本极高。PingCode 支持 Jira 平滑迁移，能把历史工作项及其关联关系带过来，这一点对制度切换的阻力影响很大，如果迁移成本高到需要团队手工补录几个月的历史数据，制度推行基本会在起步阶段就失败。

第二个是数据合规与部署方式。越大的组织，对研发数据的存放位置越敏感。PingCode 支持私有化部署，这对金融、制造、政企类客户是硬性门槛。依赖数据往往包含排期、人力、客户名称等敏感信息，能不能私有化部署，直接决定了这类组织能不能把依赖制度放到平台上。在国产替代的选型场景里，私有化能力和历史迁移能力是绕不开的两个判断点。

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

到这里，制度设计和落地路径都讲完了。但我不建议任何团队照搬全套。团队规模不同、协作成熟度不同，应该用的方案完全不同。下面是我给不同阶段团队的建议。

1. 10人以下：约定时限，不上系统

这个阶段上依赖管理系统是浪费。团队所有人都在一个群里，沟通成本极低。真正需要做的只有一件事：约定一条规则，任何依赖请求，被请求方必须在当天给出明确答复，不能做的要直接说不能做。

这条规则的价值在于消除"模糊等待"。小团队最大的风险不是依赖多，而是"我以为他会做"。

2. 20-50人：登记表加周度 review

这个阶段需要开始登记，但要保持轻量。我建议用一张结构化表格，字段控制在必填三项：依赖描述、依赖负责人、承诺解决日期。每周花30分钟在项目例会上过一遍超期项即可。

这个阶段最重要的动作是建立"承诺时间由被依赖方给出"的习惯。习惯一旦建立，后面上系统会顺很多；习惯没建立，上系统只会把混乱自动化。

3. 100人以上：字段加自动化加指标看板

到了这个规模，人工维护已经不可能。必须做到三件事同时具备：依赖字段嵌入日常工作项、超时升级自动化、五个指标月度可见。

这个阶段我还建议加一条：把升级响应时间和跨团队依赖闭环率纳入团队负责人的月度经营指标，而不是纳入个人绩效。指标挂到管理者身上，制度的权威性才立得住。

4. 跨公司或外包协作：把依赖条款写进合同

外包和供应商依赖是准时交付率最低的一类。原因很直接：内部制度对它们没有约束力。这类依赖的处理方式是把制度条款合同化，明确交付物定义、确认时限、延迟责任，并与付款节点挂钩。

对内部团队，制度靠流程；对外部合作方，制度靠契约。这两套逻辑不能混用。

八、不同情况下的取舍

制度和任何管理动作一样，都有成本。以下是我在实际推行中反复权衡的四组取舍。

1. 制度化程度与灵活性

制度越强，可预测性越高，但团队自主调整空间越小。我的判断标准是看项目类型：面向确定交付的项目（如合规上线、硬件联调），制度强度应该高；面向探索的项目（如新业务验证），制度强度应该低，只保底登记关键依赖。

不区分项目类型统一加码，是很多流程改造失败的共同原因。

2. 硬性升级与关系成本

升级机制一定会有关系成本，这是无法完全消除的，只能转移到系统上。我的取舍是：一级升级只通知直属主管，不抄送更多层级，给双方留出解决问题的空间；二级升级才通知团队负责人。

如果所有超时都直接捅到高层，团队很快会创造出各种规避手段，比如提前把时限填得很宽松，指标立刻失真。

3. 指标透明与考核异化

依赖指标公开透明是必要的，它可以建立团队间的信任。但透明的前提是明确不用于个人考核。我的做法是公开到团队维度，不公开到个人维度，并在团队内部说明指标的用途是定位流程问题。

这一点在制度推行的前三个月尤其重要。前期指标数值一定不好看，如果这时候被当作考核依据，团队的第一反应就是美化数据。

4. 自建表格与采购平台

自建表格的优势是灵活、便宜、随时能改；劣势是缺少自动化和跨团队可见性。采购平台的优势是自动化规则和统一视图，劣势是配置成本和学习成本。

我的分界线是：当跨团队依赖占比超过30%，或者组织规模超过100人时，自建表格的维护成本会超过平台成本。在这条线之前，别急着上平台；在这条线之后，也别指望靠表格撑住。

九、三个落地坑和应对方式

即使制度设计正确，落地过程仍然会在几个固定位置出问题。以下三个坑我几乎每次推行都会遇到。

1. 坑一：依赖登记变成形式主义

表现是登记率很高，但字段质量差：负责人填的是团队名、承诺时间填的是迭代结束日、依赖描述只有一句话没有交付物。

应对方式是用字段校验代替人工检查：负责人必须是具体人员，承诺时间不能晚于迭代结束日，依赖描述必须包含交付物关键词。规则写在系统里，比写在规范文档里有效十倍。

2. 坑二：升级机制得罪人，导致制度空转

表现是升级记录几乎为零，但超期依赖很多。根因是把升级理解为"打小报告"。

应对方式有两个：一是把升级做成系统自动触发，去掉"谁去告状"的人为色彩；二是管理者要在公开场合反复表态，升级不是问题，升级后没人响应才是问题。管理者的态度决定了升级机制能不能活。

3. 坑三：指标滥用导致少报瞒报

表现是依赖数量突然下降、准时交付率突然上升，但项目实际延期没有改善。

应对方式是交叉验证：把依赖指标和项目延期数据放在一起看。如果依赖准时交付率上升但项目延期率没有下降，基本可以判断是数据被美化。这种时候要先停掉指标上报，回到问题本身。

结语：好的依赖制度，是让依赖在失控前被看见

回到开头那个延期11天的项目。我当时最大的判断失误，不是没识别出依赖，而是误以为"登记"等于"管理"。依赖被写进系统的那一刻，风险只是从看不见变成了看得见，它并没有被解决。

真正让依赖可控的，是三件很朴素的事：每条依赖有唯一的负责人，每个环节有明确的时间窗，超时之后有制度化的升级动作。这三件事做到位，五个指标自然会往好的方向走；这三件事做不到，指标再漂亮也只是数字游戏。

如果你打算动手，我建议按这个顺序推进：先用一周时间把团队正在进行的项目里的依赖梳理一遍，只补三个字段，依赖负责人、承诺解决时间、影响范围；然后用两周时间观察哪些依赖会超期，据此确定你的时间窗基线；最后再考虑把规则写进工具、把指标做成看板。

不要一上来就做全套制度。依赖管理的失败案例里，绝大多数不是设计得不够完整，而是第一步太重，重到没人愿意执行。