依赖关系管理指南：PMO如何做好任务依赖，最佳实践全流程

我接手过一个跨四条产品线的项目集，交付节点前两周，项目集里 37 条跨团队依赖有 14 条还停在"已提出、未确认"的状态。最要命的是，没有任何一个人能说清楚这 14 条里，哪几条会真的拖垮里程碑，因为它们在 Excel 里只是一行行填了"承接部门：平台组"的文字，既没有到人，也没有到具体交付物，更没有承诺日期。那次复盘之后我算了一笔账：这个项目集全年因为依赖失控造成的返工和等待，折合成人天大约 460 人天，相当于白养了两个半全职工程师。

而真正让依赖失控的，从来不是"没识别出来"，而是识别出来之后没人认领、认领之后没有到期日、到期之后没人跟踪。

这篇《依赖关系管理指南：PMO如何做好任务依赖，最佳实践全流程》，我不打算再重复"依赖有 FS/SS/FF/SF 四种类型"这类教科书内容。我想讲的是我在三个中大型研发组织里真正跑通过的那套东西：依赖治理的五段闭环、11 个字段的登记表、依赖确认会的议程、到期前 5 天预警规则，以及什么规模的组织该用什么颗粒度。文中所有数据都来自我自己维护的依赖台账和项目集记录，我会标注样本范围和口径，你可以按自己的组织情况折算。

一、核心结论：PMO 管依赖，管的是承诺，不是排期

先把结论摆出来，后面所有内容都是围绕这三条展开的。

结论一：依赖管理失效的根因，90% 不在"识别"，而在"认领与跟踪"。我统计了自己经手的 1180 条依赖记录，其中被识别并登记的比例其实不低，但真正走完"登记，承诺，交付，验收，关闭"完整闭环的只有 527 条，占 44.7%。换句话说，一半以上的依赖在流程中途"蒸发"了，而蒸发的位置高度集中：没有明确承接责任人、没有书面承诺日期。

结论二：PMO 在依赖治理中的角色是登记员、撮合者和记账人，不是排期员，更不是承诺人。我见过太多 PMO 为了"推进度"，替承接团队答应了交付时间，结果到期交付不了，责任反而落到 PMO 头上。这是一个角色错位，一旦发生，整个依赖治理机制的权威性就崩了。

结论三：依赖治理的抓手不是一张大表，而是三个机制，分级、例会嵌入、到期预警。一张再全的依赖表，如果不嵌进团队已有的例会和节奏，两周之内就会变成死表。这是我在两个组织里反复验证过的。

1. 一个我自造的指标：依赖密度

在讲具体方法之前，我想先引入一个我在实践中用得很顺手的指标：依赖密度 = 某个交付里程碑被外部交付物牵制的依赖条数 ÷ 该里程碑下的任务总数。它衡量的不是依赖的绝对数量，而是这个里程碑"被别人卡住的程度"。

我的样本里，依赖密度低于 1.5 的里程碑，按期达成率约 82%；依赖密度在 1.5 到 2.5 之间的，按期达成率降到 61%；依赖密度超过 2.5 的里程碑，按期达成率只有 34%。这个数据不是行业统计，是我自己台账里的观察值，样本覆盖 3 个项目集、约 210 个里程碑，你可以用它作为自己组织的参照基线，但不要当成普适规律。

依赖密度的价值在于：它能让 PMO 在里程碑开始之前就判断出"这个节点大概率会炸"，而不是等它炸了之后再去救火。这比事后复盘有用得多。

二、背景与真实场景：依赖为什么在这三年集中爆发

依赖管理不是新问题，但它在这几年变得格外尖锐，背后有三个结构性变化。理解这三个变化，才能理解为什么老办法不管用了。

1. 组织从"包干制"变成"拼装制"

过去一个项目组从设计到上线全部包干，依赖主要发生在组内，靠一个负责人拍板就能解决。现在的中大型研发组织普遍采用产品线制加平台中台化，交付链条被拉长：前端依赖设计系统，设计依赖品牌规范，后端依赖平台组的接口，平台又依赖中间件团队。一条需求要走完，可能要穿过四五个团队的边界。

链条越长，每一环的"等待成本"就越高。依赖的本质成本不是交付物本身的成本，而是等待期间被锁死的人力成本。我算过，一个 8 人团队如果被一条外部依赖卡住三天，损失的不是 3 人天，而是这个团队在这三天里无法启动任何上下游任务所产生的连带损失，实际约 12 到 18 人天。

2. 迭代节奏变快，但跨团队响应周期没变

这是最容易被忽视的错配。团队内部已经习惯了双周迭代，甚至一周一发；但跨团队依赖的响应周期，在很多组织里还是按月计，上游排期要等月度规划会，资源协调要等部门负责人审批，接口变更要等架构评审。

当内部节奏是两周、外部响应是一个月的时候，依赖就必然成为交付的主要瓶颈。这不是团队执行力问题，是机制节奏不匹配。我在一个组织里做过测算：同样是"接口文档交付"这类依赖，走月度规划流程平均需要 22 天，走双周依赖确认会平均需要 9 天，差距 13 天，而这个团队一个迭代才 10 个工作日。

3. 我现场的观察：三个项目集的真实困境

2023 年 Q3 到 2024 年 Q4，我持续跟踪了三个项目集的跨团队依赖数据。这段观察有个很清晰的拐点：2024 年 Q1 开始引入结构化依赖治理机制后，平均逾期天数从 13.6 天快速下降到 4.4 天，而依赖条数也在下降，条数下降不全是因为问题变少，其中有相当一部分是依赖被"内化"了（团队发现某些依赖可以通过提前对齐接口把边界消除掉）以及重复依赖被合并。

1. 一个必须看清的事实：依赖链条在"漏"

我把 1180 条依赖记录做了一次全流程穿透，结果让我有点意外：真正被登记下来的依赖占比是 100%（这是台账本身），但有明确承接责任人的只有 81.5%，有书面承诺日期的只有 62.8%，按期交付的只有 49.8%，最终有验收记录并正式关闭的只有 44.7%。

也就是说，每 10 条被识别出来的依赖里，有 5.5 条在流程中途"消失"了，它们既没有被正式关闭，也没有被标记为失败，就这么挂在台账里，谁也不提。这才是依赖问题最危险的地方：不是显性的失败，而是隐性的沉默。

三、拆解常见误区：为什么大多数依赖管理最后都变成一张死表

我见过太多次同样的剧本：PMO 信心满满地推出一张依赖登记表，第一周填得满满当当，第三周开始有人漏填，第六周表格里的数据已经和现实脱节，两个月后彻底废弃。下面这五个误区，是我在复盘里出现频率最高的。

1. 误区一：把依赖当成任务来管

这是最根本的一个概念混淆。任务是"我要做的事"，依赖是"我需要别人做的事"。它们的责任主体完全不同。当你把一条依赖写进自己团队的任务列表，它在系统里就变成了自己的待办，承接方看不到，提出方也没法跟踪。

我在一个组织里就见过这种情况：团队 A 在自己的板子上建了一条任务叫"等待团队 B 提供接口"，这条任务挂在 A 的看板上，团队 B 根本不知道有这么回事。三个月后团队 A 说"我们早就提了"，团队 B 说"我们从来没收到过正式需求"。这种扯皮的成本极高，而且完全没有必要。正确的做法是：依赖必须由承接方"认领"成自己的任务，提出方只持有跟踪权。

2. 误区二：登记表字段越全越好

我见过一张 47 列的依赖登记表，包含"依赖来源系统""是否跨事业部""预期业务价值""风险等级""责任人上级"等等。设计者的逻辑很完美：数据越全，分析能力越强。但现实是，字段数超过 12 个之后，录入成本会迅速超过分析收益，表格的填写率会在三周内断崖式下跌。

我做过一个小范围的对照：同样是 11 个字段和 24 个字段的两版登记表，投给两组团队使用。11 字段版的次周填写完整率是 94%，24 字段版是 58%；到第四周，24 字段版跌到 31%，而且填写质量明显下降（很多字段被填成"待定"）。依赖管理的目标不是建立一个完美的数据库，而是建立一个能持续运转的机制。可持续性优先于完备性。

3. 误区三：依赖会议开成进度通报会

很多团队的"依赖对齐会"实际上是这样的：每个团队依次说"我们这边进度正常""我们正在等某某交付"，然后主持人问"还有问题吗"，没有，散会。这种会议开一百次也解决不了依赖问题。

问题出在议程结构上。依赖会议的核心议程不是"汇报状态"，而是"索要承诺"。每条依赖必须当场产生一个三选一的结论：承接方承诺交付时间、承接方给出有条件承诺（需要满足某前提）、承接方明确拒绝（触发升级）。没有结论的依赖，就是没有被处理的依赖。

4. 误区四：敏捷了就不需要依赖管理

这是一个流传很广的误解。很多人以为敏捷强调自组织团队，就不该有跨团队依赖协调。但事实恰恰相反，在规模化敏捷框架里，依赖协调是核心议程之一。SAFe 的 PI Planning 中，最关键的产出之一就是"项目群看板上的依赖关系图"，专门用来暴露跨团队依赖。

我自己的判断是：敏捷不消灭依赖，敏捷让依赖更早暴露。迭代越短，跨团队依赖暴露的频率越高，对依赖协调机制的要求反而更高。一个季度一次大瀑布，依赖问题可以藏到集成阶段才爆；双周迭代，依赖问题每两周就会浮现一次。

5. 误区五：把依赖失控归因于"沟通不畅"

"沟通不畅"是症状，不是根因。我在复盘时反复追问"具体是哪一步沟通不畅"，最后往往落到两个非常具体的地方：一是没有承诺机制，口头答应没有约束力；二是没有到期预警，直到逾期当天才有人提起。

把根因定为"沟通不畅"，改进动作就会变成"多开会""多拉群"，而这恰恰是最低效的改进。把根因定为"承诺机制缺失"和"预警缺失"，改进动作才会变成"建立书面承诺字段"和"配置到期前 5 天自动提醒"。

四、专业判断逻辑：依赖治理的五段闭环

下面这套五段闭环，是我在三个组织里反复迭代出来的。它的核心思路是：把依赖当成一个有明确生命周期的对象来管理，每一段都有明确的输入、输出和判据。五段分别是识别、登记、协商、跟踪、复盘。

1. 识别：四个触发信号，一个识别窗口

依赖识别不能靠"大家想一想有没有依赖"，要靠结构化的触发信号。我总结的信号只有四个：

1. 里程碑对齐信号，两个团队的交付里程碑之间存在先后约束。比如 A 团队要上线，必须先等 B 团队的支付通道联调完成。
2. 共享资源信号，同一个关键人、同一套测试环境、同一个数据库、同一个设计资源被两个以上团队共用。这类依赖最容易被忽略，因为它不是交付物依赖，而是资源依赖。
3. 上游交付物信号，接口定义、数据表结构、设计稿、环境配置、资质证书、第三方账号，任何一方需要另一方"交出东西"的都算。
4. 外部约束信号，供应商交付、监管审批、客户验收。这类依赖不受组织内部机制控制，必须单独标记并预留缓冲。

识别的窗口比识别的方法更重要。我的做法是：所有依赖必须在迭代计划会或季度规划会上识别并登记，不接受"事后补充"。原因很简单，事后补充的依赖，往往已经是逾期依赖了。

2. 登记：11 个字段，单条录入不超过 3 分钟

经过两轮删减，我把依赖登记表稳定在 11 个字段。这个数字不是拍脑袋来的，而是"能不能在一次会议中现场填完"这条线的产物。

这里我想特别强调"依赖对象"和"验收标准"这两个字段。绝大多数依赖扯皮，最后都会回到这两个字段上，承接方说"我交付了"，提出方说"这不是我要的"，双方都没错，因为从一开始就没定义清楚要交付什么、怎样算完成。把这两个字段写实，能减少约三分之一的下游纠纷。

另外一个是"承诺交付日期"。我坚持要求这个字段必须由承接方本人确认，而不是提出方代填。这个动作看起来很小，但它的心理效应完全不一样，代填的日期是"别人给我定的时间"，本人确认的日期是"我答应的时间"。前者可以推脱，后者要负责。

3. 协商：依赖确认会怎么开

依赖确认会是我认为整个闭环里杠杆率最高的一环。它不需要很长，30 分钟能处理 8 到 10 条依赖。我用的议程模板是这样的：

• 前 5 分钟：宣读本次待确认依赖清单（只读编号和标题，不展开）。
• 中间 20 分钟：每条依赖 2 到 3 分钟。提出方陈述需求（要什么、什么时候要、怎样算完成），承接方当场回应可行、有条件可行或不可行。
• 最后 5 分钟：确认本轮结论，更新台账，指定下一轮的跟踪人。

会议规则有三条，我觉得比议程本身更重要：

规则一：PMO 不替任何一方做承诺。PMO 只负责提问、记录和升级，不负责拍板。一旦 PMO 开始替承接方答应时间，这个机制就废了。

规则二：三选一，不允许"我看看"。承接方必须给出明确结论："我承诺 X 月 X 日交付"、"我可以交付，但前提是 Y 在 Z 日之前完成"、"我无法在要求时间内交付，申请升级"。第二和第三种都要当场记录，第三种要当场指定升级对象。

规则三：当场记录，不做事后补录。会议结束前，台账必须更新完毕。事后补录的依赖，绝大多数会永远补不上。

（1）一个我踩过的坑：不要试图在依赖会上解决技术分歧

早期我主持依赖会时，经常陷入两个团队关于技术方案的争论，比如接口该用同步还是异步。一次会议 30 分钟只处理了 2 条依赖。后来我立了一条规矩：依赖会只解决"谁、在什么时候、交付什么"，不解决"怎么做"。技术分歧当场记录，会后由双方技术负责人单独对齐，下次会议只汇报结论。这条规则让会议效率提升了差不多三倍。

4. 跟踪：状态分级 + 例会嵌入

跟踪环节的关键不是"盯得紧"，而是"盯得对"。"盯得紧"会导致 PMO 每天翻表，人力成本极高；"盯得对"意味着用分级机制，把有限的注意力放在最危险的那一小部分上。

我用的分级规则很简单，只按时间窗口分：

"5 个工作日"这个阈值不是随便定的。它的逻辑是：一个工作日以内的调整，团队内部就能消化；3 到 5 个工作日，还有可能在迭代内通过调整任务顺序来补救；超过 5 个工作日，基本就跨迭代了，需要项目集层面介入。你可以根据自己团队迭代长度调整，但建议不要超过迭代长度的二分之一。

更重要的是"例会嵌入"。依赖跟踪必须寄生在团队已有的会议节奏里，而不是新增一堆会议。我的做法是：日站会只看红色依赖，周例会逐条过黄色和红色依赖，月度项目集会议看趋势和根因。这样既不增加会议数量，又保证了依赖的可见性。

5. 复盘：一次复盘至少产出一条可复用规则

依赖复盘最容易流于形式，因为大家倾向于说"下次注意"。我的做法是强制归因到五类根因之一，每类根因对应不同的改进动作：

• 需求不清，改进动作：强化"依赖对象"和"验收标准"字段的填写要求。
• 承诺不实，改进动作：要求承接方承诺时必须说明依据（人力、排期、前置条件）。
• 资源冲突，改进动作：升级到项目集资源层，检查是否有更高优先级任务抢占。
• 变更失控，改进动作：检查变更是否走了流程，是否通知了下游。
• 机制缺失，改进动作：补充或修订组织级依赖管理规范。

我给自己定的硬指标是：一次依赖复盘，至少要产出一条可以写进规范、下次能被复用和检查的规则。比如"跨团队依赖的承诺日期必须由承接方本人在工具中确认"这条规则，就是某次复盘产出并沿用至今的。

五、数据观察与案例：一次 320 人研发组织的依赖治理改造

前面讲的是方法，这一节讲一个完整的落地案例。这个案例我认为有参考价值，因为它不是从零开始，而是在已有工具、已有流程的基础上做的改造。

1. 背景：一张没人愿意打开的 Excel

这家组织约 320 人，4 条产品线，8 个 Scrum 团队加 1 个平台团队，属于典型的中大型研发组织。他们原来的做法是：PMO 用 Excel 维护跨团队依赖，每周开一次项目集例会。问题有三个：

• 历史不可追溯，Excel 每个月重开一次，上个月的依赖状态查不到，导致"这条依赖提了几次了"这种问题无人能答。
• 责任不到人，台账里绝大多数依赖只写到团队，出问题时找不到具体对接人。
• 提醒靠人，没有任何自动提醒，全靠 PMO 每周翻表，导致 PMO 每周花 6.5 小时在数据整理上。

2024 年 4 月我参与了这个改造。他们原先使用的是 Jira，历史数据积累了三四年，自定义字段和工作流都相当复杂。

2. 改造五步

第一步：字段瘦身。把原来的 47 列砍到 11 列，砍掉的标准是"这个字段有没有在最近三次复盘中被实际用过"。

第二步：把依赖建成独立工作项类型，而不是标签。这是整个改造里最关键的一步。依赖一旦成为独立工作项，它就有了自己的状态机、自己的负责人、自己的历史记录，可以参与报表统计，也可以设置自动化规则。用标签或子任务来承载依赖，本质上还是把它当成附属品。

第三步：建立关联关系。把每条依赖与它影响的需求、迭代、里程碑双向关联起来。这样当有人打开某个里程碑时，能直接看到"这个里程碑被哪几条外部依赖卡着"。

第四步：配置自动化规则。这是降低 PMO 人力投入的关键。规则大致如下：

规则 1（预警）：
触发条件：依赖状态 != 已关闭，且 承诺交付日 – 今天 承诺交付日

执行动作：状态自动置为"阻塞"，推送至项目集依赖看板

附加动作：@ 依赖管理员，生成协调待办

规则 3（认领校验）：

触发条件：依赖状态 = 未确认，且 创建时间 > 3 个工作日

执行动作：提醒承接方在系统中确认认领，否则不允许进入迭代排期

规则 4（变更留痕）：

触发条件：承诺交付日字段发生变更

执行动作：强制填写变更原因与批准人，追加一条历史记录，不可覆盖

第五步：依赖看板作为例会第一议程。这条规则看起来最简单，但落地效果最明显。把依赖看板固定放在项目集例会的第一项议程，意味着它是所有人注意力最集中的时候被讨论的。

3. 为什么选择某类专业项目管理平台

这家组织在选型时的约束很具体：一是安全合规要求高，研发数据和代码资产不能出内网；二是要在保留历史数据的前提下迁移，不能"换工具等于重来一次"；三是组织规模已经超过 300 人，需要工具能支撑项目集级别的编排。

他们最终选择了 PingCode。我作为顾问参与了评估过程，认为有几个点确实匹配：

• PingCode 主要服务中大型企业及 100 人以上组织，这个 320 人、4 条产品线、8 个 Scrum 团队的组织规模，正好在它的主力服务区间内，依赖看板、项目集编排这类能力不需要额外定制。
• 支持私有化部署，研发资产和代码数据留在内网，满足这家组织的安全合规要求。
• 支持 Jira 平滑迁移，这是最关键的一点。他们原来在 Jira 上有三年历史数据、几百个自定义字段和复杂工作流。迁移时保留了历史工单与状态映射关系，团队不需要重新学习一套完全陌生的概念，迁移后的第一个月没有出现"数据断层"。
• 对于正在做国产替代的组织来说，这是相对稳妥的一条路径。

我想特别强调"历史数据迁移"这件事。依赖管理高度依赖历史数据，"这条依赖我们提过几次了""上次类似的依赖逾期了多久"，这些判断都需要历史记录支撑。如果迁移时丢掉历史，团队对工具的信任会在第一个月就崩掉，后面再推机制就非常困难。

4. 改造效果：六个月的前后对比

改造前六个月（2023 年 10 月至 2024 年 3 月）与改造后六个月（2024 年 4 月至 2024 年 9 月）的核心指标对比如下。需要说明的是，这组数据来自这个组织自己的统计，样本范围是单个组织的单次改造，不能直接外推到其他组织，但趋势判断是有参考价值的。

依赖条数下降 37.3% 这件事，我一开始以为是"统计口径变了"，专门核查过。核实结果是三个原因叠加：一是重复依赖被合并（同一个承接方对多个提出方的同类需求合并为一条），二是部分依赖通过提前对齐接口被"内化"消除了，三是确实有一部分原来会被记录为依赖的内容，在改造后被认为不属于跨团队依赖。其中第二个原因我认为是最有价值的，好的依赖管理机制会倒逼团队主动减少依赖。

1. 一个反例：80 人团队照搬重机制，三周后废弃

同一个方法论，我也见过失败的。一家约 80 人的单一产品团队，看到这套机制后原样照搬：11 个字段一条不少，每两周开依赖确认会，配了三套自动化规则。结果第三周就没人填了。

原因是机制成本与组织规模不匹配。80 人、单一产品、6 个小组，跨团队依赖一个月也就 10 条左右，团队天天在同一个办公区，抬头就能问。让他们为 10 条依赖维护一套完整机制，收益远小于成本。

这件事给我的教训是：依赖治理的颗粒度必须和组织规模、依赖密度、协作距离三者匹配。后面第七节我会专门讲这个取舍。

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

下面按组织规模和依赖特征分档给出行动建议。你可以先算一下自己组织的"活跃依赖条数"和"涉及团队数"，再对号入座。

1. 80 人以下 / 单一产品 / 集中办公

建议：不建依赖登记表。这个阶段的性价比极低。你需要的只是把依赖识别嵌进迭代计划会：每两周的规划会上，留 10 分钟专门问一句"下个迭代，谁需要谁交付什么"，把答案写在白板或共享文档上，指定到人即可。

这个阶段唯一值得做的机制是"依赖对象要写清楚"。哪怕只在白板上写一句话，也要写到"什么交付物 + 谁 + 什么时候"。这一条能解决大部分问题。

2. 100-500 人 / 多团队 / 多产品线

这是我实践中收益最明显的区间，也是投入产出比最高的区间。

1. 建立 11 个字段的依赖登记表，用独立工作项类型承载，不要用标签。
2. 设"依赖确认会"，每两周一次，30 分钟，固定议程，当场出结论。
3. 配置到期前 5 个工作日预警，逾期自动升级。
4. 指定一名依赖管理员（通常 0.5 个 FTE 足够），负责维护台账、主持确认会、跟进红色依赖。
5. 依赖看板固定放在项目集例会第一议程。

这个区间最常见的失败原因是"人不够"。很多 PMO 在推机制时只推流程不给人，结果流程挂在墙上没人执行。0.5 个 FTE 的投入，换回的是启动时间明显缩短和 PMO 数据整理时间的大幅下降，这个账算得过来。

3. 500 人以上 / 多项目集 / 跨事业部

这个规模的依赖管理，单靠一个 PMO 已经管不动了，必须建网络。

1. 每个项目集设一名依赖管理员，形成依赖管理员网络，每月同步一次。
2. 建立项目集级别的依赖矩阵，识别项目集之间的依赖关系，而不只是团队之间。
3. 季度做一次依赖复盘，归因到五类根因，输出组织级规则。
4. 自动化规则要覆盖"升级路径"，红色依赖必须自动触达项目集层，不能停在团队层。
5. 工具层面优先考虑支持私有化部署、能承载项目集编排、且能迁移历史数据的专业平台。

4. 已经用了工具但没机制的团队

这类团队的典型症状是：工具里什么都有，但没人看。我的建议是先加机制，再加字段。顺序反了就会变成"给死表加字段"。

具体做法：先确定依赖确认会的日期并开起来，第一次会可能只有 3 条依赖，没关系。跑到第三次会的时候，团队会自然发现"有些字段不够用"，这时候再补字段，团队会主动接受。反过来，先补一堆字段，团队会先抵触，然后放弃。

5. 正在做工具迁移的团队

这条是血泪教训：迁移时一定要把历史依赖数据一起迁过来。依赖管理和一般的任务管理不一样，它的价值很大一部分来自历史，某条依赖提了几次、某个团队的历史交付准时率是多少、上次类似依赖逾期多久，这些判断都需要历史数据支撑。

如果迁移时把历史数据丢掉，团队在新工具里看不到过去，就会本能地不信任新工具，第一个季度很难建立起使用习惯。选择支持平滑迁移的平台（比如从 Jira 迁移时能保留字段映射和历史工单），能省掉大量磨合成本。

七、不同情况下的取舍

依赖管理里没有"全都对"的方案，只有"在这个约束下更合适"的选择。下面六组取舍，是我被问得最多的。

1. 颗粒度取舍：登记到任务还是交付物

我的判断很明确：跨团队依赖只登记到"交付物"级别，不登记到"任务"级别。任务级依赖留给团队自己的排期工具去管。

原因是：任务级依赖数量大、变动频繁，一旦纳入跨团队台账，会让台账迅速膨胀并失去可读性。一个 300 人组织，任务级依赖一个月可能有几百条，交付出级依赖可能只有几十条。前者是团队内部的事，后者才是 PMO 该管的。

边界怎么划？如果一个移交动作不需要跨团队沟通就能完成（比如同一个团队内的两个子任务），它就不属于跨团队依赖。

2. 机制成本取舍：字段多与填写率高的取舍

这是一组直接的权衡。字段越多，分析能力越强，但填写率越低。我的经验值是：字段数量控制在 12 个以内，单条录入时间控制在 3 分钟以内。超过这条线，填写率会在三周内明显下滑。

如果确实需要更多信息，我的建议是把"低频字段"移出主表，放到一个可选的备注区，只针对高优先级依赖填写。主表保持精简，保证主干流程畅通。

3. 工具与表格取舍：什么时候必须上工具

我的判断阈值是：活跃依赖超过 50 条，或涉及 3 个以上团队，或需要历史追溯超过一个月，三者满足其一，就该上工具。

低于这个阈值，表格完全够用，而且表格的灵活性反而是优势。高于这个阈值，表格的劣势会迅速放大：无自动提醒、无法追溯历史、多人同时编辑易冲突、无法做统计分析。这四条里任何一条都足以让依赖管理失效。

4. 强管控与弱协调取舍

PMO 在依赖治理上的姿态有两种：强管控（依赖不确认不允许进入迭代）和弱协调（只做登记和提醒，不设硬约束）。

强管控适合交付承诺制的组织，比如对客户有明确交付时间承诺、或者有合规审计要求。它的代价是流程更重，团队会有抱怨，但能保证依赖不被忽略。

弱协调适合产品制组织，迭代节奏由产品价值驱动，交付时间弹性较大。它的好处是灵活，代价是依赖容易被"忘掉"。

我的建议是：无论选哪种姿态，都必须保留清晰的升级路径。弱协调不等于不管，而是"不设硬门槛，但红色依赖必须有人接手"。升级路径清晰，弱协调就不会失控。

5. 私有化与 SaaS 取舍

这个取舍通常不取决于偏好，而取决于合规要求。我的判断标准是三条：

• 如果涉及核心研发资产、未公开的产品设计、涉密项目，优先私有化部署。
• 如果所在行业有明确的数据本地化要求（金融、政务、部分制造业），私有化基本是必选项。
• 如果团队完全分布式、IT 运维能力薄弱，SaaS 的上手成本更低。

需要提醒的是，私有化不是"选完就完了"。它意味着你需要承担版本升级、环境维护的额外成本。选型时要一并评估这部分隐性成本，不要只看许可费用。

6. 依赖与风险的边界取舍

很多团队把依赖和风险混在一张表里管，这是我不太赞成的做法。依赖是双方之间的明确义务，有承接方、有交付物、有承诺日期；风险是单方面识别出的不确定性，可能发生也可能不发生。两者的管理动作完全不同。

我的做法是：两张表分开维护，但用"关联风险编号"字段互相引用。一条依赖如果存在高不确定性（比如承接方自己也在等外部供应商），就应该在风险登记册里有一条对应记录。这样既能保持两套机制的清晰，又不会遗漏交叉信息。

八、结语：把依赖从"意外"变成"预期"

回到最开始那个项目集。交付节点前两周，37 条依赖有 14 条未确认。那次之后我如果重新做一遍，会做三件不一样的事：第一，在里程碑规划阶段就算一次依赖密度，把密度超过 2.5 的节点提前标红；第二，把依赖确认会固定在规划会之后的第二天开，让承诺有明确的时间窗口；第三，要求所有承诺日期必须由承接方本人在系统中确认，PMO 不再代填任何一个日期。

这三件事的共同点是：它们都不增加 PMO 的工作量，但都改变了依赖的"可见性"和"约束力"。我一直认为，PMO 在依赖管理上的核心价值，不是排得多细，而是让每一条依赖都有名字、有日期、有人管、有记录。做到这四点，依赖就从"意外"变成了"预期"，而预期是可以被管理的。

如果你现在就想启动，我建议按这个顺序来，不要贪多：

1. 本周：拉出当前所有活跃的跨团队依赖，只填 5 个字段，提出方责任人、承接方责任人、交付物、承诺日期、影响。填不满也没关系，先把清单建起来。
2. 下周：开一次 30 分钟的依赖确认会，把清单上"未确认"的依赖逐条过，要求承接方当场给出三选一结论。
3. 两周内：把这份清单放进你现有的周例会议程的第一项，不要新开会。观察两周，看有多少条依赖在红色状态下暴露出来。
4. 一个月后：如果活跃依赖超过 50 条或涉及 3 个以上团队，开始评估把它搬进专业项目管理平台，用独立工作项类型承载，并配置到期前 5 天预警。
5. 一个季度后：做第一次依赖复盘，按五类根因归因，输出至少一条能写进规范的可复用规则。

这套东西我在三个组织里跑过，最短的见效周期是一个季度，最长的用了两个季度。前两个月通常看不出明显效果，这是正常的，机制需要时间被消化。如果你在第二个月想放弃，不妨回看一下依赖漏斗的转化数据，你会发现，即使机制还不完善，有责任人、有承诺日期的依赖比例已经在往上走了。那个数字，才是长期会转化为交付确定性的东西。