SS最佳实践：项目负责人任务依赖入门指南，常见问题

去年Q4，我陪一家做智能硬件的客户做版本复盘。固件比计划晚了11天上线，会议室里第一反应几乎都是"开发不给力"。但我把项目计划里的依赖图导出来逐条比对后发现，真正的问题出在两处 SS（Start-to-Start，开始-开始）依赖上：结构件打样和应用层联调被设成了同时启动，可前者实际比后者晚了两周才具备条件；测试团队则被安排"等开发完成再开始"，白白空转了6天。11天延期里，至少有8天是依赖关系配置错误造成的，而不是谁的执行力问题。

这件事之后，我给自己带项目的团队定了一条规矩：排期之前，先把依赖关系跑一遍，跑不通就不排。这篇内容就是把这套方法完整写下来，它既覆盖 SS 这种具体依赖类型的最佳实践，也覆盖项目负责人在任务依赖管理上会遇到的通用问题。

需要先说明语境。在项目管理术语里，SS 是四种基本依赖关系之一，和 FS、FF、SF 并列。但很多团队口语里的"SS"其实是泛指"任务依赖体系"（Schedule Sequence）。为了避免歧义，本文标题里的 SS 统一指 Start-to-Start 开始-开始依赖，同时把整个任务依赖体系一并讲清楚。如果你所在团队对 SS 另有定义，按你们的语境替换即可，方法层面是通用的。

一、先给结论：任务依赖管理的六条核心判断

很多文章会把"什么是任务依赖"作为开头，然后开始堆定义。我不打算这么做，因为项目负责人真正缺的不是定义，而是判断标准。先把结论给出来，后面再用场景和案例逐条展开。

1. 依赖是约束，不是排期

这是我在带项目时反复纠正的第一个认知偏差。排期回答的是"这件事什么时候做"，依赖回答的是"这件事凭什么能做"。前者是时间问题，后者是条件问题。把这两个问题混在一起，就会出现"时间填得很漂亮，但根本没有可执行条件"的计划。

我见过最典型的场景是：计划表里每个任务都有人名、有起止日期、有进度百分比，看起来非常完整。但一问"这个任务依赖谁交付什么"，负责人答不上来。没有依赖定义的排期，本质上是一份愿望清单。

2. SS 是并行任务的对齐器，不是提前开工的许可证

SS 依赖的原始含义是：任务 B 的开始时间不能早于任务 A 的开始时间，或者两者需要同步开始、按固定节奏并行推进。它的价值在于让两条必须同步的流水线保持节奏一致。

但在实际使用中，SS 经常被当成"提前开工许可"：为了压缩总工期，把本来应该串行的事情改成并行，用一条 SS 依赖把两个任务强行拉齐。结果是两条流水线都启动了，但其中一条长期在等另一条的中间产出，最后变成"并行不协同"，反而比串行更慢。

3. 依赖数量要控制在任务数的 1.5 到 2 倍之间

这是我从自己带过的十几个中大型项目里总结出来的经验区间。任务和依赖的数量比有一个健康范围：太少说明依赖漏标了，太多说明过度建模。

我做过一次统计，当依赖数超过任务数的 2.5 倍时，计划的可维护性会明显下降，每周更新计划需要额外投入 2 到 4 小时，而且团队开始不信任这张图。反过来，当依赖数低于任务数的 0.8 倍时，跨团队交付的延期率会显著上升，因为大量隐含依赖没有被显性化。

4. 跨团队依赖必须同时绑定"交付物"和"责任人"

跨团队依赖失控的根因，通常不是对方不配合，而是依赖被描述得太模糊。"等后端接口"不是一个依赖定义，"等后端交付用户鉴权接口 v1 文档，责任人张工，最迟 3 月 14 日"才是。

我的经验是：跨团队依赖里，交付物的可验收程度，直接决定这条依赖的可控程度。凡是无法验收的交付物描述，最终都会变成扯皮。

5. 循环依赖必须在计划阶段消除，不能拖到执行阶段

循环依赖指 A 依赖 B、B 依赖 C、C 又依赖 A 的情况。它在纸面上很容易被忽略，因为每条依赖单独看都合理。但一进入执行，整个链条会同时停摆。

我坚持的做法是：计划评审会上专门花 15 分钟跑一次循环检测。人工检查很慢，但工具通常有自动检测能力，前提是你把所有依赖都录进去了。

6. 依赖关系要有明确的变更机制，而不是谁都能改

依赖关系是整个计划的骨架，不是随手可调的参数。如果一个任务的依赖可以被任何成员随时删除或修改，那这张计划图就失去了约束力。我的做法是：普通任务变更由项目负责人确认，跨团队依赖变更必须走一次简短的同步会。

二、四种依赖关系：项目负责人必须分清的最小知识集

要谈 SS 的最佳实践，必须先把它放回四种依赖关系的坐标系里。我见过不少项目负责人能背出四种类型的名字，但在真实场景里选错类型，导致整个排期逻辑走偏。

1. FS（完成-开始）：最常用，也最容易被滥用

FS 的含义是：前置任务完成后，后续任务才能开始。它是默认依赖类型，也是直觉上最容易理解的。写完接口文档才能开始写测试用例，这是 FS。

FS 之所以容易被滥用，是因为它最"安全"，加上 FS 永远不会出错，只会把工期拉长。我在一个中台项目里见过极端案例：一条主链路上串了 34 个 FS 依赖，从需求评审到上线排了 5 个月，而同类项目的历史均值是 3 个月。逐条检查后发现，其中 11 条依赖完全可以改成并行或 SS 关系，只是当初没人愿意花时间判断。

FS 的使用原则在我看来很简单：只有当前置任务的产出物是后续任务的必要输入时，才用 FS。如果只是"习惯上先做这个"，那就不是 FS。

2. SS（开始-开始）：并行任务的对齐器

SS 的含义是：后续任务的开始时间不能早于前置任务的开始时间，两者需要同步启动。它最常见的适用场景是两个必须同步推进、且共享节奏的工作流。

举个例子：芯片流片和配套的驱动开发。驱动开发不能等流片完成才开始，否则时间来不及；但驱动调试又必须基于真实样片。这种情况下，驱动开发的部分工作可以和流片并行，用 SS 依赖保证两者从同一个时间基准启动，再配合滞后量（Lag）控制具体节奏。

SS 最关键的参数是滞后量。没有滞后量的 SS 依赖，等于要求两条流水线完全同步，多数情况下这并不现实。滞后量的作用是：允许后续任务在前置任务开始后延迟一段时间再启动，或者要求两者保持固定的时间差。

3. FF（完成-完成）：需要同时收尾的场景

FF 的含义是：前置任务完成时，后续任务也必须完成，或者后续任务的完成时间不能早于前置任务。它适用于必须同步结束的工作。

典型场景是文档与代码：功能代码合入主分支的同时，配套的技术文档必须同步完成，否则发布流程走不下去。这里用 FF 比用两个独立的 FS 更准确，因为它约束的是"同时结束"而不是"先后关系"。

4. SF（开始-完成）：用得极少，但要知道它存在

SF 的含义是：后续任务只有在另一个任务开始后才能完成。这是四种类型里最罕见的一种，典型场景是交接类工作，新流程启动后，旧流程才能正式关闭。

我个人的经验是，SF 在大多数软件项目里几乎用不到。但项目负责人需要知道它存在，因为一旦遇到交接类场景，用错类型会让整个逻辑变得别扭。

上表里的百分比是我在多个项目依赖图里统计得到的粗略分布，不是行业标准。它的作用是给你一个参照：如果你的项目里 SS 依赖占比超过 30%，大概率存在过度并行的问题。

三、项目负责人在 SS 依赖上反复翻车的四个误区

讲完四种类型，可以进入本文的核心：SS 在实际使用中到底会怎么翻车。下面四个误区，是我在复盘会上见过次数最多的，每一个都有具体的症状和代价。

1. 把 SS 当成"提前开工许可"

这是最高频的误区，也是最贵的一个。为了压缩总工期，负责人会把本该串行的两个任务改成并行，然后用一条 SS 依赖把它们"合法化"。

问题在于：并行只是让开始时间提前了，并没有让前置条件提前具备。后续任务开工后长期处于"半等待"状态，人员在两件事之间来回切换，切换成本吃掉了一部分收益，最终交付时间可能比老老实实串行还晚。

我在一个数据平台项目里见过量化结果：原本设计的 3 组 SS 并行，实际执行中后置任务平均有 47% 的工时花在等待和返工上。改成串行并适度压缩后置任务范围后，总工期反而缩短了 9 天。

2. 加了 SS 依赖，却不设滞后量

这是最隐蔽的误区。没有滞后量的 SS 依赖，语义上要求两条流水线完全同步开始。当一方有条件、另一方没有条件时，这个依赖就成了装饰品，看着有，实际不生效。

我的判断标准很直接：凡是涉及不同专业、不同团队的 SS 依赖，都应该显式设置滞后量。滞后量可以是正数（延迟启动），也可以是负数（提前启动），关键是让它反映真实节奏。

3. SS 依赖没有绑定交付物和验收标准

FS 依赖天然带交付物，因为"前置完成"就必须有产出物。SS 依赖没有这个天然约束，所以特别容易变成"我们俩一起开始"，但没说清楚"一起推进到哪一步算对齐"。

我建议的做法是：每条 SS 依赖都标注一个同步节点，例如"双方各自完成设计初稿"或"双方完成环境联通测试"。这个节点就是这条依赖的验收点，没有节点，依赖就无法评估健康状况。

4. 用 SS 依赖掩盖资源冲突

这种情况通常发生在人手不足的团队。同一个工程师被安排在两件并行任务上，为了在计划里说得通，给两者加了一条 SS 依赖。看起来是并行推进，实际是这个人在两件事之间频繁切换。

资源冲突是资源问题，不是依赖问题。用依赖关系去包装资源冲突，只会让问题更难被发现。正确的做法是把资源约束单独标出来，让它在计划评审时被看见。

四、我的依赖识别清单：从任务列表到依赖网络

知道误区在哪之后，下一个问题是怎么系统性地把依赖识别出来。我用了几年时间迭代出一套四步清单，每接一个新项目都会跑一遍，通常能在两到三小时内完成中等规模项目的依赖梳理。

1. 第一步：以交付物为单位列任务，而不是以动作为单位

很多任务列表的问题在于它们描述的是动作而非产出。"开发登录模块"是动作，"登录模块可交付版本 v1"是交付物。依赖关系建立在交付物之上，因为只有交付物才能被传递、被验收、被等待。

我的具体操作是：把原有任务列表逐条改写，确保每个任务都有一个可描述的产出物。改完之后通常会发现，原来的任务数量虚高了两到三成，因为有些"任务"其实是同一个交付物的不同动作。

2. 第二步：对每个交付物问三个问题

这三个问题贯穿全文，也是我自己带项目时的核心判断框架：

1. 谁需要这个交付物？，找出下游任务。如果没人需要，这个任务可能可以被砍掉或降优先级。
2. 什么时候需要？，确定依赖的时间约束。是必须在某个节点前交付，还是只要有就行，两者对应不同的依赖类型。
3. 拿不到会怎样？，判断依赖强度。如果拿不到就无法推进，是强依赖；如果只是体验打折，是弱依赖。

第三个问题尤其重要。我在项目里会把依赖分成强、中、弱三档：强依赖必须在计划里显式建模；中依赖标注但不强制约束；弱依赖只做记录，不进入关键路径计算。如果所有依赖都被当成强依赖，关键路径会被严重拉长，计划也会失去重点。

3. 第三步：标记外部依赖和跨团队依赖

外部依赖指不由本项目团队控制、且不受项目负责人直接管理的交付物，例如第三方接口、外部供应商、兄弟部门资源。这类依赖的风险特征和内部依赖完全不同。

我的做法是给每条外部依赖标注三个属性：对接人、交付承诺日期、承诺的确定程度。确定程度分三档，已书面确认、口头承诺、口头意向。只有"已书面确认"的依赖才能进入关键路径，另外两档必须准备备份方案。

4. 第四步：跑一次循环检测和路径检测

把所有依赖录进去之后，跑两个检测：循环依赖检测和关键路径计算。循环依赖检测是为了发现逻辑闭环，关键路径计算是为了知道哪条链最紧。

这两个检测人工做会很慢，工具通常都能自动完成。我的经验是：如果一个团队还没把依赖录进系统，说明他们的依赖管理还停留在口头阶段。

依赖识别清单（可复制使用）
任务层面

□ 每个任务是否都有可描述的交付物？

□ 交付物是否有明确的接收方？

□ 是否有任务其实可以合并或删除？

依赖层面

□ 每条依赖的交付物是否具体可验收？

□ 依赖类型是否明确（FS / SS / FF / SF）？

□ SS / FF 依赖是否设置了滞后量或同步节点？

□ 依赖强度是否标注（强 / 中 / 弱）？

外部依赖层面

□ 外部依赖是否标注了对接人和承诺日期？

□ 承诺确定程度是否记录（书面 / 口头 / 意向）？

□ 高不确定依赖是否有备份方案？

结构层面

□ 是否存在循环依赖？

□ 关键路径是否已计算？

□ 依赖总数与任务总数的比值是否在 1.5-2 倍之间？

五、一个真实案例：120 人研发组织的依赖重构

前面讲的都是方法和判断，这一节给一个完整的案例，说明这套方法在真实组织里跑起来是什么样。

1. 项目背景和初始状态

客户是一家做企业级 SaaS 的公司，研发组织约 120 人，分为 6 个研发小组加 1 个平台组。项目是核心产品的架构升级，计划周期 5 个月，涉及 4 个团队协作。

我第一次看到他们的计划表时，第一感受是"看起来很完整"：约 380 个任务，全部有人名、日期、进度。但把依赖关系导出来后，只有 90 多条依赖，任务与依赖比约 1:0.24，远低于健康区间。也就是说，绝大多数任务在计划里是孤立的。

2. 重构过程和具体动作

我们花了大约三周时间做了四件事。第一周做交付物改写，把 380 个任务压缩到 240 个，每个任务都有明确产出物。第二周跑三问法，识别出 430 条依赖，其中强依赖 168 条、中依赖 187 条、弱依赖 75 条。

第三周做外部依赖标注。这个阶段暴露的问题最多：共有 34 条外部依赖，其中只有 11 条有明确的书面确认，另外 14 条是口头承诺，9 条只是口头意向。这 9 条里后来有 4 条实际未能按时交付。

同期，我们把依赖结构迁移到了一个国产项目管理平台，PingCode。选择它的原因主要有三点：一是组织规模在 100 人以上，需要支持多项目、跨团队的依赖视图；二是他们有私有化部署的合规要求，这一点是硬约束；三是团队此前用的是 Jira，迁移成本是重要考量，PingCode 提供了相对平滑的迁移路径。

迁移过程中有一个细节值得说：Jira 里的依赖关系字段和 PingCode 的建模方式不完全一致，尤其是 SS 和 FF 类型的历史数据，需要人工核对一部分。我们最后是采用"历史项目只读迁移、新项目全新建模"的策略，避免把旧结构的问题带到新体系里。

3. 重构后的效果观察

项目最终比原计划提前 6 天完成。更重要的是过程中几个可量化的变化。

跨团队阻塞的平均处理时间从原来的 3.2 天缩短到 1.1 天，因为阻塞点在图上是可见的，每天站会直接看依赖视图就能定位。计划变更的评审时间从平均每次 90 分钟降到 35 分钟，因为依赖结构清晰后，变更影响面可以快速算出来。

最关键的一个指标是延期任务的占比：重构前三个月的历史数据是 27%，重构后的执行阶段降到 12%。这个数字包含了所有原因导致的延期，不只是依赖问题，但我认为依赖显性化是其中贡献最大的因素。

六、工具层面的 SS 依赖怎么配

方法讲完，落到工具。这一节讲的是依赖在系统里怎么落地，包括类型配置、跨项目依赖、以及选型时的几个判断点。

1. 依赖类型必须能显式配置，而不是只支持 FS

这是选型时最容易被忽略的一条。很多轻量工具只支持"阻塞关系"这一种语义，也就是只有 FS。如果你的项目里存在大量并行场景，这种工具会让你无法准确表达 SS 和 FF。

我的检查方式是：在试用阶段就建两个任务，尝试配置 SS 和 FF 依赖，看系统是否支持滞后量参数。如果滞后量不可配置，说明这个工具只能做简单串行建模，不适合复杂研发项目。

2. 跨项目依赖的能力决定了你能不能用它管多团队协作

组织规模超过 100 人之后，项目往往不是单个项目，而是项目集。这时依赖关系会跨项目存在：A 项目的任务需要 B 项目的交付物。如果工具只支持项目内依赖，跨项目协作就只能靠人工同步，风险很高。

在评估时我会重点看三个能力：能否跨项目建立依赖、跨项目依赖能否在甘特图上统一展示、跨项目依赖变更时能否自动通知相关方。第三点最容易被忽略，但它直接决定了依赖变更能不能被及时响应。

3. 私有化部署与迁移成本：中大型组织的两个硬约束

对于 100 人以上的组织，尤其是金融、制造、政企类客户，私有化部署经常是硬性合规要求。这一点在选型早期就要确认，不要等实施阶段才发现不满足。

另一个常被低估的是迁移成本。如果团队已经在用某一款项目管理工具，历史数据里的依赖关系、任务结构、自定义字段都会影响迁移复杂度。实际迁移时，通常建议历史项目做只读归档，新项目重新建模，而不是追求完全无损迁移。因为旧结构本身可能就存在问题，迁移反而会把问题固化。

4. 依赖变更的自动化提醒比可视化更重要

可视化的价值是让问题被看见，自动化的价值是让问题被主动推送。当一条跨团队依赖的交付日期发生变更时，系统能否自动通知下游任务的责任人，直接决定了响应速度。

我倾向于在配置时给所有强依赖开启变更提醒，中弱依赖只做记录不提醒。这样既保证了关键路径的响应速度，又不会让团队被无关通知淹没。

七、常见问题：项目负责人最常问的八个问题

这一节回答我在咨询和培训中被问得最多的八个问题。每个问题按"症状，原因，动作"的结构展开，动作部分尽量具体到找谁、说什么、记录什么。

1. 出现循环依赖了怎么办

症状：三个任务互相等待，整条链停摆，站会上没人能说清该谁先动。

原因：通常是需求拆分粒度过粗，或者某一方把"依赖输入"和"依赖反馈"混为一谈。

动作：第一步，把循环链上的三个任务重新拆分，找出真正的最小交付单元。第二步，判断是否存在"可以先给一个不完整版本"的可能，大多数循环依赖可以通过先交付一个可用的简化版本来打破。第三步，把处理结论记录下来，在下次计划评审时作为案例。

2. 依赖方延期了，项目负责人能做什么

症状：上游任务延期，下游整条链跟着延，负责人只能被动通知"再等等"。

原因：依赖没有提前的风险缓冲，也没有备份路径。

动作：立即判断该依赖是强依赖还是中弱依赖。如果是强依赖，评估能否拆出一个可以先行推进的子任务；如果不能，立刻升级沟通，明确新的交付时间和影响范围，并同步给所有受影响的下游。关键是不要等，依赖延期的第一天是处理窗口，第三天就只剩追责了。

3. 跨团队依赖推不动，怎么升级沟通

症状：对方团队口头答应，但排期一直往后推，问进度就回复"在做了"。

原因：依赖没有绑定明确的交付承诺和验收标准，也没有进入对方团队的正式计划。

动作：把依赖转成对方计划里的一个明确任务，有负责人、有交付日期、有产出物。如果对方没有把这个任务纳入自己的计划，说明依赖还没有真正成立。依赖是否进入对方计划，是判断它是否有效的最直接标准。

4. 依赖关系频繁变更，怎么控制影响

症状：每周都有人改依赖，计划图三天一变，团队不再信任它。

原因：依赖变更没有分级，所有变更都走同样的流程，或者都不走流程。

动作：建立变更分级：关键路径上的依赖变更需要项目负责人确认并同步相关方；非关键路径的依赖变更由任务责任人自行调整，但需在周报中记录。这样既控制了关键风险，又避免了流程过重。

5. 工具里画了依赖，但没人看怎么办

症状：依赖图做得很完整，但只有项目负责人一个人看，团队依然靠口头同步。

原因：依赖图没有进入团队的日常节奏。

动作：把依赖视图纳入每日站会的固定环节，只讲一件事：今天有没有被阻塞、有没有阻塞别人。通常三分钟就够。坚持两周后，团队会自然养成看依赖的习惯。不是依赖图没用，是它没有出现在团队每天都会看的地方。

6. SS 依赖的滞后量该设多少

症状：知道要设滞后量，但不知道数值怎么定。

原因：滞后量缺乏历史数据支撑，容易凭感觉设置。

动作：第一版按经验给，通常取前置任务预期时长的一部分作为初始值，然后在执行两周后根据实际情况校准。我自己的做法是每两周回看一次 SS 依赖的实际节奏，把偏差记录下来，下一个项目就有参照了。

7. 任务数量太多，依赖根本标不完怎么办

症状：项目有几百个任务，逐条标依赖耗时太长，团队抵触。

原因：任务粒度太细，把依赖管理做成了登记工作。

动作：只在关键层级标依赖，不必细化到每个子任务。通常标到"可独立交付的工作包"层级就足够了，一个工作包内部的依赖可以由责任人自行协调。依赖管理要覆盖的是团队之间的接口，不是每个人自己的操作步骤。

8. 小团队也需要这么复杂的依赖管理吗

症状：团队只有十几个人，觉得依赖管理是大组织的事。

原因：把依赖管理等同于复杂流程。

动作：小团队可以极简化，只做三件事：列出关键交付物、标出跨人依赖、每天站会同步阻塞。不需要完整的四步法，也不需要工具支持。但即使只有 10 个人，如果存在跨职能协作，依赖被显性化的价值就已经存在了。

八、不同场景下的取舍：没有一套通用做法

前面所有方法都需要根据场景裁剪。这一节给出三类典型场景的取舍建议，你可以对照自己团队的情况做调整。

1. 20 人以下团队：轻量化，重节奏

小团队的核心矛盾是人力紧、沟通成本低。这种情况下，依赖管理应该做到最轻：只维护一份关键交付物清单，标出跨人依赖，每天站会用三分钟同步阻塞。

不建议做的事：不建议引入复杂的依赖建模工具，也不建议做完整的循环依赖检测。人少的时候，一次面对面沟通比任何系统提醒都快。

需要坚持做的事：关键交付物必须写下来，口头承诺要落到共享文档。这是小团队最容易偷懒、也最容易在规模扩张时付出代价的地方。

2. 20 到 100 人团队：结构化，重接口

这个规模是依赖管理真正开始产生价值的区间。跨职能协作频繁，但还没有复杂到需要项目集管理。

建议做的事：完整跑一遍四步依赖识别清单，把依赖录进系统，建立变更分级机制，把依赖视图纳入周会。这个规模下，工具的跨项目能力可能还用不上，但依赖类型完整度和变更提醒是必要的。

取舍点在于：是否需要专职的项目管理支持。我的经验是，超过 50 人且同时并行三个以上项目时，配备一名专职项目管理人员能明显降低依赖失控的概率。

3. 100 人以上组织：体系化，重治理

到了这个规模，依赖管理不再是单个项目负责人的事，而是组织级的能力。需要统一的建模规范、统一的工具平台、统一的变更流程。

这个阶段选型要考虑的就不只是功能，还包括私有化部署能力、历史数据迁移路径、跨项目依赖的支持程度。像 PingCode 这类面向中大型组织的国产项目管理平台，在这几个维度上通常会有针对性设计，对于有国产替代和合规要求的组织是一个可评估的选项。

需要警惕的是过度治理。我见过一些组织把依赖管理做成了审批流程，每条依赖变更都要走三级审批，结果是团队开始绕过系统、在私下沟通。治理的目标是让关键风险可见，不是让所有动作都变慢。

九、下一步：先做这三件事

写到这里，方法、案例、工具、常见问题基本覆盖完了。如果你准备马上动手，我建议不要一次性铺开，先做三件事。

1. 用一小时把当前项目的依赖数出来

不要追求完整，先把手上项目的任务数和依赖数统计出来，算一个比值。如果比值低于 0.8，说明大量隐含依赖没有被显性化，这是最值得优先处理的问题。

这一步的价值在于建立一个基线。没有基线，后面的改进无法衡量。

2. 挑出三条最关键的 SS 依赖做一次校准

找出项目里所有的 SS 依赖，挑出其中影响最大的三条，逐条检查：有没有滞后量、有没有绑定交付物、有没有明确同步节点。三条改完，你就能感受到差异。

选三条而不是全部，是因为改动需要沟通成本，小范围试点更容易获得团队支持。

3. 把依赖视图放进下一次站会

这是最简单也最有效的一步。把依赖关系图投到站会屏幕上，让每个成员说一句"我今天有没有被阻塞、有没有阻塞别人"。坚持一周，你会发现有些问题在变成延期之前就被提出来了。

最后回到本文的核心判断：项目负责人的第一责任不是排期，是让依赖可见。排期是把时间填进表格，依赖管理是让每个"等"字都有明确的对象、条件和期限。前者看起来专业，后者才真正决定项目能不能按时交付。

SS 依赖之所以值得单独拿出来讲，是因为它是四种依赖类型里最容易被误用的一种。它给了你并行的可能，但也要求你对节奏有更精确的掌控。用好了，它是压缩工期的工具；用不好，它只是把等待藏得更深了一点。