去年双十一前两周，我接手的一个中台改版项目突然卡死：前端已经按接口文档联调了三天，后端忽然推送了一版字段变更，把订单状态从 6 个扩到了 11 个。没有变更通知、没有影响范围说明、没有下游确认记录。结果前端 60% 的联调工作作废，测试用例要重写，上线日从 11 月 3 日滑到 11 月 18 日，整整 15 天的延期，复盘时发现根因只有一个，这条依赖关系从未被任何一张表、任何一个看板记录过。
这件事让我意识到一个很反常识的结论：产品经理管不住任务协同，往往不是因为沟通能力差，而是因为把依赖关系留在了聊天记录里，而没有把它变成可度量、可追踪、可预警的指标。 顺丰（SF）那套"算法+系统+运营"的流程规范思路之所以值得借鉴，不是因为它讲了什么高深理论，而是因为物流体系天生就无法容忍"依赖不清"，一个包裹从揽收到派送要经过十几个环节，任何一个环节的依赖断了，件就丢了，所以它必须把依赖显性化、指标化。
下面我会围绕任务依赖的四类模型、六个可落地指标、落地机制和取舍策略展开，把我踩过的坑和验证过的做法完整讲清楚。
一、核心结论：依赖管理的本质是"把隐性等待变成显性数字"
先给结论，后面再展开论证。产品经理在任务协同上的核心痛点，其实可以压缩成一句话：你知道任务在等，但你不知道它在等谁、等多久、等几次、等出了多大代价。
我在过去三年带过的跨团队项目里做过一个粗略统计：真正因为"某个人能力不行"导致的延期不到 15%，而因为"依赖方和被依赖方对交付标准、交付时间、变更规则没有共识"导致的延期超过 60%。剩下 25% 是资源被多项目争抢导致的排队延误。这个分布直接决定了：你应该把精力花在设计依赖规则和依赖指标上，而不是反复开协调会。
借鉴 SF 流程规范里"算法+系统+运营"的三段式，我把它翻译成产品经理的语言就是三句话：用规则替代人盯人（算法）、让依赖关系可视化（系统）、持续监控而非一次性梳理（运营）。而这三句话要真正落地，必须依托六个可量化指标作为骨架。
二、背景与真实场景：为什么依赖管理会在中大型组织里失控
1. 三个让我印象最深的失控场景
第一个场景是我在第一家公司做 SaaS 后台重构时遇到的。需求依赖没登记，设计稿基于旧版 PRD 做了两周，等新 PRD 定稿时发现核心流程多了"批量审批"分支，设计要推翻重做。这次返工的隐性成本大约是 12 人天，但没有任何报表能体现出来，只有设计师在周会上说了一句"又要加班了"。
第二个场景是资源依赖。有一段时间，我们团队唯一的动效设计师同时被 4 个项目依赖，每个项目都默认"他随时能接我的活"。结果他实际上每周有 3 天在切换任务上下文，真正产出的时间不到 40%。协同饱和度这个东西一旦超过 1.5，单位产出就会断崖式下跌，但几乎没有团队在盯着它。
第三个场景是信息依赖。运营侧敲定了一个活动规则，但没有同步给研发，研发按旧规则实现的功能上线后直接导致活动首日数据错乱，损失了大概半天的活跃转化。这条依赖从头到尾都活在一条微信消息里。
这三个场景的共同点是：依赖是真实存在的，但它没有被结构化地记录下来，所以既没法提前识别，也没法事后归因。
2. 为什么中大型组织比小团队更容易栽在这里
小团队依赖少、沟通半径短，靠"抬头喊一声"就能解决。但当一个组织超过 100 人、跨越多个产品线和职能线时，出现三个结构性变化：
- 依赖数量呈非线性增长：5 个人的团队依赖对大约是 10 对；20 个人的团队可能超过 150 对。靠人脑记住是不现实的。
- 信息传递链条变长：A 的决策要传到 D，中间要经过 B 和 C 的转述，每转述一次就有一次信息衰减和一次延迟。
- 责任边界变模糊：跨团队时，"这事该谁推动"经常说不清，最后就变成谁嗓门大谁推动，或者谁都不推动。
这也是为什么我后来在选择协作工具时越来越看重"依赖建模"能力，而不只是"任务分配"能力。比如 PingCode 这类平台在研发项目里会把需求、任务、缺陷、测试用例串成一条链路，依赖关系能直接挂在实体上而不是挂在人身上，这对 100 人以上、跨职能的组织来说，是把依赖从聊天记录搬进系统的关键一步；同时它支持私有化部署和 Jira 平滑迁移，对正在做国产替代的中大型企业来说迁移成本可控。
这一点对小团队其实没那么重要，但对中大型组织几乎是刚需。
3. 从 SF 流程规范里能借鉴的到底是什么
要特别强调：我不是让你去照搬顺丰的内部流程。 顺丰对外公开的"智能算法+系统集成+精益运营"是品牌话术层面的表述，企业内部的具体制度、岗位职责、考核指标都没有公开资料，任何声称"顺丰内部就是这么做的"的说法都值得怀疑。
真正可借鉴的是一个思路： 包裹丢件是可见的，任务阻塞是不可见的，所以前者有人管，后者没人管，这就是差距的根源。
三、拆解常见误区：你可能正在用错误的方式"管依赖"
1. 误区一：把"沟通"当成依赖管理
最普遍的误区是认为"多开会、多对齐就管好了依赖"。我见过团队每周开三次跨部门同步会，结果延期率一点没降。原因是：会议传递的是"状态"，不是"依赖结构"。 你在会上说"我这边基本没问题，就差后端接口了"，这句话没有说清接口的哪个字段、什么时候给、如果变更了怎么办。
依赖管理的核心动作不是沟通，是登记与量化。沟通只是最后的确认环节。
2. 误区二：把任务清单当成依赖清单
很多团队有一张漂亮的需求排期表，但那张表只记录"谁做什么、什么时候做完"，不记录"谁在等谁"。这两个是完全不同的信息维度。排期表能回答"这个任务什么时候完"，但回答不了"这个任务卡住会连累几条下游任务"。
我吃过的最大的坑就在这里：排期表显示每个任务都"按计划进行中"，直到上线前三天才发现有 7 条依赖是隐性的，全卡在一个没被识别的关键路径上。
3. 误区三：用"进度百分比"衡量协同健康度
进度百分比是给老板看的，不是给协同管理用的。两个团队进度都是 80%，但一个团队是被 5 条未决依赖压着，一个是健康推进，风险完全不同。进度百分比掩盖了阻塞结构，越用它判断协同健康度，越容易误判。
4. 误区四：指标越多越好，一次上十几个
我早期犯过的错就是一次设计了 12 个协同指标，结果团队看不过来，第二周就没人填报了。协同指标的黄金数量是 5-7 个，而且必须能从一个数据源自动或半自动采集出来。 靠人工每周手填的指标，寿命通常不超过一个月。
四、专业判断逻辑：为什么依赖管理一定要指标化
1. 判断逻辑一：不可见的依赖无法被优化
这是最朴素的道理，也是最容易被忽略的。如果一个依赖的时长、频率、影响范围都没有数字，那你对它的一切管理都只能靠感觉。感觉是可以在周会上被质疑的，数字不行。
我现在的习惯是：任何一个跨团队依赖，一旦被识别出来，第一件事就是在系统里登记，并打上依赖类型、依赖方、被依赖方、期望交付日、实际响应日这几个字段。登记这个动作本身就是一种承诺机制，被依赖方看到自己被登记了，响应速度平均会提高 2-3 天。
2. 判断逻辑二：指标是设计规则的原材料，不是考核工具
很多人一听指标就紧张，觉得是拿来考核的。这是误用。协同指标的第一用途是暴露结构问题，第二用途是复盘归因，考核排到最后甚至不用。 当你看到"阻塞时长中位数"从 2 天涨到 6 天，你要做的不是批评谁，而是去查为什么依赖响应变慢了，是流程变了、资源少了、还是决策链长了。
3. 判断逻辑三：依赖有类型之分，指标必须分类设计
用一套指标套所有依赖是无效的，因为需求依赖、资源依赖、时序依赖、信息依赖的瓶颈位置完全不同。需求依赖的瓶颈通常在"定义清晰度"，资源依赖的瓶颈在"排队与切换"，时序依赖的瓶颈在"关键路径"，信息依赖的瓶颈在"同步时机"。同一个指标（比如响应时长）在这四类里代表的含义和正常值都不应该一样。
4. 判断逻辑四：指标必须能自动或半自动采集
这是我最强调的一条。任何需要产品经理"每周手动汇总"的指标都会在两到三周内死掉。可行的路径只有两条：要么让协作工具自动记录时间戳（任务状态变更、依赖登记、审批流转都能产生时间戳），要么把手工成本压到 10 分钟以内。指标的寿命等于采集成本的倒数。
五、具体观察与案例：用六个指标管理依赖协同
下面这六个指标是我在多个中大型项目里反复调过阈值后沉淀下来的版本。数据是我自己项目的观察值，你可以把它们当作起始基准，再按团队实际调整。
1. 依赖识别率
定义： 在任务启动前被显式登记并明确交付标准的依赖数 ÷ 实际存在（含项目后期才被发现的）的所有依赖数。
计算方式建议： 分子用系统里带依赖类型字段的记录数，分母用"启动前登记的 + 事后复盘补登的"之和。后者需要你坚持做迭代复盘，否则分子分母会一起失真。
监控频率： 每个迭代复盘一次。异常阈值参考： 低于 60% 就要警惕，我见过健康的团队能稳定在 75%-85% 之间。
我第一年带项目时这个指标大概只有 40% 左右，大部分依赖都是事后才发现的。把"启动前必须登记依赖"写进立项 checklist 后，三个月内爬到了 72%。这个指标是所有协同指标的总开关，它低，其他指标全是假的。
2. 阻塞时长中位数
定义： 一个任务从进入"等待依赖"状态到"依赖解除"状态的时长中位数（用中位数不用均值，是为了排除极端值干扰）。
计算方式建议： 若你的项目管理平台支持状态时间戳（比如 PingCode 这类平台在任务状态流转时会自动记录时间），可以直接按状态区间统计，手工维护的成本几乎为零。若不支持，就只能用依赖登记表里的"期望交付日"和"实际响应日"相减。
监控频率： 每周看一次趋势。异常阈值参考： 跨团队场景下，中位数在 2 天以内算健康，超过 5 天意味着依赖响应机制出问题了。
3. 协同饱和度
定义： 单个成员在同一时间段内被作为依赖方（被等待交付）的任务数。
计算方式建议： 按人聚合其作为"被依赖方"的进行中任务。注意只算跨团队或跨职能的，团队内的小依赖别算进来，否则数字会虚高。
监控频率： 每周。异常阈值参考： 超过 1.5 就要开始注意，超过 2.5 基本可以断定这个人的实际产出已经大幅下降。前面提到的那位动效设计师，当时饱和度长期在 3 以上，产出效率大概只有名义值的三分之一。
4. 依赖变更频率
定义： 每个迭代内，已登记依赖发生的变更次数 ÷ 已登记依赖总数。
计算方式建议： 依赖登记表增加"变更记录"字段，每次变更必须写原因（比如"字段范围调整""优先级重排""上游需求变更"）。变更原因是这个指标最有价值的部分，它会告诉你依赖不稳定的根因到底是需求本身不稳，还是流程不稳定。
监控频率： 每个迭代。异常阈值参考： 高于 30% 说明上游稳定性不足，需要往前追设计评审质量；低于 10% 说明依赖登记可能过于宽松。
5. 跨团队响应时长
定义： 从依赖正式发起到被依赖方给出明确响应（哪怕是"我现在不能接，最早哪天可以"这种否定响应也算响应）的平均耗时。
计算方式建议： 发起时间用系统里依赖记录的创建时间，响应时间用第一条实质性回复的时间，不要用最后解决时间。关键洞察：响应≠完成，先要的是响应，不是解决。 很多团队把这两个混为一谈，导致依赖发起后石沉大海。
监控频率： 每两周。异常阈值参考： 平均超过 24 小时就要在流程上做硬约束，比如规定依赖发起后一个工作日内必须给响应。
6. 协同阻塞率
定义： 因依赖问题导致延期的任务数 ÷ 当期总延期任务数。
计算方式建议： 这个指标最需要制度化，因为它涉及归因。我的做法是每次延期复盘必须标注延期根因，归到"依赖阻塞"或"其他"两类，月度汇总。
监控频率： 每月。异常阈值参考： 高于 50% 说明协同是当前最大瓶颈，应该把它列为下个季度的组织级改进重点；低于 25% 说明依赖管理基本可控。
| 指标名称 | 核心用途 | 建议监控频率 | 异常阈值参考 | 典型采集方式 |
|---|---|---|---|---|
| 依赖识别率 | 检验依赖是否被显性化 | 每迭代 | < 60% | 启动登记 + 事后补登 |
| 阻塞时长中位数 | 衡量依赖响应的真实代价 | 每周 | > 5 天 | 任务状态时间戳 |
| 协同饱和度 | 预警关键资源过载 | 每周 | > 1.5 | 按人聚合被依赖任务 |
| 依赖变更频率 | 暴露上游稳定性问题 | 每迭代 | > 30% | 依赖变更记录 |
| 跨团队响应时长 | 约束依赖响应机制 | 每两周 | > 24 小时 | 创建与首次响应时间 |
| 协同阻塞率 | 判断协同是否为头号瓶颈 | 每月 | > 50% | 延期复盘归因 |
7. 一个关于工具的真实观察
我前两年在一家中型公司推动依赖数字化时，踩过一个工具选型的坑：工具的任务分配能力很强，但状态变更时间戳不完整，导致"阻塞时长中位数"这个指标根本算不出来，只能退回人工统计，寿命一个迭代就结束了。
后面换到 PingCode 这类把研发全流程串起来的平台后，情况明显改善：需求、任务、缺陷、测试的状态流转都会留时间戳，依赖挂到实体上，指标可以直接从数据里捞出来。对 100 人以上、跨职能、需要长期盯依赖指标的中大型组织，这种"数据自然沉淀"的能力比单纯的协作界面好不好看重要得多。 顺带说一句，如果你正在做 Jira 的国产替代评估，PingCode 支持平滑迁移和私有化部署，这两点在合规压力大的企业里是比较现实的加分项。
六、不同情况下的行动建议
1. 如果你是 5-15 人的小团队
不要上复杂指标系统。你只需要两件事：一张共享的依赖登记表（哪怕是表格软件），和每周 15 分钟的依赖对齐。重点做"依赖识别率"和"协同阻塞率"这两个指标就够了，其余四个先不管。 小团队依赖少，指标太多反而增加负担。
2. 如果你带的是 20-100 人的多团队项目
这个区间是依赖管理的"死亡谷"，最容易失控。建议六个指标全上，但分两批：第一批上依赖识别率、阻塞时长中位数、协同阻塞率；跑顺了再补协同饱和度、依赖变更频率、跨团队响应时长。关键是找到能自动产生时间戳的工具，把采集成本压到最低。
3. 如果你在 100 人以上的中大型组织
不要再依赖任何手工流程。你需要的是把依赖登记写进工作流强制节点，把指标接到管理看板上，最好选择支持私有化部署、能与现有研发流程深度集成的平台来做底座。这个规模下唯一能跑起来的路径是"系统化依赖建模"，任何靠人盯人的方案都会在两个月内崩掉。
4. 如果你刚接手一个已经延期严重的项目
先别急着建指标体系，先做一次全量依赖盘点。把当前所有进行中任务的依赖关系梳理一遍，标出关键路径上的依赖和未响应的依赖，先把最紧急的阻塞解掉。指标是长期机制，救火是短期动作，两件事不要混着做。
七、不同情况下的取舍
1. 追求指标完备 vs 追求执行可持续
这是第一个必须做的取舍。我的判断是：永远优先可持续性。 一个只有三个指标但跑了半年的团队，协同状况一定好过一个有十二个指标但跑了三周就散的团队。取舍标准很简单：如果某个指标需要你每周手动花超过 15 分钟整理，暂时就不要它。
2. 依赖强管控 vs 依赖弱约束
强管控意味着所有依赖必须登记、所有变更必须走流程；弱约束意味着依赖记录但不强制流程。我的判断是：关键路径上的依赖必须强管控，非关键路径上的可以用弱约束。 对所有依赖一视同仁地强管控，会把团队拖进流程泥潭；完全弱约束，关键路径就会频繁爆雷。
3. 依赖响应机制靠制度 vs 靠工具
制度解决"该不该响应"，工具解决"响应得快不快"。两者不能互相替代。先有制度（比如"依赖发起后一个工作日内必须给响应"这条硬规定），再用工具把这个规定变成自动提醒和自动计时，两者叠加才有效。 只上工具不定制度，提醒会被忽略；只定制度不上工具，制度会在两周内被遗忘。
4. 工具投入 vs 人力投入
工具投入是一次性的（选型、迁移、培训），人力投入是持续的（每周协调、每月复盘）。很多人低估了人力投入的长期成本，高估了工具投入的门槛。从三年周期算，一个能自动采集依赖指标的平台，节省下来的协调人力通常远超其采购和迁移成本。 这也是为什么我一直建议 100 人以上组织优先考虑支持私有化部署、能平滑承接既有流程的平台，而不是为了省事在多个轻量工具之间来回切换。
| 取舍维度 | 优先选 A 的条件 | 优先选 B 的条件 | 我的默认建议 |
|---|---|---|---|
| 指标完备 vs 可持续 | 组织成熟、数据基础好 | 首次建立协同机制 | 先可持续，再补完备 |
| 强管控 vs 弱约束 | 任务在关键路径上 | 任务有缓冲、影响面小 | 按关键路径分层 |
| 制度 vs 工具 | 流程尚未定型 | 流程已相对稳定 | 制度先行，工具固化 |
| 工具投入 vs 人力投入 | 团队规模 > 50 人 | 团队规模 < 20 人 | 规模决定投入结构 |
5. 我自己的取舍结论
如果只能保留一条经验，那就是：把依赖识别率当成第一个必须跑通的指标，其他所有指标都建立在它之上。 依赖没被识别，后面的时长、饱和度、变更频率、响应时长、阻塞率全是空中楼阁。这就是从 SF 流程规范里我最想迁移过来的那条原则，物流体系先保证"每个包裹都被扫描到"，产品经理先保证"每条依赖都被登记到"。
八、结语：从"救火式协同"到"指标化协同"
回到开头那个 15 天延期的项目。如果当时有一条依赖登记、一个阻塞时长指标、一个跨团队响应约定，这场延期大概率不会发生，或者至少能在第三天就被发现并止损。依赖本身不可怕，可怕的是依赖不可见。
SF 流程规范给产品经理的真正启发不是某套具体制度，而是一种把不确定性变成可度量数字的思维方式：先让每个依赖被登记，再让每个依赖的时长、频率、影响被看见，最后让规则和系统替你去盯人。
下一步怎么做？如果你现在手上就有一个跨团队项目，今天就做一件事：把你已知的所有依赖写下来，标出关键路径上的那几条，然后挑其中一条，记录它的发起时间和响应时间。一个依赖指标跑起来，比一整套指标体系写完更有价值。
如果你的团队已经开始需要长期盯依赖指标，也可以评估一下自己当前的协作工具能不能自动产生依赖时间戳、能不能把依赖挂到任务实体上，这是决定你的指标能不能活过半年的技术前提。
1. 常见问题速答
问：六个指标必须全上吗？ 不必。20 人以下团队先跑依赖识别率和协同阻塞率；20 人以上再多加阻塞时长中位数、协同饱和度；跨团队多、变更频繁的组织再补齐依赖变更频率和跨团队响应时长。
问：指标数据靠人工填还是系统采？ 能系统采的绝不手工填。任务状态变更、依赖创建、首次响应这些都有天然时间戳，优先用平台自动采集，人工只负责补原因字段。
问：协同饱和度的 1.5 阈值是怎么来的？ 这是我在多个项目里观察到的经验基准值，不是行业公认标准，你应按自己团队的实际返工率和切换成本重新校准。
问：和 SF 的关系到底是什么？ 只是一个借鉴的思考框架，不是照搬制度。顺丰对外公开的表述可作为类比参照，企业内部具体流程并未公开，不要当作标准引用。
问：小团队真的需要指标吗？ 需要，但可以极简。哪怕只记录"依赖识别率"这一个数，也能让依赖管理从凭感觉变成有据可依。
常见问题解答（FAQ）
1. 产品经理怎么判断一个任务依赖是不是‘真阻塞’，而不是同事在拖进度？
我们团队每次迭代都有人喊‘被卡住了’，但我真去问，有时候对方只是还没排期，有时候是真的在等上游接口。我分不清到底该催谁、该不该升级，搞得自己像在逼人。
判断标准是看这个依赖有没有明确的‘交付物+承诺时间’。真阻塞有三个特征：一是交付物可以命名，比如‘订单导出接口联调通过’而不是‘后端支持’；二是有一个双方确认的承诺时间，哪怕是口头确认；三是延迟会直接导致下游任务无法开工。三者缺一，大概率是排期问题不是依赖问题。
实操上我建议在依赖登记表里加两列，‘交付物描述’和‘承诺时间’，填不出来的就不算依赖，直接进正常的排期沟通；填得出来的按阻塞处理，超时未响应就触发升级。这样你催的不是人，是那条被记录下来的承诺，心理负担会小很多。
2. 任务依赖协同管理到底该盯哪几个指标？指标太多根本维护不过来怎么办？
我看过不少讲协同管理的文章，列了十几个指标，什么依赖密度、响应时长、返工率……我们小团队就五六个人，全上根本不现实，最后表格填了两周就荒废了。
小团队只需要盯三个指标就够启动：依赖识别率、阻塞时长中位数、跨团队响应时长。依赖识别率的算法是‘迭代中记录在案的依赖数 ÷ 复盘时实际发生的依赖数’，它衡量的是你有没有提前看见问题，比事后统计阻塞更有价值；
阻塞时长中位数统计每个被阻塞任务从标记阻塞到解除的天数，取中位数而不是平均值，避免一个超长阻塞把整体数据带偏；跨团队响应时长只看从你发出依赖请求到对方第一次明确回应的小时数，超过24小时就值得在周会上提。
这三个指标维护成本低，一个共享表格就能跑，等团队稳定运行两三个迭代后再考虑加协同饱和度和依赖变更频率。指标不是越多越好，能持续填下去才是有效的。
3. 依赖关系中途变了，之前定的指标还准吗？要不要推倒重来？
我们上个季度辛辛苦苦统计的依赖数据，这个季度组织架构一调整，上下游全换了，感觉之前那套指标全白做了，团队也没人愿意继续填。
不要推倒重来，要区分‘指标口径’和‘依赖对象’。变的是依赖对象，比如原来对接A组现在对接B组，但指标口径本身，怎么算阻塞时长、怎么定义响应，是不需要变的。正确做法是在依赖登记表里加一个‘变更记录’字段，记录这条依赖在什么时间因为什么原因变更了对接方，这样你的历史数据仍然可比较。
真正需要调整指标口径的情况只有两种：一是团队规模变化超过一倍，协同饱和度的阈值需要重算；二是业务模式从项目制转成持续交付，阻塞的定义要从‘无法开工’改成‘影响发布节奏’。除此之外的调整都属于对象变化，不动口径。另外建议每季度做一次指标复盘，问三个问题：这个指标上季度触发过几次行动？
如果一次都没有，就考虑删掉它；如果有但没人跟进，那是流程问题不是指标问题。
4. 没有专门的项目管理软件，用表格能不能管好任务依赖协同？
我们公司不给买工具，只有一个共享文档。我看别人都是用系统自动拉依赖关系、自动算阻塞时长，感觉用表格做这事就是土办法，做不专业也做不长。
表格完全够用，关键在字段设计而不是工具本身。最小可用的依赖登记表只需要六列：依赖编号、提出人、依赖对象、交付物描述、承诺时间、实际解除时间。阻塞时长就是实际解除时间减承诺时间，负数说明提前交付，正数就是延迟天数，这个计算逻辑比大多数工具默认的还清楚。
真正让表格跑不下去的不是工具弱，是两个习惯没建立：一是每次迭代规划会必须过一遍登记表，确认新依赖进表；二是每日站会只看‘今天有没有新增阻塞’，而不是逐个念任务。这两件事坚持三个迭代，表格就活了。
等到依赖条目超过50条、或者跨三个以上团队协作时，再考虑迁移到某项目管理平台，那时候你也更清楚自己需要哪些字段和视图，选型反而更准。
核心关键词
文章包含AI辅助创作：SF流程与规范：产品经理任务依赖协同管理关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/433852
读者评论
作者说延期六成来自依赖规则缺失，我信。我们团队就是每周三次对齐会，但接口字段变更照样没人通知，问题确实不在沟通频率，在于没有登记和量化。
指标一次上十几个那条太真实了。我们之前搞过协同看板，第二周就没人填了。能自动采集时间戳的指标才活得下来，靠人工汇总的最后都是形式主义。
四类依赖分类设计的思路有启发。资源依赖的瓶颈是排队切换，加人比加会有效；信息依赖是同步时机，晚了就返工。用一套响应时长指标量所有依赖确实没意义。
对SF那段保留意见。作者自己也说顺丰具体制度未公开，拿来当参照讲思路可以，但把它当成流程规范标杆有点过度借势。依赖管理本身的价值不依赖这个案例。