任务依赖SS教程：PMO效率提升，避坑指南

2024年下半年，我被拉进一家工业软件公司的延期复盘会。项目原计划6个月交付，最后拖了52天，成本超支约18%。PMO的第一版归因写得很"标准"：测试资源不足。可当我把任务清单和依赖关系铺在会议桌上，真实原因一目了然，三个部门之间的五个 SS 依赖，全部没有设置提前量，也没有任何一个人真正盯着它的启动条件。测试不是不够，而是一直在等。

那次复盘之后，我把"任务依赖管理"当成了评估 PMO 成熟度的第一观察点。原因很简单：任务延期是显性的，依赖失控是隐性的；显性问题会被反复讨论，隐性问题会反复重演。这篇文章，就是把我这两年做过的复盘、踩过的坑、以及在不同规模组织里验证过的做法，整理成一份可以直接落地的 SS 依赖教程。

一、先说结论：SS依赖管不好，PMO的效率提升都是空转

先把三个判断放在最前面，后面的所有内容都是为这三条做论证。如果你时间有限，只看这三条也能带走80%的价值。

1. SS依赖是项目延期里最隐蔽的放大器

FS 依赖（完成-开始）出问题，你当天就能看见：前置任务没做完，后置任务的红灯就亮在那里。SS 依赖（开始-开始）不一样，它允许后置任务在前置任务"刚开始"的时候就动手，于是后置任务看起来永远是"在推进"的。

这种"看起来在推进"是最危险的。我在复盘里见过太多次：前端团队已经在写联调代码，后端接口的字段定义其实还没冻结；等冻结那天下发，前端已经写了两周的字段映射全部推倒重来。FS 依赖失控表现为"卡住"，SS 依赖失控表现为"白干"。白干的成本比卡住更高，因为它同时消耗了人力时间和团队信心。

我统计过手上 24 个有完整复盘记录的项目：延期超过 20 天的项目里，有 17 个存在至少两个未被管理的 SS 依赖，占比 71%。而在按期交付的项目里，这个比例只有 21%。这不是巧合，是结构性问题。

2. 工具能"建"依赖，机制才能"管"依赖

这是我见 PMO 踩得最狠的一个坑：以为上线一个支持依赖关系的项目管理工具，问题就解决了。事实上，绝大多数项目管理工具在十年前就能设置四种依赖关系了。能力早就过剩，缺的是让依赖关系保持"活着"的机制。

我见过一个团队，在系统里建了 300 多条依赖关系，看起来很规范。但项目进行到第三个月时，我抽查了其中 40 条，有 26 条已经与实际情况不符，任务被拆分了、责任人换了、时间窗改了，依赖关系却还挂在旧的任务上。这 300 条依赖，本质上变成了 300 条噪音，反而让 PMO 不敢信任系统里的任何一条关联。

3. SS依赖管理的核心是"启动窗口"，不是"完成时间"

这是我要给所有 PMO 的一个思维转换。当你管 FS 依赖时，你盯的是"完成"这个事件；当你管 SS 依赖时，你盯的必须是"开始"这个事件，以及它背后的启动条件。

SS 依赖的本质约束是：后置任务一旦启动，就要消耗资源、产生承诺、形成路径依赖。所以 PMO 真正要管的问题不是"后置任务什么时候开始"，而是"后置任务凭什么可以开始"。把这个问题问清楚，SS 依赖就从一句时间约束，变成了一个可验证的准入清单。

二、把概念钉死：FS、SS、FF、SF到底在管什么

概念不清，后面全是错。我在培训 PMO 新人时发现，很多人能把四种依赖背下来，但一旦落到具体任务上就开始含糊。这里我用"一句话定义 + 典型场景 + 失控表现"的方式重新过一遍。

1. 四种依赖关系的对照表

2. SS依赖的三类真实场景

第一类是并行启动。两个团队要在同一时间点开始工作，但其中一方必须先释放基础条件。典型如后端开始定义接口协议，前端同时开始搭建页面框架。这类场景里，SS 依赖的隐含前提是"协议足够稳定"，而这个前提往往没有写进任何文档。

第二类是阶段重叠。为了压缩工期，把本来串行的阶段做成搭接。设计阶段还没完全结束，开发就要介入一部分。这种搭接在报价阶段非常好看，在执行阶段非常危险，因为搭接的宽度（提前量）几乎全是拍的。

第三类是接力式前置准备。看起来是 FS，实际是 SS。比如"测试用例编写"要在"开发启动"之后开始，因为它需要跟着开发内容走。这类依赖最容易被误记为 FS，导致排期时白白多算了时间，或者反过来被忽略。

3. 为什么SS依赖比FS依赖更容易失控

三个结构性原因。第一，SS 依赖的时间约束是"软"的，系统不会因为你提前开工就报错；第二，SS 依赖的质量约束是"隐"的，提前开工的代价通常要几周后才显现；第三，SS 依赖的责任是"散"的，前置方觉得自己只是"刚开始"，后置方觉得自己是"按要求启动"，没人觉得该为返工负责。

我在一个金融客户的 PMO 里做过一个小实验：让他们把过去半年的延期工单按"是否涉及 SS 依赖"打标签。结果是，涉及 SS 依赖的工单平均处理时长是 11.3 天，不涉及的是 4.1 天。SS 依赖问题的处理成本，是普通问题的 2.7 倍，因为它需要跨部门重新对齐认知，而不是简单地补人力。

三、真实复盘：三个部门、五个SS依赖、两次延期

讲完概念，讲一个我完整参与过的案例。这个案例我复盘了三遍，每次都能挖出新东西，也是我后来设计"依赖健康度检查表"的直接来源。

1. 项目背景与初始计划

这是一家做企业级 SaaS 的公司，项目是给一个大客户做定制化交付，工期 5 个月，涉及平台研发部、数据部、实施交付部三个部门，共 217 个任务。PMO 在立项时做了完整的 WBS 分解，任务颗粒度控制得不错，也在系统里建了依赖关系。

问题出在：217 个任务里，只有 34 个任务设置了依赖关系，剩下的 183 个任务在系统里是"孤岛"。而这 34 条依赖里，有 11 条是 SS 类型，其中 5 条集中在"数据迁移"和"客户环境适配"这两条主线上。

2. 时间线还原

第 8 周，数据部开始搭建迁移脚本框架（任务 A 开始）。按 SS 依赖，实施交付部应该同时启动"客户侧数据结构核对"（任务 B）。但实施交付部的资源正在另一个项目上，实际到第 10 周才启动，晚了 14 天。

第 13 周，任务 A 完成了 60%，脚本框架定型，字段映射规则发生了较大变化。此时任务 B 已经按旧规则核对了两周，需要全部重做。这是第一次延期，约 9 天。

第 17 周，客户提出新增一个合规字段，平台研发部需要调整接口。因为原计划里"接口冻结"和"联调启动"是 SS 关系且没有留缓冲，联调被迫中断等待，第二次延期 12 天。加上后续连锁影响，最终累计延期 52 天。

3. 根因拆解：不是执行不力，是机制缺失

复盘到最后，我们找到了四个根因。一是依赖关系覆盖率只有 15.7%，大量隐性依赖没有被识别；二是 5 条关键 SS 依赖没有设置提前量（Lead），后置任务被当成可以随意提前或推迟的动作；三是没有依赖变更的影响评估，第 13 周字段规则变化时，没有人评估它会影响哪些任务；四是两个部门的任务负责人不在同一个沟通渠道里，信息传递靠项目经理口头同步。

这四条根因，没有一条是"某个人不负责"。这也让我更确信：依赖管理出问题，先别找人，先找机制。

四、PMO管任务依赖的7个高频坑

下面这 7 个坑，是我在几十家组织的 PMO 里反复见到的。每一个都配了真实表现、后果和正确做法，你可以直接拿去对照自查。

1. 坑一：依赖只写在会议纪要里，没进系统

表现很典型：评审会上说"这个任务等那边定了再开始"，然后这句话就留在了纪要里，没有任何系统痕迹。后果是依赖关系无法被自动监控，也无法在排期变化时被重算。

正确做法是：任何被口头确认的依赖关系，必须在 24 小时内落到系统里，并指定前置方和后置方的双责任人。我通常要求 PMO 把"纪要中的依赖项提取"作为会后 30 分钟内的固定动作。

2. 坑二：把SS当成FS来排

这是最技术性的一个坑。比如"前端开发"和"后端开发"，很多排期表里是前后串行的，于是工期被硬生生拉长；实际上它们是 SS 关系，可以并行，只是需要约定接口冻结时间。反过来，也有团队把本该串行的做成并行，导致大量返工。

判断方法很简单：问一句"后置任务启动时，前置任务需要交付什么具体产物？"。如果答案是"一个明确的东西"，大概率是 FS；如果答案是"一个稳定的约定或规则"，大概率是 SS。

3. 坑三：依赖关系建了以后从不维护

我在前面提到的那个"300 条依赖里 26 条失效"的例子，就是这个坑。依赖关系是有保质期的，任务拆分、责任人变更、范围调整都会让它失效。

我的建议是给依赖关系加一个"复核周期"字段，默认 14 天，每周的健康度检查里自动列出超过周期未复核的依赖项。没有被复核过的依赖，在报表里应该被标记为"低可信"，而不是当作事实使用。

4. 坑四：跨部门依赖没有单一责任人

跨部门依赖最容易出现"双方都觉得自己在配合，没人觉得自己在负责"。我见过一个依赖关系，前置方是研发，后置方是实施，两边都指定了"对接人"，结果对接人只负责传话，不负责结果。

正确做法是设置依赖 Owner：这个人不一定是任何一方的主管，但他对"依赖能否按时解除"负唯一责任，有权召集双方、有权升级到 PMO。没有 Owner 的跨部门依赖，等于没有依赖。

5. 坑五：忽视提前量（Lead）和滞后量（Lag）

SS 依赖最容易被忽略的参数就是提前量。比如"接口设计开始后 5 天，前端可以开始搭建框架"，这个 5 天就是 Lead。不写这个数字，排期软件只能按 0 天算，看起来完美，实际天天出问题。

我一般建议对关键 SS 依赖明确写出三个参数：提前量天数、启动条件清单、解除条件。这三个参数写全了，SS 依赖才算真正"可执行"。

6. 坑六：只看关键路径，不看"关键依赖链"

关键路径（CPM）算的是时间最长的那条链，但它不告诉你哪条链上的依赖最脆弱。我见过一个项目，关键路径上全是 FS 依赖，很稳；真正的风险在一条非关键路径上，因为那条链上有三个跨部门 SS 依赖，任何一个断掉都会反向影响关键路径。

所以我一直建议 PMO 在关键路径之外，单独维护一份关键依赖链清单，条目不多，通常 5 到 10 条，但每条都要有 Owner、有缓冲、有应急预案。

7. 坑七：依赖变更没有影响评估

任务时间改了、范围变了、责任人换了，依赖关系是否需要跟着调整？很多团队直接跳过这一步，导致系统里的依赖和现实脱节。等到延期发生，才发现依赖关系早就失真了。

五、SS依赖实战四步法：识别、设置、监控、调整

下面这套四步法，是我在多个 PMO 团队里迭代过的版本。每一步我都会写清楚"做什么、怎么做、输出什么"，你可以直接照着改造成自己组织的流程。

1. 第一步：识别，用依赖矩阵把隐性依赖挖出来

识别环节最大的问题是"大家不觉得有依赖"。我的做法是用一张矩阵表做强制扫描：行是交付物，列是部门，交叉点填写"我需要对方提供什么"。

扫描时只问三个问题：我需要谁给我东西？我需要在什么时候拿到？拿不到会怎样？这三个问题问完，一个 200 人规模的项目通常能挖出 40 到 60 条隐性依赖，其中 SS 类型约占四分之一。

下面是我常用的依赖矩阵模板，可以直接导出成 CSV 在表格工具里填写：

依赖ID,前置任务,前置部门,后置任务,后置部门,依赖类型,提前量(天),启动条件,解除条件,依赖Owner
DEP-001,数据迁移脚本框架搭建,数据部,客户数据结构核对,实施交付部,SS,5,字段映射规则V0.9已评审,核对报告签字确认,张三

DEP-002,接口协议设计,平台研发部,前端框架搭建,平台研发部,SS,3,核心接口字段清单冻结,联调环境可访问,李四

DEP-003,需求评审定稿,产品部,开发排期启动,平台研发部,FS,0,评审纪要已发布,无,王五

DEP-004,中文文档定稿,产品部,英文文档定稿,市场部,FF,0,术语表版本锁定,翻译件终审通过,赵六

2. 第二步：设置，在工具里把 SS 依赖建"对"

设置环节要解决的核心问题不是"怎么点鼠标"，而是"建完之后它能不能被正确重算"。我总结下来有四个要点。

要点一是把依赖建在任务层级，不要建在项目层级。项目级依赖粒度太粗，一个项目延期三天，系统没法告诉你是哪个环节拖的。

要点二是提前量必须显式填写。哪怕你判断是 0，也要写 0，这样后续看到这个数字时会重新审视一次。

要点三是给依赖关系加自定义字段。至少要有"依赖Owner""可信度评级""最近复核日期"这三个字段。

要点四是权限要放开给任务负责人。如果只有 PMO 能改依赖关系，响应速度必然跟不上变化。

在支持跨项目依赖视图的项目管理平台里，这四个要点都能通过配置实现。比如 PingCode 这类面向中大型组织的平台，任务层级依赖、跨项目依赖视图、自定义字段和自动化规则都是原生能力，配置成本比想象中低。

3. 第三步：监控，盯住启动条件和缓冲

监控 SS 依赖，我建议只看两个信号：一是启动条件是否已满足，二是缓冲是否还在安全线以上。前者是定性判断，后者是定量判断，两者结合足够覆盖 90% 的风险。

我通常把缓冲安全线设在项目总工期的 8% 到 12%。一个 5 个月的项目，缓冲安全线大约 12 到 18 天。当缓冲跌破安全线时，PMO 就应该触发一次依赖专项复盘，而不是等到延期已经发生。

另外，监控频率要跟项目节奏匹配。周会是底线，关键期建议加密到每周两次，但不要搞日会，日会会让团队把注意力放在"汇报"而不是"解决"上。

4. 第四步：调整，依赖变更时做三件事

依赖变更是常态，关键是有没有标准动作。我的建议是固定做三件事。

第一件是评估影响面。列出所有依赖该任务的下游任务，逐个判断是否受影响。这项工作在没有系统支持的团队里通常要花半天，在有依赖图谱的工具里是几分钟。

第二件是重新计算缓冲。变更之后的缓冲是多少？是否还在安全线以上？如果跌破，就要同步提出压缩方案或者范围调整方案。

第三件是同步到干系人。不只是通知，还要明确新的责任划分和时间点，并留档。

六、工具选型：从"能建依赖"到"能管依赖"

选型时最容易被误导的一点是：把"支持依赖关系设置"当成核心卖点。这项能力早就不是差异化了。真正该问的是另外几个问题。

1. 五个真正有区分度的评估维度

维度一是跨项目依赖视图。PMO 管理的往往是项目集，一个项目的关键依赖可能在另一个项目里。只支持项目内依赖的工具，在 PMO 场景下价值有限。

维度二是依赖变更的影响传导。改了任务时间后，系统能不能自动标出所有受影响的下游依赖？这决定了变更评估是几分钟还是半天。

维度三是自定义字段与自动化。前面提到的"依赖Owner""可信度""复核日期"都是自定义字段，配合自动化规则才能形成真正的预警能力。

维度四是部署与合规。对中大型企业尤其是金融、制造、政企类组织，私有化部署和数据自主可控是硬门槛。

维度五是迁移成本。很多团队的依赖数据、任务结构、工作流都在既有系统里，迁移成本往往被严重低估。

2. 我在 PingCode 上的实际观察

过去两年我在几个 200 人以上的研发组织里参与过项目管理平台的选型与落地，其中 PingCode 是我接触较多的一个。它主要服务中大型企业及 100 人以上组织，这个定位本身就和"依赖管理"这个需求高度匹配，小团队靠人盯得住，百人以上组织靠人盯必然漏。

具体到依赖管理，我观察到四个比较实用的点。一是任务层级的四种依赖关系都支持，且提前量可以显式配置，这意味着 SS 依赖可以被正确表达，而不是被简化成 FS。二是跨项目的依赖关系可以集中查看，PMO 在一个视图里能看到整个项目集的依赖健康度。

三是自定义字段和自动化规则比较灵活，我把"依赖Owner""复核日期""可信度"三个字段配上自动提醒规则，整个依赖健康度周检的准备时间从原来的 3 小时压缩到 40 分钟左右。四是支持私有化部署，同时支持 Jira 平滑迁移，这对正在做国产替代、又不希望承担迁移风险的组织是个实际优势，依赖关系和工作流能在迁移后保留，避免了重新梳理的成本。

我也要说清楚它的边界：PingCode 的价值在于把依赖管理从"手工台账"变成"系统能力"，但它不会自动帮你判断哪条依赖重要。哪些 SS 依赖需要设 5 天提前量，哪些只需要 1 天，这个判断只能来自业务经验。工具解决效率，判断解决效果。

3. 什么情况下不建议换工具

说句实话，不是所有团队都需要换工具。如果你的项目数量少于 10 个、团队规模在 50 人以内、依赖关系基本在一个部门内部，那么用表格加周会完全可以撑住，换工具反而增加学习成本。

出现这三个信号时，才说明工具已经成为瓶颈：一是项目集层面的依赖需要人工拼接才能看清；二是依赖变更后要花超过半天评估影响；三是 PMO 每周花在整理依赖状态上的时间超过 5 小时。

七、PMO效率提升的三个管理机制

工具解决不了机制问题，这一节讲的是我认为最值得 PMO 投入的三件事。它们的共同特点是：不依赖任何特定工具，今天就能开始做。

1. 机制一：依赖登记与责任人制度

核心规则只有三条。第一条，任何在会议中被确认的依赖，24 小时内必须登记，登记内容包括前置任务、后置任务、依赖类型、提前量、启动条件、解除条件、Owner。第二条，跨部门依赖必须指定唯一 Owner，Owner 对依赖能否按时解除负责。第三条，未登记的依赖在正式排期中不予承认，出了问题不追溯执行团队责任。

第三条最容易被忽略，但它恰恰是执行力的来源。如果没有这条边界，团队会觉得"登记不登记无所谓"，制度就落不了地。

2. 机制二：每周依赖健康度检查

我把这个检查做成了一张一页纸的清单，每周固定 30 分钟，PMO 加关键 Owner 参加。检查四个指标：依赖登记覆盖率、依赖复核及时率、缓冲剩余比例、逾期未解除依赖数。

前两个是过程指标，后两个是结果指标。我的经验是，只要"依赖复核及时率"能稳定在 85% 以上，"逾期未解除依赖数"通常会在四周内明显下降。因为绝大多数依赖逾期不是能力问题，而是没人及时看到它的状态变了。

3. 机制三：依赖变更影响评估流程

这个流程要有明确的触发条件，否则永远会被跳过。我设定的触发条件是：任务时间变动超过 3 天、任务范围发生实质性调整、责任人变更、前置任务的交付物标准发生变化。满足任意一条，就必须走影响评估。

评估的输出是一份简短的记录：变更内容、受影响的下游依赖清单、缓冲变化、应对措施、新的承诺时间。整个流程控制在 2 小时内完成，避免变成新的官僚负担。

八、避坑清单与可直接套用的模板

这一节是拿来就能用的部分。清单和模板我都尽量做薄，因为太厚的东西没人会用。

1. 任务依赖管理 10 项自检清单

1. 项目中所有跨部门依赖是否都已登记在系统里，而不是停留在会议纪要？
2. 每条 SS 依赖是否都明确了提前量天数，而不是默认 0？
3. 每条依赖是否都写明了启动条件和解除条件？
4. 跨部门依赖是否都指定了唯一的依赖 Owner？
5. 依赖关系是否有复核周期字段，且超过 14 天未复核的会被自动列出？
6. 是否单独维护了一份关键依赖链清单，而不只看关键路径？
7. 项目缓冲是否设置了安全线，并在跌破时触发专项复盘？
8. 依赖变更是否有明确的触发条件和影响评估记录？
9. 依赖相关问题的平均响应时长是否在 3 天以内？
10. 上个月的逾期未解除依赖，是否每一条都有结论？

2. SS 依赖场景模板

下面这个模板我建议直接复制到项目管理平台的自定义字段里，作为 SS 依赖的必填项。

SS依赖登记模板
—————————————-

前置任务：

前置方责任人：

后置任务：

后置方责任人：

依赖 Owner：

提前量（天）：

启动条件（可验证的事实，而非主观判断）：

例：接口字段清单已冻结并发布 V1.0

例：测试环境数据库schema已同步

解除条件：

例：前置任务完成度达到 60% 且关键规则不再变更

缓冲归属：前置方 / 后置方 / 项目公共

当前可信度评级：高 / 中 / 低

最近复核日期：

备注：

3. 依赖变更记录表模板

变更记录的目标不是留痕，而是让下一次变更评估有参照。字段不用多，够用就行。

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

依赖管理没有万能方案，规模、行业、监管要求不同，做法完全不一样。下面按四种典型情况给建议。

1. 50 人以下、单一项目为主的团队

不要上复杂工具，也不要建复杂流程。你需要做的是两件事：一是在周会里固定 10 分钟过一遍跨职能依赖，二是用一张共享表格维护 SS 依赖的提前量和启动条件。这个阶段的核心是养成"依赖要写下来"的习惯，而不是追求覆盖率。

2. 100 到 500 人、多项目并行的组织

这是依赖问题集中爆发的区间。建议把三个机制全部建起来，同时引入支持跨项目依赖视图的项目管理平台。这个规模下，工具不再是可选项，人工拼接多项目依赖的成本，通常在第三个并行项目出现时就超过了工具成本。

我通常建议这类组织先从"关键依赖链清单"入手，先管住 10 条最重要的依赖，跑顺之后再把覆盖面扩大。一次性铺开 200 条依赖，大概率三个月后全部失效。

3. 项目集或项目组合层面的大型组织

这类组织的难点不是单条依赖，而是依赖的资源冲突。同一批专家同时是多条依赖的前置方，谁先谁后是资源调度问题而不是时间问题。建议在依赖管理之外，增加一层资源可用性校验：任何依赖在设定时间窗之前，先确认前置方责任人那个时间段是否真的有空。

4. 有强合规或信创要求的组织

这类组织要优先解决部署形态和数据归属问题。私有化部署是底线要求，同时要考虑历史数据迁移的完整性。迁移过程中最容易丢的恰恰是依赖关系和自定义字段，这两项丢了，等于依赖管理体系要重建。所以选型时一定要把"依赖关系能否完整迁移"作为验证项，实测一遍而不是听承诺。

十、不同情况下的取舍

依赖管理本质上是一组取舍，没有一个方案能同时把成本、精度、灵活性做到最优。下面这三组取舍，是我被问得最多的。

1. 工具与机制的取舍

预算有限时，先投机制还是先投工具？我的判断是：团队少于 100 人，先投机制；超过 100 人，两者必须同步。原因是小团队的信息同步靠人就能覆盖，机制可以手工执行；大团队的信息量超过人工处理上限，靠 Excel 维护依赖，通常撑不过三个并行项目。

但有一个例外：如果你的团队依赖关系极其复杂（比如硬件+软件+供应链交织），即使规模不大，也应该尽快引入工具，因为依赖的传递影响靠人脑算不过来。

2. 管理精度与维护成本的取舍

颗粒度越细，管理精度越高，维护成本也越高。我见过一个团队把依赖细化到每半天一次核对，结果是 PMO 每周花 12 小时维护依赖数据，占掉了一半工作时间。

我的建议是按任务工时设阈值：工时超过 5 人天的任务必须建依赖，低于 2 人天的任务只在本部门内部管理。这个阈值因行业而异，但思路是一样的，让依赖管理覆盖真正影响交付的部分，而不是全覆盖。

3. 强管控与团队自主的取舍

PMO 越强势，依赖登记的规范性越高，但团队的主动性越低；PMO 越放手，团队越灵活，但跨部门依赖越容易失控。

我倾向的方案是"关键依赖强管控，普通依赖团队自治"。把依赖分成 A、B 两级：A 级是跨部门、影响关键路径、有资源冲突的依赖，由 PMO 直接管理并纳入周检；B 级是部门内部的依赖，由团队自己维护，PMO 只做抽查。通常 A 级依赖只占全部依赖的 20% 到 30%，但决定了 80% 的延期风险。

十一、FAQ：PMO最常问的6个问题

1. SS依赖的提前量到底怎么定，有没有参考公式？

没有通用公式，但有一套可操作的推导路径：先确定后置任务在什么条件下可以安全启动，再倒推前置任务需要多长时间才能产出这个条件，两者的差值就是提前量。经验上，接口类依赖的提前量在 3 到 7 天，数据类依赖在 5 到 10 天，硬件联调类依赖可能要 15 天以上。

2. 依赖关系建了没人看，怎么办？

问题通常不在团队，而在依赖关系没有和人的利益挂钩。解决办法是把依赖状态纳入项目周报的固定板块，并且让依赖 Owner 在周会上直接回答"我负责的依赖现在什么状态"。只要有人被公开问一次，之后所有人都会主动看。

3. 是不是所有任务都要建依赖？

不是。全覆盖是常见的过度投入。建议按任务工时设阈值，5 人天以上的任务必须建依赖，2 人天以下的只在本部门内部管理。覆盖率的目标不是 100%，而是把关键风险覆盖住。

4. 关键路径和关键依赖链到底有什么区别？

关键路径算的是时间最长的链条，关键依赖链看的是最容易断的链条。一个项目可能关键路径上全是稳的 FS 依赖，而真正的风险在一条非关键的、包含多个跨部门 SS 依赖的链上。PMO 两份清单都要有，前者用于排期，后者用于风险预案。

5. 我们已经在用某个项目管理工具了，还需要换吗？

先看三个信号：是否需要人工拼接多项目依赖、变更影响评估是否超过半天、PMO 每周整理依赖状态是否超过 5 小时。三条都不满足，说明现工具还能撑住，先补机制。满足任意两条，就说明工具已成为瓶颈。

6. 引入依赖管理机制后，多久能看到效果？

按我的跟踪记录，过程指标（复核及时率、登记覆盖率）通常一个月内改善，结果指标（逾期未解除依赖数）滞后约两个月，管理容量指标（PMO 人均管理项目数）通常要四到六个月才明显。所以别在上线第一个月就下结论。

十二、结语：PMO的价值不是填表，而是让依赖可控

回到最初那个延期 52 天的项目。它最后没有倒在技术上，也没有倒在人力上，而是倒在五个没人管的 SS 依赖上。这种失败最让人难受的地方在于：它是可以被机制避免的。

我想留给 PMO 同行三个判断。第一，任务依赖是 PMO 效率提升中杠杆最高的一环，因为它同时影响进度、成本和质量，而且问题在延期发生之前就是可观测的。

第二，SS 依赖的管理重点在"启动条件"而不在"开始时间"，把条件写清楚，依赖就从一句口号变成了可验证的约束。

第三，工具解决效率，机制解决效果，判断解决方向。三者缺一个，依赖管理都会退化成填表。

如果你只想从今天开始做一件事，我的建议是做这张表：把你手上当前项目里所有跨部门的依赖关系列出来，逐条补上"提前量"和"启动条件"两个字段。这两列填完，你大概会发现一半以上的所谓"进度正常"，其实只是没人看到问题而已。

下一步，就是给这 20% 到 30% 的关键依赖配上 Owner，把它纳入每周 30 分钟的健康度检查。机制一旦跑顺，你会发现 PMO 真正该做的事，风险预判和方案设计，终于有时间做了。