任务依赖依赖冲突教程：PMO落地方案，避坑指南

2024 年我们做了一个跨 5 个部门的版本集，原计划 10 月 18 日上线，最后拖到 12 月 4 日，延期 47 天。复盘时我把这 47 天逐日拆开，结论有点扎心：真正卡在技术难题上的时间只有 6 天，剩下 41 天全部消耗在依赖上，A 团队等 B 团队的接口，B 团队等 C 团队的架构评审结论，C 团队的评审员被抽去做另一个"更紧急"的项目。更麻烦的是，这 41 天里没有任何一天被记录为"阻塞"，所有人都以为自己在正常干活。

这篇文章不讲教科书上的依赖定义，只讲一件事：PMO 怎么把依赖从"大家心里都知道"变成"系统里有记录、有责任人、有仲裁规则"的治理机制。

一、先把结论说在前面：依赖冲突是治理失效，不是执行力问题

我做了六年 PMO，前三年我一直以为依赖冲突是沟通问题，多做几次对齐会、多拉几个群就能缓解。直到 2023 年我统计了手上 37 个延期超过 15 天的项目，把每个项目的延期原因做归因打标，才发现沟通只是表象。

1. 结论一：依赖冲突的本质是权责冲突和优先级冲突

两个团队为"谁先交付"吵起来，表面看是排期问题，实际是两个团队各自背的 KPI 不同。A 团队的考核指标是版本交付及时率，B 团队是线上故障数。B 团队多花 3 天做加固，对自己是加分项，对 A 团队是延期。这种情况下，"加强沟通"是无效的，因为冲突的根不在信息差，在激励结构。

所以 PMO 介入依赖冲突时，第一个动作不该是拉会，而是问清楚：这两个团队的考核口径是什么，这次冲突损害的是谁的指标。如果两边都没有损失，那这就不是冲突，只是没人愿意主动干活，那要靠规则而不是靠协调。

2. 结论二：依赖冲突的成本随发现时间呈非线性上升

我把自己经手的项目做过一个粗略估算：同一个依赖问题，在需求评审阶段发现，平均花 0.5 人天就能解决；在联调阶段才发现，平均要花 12 人天；如果拖到上线前一周，因为要重新拆包、重新测、重新约窗口，平均要 28 人天。成本差 50 倍以上，但绝大多数团队的依赖登记动作都发生在开发阶段之后。

3. 结论三：PMO 是规则制定者和仲裁支持者，不是催办员

这句话我说过很多次，但真正做到很难。因为催办是即时见效的，你今天催，明天对方就回了；建规则是三个月见效的，前两个月你看起来什么都没做。我第一年带 PMO 的时候就是靠催，催到后来所有部门都躲着我，而且只要我休假一周，整个依赖链条立刻停摆。

后来我换了做法：PMO 输出的是规则、模板、升级路径和度量数据，具体依赖的推进交还给接口人和项目经理。判断标准很简单，如果我休假两周，依赖机制还能转，说明这个机制成立；如果转不动，说明那只是我个人在当人肉中间件。

4. 结论四：工具解决可见性，机制解决约束力

把依赖画到甘特图上，只能让人看见它，不能让人为它负责。我见过最漂亮的一张依赖图，是某项目组用在线表格手工维护的，42 条依赖线画得像蜘蛛网，但没有任何一条有责任人、有任何一条有承诺日期。这张图上线两周后就没人更新了。

可见性是必要条件，不是充分条件。依赖要真正被管住，至少要有四个要素同时存在：唯一接口人、承诺日期、缓冲额度、升级路径。缺任何一个，依赖就会退化成"大家都知道但都不负责"的状态。

5. 结论五：80% 的严重依赖冲突来自跨部门，而非部门内

部门内部的依赖冲突，通常一顿饭或者一个群里 @ 一下就能解决，因为两边有共同上级、有共同的交付压力。跨部门的依赖冲突才是真正的深水区，因为它同时缺三样东西：共同目标、共同上级、共同的信息节奏。

所以 PMO 的精力分配应该是二八开：20% 用来优化部门内依赖的流程，80% 用来设计跨部门依赖的接口人机制和升级机制。把 80% 的精力花在画部门内的依赖图上，是典型的投入产出错配。

二、真实场景：依赖冲突为什么总在项目后期集中爆发

我把三年来印象最深的四类场景写出来。它们有个共同规律：问题在前两个月就已经埋下了，但直到第三个月才浮出水面，中间这段时间没有任何机制能把它捞出来。

1. 场景一：口头承诺型依赖

最常见的一种。开发 A 在群里说"这个接口我下周三给你"，开发 B 回了个"OK"，然后这条消息就被 200 条聊天记录淹没了。到了下周三，A 手上的任务被临时插进来的紧急需求挤掉，接口延期，B 一直在等，等到第四天忍不住问一句，A 说"我以为不急"。

这个场景的核心问题不是 A 不守信用，而是这条依赖从来没有进入任何人的正式任务列表。口头承诺没有排期，没有排期就没有资源占用，没有资源占用就随时可以被别的需求挤掉。这是所有依赖冲突里最常见、也最容易通过制度解决的一类。

2. 场景二：隐性依赖根本没被识别出来

这个更危险。项目计划里完全没有体现的依赖，比如"新版本的登录模块依赖统一的账号中台升级"，这条依赖写在账号中台自己的路线图里，但产品 A 不知道，项目经理也不知道，直到联调时发现老接口返回结构变了。

隐性依赖的产生，通常来自组织结构本身：当两个团队共享一个底层组件或平台时，依赖关系大量存在于"平台团队的路线图"里，而不在"业务团队的项目计划"里。PMO 如果没有横跨两条路线的视图，这类依赖就是盲区。

3. 场景三：优先级打架，两个"P0"撞在一起

我遇到过一次典型情况：两个项目都标记为 P0，都需要同一个团队的一名资深架构师做评审。这名架构师一周只能做两次评审，而两个项目都要求同一周内完成。

这时候无论架构师怎么选，都会有一个项目延期。而且更糟的是，他往往选择"两个都接、两个都拖"，最后两个项目一起延期。优先级冲突不能靠执行层自己消化，必须有人在更高层做取舍，而这个取舍必须是显性的、被记录的，否则被牺牲的那一方永远不知道自己是被牺牲的，只会觉得对方不配合。

4. 场景四：变更悄悄吃掉缓冲

我们的排期里通常有 15% 的缓冲，但这些缓冲在第一周就被各种"小改动"吃掉了：加一个字段、改一个文案、调整一个流程。每一次变更单独看都不大，项目经理也就口头同意了，因为"这么点事还要走流程显得太死板"。

等到真正出现依赖延期时，缓冲早就没了，延期直接传导到上线日。缓冲被吃掉的真实原因不是变更本身，而是变更没有被记录，所以没有人知道缓冲还剩多少。

三、拆解常见误区：PMO 最容易踩的 7 个坑

下面这 7 个坑，我自己踩过 5 个，剩下 2 个是看同行踩的。它们有共同特征：在短期内看起来都是"正确的、负责任的、积极的"动作，但三个月后一定出问题。

1. 认知类误区：方向一开始就偏了

（1）把依赖当成排期问题

表现是 PMO 花大量时间优化甘特图，把依赖线画得整整齐齐，但没有任何一条依赖有责任人。后果是图很漂亮，冲突照旧。正确做法是先定"谁负责"，再定"什么时候做"。

（2）认为依赖问题靠沟通频率就能解决

表现是把会议从每周一次改成每天一次。后果是会议时长翻倍，信息质量下降，所有人都在汇报状态但没人做决策。正确做法是把精力放在接口人识别和升级路径上。

（3）指望业务部门主动配合

表现是发一个自愿填写的依赖登记表。后果是登记率长期低于 40%，登记的还都是不重要的事。正确做法是把依赖登记作为评审通过的必要条件，而不是一个可选动作。

2. 机制类误区：PMO 最容易做"过"的地方

（1）所有冲突都升级，把升级机制变成日常

表现是给每个依赖都设三级升级，一有风吹草动就往上捅。后果是高层很快对升级麻木，真正严重的冲突反而得不到重视。正确做法是明确升级门槛，比如"超过承诺日期 2 天且影响关键路径"才允许升级。

（2）PMO 越权替业务承诺日期

表现是 PMO 在协调会上直接说"这个接口我们定在 8 月 20 日交付"。后果是承诺无效，因为 PMO 没有资源调度权，被承诺方也不会为这个日期负责。正确做法是 PMO 只记录承诺，不制造承诺，日期必须由被依赖方的实际负责人给出。

3. 落地类误区：导致机制被废弃的两个细节

（1）流程一上来就上全套

表现是第一版就设计了 8 个字段、5 级审批、3 类报表。后果是项目经理填两周就放弃，因为"填表的时间比协调的时间还长"。正确做法是第一版只保留 4 个必填字段：依赖方、被依赖方、承诺日期、接口人。

（2）度量做成催办排行榜

表现是按"依赖逾期次数"给各团队排名并公开。后果是团队开始少登记、晚登记，数据越来越好看，问题越来越隐蔽。正确做法是把度量重点放在依赖登记率和确认及时率上，逾期率只用于内部改进。

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

讲完误区，讲我的判断框架。我把依赖治理拆成四层，这四层是递进关系，不能跳级。很多 PMO 一上来就想做第四层的度量，结果因为第一层没打通，度量数据全是假的。

1. 可见层：把依赖变成一个有字段的对象

这一层要解决的是"依赖在哪里"。依赖不能存在聊天记录里，也不能只存在某个人的脑子里，它必须是一个有 ID、有状态、有责任人的对象。

最小字段集我建议是六个：依赖 ID、依赖方任务、被依赖方任务、接口人、承诺日期、当前状态。状态机也很简单：草稿 → 已确认 → 有风险 → 已阻塞 → 已关闭。

我见过一个团队用一份 YAML 文件管理依赖，放在代码仓库里，任何人改动都要走 MR，反而比某些重型工具更有效。形式不重要，重要的是依赖变成了可以被查询、被排序、被统计的东西。

# dependency-record.yaml（我们早期用过的依赖登记结构）
id: DEP-2024-0731

from_task: PAY-1420 # 依赖方：需要别人先交付的任务

to_task: ARCH-0311 # 被依赖方：承诺交付的任务

type: finish_to_start # 强制依赖 / 外部依赖 / 资源依赖

interface_owner: 张XX # 唯一接口人，问事只找他

commit_date: 2024-08-20 # 被依赖方给出的承诺日期（不是 PMO 定的）

buffer_days: 5 # 汇入缓冲，用于吸收小幅延期

priority_rank: P1 # 由项目集决策会裁定，不由执行层协商

escalation_level: L2 # 当前升级层级

status: confirmed # draft / confirmed / at_risk / blocked / closed

evidence: 接口文档 v0.9 + 联调环境已就绪

2. 约束层：把依赖变成一个有代价的承诺

登记只是让它可见，真正产生约束力的是"承诺有代价"。这个代价可以是排期上的：一旦承诺某个日期，该任务就占用被依赖方的人力额度，不能随便被别的需求挤掉。

也可以是对比上的：承诺日期和实际交付日期的差异会被记录，作为团队协作质量的参考。注意这里的分寸，记录差异是可以的，把差异做成公开羞辱是不行的，后者会直接摧毁数据质量。

3. 决策层：把冲突变成一次显性的取舍

当两个 P0 撞在一起，PMO 的价值不是和稀泥，而是把冲突结构化地呈现给有决策权的人，让他做一个有记录的选择。呈现方式我建议固定三句话：如果不调整，A 会延期几天；如果保 A 弃 B，B 会延期几天；如果两边都保，需要额外投入什么。

决策一旦做出，必须记录在案，包括被牺牲的一方和牺牲的理由。这一步最容易被跳过，但它是整个治理体系能否长期运转的关键，没有记录的取舍，下次冲突时没人相信 PMO 是中立的。

4. 反馈层：把每一次异常变成一次规则修订

每次依赖冲突解决后，PMO 应该问一个问题：这次冲突暴露了我们哪条规则的缺口？如果答案是"没有规则"，那就补一条；如果答案是"有规则但没人执行"，那就要看是规则太重还是缺少约束。

我自己的习惯是每季度出一份依赖治理复盘，只写三件事：本季度最严重的 3 次依赖冲突、根因归类、下季度要改的 1 条规则。只改一条，改多了没人记得住。

五、PMO 落地六步法：每步都有明确的产出物

下面这套六步法，是我在两家公司迭代过的版本，第一版有九步，太重，落地两个月就废了。现在这版六步，通常在 6-8 周内能跑完第一轮。

1. 第一步：统一依赖的定义和登记口径

先解决"什么算依赖"。我的定义是：当一个任务的开始或结束时间，取决于另一个团队（或另一个项目）的交付物时，这条关系就是依赖，必须登记。同一个人、同一个小组内部的任务前后顺序不算，那属于排期，不属于依赖治理范围。

这一步的产出物是一页纸的登记规范：什么必须登记、什么时候登记、谁负责登记。我的建议是"评审不通过就不能进入开发"，用评审节点做强制拦截，比事后检查有效得多。谁来做：PMO 起草，各团队负责人确认。产出物：依赖登记规范 v1.0。

2. 第二步：建立依赖矩阵和关键路径视图

依赖矩阵是给 PMO 和项目集经理看的，一屏之内能看到所有跨团队依赖；关键路径视图是给决策层看的，只看影响上线日的那几条。

这里要提醒一句：不要试图把所有依赖都放进一张图，超过 50 条依赖的图没人看得懂。我的做法是矩阵放全量，关键路径只放"影响上线日 ±3 天"的依赖，通常不超过 15 条。谁来做：PMO。产出物：依赖矩阵（全量）+ 关键路径清单（约 15 条）。

3. 第三步：明确接口人与三级升级路径

接口人的定义是：关于这条依赖的任何问题，只找这个人，他负责给出答复或明确转交。接口人不能是"部门"或"团队"，必须是一个具体的人名。我见过太多依赖写着"接口人：XX 平台组"，等于没有接口人。

升级路径分三级：L1 是接口人之间协商，响应时限 1 个工作日；L2 是双方团队负责人，响应时限 2 个工作日；L3 是项目集决策会，每周一次固定窗口。L3 必须是固定窗口而不是随时可开，否则升级会失控。

4. 第四步：建立变更控制与同步节奏

变更控制的目标不是阻止变更，而是让缓冲的消耗可见。我的做法是给每个依赖设置"缓冲额度"，比如 5 天，任何影响承诺日期的变更都要扣减缓冲，缓冲低于 2 天时自动进入风险清单。

同步节奏上，我只保留两个固定动作：每周一次跨团队依赖对齐（30 分钟，只看红色和黄色依赖），每两周一次缓冲盘点（15 分钟，只看缓冲余额低于 50% 的依赖）。其他的沟通通过工具完成，不占会议时间。

5. 第五步：设置缓冲与优先级仲裁规则

缓冲分两种：任务级缓冲（加在单条依赖之后）和项目级缓冲（加在关键路径末端）。我的经验是任务级缓冲 10%-15%，项目级缓冲 15%-20%，两者不要叠加使用。

优先级仲裁规则要提前定，不能等冲突了再定。我建议的规则顺序是：先看是否影响已对外承诺的上线日，再看是否阻塞关键路径，最后看投入产出比。三条规则按顺序判断，避免每次都为"谁更重要"吵一遍。

6. 第六步：用度量指标驱动复盘

度量指标只保留四个，多了没人看：依赖登记率（应登记且已登记的比例）、依赖确认及时率（被依赖方在 2 个工作日内给出承诺日期的比例）、依赖逾期率、关键路径阻塞天数。

其中前两个是过程指标，必须重点看；后两个是结果指标，用于验证治理效果。如果登记率低于 70%，说明流程还没跑通，此时看逾期率没有任何意义。

六、案例拆解：一次跨 5 部门的依赖冲突，我们花了 11 天解决

下面这个案例来自 2024 年我们真实经历的一次冲突，数据是我从当时的会议纪要和系统记录里翻出来的，为了不暴露业务细节，任务名做了脱敏。整个处理过程 11 天，比我预期的 4 天长得多，但它暴露的问题很典型。

1. 冲突是怎么被发现的

2024 年 8 月 6 日，版本集的联调阶段第 3 天，测试同学报了一个问题：订单模块调用风控接口返回 401。查下来发现，风控团队两周前升级了鉴权方式，从固定 Token 换成动态签名，但升级通知只发在风控自己的技术群里，订单团队没人看到。

这条依赖在系统里根本没有登记记录。也就是说，我们的依赖登记率达到 89% 的那个月，漏掉的那 11% 里，恰好包含了最致命的一条。

2. 前 3 天：常规协调为什么失效

第 1 天，项目经理在群里 @ 了风控的对接人，对方说需要评估兼容方案，第二天给答复。第 2 天没消息，第 3 天回复说"最快 8 月 20 日能提供兼容层"。

问题在于，我们的上线窗口是 8 月 18 日，而且这个窗口已经对外承诺过。3 天时间里，协调一直在两个执行层的人之间来回，谁都没法做"延期上线"或者"砍需求"这种级别的决策。这 3 天是被浪费掉的，因为冲突的级别和协调的层级不匹配。

3. 第 4-7 天：升级到决策层，拿到第一个取舍

第 4 天我们启动了 L3 升级，把问题提到了项目集决策会。我把三个选项和各自的代价列成一张表：保留原上线日但砍掉风控升级带来的新增校验能力，延期 2 天到 8 月 20 日，或者让订单模块先接旧版鉴权、风控提供双版本支持。

决策会选了第三个，因为它同时保住了上线日和风控的升级节奏。但这个选项需要风控投入 3 人天做兼容层。这个投入是决策层拍板的，不是执行层自己协商出来的，这是它能推动的原因。

4. 第 8-11 天：拆解任务与并行推进

拿到决策后，我们把这条依赖拆成三条子任务，全部落到系统里：风控提供兼容层（3 人天）、订单模块切换鉴权配置（0.5 人天）、联调与回归（1.5 人天）。三条任务设了同一个接口人，承诺日期分别是 8 月 14 日、15 日、16 日。

这里我用到了实际工具的能力。我们当时已经把跨团队依赖管理迁到了 PingCode 上，因为我们的项目数据不能出内网，而它支持私有化部署；同时我们从原 Jira 迁移过来，历史工作项的字段映射做得比较平滑，迁移了约 12 万条历史数据，用了 3 周时间，没有中断日常交付。

具体做法是：在 PingCode 里建了一个"依赖"工作项类型，把接口人、承诺日期、缓冲天数、升级层级做成自定义字段，再用过滤视图做一个"依赖健康度看板"，红色表示逾期或有风险，黄色表示缓冲余量不足，绿色表示正常。这个看板每天自动刷新，不需要任何人手工维护。

说实话，工具本身没有解决这次冲突，解决冲突的是决策层的取舍。但工具让"这条依赖从哪来、谁承诺的、还剩几天"变成了一查就知道的事，把协调成本从 2 天压到了 2 小时。

5. 复盘：这次处理暴露的两个机制缺口

第一个缺口是外部变更的传导机制。风控的鉴权升级属于平台侧的变更，它没有义务知道有哪些业务方在调用。后来我们补了一条规则：所有平台的接口变更，必须在上线前 10 个工作日通过依赖登记系统发起"影响面征询"，没有完成征询的不允许上线。

第二个缺口是升级的触发条件太模糊。前 3 天之所以被浪费，是因为没有明确的"多久没答复就该升级"。后来我们定的规则是：L1 接口人 2 个工作日无实质进展，自动升 L2；L2 再 2 个工作日无结论，自动进 L3 议程，不需要任何人额外申请。

七、度量：依赖治理到底该盯哪几个指标

指标设计是 PMO 最容易自我感动的地方。我见过一份 23 个指标的项目管理看板，实际被使用的只有 3 个。依赖治理这块，我建议只保留 6 个指标，并且明确每个指标什么时候该看、什么时候不该看。

1. 过程指标优先于结果指标

很多 PMO 盯着延期天数，但延期天数是滞后的，等它恶化的时候已经来不及了。登记率和确认及时率是先行指标，它们恶化之后 3-4 周才会体现到延期上，这段时间就是干预窗口。

2. 指标的采集必须自动化

手工采集的指标活不过两个月。我在第一家公司做依赖治理时，靠项目经理每周五填表，第三周开始就有人漏填，第六周数据质量已经没法看了。后来改成系统自动统计，只要依赖在工作项里有明确字段，看板可以自动刷新，维护成本几乎为零。

3. 指标要能定位到人，但不能公开排名

指标必须能下钻到具体依赖和具体接口人，否则没法改进；但不建议做跨团队的公开排名。我的替代方案是只把排名给到各团队负责人本人，让他们自己看，PMO 层面只公布整体趋势。

八、工具取舍：自建表格、轻量工具、项目管理平台怎么选

工具这块我踩过最贵的坑，是 2022 年花了两个月自研了一套依赖管理模块，上线后没人用，因为它的数据和任务系统是两套，大家不愿意在两个地方维护状态。依赖数据的价值在于它和任务、迭代、发布绑定在一起，脱离任务系统的依赖管理工具，基本都会沦为摆设。

1. 三种方案的适用边界

自建表格（在线表格 / Excel）适合 30 人以下、依赖数量少于 20 条的团队。它的优势是零成本、上手快、灵活；劣势是权限粗、审计弱、无法与任务状态联动，一旦依赖超过 30 条就开始失控。

轻量协作工具适合 30-100 人的团队。这类工具通常有任务和看板，依赖关系可以用"关联"字段近似实现，能满足基本的可视化需求。但它们对多级依赖、跨项目集视图、缓冲管理的支持通常有限。

中大型项目管理平台适合 100 人以上、多产品线并行的组织，也就是 PingCode 主要服务的这类规模。这类组织的特点是依赖数量大（通常单版本 50 条以上）、跨部门多、对私有化部署和数据合规有硬要求。

2. 选型时必须问清楚的三个问题

第一个问题：能不能把"依赖"当成一个独立的工作项类型？如果不能，只能用关联字段近似表达，你就没法给依赖单独设状态机、单独做看板、单独统计转化率。

第二个问题：支不支持私有化部署？对金融、政企、部分制造业客户来说，项目数据不能出内网是硬约束，这条不满足，功能再好也用不了。我们的选择标准就是这一条，这也是我们最终选 PingCode 的核心原因。

第三个问题：历史数据迁移成本有多大？如果原来用的是 Jira，要问清楚字段映射、状态映射、附件和评论是否完整迁移。我们那次迁移了约 12 万条历史工作项，用了 3 周，其中 1 周花在字段映射方案上，这部分工作量一定要提前算进选型成本。

九、不同规模团队的落地建议与取舍

同一套方法在不同规模的组织里，落地强度完全不同。下面按四个规模段给出我的建议，重点是每段的"不该做什么"，因为做多了比做少了更容易失败。

1. 20 人以下：只做一件事，把依赖写到任务里

这个规模不需要依赖登记系统、不需要升级路径、不需要缓冲规则。唯一要做的是：任何跨人协作的任务，在任务描述里写清楚"等谁交付什么"。

取舍上，牺牲的是统计能力，换取的是零管理成本。这个阶段如果上流程，团队会直接绕过 PMO 干活。

2. 20-100 人：依赖登记 + 每周一次对齐会

这个规模会出现"我不知道还有谁在等我"的问题。建议加两样东西：一份共享的依赖清单（可以是表格），每周一次 30 分钟的对齐会，只讨论红黄状态的依赖。

取舍上，牺牲的是流程的严谨性（表格容易失真），换取的是低阻力落地。这个阶段的目标是把"登记"这个动作变成习惯，而不是把数据做准。

3. 100-500 人：六步法全量落地，工具必须跟上

这个规模依赖数量通常单版本超过 50 条，手工维护一定崩。建议按前面六步法完整落地，同时引入专业项目管理平台，把依赖做成独立工作项类型。

取舍上，牺牲的是短期的灵活性（要填更多字段、走更多流程），换取的是跨部门依赖的可见性和可追溯性。这个阶段最大的风险是流程过重导致反弹，所以第一版字段一定要控制在 4-6 个以内。

4. 500 人以上或多产品线：治理要分级，不能一刀切

这个规模下，试图用一套流程管理所有依赖一定会失败，因为不同产品线的交付节奏、合规要求、团队成熟度差别很大。我的建议是分两级：公司级只管"影响对外承诺上线日"的依赖，产品线级管其余依赖，两级用同一套字段和指标口径，但流程强度不同。

取舍上，牺牲的是统一的管控感（有人会觉得不够集中），换取的是流程的可持续性。我见过太多大型组织因为追求统一，最后把所有团队都逼回线下沟通。

5. 三个必须提前想清楚的取舍

取舍一：流程复杂度 vs 执行力。流程每增加一个字段，登记率大约下降 5-8 个百分点（这是我们内部三次调整的观察）。在登记率没到 85% 之前，任何新增字段都应该慎重。

取舍二：集中管控 vs 团队自治。PMO 管得越多，团队的责任意识越弱，因为"反正有人替我盯着"。我的建议是 PMO 只管规则和升级，具体依赖的推进完全交给接口人。

取舍三：数据的完整性 vs 数据的真实性。强制要求所有依赖都登记，会带来大量敷衍填写的记录；只要求关键路径依赖登记，数据会更真实但覆盖面窄。我倾向后者，先用真实数据建立信任，再逐步扩大覆盖范围。

结语：PMO 的价值不是催进度，而是让依赖可控

回到开头那次延期 47 天的版本集。真正的转折点不是我们买了什么工具，而是决策层第一次认真做了一次取舍，并且把取舍的理由记录在案。从那之后，类似的冲突依然会发生，但处理时间从平均 11 天降到了 4 天以内。

我现在的核心判断是：依赖冲突是组织权责结构的投影。PMO 能改的是可见性和规则，改不了的是权责本身；但只要你把冲突结构化地摆到有决策权的人面前，冲突的处理成本就会大幅下降。这也是为什么我一直坚持 PMO 不要做催办员，催办解决的是这一次，规则解决的是下一次。

如果你正在推动依赖治理，我建议的下一步只有一件事：先做一次依赖盘点，把当前所有版本里"跨团队且影响关键路径"的依赖列出来，数一数有多少条，其中有多少条有明确接口人和承诺日期。这个数字会告诉你，你现在最该补的是登记机制，还是升级机制，还是最基础的接口人制度。

盘点完之后，先不要急着上流程，只做一件事：给这十几条依赖每条指定一个具体的接口人。这一步花不了半天，但它是整个依赖治理体系里性价比最高的一步。