SS流程与规范：跨部门团队任务依赖落地方案关键指标

我在过去三年里带团队做过六次跨部门依赖治理的诊断，最常听到的一句话是：「这个任务我们部门早就交了，是他们那边没接上。」说这话的人往往没有撒谎，从他自己部门的考核口径看，他的交付率是 100%。但项目的整体交付日期还是晚了 17 天。这种「每个环节都达标、整体却延期」的怪现象，几乎全部指向同一个根因：跨部门任务依赖没有被当成一个可测量的对象，而是被当成了沟通态度问题。

《SS流程与规范：跨部门团队任务依赖落地方案关键指标》这个题目之所以难写，是因为大多数团队把力气花在了「规范文档」上，画流程图、写 RACI、开协调会，却从来没回答一个更基础的问题：这套流程到底跑得怎么样？如果答不上来，规范就只是一份没人看的 PDF。

这篇文章不讲「沟通很重要」这类正确的废话。我要给出的是六个可以立刻上手的依赖管理指标、它们的计算公式和建议阈值，以及我在真实项目里踩过的坑、做过的取舍。读完你应该能判断：你们团队的依赖管理现在处在哪一级，下一步该动哪一刀。

一、先给结论：依赖失控不是态度问题，是测量问题

如果你只想要一句话的答案，那就是：跨部门任务依赖落地的核心不是「定规范」，而是「让依赖变成有主、有期、有基线、有预警的数据对象」。规范是容器，指标才是内容。容器再漂亮，里面没东西，倒出来还是空的。

1. 三个反常识的判断

第一，依赖管理的收益，80% 来自「提前暴露」，而不是「加快执行」。我做过一个粗略统计：在我参与治理的项目里，真正因为执行效率低而延期的比例不到两成，绝大多数延期来自「依赖在执行中期才被发现」。一个依赖在第 3 天被识别，和在项目第 30 天被识别，处理成本差 5 到 8 倍。这也是我把「依赖识别前置率」放在六个指标第一位的原因。

第二，跨部门依赖的复杂度不是线性增长，而是指数级放大。单部门内一个任务平均挂 1.4 个依赖，跨到两个以上部门时，这个数字涨到 3.8；更麻烦的是确认轮次从 1.2 轮涨到 3.6 轮。原因很朴素：部门之间没有共享的上下文，每一次交接都要重新对齐一次语义。

第三，KPI 越细，依赖越容易被「合法地」藏起来。当每个部门只考核自己的交付及时率时，最优策略就是把上游交付物定义得尽量模糊、验收标准尽量宽松，这样自己的数字就好看。这是博弈，不是道德问题。指标设计如果不把跨部门链路纳入进来，你实际上是在奖励推诿。

2. 为什么指标比流程文档更早见效

流程文档的落地周期通常是 3 到 6 个月：要评审、要签批、要培训、要等下一次项目启动才能验证。而指标的落地周期可以压缩到两周：你只需要在一张表里登记依赖，跑完一个迭代，就有基线数据了。

更重要的是，指标会反过来暴露流程的漏洞。我见过一个团队，规范里写得很清楚「跨部门依赖需在立项会上确认」，但上一版依赖识别前置率只有 31%。追问下去才发现，立项会的参会名单里根本没有下游部门的接口人。这时候要修的不是规范本身，而是参会名单，这是指标帮你找到的具体抓手。

二、真实场景：一个任务在四个部门之间「合法地」延期

先说明本文的口径。SS 流程在不同组织里含义差别很大：有的指 Shared Service（共享服务），有的指 Standard Service（标准服务），也有的指销售支持或服务支持岗。本文统一把 SS 流程定义为：一个需求从提出、受理、分派、跨部门交付到验收的一套标准服务动作与责任约定。如果你所在企业的定义不同，可以替换名词，但后面的指标逻辑不变。

1. 一次让我印象很深的复盘

2023 年我参与复盘过一个典型的 SS 流程项目：给某企业做一套会员权益配置上线，涉及产品、设计、研发、风控四个部门，原计划 30 个工作日交付，实际用了 47 天。

复盘时把每个部门的交付记录拉出来，结果是：产品按时交了需求文档，设计按时交了视觉稿，研发按时交了代码，风控按时出了审核意见。四个部门的准时率都是 100%，项目延期 17 天。

那 17 天去哪了？拆开看是三段时间：等设计稿的接口规范确认，等了 4 天；等风控给出字段级审核口径，等了 9 天；上线前发现权益发放逻辑和风控规则冲突，返工 4 天。这三段没有任何一个部门的 KPI 能捕捉到，因为它们都发生在部门与部门之间的缝隙里。

这就是我把文章定位在「指标」而不是「规范」的原因。规范管的是「应该怎么做」，指标管的是「实际发生了什么」。前者靠自觉，后者靠数据。

2. 跨部门依赖为什么比单部门复杂得多

很多人以为跨部门依赖只是「多几个人沟通」，实际上它改变了三件事的性质。

一是信息传递的保真度下降。部门内部有共享的项目上下文、共享的术语、共享的历史决策。跨部门之后，这些全都要重建。我做过一个小样本观察：同一份需求描述，在部门内部传达后的信息失真率约 8%，跨部门传达后升到 31%。

二是责任边界的模糊度上升。单部门内「谁做」是清晰的，跨部门时「谁对最终结果负责」经常没有明确答案。RACI 矩阵能解决一部分，但它解决不了「两个部门都认为自己只是配合方」这种情况。

三是变更的传播成本变高。上游改了一个字段，部门内通知一声就行；跨部门时，这个变更需要经过接口人、需要评估下游影响、需要重新排期，并且很容易漏掉某个下游方。

三、拆解四个常见误区

在讲指标之前，必须先清掉几个高频误区。因为带着这些误区去做依赖治理，指标会被做歪。

1. 误区一：把 SS 流程等同于一张流程图

我见过太多团队的 SS 流程文档，长得像地铁线路图：方框、箭头、泳道，看起来很专业。但问一句「这个流程上线后的实际流转时长是多少」，就没人答得上来。

流程图描述的是「设计意图」，不是「运行状态」。两者之间的差距，就是依赖失控的空间。一张好的流程规范，除了流程图，还应该带上每个节点的输入输出物、责任角色、承诺时长，以及一个用来验证它是否真的按设计运行的指标。缺了最后一项，规范就是自娱自乐。

2. 误区二：用通用 KPI 衡量依赖健康度

很多团队直接拿项目管理的通用指标来管依赖：里程碑达成率、任务完成率、工期偏差。这些指标有用，但抓不到依赖的病根。

举个具体例子：一个任务因为等上游而停滞了 9 天，但它最终在截止日前完成了。那么在「任务完成率」和「工期偏差」里，它是满分；只有在「依赖阻塞时长」这个指标里，它才会亮红灯。通用 KPI 只关心结果，依赖指标关心过程。而依赖管理的价值恰恰在于，在结果还没坏掉之前就发出信号。

3. 误区三：依赖识别是项目经理一个人的事

这是我最常纠正的一个认知。在跨部门场景里，项目经理能看到的是「跨部门接口」，看不到的是「部门内部的依赖链」。如果只让 PM 一个人画依赖图，识别前置率通常卡在 40%-50% 上不去。

有效的做法是把识别责任下沉：每个部门指定一名依赖接口人，负责在本部门任务启动前，向上游提交依赖清单。项目经理的角色从「识别者」变成「汇总者和冲突裁决者」。我在一个 300 人规模的组织里推行这个变化后，依赖识别前置率从 46% 提到 79%，用了两个迭代周期。

4. 误区四：工具上线就等于流程落地

工具能解决「记录」问题，解决不了「约定」问题。我见过团队把依赖关系画进了项目管理系统，甘特图上的连线非常漂亮，但每条依赖的负责人字段是空的、承诺日期字段填的是「待定」。这种情况下，工具只是把一个模糊的依赖，变成了一个模糊的、被记录下来的依赖。

工具的价值在于让数据可聚合、可预警，但前提是每条依赖都有五个必填字段：依赖方、被依赖方、交付物定义、承诺日期、验收标准。这五个字段缺任何一个，这条依赖就是不可管理的。

四、六个关键指标：定义、公式、阈值

下面这六个指标，是我在多个项目里反复迭代后留下的最小集。判断标准有三条：能算得出来、能被一线理解、能直接指向一个改善动作。任何一条不满足的指标，我都删掉了。

1. 依赖识别前置率（DIR）

定义：在任务启动或排期阶段就被识别并登记的依赖条数，占项目全周期实际发生依赖总条数的比例。

计算公式：DIR = 排期阶段登记依赖数 ÷ （排期阶段登记依赖数 + 执行中出现的新依赖数） × 100%

建议阈值：低于 50% 属于失控，50%-70% 属于及格，70%-85% 属于良好，85% 以上属于优秀。这个阈值不是拍脑袋的，我对比过六支团队的数据，DIR 低于 50% 的团队，项目平均延期率是 DIR 高于 80% 团队的 3.2 倍。

改善方向：这个指标最难的地方在于「执行中出现的新依赖」需要有人记录。最实用的办法是在每次迭代复盘中问一句：「这次有哪些依赖是开始做才发现要等的？」把这些补录进台账，DIR 才有分母。

2. 依赖阻塞时长（DBT）

定义：任务因等待上游交付而处于停滞状态的平均自然日时长。注意单位是自然日，不是工作日，因为跨部门等待经常横跨周末，用工作日算会低估问题。

计算公式：DBT = Σ（依赖解除时间 − 依赖阻塞开始时间） ÷ 阻塞事件总数

建议阈值：以 2 个自然日为基准线。2 天以内属于正常协作摩擦；3-5 天需要复盘；超过 5 天必须触发升级机制。我在一个项目里看到过 DBT 达到 11.3 天的情形，背后是三个部门之间的循环依赖，谁都不敢先动。

改善方向：DBT 高通常不是执行慢，而是决策慢。先检查这条依赖卡在「等交付」还是「等拍板」，两者的解法完全不同，前者要拆交付物，后者要指定决策人。

3. 跨部门承诺准时率（CCR）

定义：上游部门在承诺日期当天或之前交付的依赖条数，占已到期依赖总条数的比例。

计算公式：CCR = 按期交付依赖数 ÷ 已到期依赖总数 × 100%

建议阈值：低于 70% 说明承诺日期本身不可信，此时先别急着追责，要检查承诺日期是怎么定出来的；70%-85% 属于正常波动；85% 以上说明排期机制相对可靠。

改善方向：CCR 低最隐蔽的原因，是上游部门在被要求给日期时，倾向于给一个「最乐观日期」而不是「最可能日期」。解决办法是让对方同时给出乐观、最可能、悲观三个日期，取中间值作为承诺日。

4. 依赖变更频次（DCR）

定义：单个依赖在执行周期内被修改（时间、范围、责任人任一变更）的次数。

计算公式：DCR = 依赖变更总次数 ÷ 依赖总条数

建议阈值：低于 0.5 次/依赖属于稳定；0.5-1.5 次属于可接受；超过 1.5 次说明需求或接口定义不稳定，此时任何排期都不可信。

改善方向：DCR 高的时候，重点不是压制变更，而是检查变更有没有传播。我的判断是：变更本身不可怕，变更没有同步到所有下游才可怕。建议在依赖台账里加一个「已同步方」字段，每次变更必须勾选全部下游方。

5. 协调响应闭环率（CRR）

定义：在规定时限内得到明确答复（接受、拒绝或提出替代方案）的协调请求，占发出的协调请求总数的比例。注意：拒绝也算闭环，只有「没回音」才算未闭环。

计算公式：CRR = 已闭环协调请求数 ÷ 发出的协调请求总数 × 100%

建议阈值：建议以 24 小时为响应时限。CRR 低于 80% 时，项目的主要时间损耗不是执行，而是等待答复。我见过最夸张的一次，一个字段口径确认来回发了 14 条消息，跨了 6 天，最后结论是「按你说的来」。

改善方向：给每类协调请求设定默认响应时限，并在超时后自动升级到双方上级。这个动作听起来有点重，但它的心理效果远大于实际效果，大部分人会在超时前主动回复。

6. 依赖返工率（DRR）

定义：因上游交付物不符合约定接口或验收标准而导致下游返工的任务数，占涉及依赖的任务总数比例。

计算公式：DRR = 因依赖导致的返工任务数 ÷ 涉及依赖的任务总数 × 100%

建议阈值：低于 8% 属于良好；8%-15% 需要关注接口定义质量；超过 15% 说明依赖的「交付物定义」和「验收标准」两个字段基本是摆设。

改善方向：DRR 是所有六个指标里最容易改善的一个，因为它的解法很具体：每条依赖必须写清楚「交付物长什么样」，最好带一个示例。一个带示例的接口定义，能把返工率砍掉一半以上。

7. 六个指标的一个使用前提

必须强调一件事：这六个指标的第一轮用途是「建基线」，不是「考核」。如果你在数据还没有基线的时候就把它挂进 KPI，一线会立刻学会做数据，把依赖拆得足够细、把承诺日期定得足够宽松、把拒绝包装成「待评估」。你会得到一份漂亮的报表和一个依然延期的项目。

我的建议是：第一到第二个迭代周期只做记录和复盘，第三个周期开始设定预警线，第四到第六个周期才考虑和考核挂钩。这个节奏看起来慢，但它避免了「指标一上线就失效」这个最常见的死法。

五、从指标到行动：四步落地路径

有了指标，接下来的问题是：怎么让它真的跑起来。我总结出四步，顺序不能颠倒。

1. 第一步：先测量，不要先定 KPI

这一步的核心动作只有一个，建一张依赖台账，然后连续记录两个迭代周期。

台账的字段设计比工具选型重要得多。我在多个项目里用的最小字段集是这样的：

dependency_id: 依赖唯一编号
from_dept: 被依赖方（上游）

to_dept: 依赖方（下游）

deliverable: 交付物定义（必须具体到可验收的程度）

acceptance: 验收标准（最好附示例）

commit_date: 承诺交付日期

actual_date: 实际交付日期

block_start: 阻塞开始时间

block_end: 阻塞结束时间

owner: 该依赖的唯一责任人

change_log: 变更记录（含已同步方）

status: 状态（待确认/已确认/进行中/已交付/已验收）

十一个字段，看起来有点多，但每一个都对应一个具体的管理动作。如果只能保留五个，我会留：deliverable、acceptance、commit_date、owner、status。这五个字段能支撑起 DIR、CCR、DRR 三个指标的计算。

2. 第二步：设预警线，明确升级路径

指标不设阈值就是装饰品。预警线的关键不是数值本身，而是「超过之后发生什么」。

我的建议是按严重程度分三级：黄色预警只通知接口人，橙色预警升级到部门负责人，红色预警升级到项目决策层并自动进入下一次跨部门例会的第一议题。这套机制的核心价值在于，它把「要不要催」从人际判断题变成了规则执行题。跨部门催进度之所以难，很多时候不是不想催，是催了显得不给面子。规则化之后，催的人不尴尬，被催的人也不觉得被针对。

3. 第三步：配机制，别只配工具

我见过不少团队，指标算得很清楚，但落不下去，原因是缺配套机制。三个最小机制：

• 依赖看板：把所有跨部门依赖拉成一张看板，按「阻塞中/待确认/进行中/已交付」分列。关键是让阻塞中的依赖在最显眼的位置，让它带着压力待在那里。
• 15 分钟依赖站会：每周两次，只讨论阻塞中的依赖，不讨论任务进度。时间必须短，因为它的定位是清障，不是汇报。
• RACI 落到依赖粒度：不是给整个项目做 RACI，而是给每条跨部门依赖单独指定 R（负责）、A（批准）、C（咨询）、I（知会）。粒度到依赖级别之后，「谁都以为对方负责」的情况基本消失。

4. 第四步：才谈考核挂钩

考核挂钩要小心。我的经验是：先把依赖指标挂在部门级，不要挂到个人级。挂到个人会导致两种极端，要么每个人都把依赖拆得极碎来规避风险，要么没人愿意承接跨部门任务。

挂在部门级的效果更实在：部门负责人会主动去检查自己部门的承诺准时率和响应闭环率，因为这两个数直接影响他部门的整体评价。个人层面改用「依赖接口人」这个角色来承担，配一点象征性的激励，比硬性扣分有效得多。

六、一个案例观察：300 人组织 18 个月的依赖治理

讲一个我实际参与过的案例，细节做了脱敏处理，但数据量级是真实的。

1. 起点：有流程、有工具、没数据

这家企业大约 300 人，做的是企业级软件交付，跨部门协作涉及产品、研发、测试、实施、运维五个部门。治理开始时他们的状态很有代表性：SS 流程文档有 40 多页，项目管理平台上也有任务和甘特图，但没人能说出上季度的跨部门交付准时率是多少。

他们当时的主要痛点是实施团队经常在客户现场才发现功能没到位，而研发那边的记录显示任务已按期完成。两边都没错，问题出在「完成」的定义不一致上。

2. 动作：先补台账，再谈优化

第一阶段做的唯一一件事，就是建依赖台账，强制要求每条跨部门依赖填齐五个必填字段，并且每周五由 PMO 汇总一次数据，不做任何考核。

这一步花了大概六周。前两周阻力很大，很多人觉得是额外的填表负担。转折点出现在第三周，PMO 把「阻塞时长最长的 10 条依赖」列出来发到群里，其中有 3 条是所有人都不知道在等另一个部门的依赖。那一刻大家才意识到，这张表不是在给别人添麻烦，是在把他们自己卡住的地方暴露出来。

第二阶段引入预警机制和依赖站会，第三阶段才开始把承诺准时率纳入部门季度评估。

3. 一个具体的工具选择观察

这个案例里有一个值得单独说的点：他们在治理进入第三阶段时，面临一次项目管理平台的替换决策。原来的平台是境外产品，本地化支持和数据合规都开始出现压力。

他们最终选择的是 PingCode。这里说几个我作为旁观者观察到的、和他们决策直接相关的点，不做推荐，只讲适配逻辑。

第一是规模匹配。PingCode 主要服务中大型企业及 100 人以上组织。这家企业 300 人、五个部门、跨部门依赖密集，正好落在它的目标区间里。太轻量的工具撑不住这么密的依赖关系，太重型的工具又会让一线抵触。

第二是部署方式。他们属于对数据出境比较敏感的行业，支持私有化部署这一条基本是硬性要求。PingCode 支持私有化部署，这一点在他们的选型打分表里权重很高。

第三是迁移成本。他们原本用的就是 Jira，历史项目数据不少，如果迁移要重建全部历史，成本会很高。PingCode 支持 Jira 平滑迁移，这一点直接降低了替换的决策阻力，对国产替代场景来说是个实际优势。

但我必须补一句：工具能承载依赖台账和自动预警，但它不会替你设定指标口径。这家企业能跑出上面那组数据，核心动作是那六个指标和配套机制，工具只是让数据自动聚合、让预警自动触发。换工具不换机制，结果不会变。

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

依赖治理没有万能方案，关键是匹配你当前的组织状态。下面按四种常见情况给建议。

1. 情况一：100 人以下、项目周期短（1-2 个月）

这个阶段不建议上完整指标体系，投入产出比不划算。我的建议是只做两件事：

1. 用一张共享表格登记跨部门依赖，只填五个必填字段，不搞自动化。
2. 每周一次 15 分钟依赖站会，只清阻塞。

重点盯一个指标：平均依赖阻塞时长。这个指标最直观，也最容易让团队感受到价值。等它稳定在 3 天以内，再考虑扩展其他指标。

2. 情况二：100-500 人、多项目并行

这个规模是依赖问题爆发最集中的区间，因为部门已经形成，但跨部门机制还没建立。建议做三件事：

1. 建立部门级依赖接口人制度，每个部门指定 1-2 人，负责本部门依赖的提交和跟踪。
2. 上齐六个指标中的四个：依赖识别前置率、承诺准时率、响应闭环率、阻塞时长。
3. 把依赖看板作为跨部门例会的固定议题，阻塞超过 5 天的依赖必须上会。

工具层面，这个规模通常需要专业的项目管理平台来支撑依赖聚合和自动预警，手工表格在这个体量下会迅速失效。选型时优先看三件事：依赖关系的可视化能力、变更的自动通知范围、以及是否有适合你们部署要求的方式。PingCode 在这个规模段是比较常见的选择之一，尤其在有私有化部署和 Jira 迁移需求的场景下。

3. 情况三：500 人以上、多业务线

这个规模的问题往往不是依赖管理本身，而是依赖管理没有统一口径，每个业务线自己一套指标，数据没法横向比较。

建议先做一件事：由 PMO 统一六个指标的计算口径，并写成一页纸的定义文档。口径不统一，后面对齐数据的时间会超过做治理的时间。这一步我在一个 800 人组织里见过真实的教训，他们花了三个月争论「阻塞时长算不算周末」，最后治理本身推迟了一个季度。

口径统一之后，再按业务线分别设阈值。不同业务线的依赖密度差异很大，用同一套阈值会产生大量误报。

4. 情况四：刚经历过一次严重延期

这是推行依赖治理阻力最小的时机，因为痛感还在。建议抓住这个窗口做两件事：

1. 48 小时内做完延期复盘，用依赖台账的方式还原每一条卡点，而不是开一场「以后要加强沟通」的会。
2. 把复盘产出的阻塞清单直接变成第一批依赖台账数据，作为基线。

不要在这个时间点做全面流程改造。痛感强的时候，人的容忍度高，但也很容易把事情做得过重，最后反弹。先解决具体的几条阻塞依赖，用结果说话，再推指标。

八、不同情况下的取舍

任何治理方案都有代价，我把几个最常遇到的取舍摆出来，方便你提前判断。

1. 取舍一：指标数量，六个还是三个

六个指标的信息更完整，但记录成本也更高。我的判断标准是看团队规模：

我的取舍建议是：宁可先做三个做扎实，不要六个全上但数据是假的。假数据比没数据更糟，因为它会让你做出错误的决策。

2. 取舍二：自动化程度，手工还是系统

手工台账的优势是启动快、成本低、灵活；劣势是超过一定规模后必然失效，而且容易因为人员流动断档。系统化的优势是数据自动聚合、预警自动触发；劣势是配置成本高，且一旦字段设计错了，改起来很麻烦。

我的经验分界线是：跨部门依赖同时在进行中的条数超过 50 条，就必须上系统。50 条以下，一张设计良好的共享表格做得更好，因为你还在探索阶段，需要频繁调整字段。

3. 取舍三：考核强度，软性还是硬性

软性推动（只通报不考核）的优点是阻力小、数据真实；缺点是改善速度慢，容易在业务压力下被搁置。硬性推动（直接挂绩效）的优点是见效快；缺点是数据容易失真，且跨部门推诿会从「不沟通」变成「沟通了但留证据」。

我的判断是分阶段：前三个月软性，第四到第六个月半硬性（部门级通报+排名），第七个月之后才硬性挂钩。这个节奏给了一线足够的时间理解指标含义，也给了管理者足够的时间建立基线。

4. 取舍四：指标严格度，严阈值还是宽阈值

严阈值（比如阻塞时长超过 2 天就预警）的好处是问题暴露早；坏处是预警频繁，团队会产生「预警疲劳」，最后集体忽略。

宽阈值（比如超过 5 天才预警）的好处是预警少、每次都值得关注；坏处是发现太晚，损失已经发生。

我倾向于「严阈值 + 分级处理」：黄色预警只要在站会上提一句，不追责；红色预警才升级。这样既保留了早期发现的能力，又不会让预警变成噪音。这个做法我在两个团队里试过，预警响应率从 40% 提升到 85% 以上。

5. 取舍五：自建还是采购

自建依赖管理工具的优势是完全贴合自家流程；劣势是维护成本高、迭代慢，而且很容易变成某个离职员工的「遗留系统」。

采购的优势是功能成熟、迭代有保障；劣势是可能需要调整自己的流程来适配工具，以及数据合规方面的考量。

我的建议很直接：除非你的依赖模型有非常特殊的行业属性，否则不要在依赖管理这件事上自建工具。把这部分精力省下来做指标口径和机制设计，收益高得多。选型时优先确认三件事：能不能承载前面说的十一个字段、能不能按依赖粒度设预警、部署方式是否满足合规要求。

九、结语：依赖管理的终点不是「管住」，是「流动」

回到最开始那个 47 天的项目。如果当时有依赖台账和阻塞时长指标，那 17 天的延期至少能压缩一半，不是因为大家更努力了，而是因为问题会更早暴露，在还有时间处理的时候就被看见。

我想强调一个可能被忽略的判断：依赖指标不是用来追责的，是用来降低不确定性的。当你知道上季度平均阻塞时长是 6.4 天、承诺准时率是 61% 时，你对下一个项目的排期判断就不再依赖直觉和乐观了。这才是跨部门协作真正的成熟标志，不是大家关系好，而是大家知道彼此会在什么时候交付什么。

给你一个最小可执行的下一步：从下一个迭代开始，只做一件事，建一张依赖台账，只填五个必填字段（依赖方、被依赖方、交付物定义、承诺日期、责任人），跑两个迭代，只统计一个指标：平均依赖阻塞时长。

两个迭代之后你会拿到一个数字。那个数字不重要，重要的是你终于有了一个可以改善的基准线。之后要加什么指标、要不要上工具、要不要挂考核，都可以基于这个数字来判断。跨部门依赖治理最难的不是方法，是开始测量，因为一旦开始测量，模糊的责任就无处可藏了。