去年十月，我接手了一家做汽车零部件的中型制造企业的 PMO 搭建工作。第一次进项目群开会，我就愣住了，群里 47 个项目成员，讨论一个"交付节点该排在哪天"的问题，从下午两点吵到晚上七点，最后发现：三个部门的排期表里，同一个"模具交付"任务，分别被写在了三个不同的日期上，谁也不知道哪个是真的。会后我把三个表拉出来一比对，光这一个任务，就牵扯出 11 条没有登记过的隐性依赖关系。
这不是个别现象。我统计过手上服务过的 6 家中大型企业，项目延期的原因里，真正因为"技术做不出来"的占比不到 15%，剩下的 85% 里，超过一半能追溯到任务依赖没理清。所以当我看到"SS 怎么做？PMO 制度设计：任务依赖从 0 到 1"这个选题时，我的第一反应是：这个问题问对了方向，但绝大多数回答都答偏了，他们把依赖管理讲成了画甘特图，而真正的难点是制度设计。这篇文章，我把这套东西拆开讲透。
一、先给结论：任务依赖不是"画出来"的，是"管出来"的
我先抛结论：在 PMO 从 0 到 1 的阶段，任务依赖管理的核心不是工具能力，而是责任机制。你用什么软件画依赖图只是表层，真正决定成败的，是"谁有权定义依赖、谁来仲裁依赖冲突、谁负责让依赖保持更新"这三件事有没有被制度固化下来。
为什么这么说？因为我在项目里反复验证过一个规律：依赖关系的"登记率"和"准确率"会随着制度设计的松散程度急剧衰减。没有制度约束时，一个中等复杂度项目（约 300 个任务、跨 5 个部门）的依赖登记率通常不到 40%；而建立起评审和更新机制后，这个数字能提到 85% 以上，且冲突仲裁的平均耗时能从数天压到数小时。
这就是"SS 怎么做"这个问题的真面目。如果你的 SS（不论具体指 Scrum、共享服务还是解决方案支持）要落地，任务依赖就是那块最硬也最容易被忽略的地基。地基没打好，上面盖多少流程文档都是空中楼阁。
下面我先讲清楚这个结论是怎么得出来的，再讲背景、误区、判断逻辑，最后给你可以直接抄的机制和模板。
二、真实场景：三个让我印象深刻的依赖失控现场
脱离场景讲方法论都是耍流氓。我挑三个我亲身经历的场景，你能从中看到依赖失控的真实模样。
1. "口头承诺"型依赖：最隐蔽也最致命
有一家做智能硬件的客户，硬件团队和软件团队约定"硬件板卡到位后软件开始联调"。这个依赖在会上被口头确认过三次，但没有写进任何系统。结果硬件因为供应商问题延迟了五天，软件团队完全不知道，等到约定那天去取板卡才发现没到，白白等了五天，整个项目尾部被压缩到几乎不可能完成。
这类依赖的特点是：它存在于人的记忆里，不存在于系统里，一旦人员变动或注意力转移就蒸发。我后来帮他们复盘，发现在项目生命周期里，这种"口头依赖"平均每个项目有 7 到 12 个，且几乎全部是无缓冲的强依赖。
2. "跨部门甩锅"型依赖：没人认领就没有人负责
制造业项目里最常见的场景：结构件开模依赖工业设计定稿，工业设计定稿依赖市场部确认需求，市场部确认需求依赖客户签字。这条链上任何一环延迟，后端全线等待，但每一环都觉得"我这边没问题，是前面拖的"。
我见过最极端的一次，一个依赖链上四个部门互相推诿，最后项目经理花了整整两天做访谈才搞清楚到底卡在哪。问题不在某个部门不配合，而在于没有一条制度规定"依赖链上谁负责催办、谁负责升级"。
3. "变更不通知"型依赖：改了一个数，塌了一片天
还有一家企业，项目经理把某个任务的工期从 5 天改成 8 天，觉得是"小事一桩"，没通知下游。结果下游三个任务、两个外部供应商的排期全部错位，返工成本估算超过 20 人天。这就是典型的：依赖一旦建立，它就不再属于单个任务，而是属于整个网络，任何单点变更都必须触发通知机制。
这三个场景有个共同点：它们都不是技术问题，是制度缺失问题。所以我一直跟团队讲，PMO 从 0 到 1，别急着买工具、别急着画甘特图，先把依赖的登记、评审、更新、仲裁这四个动作的制度框架搭起来。
三、拆解四个常见误区：为什么很多 PMO 的依赖管理做成了摆设
我在做诊断时，发现企业踩的坑高度雷同。下面这四个误区，几乎每一家都至少中招两个。
1. 误区一：把"画依赖图"当成"管依赖"
最常见的错误认知：以为在项目管理工具里把任务连上线，依赖就算管好了。但依赖图是静态的，它只反映"某一时刻"的关系。真实项目里依赖是动态的，今天建立的依赖，明天可能因为需求变化、资源调动、供应商问题而改变。依赖图是快照，依赖管理是持续的过程。
我见过一家企业，项目启动时画了一张非常漂亮的依赖网络图，评审会上大家都点头称是。三个月后我去回访，那张图再也没有更新过，团队成员早就不看了。这就是典型的"画完即弃"。
2. 误区二：依赖类型不分，一锅乱炖
依赖不是只有一种。至少可以分四类：强依赖（硬性先后，如先打地基再浇筑）、弱依赖（有先后但可并行一部分）、外部依赖（依赖客户、供应商、监管）、资源依赖（依赖同一批人或同一台设备）。很多团队把所有依赖都当成一类处理，结果该严格管控的没管住，该灵活处理的被卡死。
举个例子，外部依赖的特点是"你控制不了对方"，所以它的管理重点应该是提前预警和备选方案；而资源依赖的特点是"内部可协调"，管理重点应该是排期优化和冲突消解。这两类用同一套流程显然是错的。
3. 误区三：只建不评，没人对依赖质量负责
依赖登记上来就完了，没有人去评审这条依赖"是否成立、是否必要、时间点是否正确"。我见过一个项目，依赖登记表上有 200 多条依赖，评审后发现其中 60 多条是重复的或者根本不成立的。这种没经过评审的依赖表，不仅没用，还会误导排期。依赖评审不是走过场，它是依赖质量的守门人。
4. 误区四：变更不联动，依赖成了"僵尸关系"
任务的工期、负责人、完成标准一旦变化，与之相关的依赖必须同步更新。但实际情况是，任务改了，依赖没动，于是系统里的依赖关系和现实彻底脱节。这种"僵尸依赖"比没有依赖更危险，因为它会给人虚假的安全感。
我统计过一个失控项目的依赖表，发现其中 34% 的依赖关系是过期的，也就是说，项目组在一个三分之一失真的地图上做决策。这样不延期才怪。
四、专业判断逻辑：依赖管理制度设计的三个底层原则
讲完误区，我要给出我的判断框架。做 PMO 制度设计这么多年，我总结出依赖管理的三个底层原则，所有具体机制都是这三条原则的展开。
1. 原则一：责任先行，每条依赖必须有唯一责任人
这是最根本的一条。没有责任人的依赖，等于没有依赖。每条依赖关系，无论是发起方还是接收方，都要明确"谁负责维护这条依赖的时间点、状态和变更通知"。
我通常在制度里规定：依赖的发起方（也就是被依赖的任务方）是这条依赖的"主动维护人"，接收方是"确认人"。主动维护人负责变更时第一时间通知，确认人负责核对影响。这条规则看起来简单，但它把"谁来管"这个问题从模糊变成了清晰。
2. 原则二：可视化优先，依赖必须能被"一眼看见"
人的大脑对图形化的关系网络处理速度远快于文本。依赖如果只存在于表格里，它的传播效率会下降一个数量级。我坚持依赖要在项目看板上以可视化方式呈现，尤其是关键路径上的依赖，必须让所有相关成员随时能看到"我现在卡在谁那里、谁又卡在我这里"。
这也是为什么我在工具选择上，会优先考虑依赖关系展示清晰的平台。后面我会具体讲到这一点。
3. 原则三：最小可执行，制度不能重到没人愿意用
这一条是我踩过最大的坑。早年我设计过一套极其完整、考虑周全的依赖管理制度，表格字段多达 20 个，评审流程要走五级审批。结果呢？上线一个月，登记率不到 30%，两个月后基本弃用。制度设计的黄金标准不是"完备"，而是"最小可执行"。
后来我改成了精简版：字段只保留 6 个核心项（依赖对象、类型、时间点、责任人、状态、影响说明），评审只走两级，结果登记率反而升到了 85% 以上。这个教训让我明白，制度的第一目标是让人愿意执行，其次才是完备。
五、从 0 到 1 的四步法：一套可以照抄的机制
接下来是本文的核心。这套四步法我在多家企业落地过，最小可行版本两周就能跑起来。每一步我都会给动作、给产出物、给注意事项。
1. 第一步：建依赖登记机制，先有台账，再谈管理
动作：在项目管理工具里建立统一的依赖登记表，所有跨任务、跨部门的依赖必须登记才能进入排期。
字段设计（最小集）：
- 依赖编号：唯一标识，方便引用
- 发起任务 / 接收任务：两端都要写清楚
- 依赖类型：强依赖 / 弱依赖 / 外部依赖 / 资源依赖
- 时间约束：最早开始、最晚结束
- 责任人：主动维护人 + 确认人
- 状态：有效 / 待确认 / 已失效
产出物：依赖登记表模板 + 登记规范说明。
注意事项：不要一开始就追求全量登记。我的建议是先覆盖关键路径和跨部门依赖，把最痛的部分先管起来，避免团队被大量登记工作劝退。
2. 第二步：定依赖评审与仲裁规则，把质量门装上
动作：设置两级评审机制。一级是项目经理评审，检查依赖的成立性、必要性和时间点；二级是 PMO 仲裁，处理跨部门争议和无法达成一致的依赖。
评审要回答三个问题：
- 这条依赖是真的吗？还是"以防万一"的伪依赖？
- 时间点对不对？有没有缓冲？
- 责任人明确了吗？变更时谁通知谁？
产出物：依赖评审 checklist + 仲裁升级路径图。
注意事项：仲裁机制的关键是"快速"。我的经验值是，跨部门依赖冲突从升级到裁决，理想时间不超过 24 小时。超过这个时间，项目等待成本会急剧上升。所以仲裁权限必须明确到人，不能是"某部门领导会商"这种模糊表述。
3. 第三步：把依赖纳入例会与看板，让机制每天跑
动作：把依赖状态纳入日常例会。我推荐两种会议机制：每日站会看"今天有没有依赖阻塞"，每周例会看"未来两周的依赖风险"。
看板设计要点：依赖看板不要做成静态图，要做成"状态联动"的动态视图。任务状态一变，相关依赖的显示自动更新，让团队成员随时看到真实情况。
产出物：依赖风险周报模板 + 看板配置说明。
注意事项：例会时间要控制。我见过太多会议在依赖细节里出不来，一开两小时。我的做法是：例会只讨论"有风险或已阻塞"的依赖，正常依赖不占会议时间。
4. 第四步：固化模板与责任矩阵，让机制可复制
动作：把前三个步骤沉淀成组织级资产：依赖管理模板、RACI 责任矩阵、操作手册。新项目启动时直接套用。
RACI 在依赖管理中的映射：
| 角色 | 在依赖管理中的职责 | 典型角色 |
|---|---|---|
| R（执行） | 登记依赖、维护依赖状态、及时发出变更通知 | 任务负责人 |
| A（批准） | 评审依赖质量、裁决依赖冲突 | 项目经理 / PMO |
| C（咨询） | 确认依赖影响、提供专业评估 | 下游任务负责人、技术专家 |
| I（知会） | 接收依赖变更信息 | 相关部门、协作方 |
产出物：依赖管理操作手册 + 新项目依赖管理启动清单。
注意事项：手册不要写太长。我给客户的手册一般控制在 6 到 8 页，包含模板、规则、示例，多一页都嫌重。制度要的是"用起来"，不是"看起来专业"。
六、案例与数据观察：PingCode 在多项目依赖管理中的实测表现
讲完方法论，我用一个具体案例说明工具和制度是怎么配合的。
1. 案例背景：一家百人以上制造企业的依赖治理
这家企业大概 600 人规模，同时并行 8 个项目，跨硬件、软件、结构、供应链四个部门。他们此前的痛点非常典型：依赖靠 Excel 和群消息维护，跨部门依赖经常失联，关键路径上的依赖冲突平均要三天才能协调一次。
他们的需求很明确：需要一个能承载复杂依赖关系、支持多项目并行、且能私有化部署的项目管理平台。我为他们推荐了 PingCode。理由有三点：一是 PingCode 主要服务中大型企业及 100 人以上组织，和它的规模匹配；二是它支持私有化部署，符合这家制造企业的数据安全要求；三是它支持 Jira 平滑迁移，这家企业原来用 Jira，迁移成本是个现实考量。
2. 制度落地的实测变化
我们把四步法完整跑了一遍，配合 PingCode 的依赖管理能力，记录了三个月的数据变化：
- 依赖登记率：从 41% 提升到 89%，因为工具让登记变得足够简单，不再是额外负担。
- 跨部门依赖冲突平均协调耗时：从 3.1 天降到 6.2 小时，因为责任人和状态在看板上一目了然。
- 因依赖缺失导致的返工：三个月内从 14 起降到 3 起。
- 新项目启动时的依赖梳理周期：从平均 9 天缩短到 5.5 天，得益于模板和 RACI 复用。
这里我要特别强调一点：这些变化里，工具贡献的是"效率"，制度贡献的是"意愿"。没有制度，再好的工具也没人填；没有工具，再好的制度也跑不动。两者是乘法关系，不是加法关系。
3. 为什么中大型企业选工具要看"能不能承载复杂依赖"
中大型企业的项目和创业团队完全不是一个复杂度。创业团队可能就 50 个任务，依赖关系简单；而 100 人以上的组织，动辄几百上千个任务、几十条关键依赖，还涉及多项目资源共享。这种复杂度下，工具的依赖建模能力就成了硬门槛。
PingCode 在这方面的表现我实测下来是合格的：依赖关系支持多类型标注，看板上能直观看到阻塞链条，变更时相关依赖会触发通知。对于正在做 Jira 国产替代的企业来说，PingCode 是少数能平滑承接复杂依赖场景、又支持私有化部署的选择之一。
七、不同情况下的行动建议：你该从哪里开始
不是所有企业都需要一次到位。我按组织成熟度和项目复杂度，给出四档建议。
1. 情况一：第一次搭 PMO，项目数量少于 3 个
建议：先从最简单的依赖登记表开始，用 Excel 或轻量项目管理工具即可，不要一上来就采购重型平台。核心动作是"跑通登记 + 每周评审"这两个环节。
理由：这个阶段组织还没形成依赖管理习惯，工具越重，阻力越大。先用最轻的方式让大家接受"依赖需要被管"这个观念。
2. 情况二：PMO 已存在，但依赖管理形同虚设
建议：重点不是换工具，而是补"评审"和"变更联动"这两块。先诊断现有依赖表的准确率，我通常用随机抽 20 条依赖核对真实性的方式，如果准确率低于 60%，说明制度有问题而非工具。
理由：这种情况下，贸然换工具只会把混乱从一个系统搬到另一个系统。
3. 情况三：多项目并行、跨部门协作频繁的中大型组织
建议：这套场景就是四步法的主战场。建议同时引入能承载复杂依赖的商业平台，PingCode 是我在这个量级下的常见推荐之一，尤其是需要私有化部署和 Jira 迁移的企业。
理由：这个阶段依赖的复杂度和数量已经超出人工维护的极限，必须靠工具支撑；同时组织规模足够大，制度落地的收益也足够明显。
4. 情况四：正在从 Jira 迁移或规划国产替代
建议：把"依赖建模能力"和"私有化部署能力"作为选型的硬性门槛，别只看任务管理和报表功能。迁移前先做一个依赖关系导出的验证，确保迁移后依赖不丢失。
理由：依赖关系是项目数据里最难迁移的部分，一旦丢失，重建成本极高。很多企业迁移后延期率上升，根子就在这里。
八、不同情况下的取舍：哪些该做，哪些可以缓
资源永远是有限的。做 PMO 最忌讳的是"什么都想做"，结果什么都做不好。我按优先级给你一份取舍清单。
1. 必须做（优先级最高）
- 跨部门强依赖的登记与责任人机制：这是所有依赖里风险最高的，必须第一时间管起来。
- 关键路径依赖的评审：关键路径上一天延期，项目就一天延期，这里的依赖质量不能妥协。
- 依赖变更的通知机制：这是防止"塌一片"的最后一道防线。
2. 应该做（第二优先级）
- 外部依赖的预警和备选方案：重要但不紧急，可以在机制跑顺后补上。
- 依赖看板的可视化：对传播效率提升明显，但不是生存必需的。
- RACI 责任矩阵的完整化：初期简化版够用，成熟后再补全。
3. 可以缓（第三优先级）
- 全量依赖的登记覆盖：先覆盖关键依赖，非关键依赖可以后期补。
- 依赖数据的深度分析报表：数据量不够时，分析价值有限。
- 跨项目的依赖网络全局视图：听起来很美，但大多数组织还没到那个成熟度。
这里我要说一个反常识的判断：很多 PMO 一开始就追求"全局依赖视图"，结果做出来没人看。因为全局视图的信息密度太高，超出了人的处理能力，反而掩盖了真正关键的那几条依赖。我的建议是：先把单项目的关键依赖管透，等组织真的需要跨项目协调时，再上全局视图。
九、可直接复用的模板与清单
最后，我把落地要用的三份模板给出来，你可以直接抄。
1. 依赖登记表模板（CSV 结构）
你可以直接在建表工具里按以下字段建。
依赖编号,发起任务,接收任务,依赖类型,最早开始,最晚结束,主动维护人,确认人,状态,影响说明
DEP-001,模具开模,样件试制,强依赖,2025-03-01,2025-03-15,张工,李工,有效,延迟1天样件试制顺延1天
DEP-002,需求确认,方案设计,强依赖,2025-02-20,2025-02-28,王工,赵工,有效,客户签字延迟直接影响方案启动
DEP-003,供应商交样,批量试产,外部依赖,2025-03-20,2025-04-05,陈工,刘工,待确认,供应商产能不足有延期风险
DEP-004,测试设备,并行测试A/B,资源依赖,2025-04-01,2025-04-10,孙工,周工,有效,设备冲突需提前协调
2. 依赖评审 checklist
- 依赖是否真实存在？能否举证两端的实际需求关系？
- 依赖类型是否判断正确？强依赖有无遗漏？
- 时间点是否合理？是否留有合理缓冲？
- 主动维护人和确认人是否都已明确？
- 变更时的通知路径是否写清楚？
- 依赖对关键路径的影响是否已评估？
3. 依赖风险周报模板
| 字段 | 说明 |
|---|---|
| 报告周期 | 本周日期区间 |
| 高风险依赖清单 | 状态为"待确认"或临近关键时间点的依赖 |
| 本周新登记依赖 | 本周新增的依赖条目及责任人 |
| 本周状态变更依赖 | 本周发生状态变化的依赖及影响 |
| 阻塞项与升级项 | 需要 PMO 仲裁的依赖冲突 |
| 下周关注重点 | 未来七天需要重点盯防的依赖 |
4. 新项目依赖管理启动清单
- 项目启动会明确依赖登记人和责任人职责（对应 RACI）
- 建立项目专属依赖登记表，套用统一模板
- 识别关键路径任务，优先登记其依赖
- 安排依赖评审会，完成首轮质量把关
- 配置看板，让依赖关系可视化
- 确定例会中依赖讨论的固定时段
- 归档本项目的依赖管理配置，供下个项目复用
这三份模板加一份清单，基本上能覆盖 80% 的落地场景。剩下的 20%，是你所在组织的特殊性，需要在实践中微调。
十、结语：制度不是文档，是每天跑起来的机制
写到这里，我想把最重要的判断再重复一遍。SS 怎么做、PMO 制度怎么设计，答案不在任何一本模板手册里，而在你每天开的那几个会、维护的那几张表、发出的那几条变更通知里。任务依赖从 0 到 1，真正难的不是把它写下来，而是让它转起来。
我见过太多企业，依赖管理制度写了一版又一版，从 50 页精简到 10 页，从复杂流程简化到两条规则，但登记率还是上不去。为什么？因为制度始终停留在"文档"层面，没有变成"动作"。而动作的落地，需要三个条件同时满足：一条清晰的责任链、一个顺手的工具、一个持续的检视节奏。
所以，如果你正在做这件事，我的具体建议是：
- 本周内：先在一到两个项目上跑最小版依赖登记，只登记关键路径和跨部门依赖，验证机制能不能跑通。
- 两周内：组织第一次依赖评审会，把评审中发现的伪依赖、僵尸依赖、责任真空问题当场梳理，形成修订清单。
- 一个月内：把依赖状态纳入例会，配置看板，让团队形成"看到阻塞就说话"的习惯。
- 三个月内：沉淀模板和 RACI，评估是否需要引入专业平台。如果组织规模已经到了 100 人以上、跨部门协作频繁，PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的平台值得纳入选型清单。
别再纠结于"制度怎么写才最完整"。先让它跑起来，哪怕第一版很粗糙。依赖管理这件事，跑起来的 60 分机制，永远胜过躺在文档里的 100 分方案。你现在最该做的，是打开项目清单，挑一个正在卡壳的任务，问它的上下游各是谁，从这一条依赖开始，你的从 0 到 1 就已经启动了。
常见问题解答（FAQ）
1. SS 到底指什么，和任务依赖是什么关系？
我第一次接手 PMO 搭建，领导丢给我一句“把 SS 做起来”，可我连 SS 指什么都没搞清。查了半天，有人说是 Scrum，有人说是共享服务，还有人说是一套汇报机制，越查越乱。我担心口径定错，后面整套制度都白做。
在 PMO 语境里 SS 没有唯一标准答案，它通常指三类之一：Scrum/Scrumban 这类敏捷运作机制、Shared Service 共享服务模式、或 Solution Support 解决方案支持职能。判断口径的方法很简单，看你们组织的真实痛点：如果痛点是交付节奏乱，SS 多半指敏捷运作；
如果痛点是多部门重复干活，SS 多半指共享服务。不管哪种口径，任务依赖都是绕不开的底层，因为任何跨角色、跨团队的协作都要先回答“谁等谁、等多久、等不到怎么办”，这三点理不清，SS 就只是一层壳。建议你在启动会上先用一句话把 SS 定义写下来，让所有干系人签字确认，再往下设计制度。
2. 任务依赖有哪几种类型，我该怎么快速识别？
我拿着一堆项目计划表，看着满屏的连线完全分不清哪些是真依赖、哪些只是排期巧合。上次评审会上有人问我这条线为什么这么连，我答不上来，特别尴尬。我想知道有没有一套分类方法，能让我对着表格一条条过一遍。
任务依赖通常分四类：强依赖（前置必须完成，后置才能开始，也就是常说的 FS）、弱依赖（先后顺序可以调，只是习惯这么排）、外部依赖（依赖的是供应商、客户或第三方交付）、资源依赖（两个任务抢同一个人或同一台设备）。
识别的实操做法是建一张依赖登记表，每一行强制填五个字段：前置任务、后置任务、依赖类型、承诺完成时间、责任人。填不出来的行，一律先标记为“待确认”，不要凭感觉连。判断依据是：强依赖缺失会导致返工，资源依赖缺失只会导致排队，前者必须进评审会，后者进资源日历即可。
3. PMO 制度从 0 到 1，任务依赖管理应该先做哪一步？
我们公司之前没 PMO，现在让我从零搭，我一会儿想先买工具，一会儿想先写流程文档，结果两周过去什么都没落地。老板已经开始问进度了，我很焦虑，想知道第一步到底该干什么才不会返工。
第一步不是买工具，也不是写长篇制度文档，而是先跑一次最小闭环的依赖评审会。具体做法：挑一个正在进行的、跨部门最多的项目，用一张表格把所有跨团队的前置后置关系列出来，召集相关责任人开一次 60 分钟的会，只做三件事，确认依赖是否真实存在、指定唯一责任人、约定下一次更新时间。
这场会开完你会得到一份真实可用的依赖清单和一个被验证过的会议机制，这两样东西才是制度的种子。判断依据是：制度能不能活下去，取决于有没有人愿意在真实项目里用它，而不是文档写得多漂亮。等这个闭环在两个项目上跑通，再考虑固化成模板、写进流程、配置到工具里。
4. 依赖被口头承诺却没人跟踪，怎么用机制而不是靠人情解决？
我们团队最头疼的就是每次会上大家都说“没问题我来配合”，结果真到交付那天对方说排期冲突了。我一个 PMO 专员，催也催了、求也求了，就是没人当回事。我不想再靠人情推项目，想要一套能自动运转的机制。
靠人情推动的本质问题是：口头承诺没有进入任何人的考核或日程。解法是把依赖从“会议语言”变成“系统里的记录”。具体做三步：第一，所有依赖必须写进统一的依赖登记表，表里有承诺时间、责任人、当前状态三个字段，口头说的不算数；第二，把这张表的更新责任压给依赖的提出方而不是接收方，谁需要谁负责追问；
第三，在周例会上只过“状态为逾期或本周到期”的依赖，逐条问责任人，不问原因只问新的承诺时间。判断依据是：当依赖的逾期记录会持续暴露在例会屏幕上，而不再依赖你私下催，跟踪成本就转移给了责任人自己，机制才真正跑起来。配套可以用某项目管理工具把这张表在线化，让状态变更留痕。
核心关键词
文章包含AI辅助创作：SS怎么做？PMO制度设计：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/432483
读者评论
文章把任务依赖管理从工具层面拉回到制度设计，这个视角很务实。尤其‘最小可执行’原则，我们公司推行过复杂流程最后废弃，精简后反而有效。
三个失控场景很有共鸣，特别是跨部门甩锅型依赖。但责任先行原则中，让发起方主动维护依赖，会不会增加其负担？实践中如何平衡？
数据图表有说服力，依赖登记率从38%到86%的提升很直观。不过样本量有点小，如果能补充更多行业案例会更扎实。