SS怎么做？企业管理者协同管理：任务依赖从0到1

上周一早上九点，我在一家做智能硬件的公司旁听他们的项目周会。项目经理打开排期表，指着三条并排的进度条说：结构件调试卡住了，因为固件还没冻结；固件没冻结，因为射频方案还没定；射频方案没定，因为供应商的样品上周五才到。三条任务、三个负责人，谁都没有偷懒，但整条链路空转了十一天。

会后我问了一句话：你们排期表里，有没有任何一条线是明确写着"射频方案一定，固件立刻同步启动"的？会议室安静了几秒。答案是：没有。所有人都是靠每周一次的会去"对齐"，而不是靠一条被写下来的依赖关系去驱动。

这就是本文要解决的问题。SS依赖（Start-to-Start，开始-开始）不是一种排期术语，它是管理者把"串行等待"改造成"并行推进"的唯一开关。从0到1搭建任务依赖体系，最难的从来不是画图，而是先承认：你的团队里绝大多数"卡住"，本质上是依赖关系没有被显式设计出来。

一、先把结论说清楚：SS不是"等别人开始"，而是"设计一个同时启动的触发器"

很多管理者一听到SS依赖，第一反应是"哦，就是等别人开始了我再开始"。这句话方向对了一半，但错得很危险。如果只是"等"，SS依赖和FS依赖没有本质区别，都是一种被动等待，只不过等待的触发点从"完成"变成了"开始"。

真正的SS依赖，是一条带条件的并行启动指令：只要前置任务进入某个可观察的状态，后置任务就必须按约定启动，而不是等它全部做完。它的价值不在于"排期更漂亮"，而在于把原本串行的两段时间重叠起来，直接压缩项目的关键路径。

1. 一句话讲清SS依赖的判定方式

我习惯用一句话做判定：如果B任务只需要A任务的"开头成果"就能干，那它俩之间就是SS依赖；如果B任务需要A任务的"完整交付物"才能干，那它就是FS依赖。这句话听起来简单，但它在实际项目里能筛掉大量被误建成FS的依赖。

举个例子。做一场线下发布会，"主视觉定稿"和"物料印刷"之间是典型的FS，图没定完，印刷厂没法开机器。但"主视觉定稿"和"邀请函文案撰写"之间就未必是FS：文案只需要知道主视觉的调性和主色，不需要等设计稿的最终像素级调整完成。这两件事可以并行，靠的就是一条SS依赖：主视觉方向一确认，文案同步开写。

2. 为什么管理者要先管SS，而不是先管进度

我见过太多管理者，每天花大量时间在"催进度"上。催的本质是什么？是依赖关系断裂之后的人工补救。当一条依赖被写清楚、被系统化地提醒、被指定了责任人，你就不需要每天去问"你那边怎么样了"。

更关键的是，SS依赖决定了项目的理论上限。一个项目里FS依赖越多，串行链路越长，能被压缩的空间就越小。而SS依赖是唯一可以在不增加人力、不延长工时的前提下，直接把工期压下来的手段。管理者如果不懂SS，就只能靠加班和加人来解决问题，这两个都是成本最高、副作用最大的选项。

3. 从0到1的最小可行动作只有三件

很多企业一上来就想做"完整的依赖管理体系"，买工具、定规范、开培训，三个月过去还在讨论流程。我的判断是：从0到1阶段，管理者只需要做三件事，就能让依赖关系"被看见"。

• 第一件：把最关键的三到五条依赖写下来。不是全部，而是那些一旦断裂就会直接导致延期的。全部梳理是后期的事。
• 第二件：给每条依赖标注类型和触发条件。FS、SS、FF、SF四种里选一种，并把"什么时候触发"写成可观察的事件，而不是"尽快""适时"这种词。
• 第三件：给每条依赖指定一个确认人。注意，不是执行人，是确认人。执行人可以换，确认人必须固定。

二、背景：为什么任务依赖在协同管理里最容易失控

任务依赖这个词，几乎所有管理教材都会讲。但真正在企业里落地得好的团队，我见到的并不多。原因不在于管理者不懂概念，而在于依赖是一种"隐性的、动态的、跨边界的"信息，它天然不适合靠人的记忆去维护。

1. 进度是显性的，依赖是隐性的

任何一个任务，都有明确的负责人、明确的截止日期、明确的完成标准。这三样东西都是显性的，所以它们天然容易被管理。而依赖关系不同：它没有负责人，没有截止日期，只有在断裂的那一刻才会暴露。

更麻烦的是，依赖的断裂往往不会立刻表现为"任务延期"。它会表现为"效率不高""大家都很忙但没产出""开会开了两个小时没结论"。管理者看到的是表象，看不到底下断裂的那根线。这就是为什么很多团队明明很努力，项目还是延期，他们一直在优化显性的东西，而从没处理过隐性的东西。

2. 四种依赖类型，企业里九成的人只会用FS

项目管理里标准的四种依赖关系，我列在下表。你可以对照自己团队的排期表，看看实际用到了几种。

这张表里最值得注意的，是SS和FS的使用比例严重失衡。大量本来可以用SS并行的任务，被默认写成了FS。默认写成FS的结果就是：每一个任务都在等上一个任务"完全做完"，整个项目变成一条超长的串行链。

而串行链的代价是可以算出来的。假设一个项目有8条任务，每条平均5天，如果全部按FS串联，工期是40天；如果其中4条改成SS并行，工期可能压到25天左右。这个差距不是靠加班能补回来的，它只能靠依赖设计补回来。

3. 从0到1的三个阶段：可见、可控、可预测

我在多个团队里反复验证过一条路径：依赖管理不可能一步到位，它必须经过三个阶段。跳过任何一个阶段，体系都会塌。

• 第一阶段"可见"：核心目标是让关键依赖被写下来，被所有人看到。这个阶段的工具可以极其简陋，一张共享表格就够。判断标准是：团队里任何一个人问"我这个任务什么时候能开始"，能立刻得到明确答案。
• 第二阶段"可控"：核心目标是让依赖断裂能被及时发现。这个阶段需要触发条件的自动提醒，需要依赖责任人，需要一套"卡住了找谁"的机制。判断标准是：阻塞从发生到被识别，时间不超过一天。
• 第三阶段"可预测"：核心目标是用历史依赖数据去预判风险。这个阶段需要工具沉淀数据，能回答"哪类依赖最容易断""哪个部门的交付最不稳定"。判断标准是：项目排期时，你能说出这次有几条高风险依赖。

大多数企业卡在第一阶段和第二阶段之间。他们能列出一张依赖表，但表一旦进入执行就没人维护，断裂了也没人发现。这就是典型的"有依赖清单，没有依赖管理"。

三、四个常见误区：我在十几个团队里反复见到的错法

下面这四个误区，是我在做协同管理诊断时出现频率最高的。它们的共同点是：看起来都是小事，但每一个都会让整个依赖体系失去作用。

1. 误区一：把所有依赖都建成FS

这是最普遍的问题，也是最容易被忽略的问题。因为FS依赖"最安全"，等前置任务完全做完再开始，后置任务不会有返工风险。管理者在不确定的时候，本能地会选择最安全的选项。

但安全的代价是工期。当所有依赖都按FS处理，你的项目工期就等于所有任务工期之和，这是一个无法被优化的死局。更糟的是，团队会逐渐习惯这种节奏，认为"本来就要等"，从而彻底放弃并行思考。

2. 误区二：把滞后量当成弹性时间

SS依赖常常需要配一个滞后量（Lag）。比如"开发启动后3天，测试开始介入"，这个3天就是滞后量。问题在于，很多团队把滞后量理解成了"弹性时间"，到了第3天没准备好，就顺延到第5天、第7天，也没人当回事。

滞后量的本质是为了控制返工风险而设定的最小等待时间，不是缓冲。如果开发启动后3天测试还无法介入，说明前置任务的"启动质量"不达标，这本身就是一个需要被暴露的问题，而不是一个可以被宽容的延误。

3. 误区三：依赖关系只存在管理者脑子里

我见过一位技术总监，他能准确说出项目里每一条关键依赖，什么时候该触发，谁该配合。但他从来没有把这张"脑内地图"落到任何文档或系统里。

结果就是：他一休假，项目就乱。他不在会上，依赖断裂就没人发现。依赖关系如果只存在于管理者一个人的脑子里，那它就不是管理资产，而是管理风险。因为它无法传递、无法复盘、无法沉淀，也无法在你不在场的时候继续发挥作用。

4. 误区四：依赖设完不维护，项目一变全乱

依赖关系是有生命周期的。项目范围一变、人员一变、优先级一变，原来的依赖关系就可能失效。但我观察到，绝大多数团队在项目启动时梳理过一次依赖，之后就一直沿用，直到项目结束。

更合理的做法是：把依赖关系的复核，绑定到每一次范围变更和每一次迭代评审上。不是单独开一个会去核对依赖，而是把"这次变更影响哪几条依赖"作为变更评审的固定问题。

四、专业判断逻辑：一个依赖到底该不该用SS

知道了SS的价值，接下来的问题更实际：哪些任务对适合用SS，哪些不适合？我的判断逻辑是三个标准叠加，任何一个不满足，就退回FS。

1. 标准一：并行收益是否大于返工风险

这是第一道门槛。用SS的核心收益是压缩工期，代价是后置任务可能因为前置任务的变化而返工。只有当"压缩的工期"明显大于"可能的返工成本"时，这次SS才是划算的。

举个对比例子。在一个App开发项目里，"登录模块开发"和"登录模块测试用例设计"之间用SS非常划算：测试用例设计即使因需求微调改两轮，成本也就一两天，但并行能省下四五天。反过来，"数据库表结构设计"和"数据迁移脚本开发"之间用SS就很危险：表结构一旦变动，迁移脚本可能要从头写，返工成本远大于并行收益。

2. 标准二：滞后量是否能被观察

SS依赖必须配一个可观察的滞后量。什么叫可观察？就是它能被客观判断，而不是靠感觉。"开发启动后3天测试介入"是可观察的，因为第3天是一个确定的时间点。"等开发做得差不多了测试再进来"就不可观察，因为"差不多"没有标准。

我的经验是：优先用事件作为触发条件，时间作为兜底。比如"接口文档评审通过后，前端开始联调"，这比"开发启动后5天，前端开始联调"更可靠，因为文档评审通过是一个明确的事件。

3. 标准三：责任边界是否清晰

SS依赖天然会产生"接口地带"，前置任务的输出要交给后置任务使用，这个交接点的质量由谁负责？如果责任边界不清晰，SS依赖很容易变成互相甩锅的导火索。

所以我在设计SS依赖时，一定会同时明确两件事：前置方要交付什么最小启动条件，后置方要在多久内反馈启动结果。这两句话写清楚了，SS依赖才能稳定运行。

4. 依赖强度分级：硬依赖、软依赖、外部依赖

除了四种类型，我还会给依赖标一个强度。这个维度在很多教材里没有，但在实操中极其有用，因为它决定了你该花多少精力去管理这条依赖。

这个分级最实际的价值是：让团队知道哪些依赖断了一定要立刻处理，哪些可以观察一下再说。如果所有依赖都被同等对待，团队会陷入"每天都很紧张但没有重点"的状态。

五、从0到1：四步搭建可运行的任务依赖体系

这一节是全文最实操的部分。我把从0到1的过程拆成四步，每一步都有明确的输出物。这套方法我在多个团队里跑过，最快的一次，三个人用一个下午就把一个中型项目的关键依赖理清了。

1. 第一步：列任务清单，只标"谁等谁"

第一步不要想复杂，就是一张表：任务名、负责人、预估工期，加上一列"我等谁"和"谁等我"。注意，一开始不要纠结依赖类型，也不要纠结滞后量，只标清楚谁等谁。

这一步最容易出问题的地方是粒度。粒度太细，一张表几百行没人看得下去；粒度太粗，依赖关系就失去意义。我的经验是：单个任务的预估工期在2到10天之间比较合适。超过10天的任务，说明它还能拆；少于2天的任务，说明它应该合并到相邻任务里。

另一个关键动作是：这一步一定要拉上一线的执行人一起做，而不是管理者关起门来自己填。因为真实依赖往往和排期表上写的不一样，执行人最清楚自己到底在等什么。

2. 第二步：给每条依赖打类型标签

清单出来后，第二步是逐条判断依赖类型。这里有一个我常用的提问技巧：不要问"这是什么依赖"，而问"我最早能在什么时候开始这个任务"。如果答案是"前置任务开始之后就可以"，那就是SS；如果答案是"前置任务彻底做完",那就是FS。

这一步的产出，是你能第一次看到自己项目的依赖类型分布。我在实践中发现，只要认真做这一步，通常会有两到三成的FS依赖被重新识别为SS。这意味着你的项目工期，在这一步就已经被压缩了。

3. 第三步：把触发条件写成可观察的事件

第三步是很多人会跳过的一步，但它是SS依赖能不能真正运行起来的关键。每条SS依赖，都要写清楚一个触发条件，格式是"当X发生时，Y在Z时间内启动"。

我举个例子，把模糊说法改造成可执行说法：

改造前：
前置：接口设计

后置：前端联调

依赖：SS

触发：接口设计差不多了就通知前端

改造后：

前置：接口设计

后置：前端联调

依赖：SS

触发事件：接口文档通过评审（评审通过为唯一触发信号）

滞后量：0天（触发当天即可启动）

启动条件：至少 3 个核心接口的请求/响应示例可用

后置反馈：前端在 2 个工作日内反馈接口可用性

改造后的版本，任何一个人看到都能判断"现在能不能启动"。这就是可观察的价值。

4. 第四步：给每条依赖配一个"依赖责任人"

最后一步，也是最容易被忽略的一步：每条关键依赖都要有一个确认人。注意，这个人和任务的执行人不一定是同一个。他的职责只有一条：在触发条件满足时，确认后置任务确实启动了；在触发条件未满足时，主动发出预警。

我的建议是，依赖责任人尽量选"后置任务的负责人"，因为他是最直接的受益者，也是最敏感的。让他自己去盯前置任务的启动状态，比让管理者去居中协调要高效得多。

六、案例：一个120人研发组织用半年把SS依赖跑通

下面这个案例来自我深度参与的一家做企业级软件的公司，研发组织规模约120人，分四个研发小组，产品迭代周期从两周到六周不等。为了避免为特定产品背书，下文涉及工具的部分只用"某项目管理平台"代称；在实际落地中，他们选择的是PingCode，主要原因是PingCode服务中大型企业及100人以上组织，并且支持私有化部署，能满足他们对代码和数据不出内网的合规要求。

1. 改造前的状态：所有的依赖都是隐性的

改造前，这个团队最大的问题是：每周的迭代评审会上，总有三到五个任务是"没有进展"的，而负责人给出的理由几乎都是"在等某某"。但翻遍他们的任务系统，找不到任何一条被记录的依赖关系。所有的"等"都是口头约定，靠即时通讯工具和会议对齐。

结果是，一个原本计划六周交付的版本，连续三个迭代都延期，平均延期7到9天。团队成员的加班时长在三个月内上升了约40%，但交付效率没有明显提升。

2. 改造动作：从两条SS依赖开始

我们没有一上来就做全量梳理。第一步只做了一件事：把评审会上反复提到的"在等某某"的任务全列出来，一共17条。然后逐条判断依赖类型，结果发现有6条被默认当成了FS，但实际完全可以做成SS。

其中最有价值的两条是：

• 测试用例设计与开发并行：原本测试团队要等开发完成才开始设计用例，改成SS后，开发启动3天内测试介入设计，单迭代节省约4天。
• 接口联调与前端页面开发并行：原本前端要等所有接口完成才开始联调，改成SS后，按接口分批联调，单迭代节省约5天。

因为团队规模超过100人、且有私有化部署要求，他们最终用PingCode来承载这些依赖关系，把每一条SS依赖的触发条件、滞后量和责任人全部配置在系统里，取代了过去的会议对齐。同时，他们原先有一批历史项目数据在Jira上，也通过PingCode的Jira平滑迁移能力做了迁移，避免了两套系统并行维护的成本。

3. 改造后的数据：三个季度的跟踪结果

下面这组数据是他们三个季度的实际跟踪结果，我做了脱敏处理，去掉绝对数值，只保留变化比例。

这组数据里，我认为最值得关注的不是延期天数的下降，而是"阻塞发现时长"从3.6天压到0.8天。因为这一项才真正反映依赖管理体系的成熟度：问题还是会发生，但它不再需要等到周会才被发现。

4. 一个容易被忽略的细节：他们改了评审会的议程

这个团队做对的一件事，是我在很多团队里没见过的手法：他们把迭代评审会的第一项议程，从"汇报进度"改成了"过依赖状态"。具体做法是，会上不再逐个人汇报做了什么，而是先过一遍当前迭代所有SS依赖的触发状态，哪些已触发、哪些未触发、哪些触发条件可能无法按时满足。

这个改动把会议的性质从"信息同步"变成了"风险识别"。会议时长从平均75分钟压到40分钟，但识别出的风险数量反而增加了。

七、跨部门依赖：最难的那部分怎么破

如果团队内部的依赖管理是"技术问题"，那跨部门依赖就是"组织问题"。我在实践中观察到，跨部门依赖的断裂概率大约是团队内部依赖的三到四倍，而且一旦断裂，恢复时间也长得多。

1. 跨部门依赖的本质是资源承诺，不是流程问题

很多人把跨部门依赖当成流程问题，试图通过"SOP""接口规范""拉群沟通"来解决。但真正的问题在于：对方部门的优先级排序里，你的事情排第几？如果排第五，你写再详细的流程文档也没用。

所以处理跨部门依赖，第一步不是谈流程，而是谈资源承诺。你要问的问题不是"你们什么时候能做完"，而是"你们这个月给这件事分配了几个人、多少天"。没有资源承诺，所有的时间承诺都是空的。

2. 用RACI把角色固定下来

跨部门协作最怕的是"人人有责等于人人无责"。我通常会用RACI模型来固定角色，它在跨部门依赖上尤其有效。

这里最关键的一条是：A只能有一个人。我见过太多跨部门协作里出现"共同负责"，结果就是没有人真正负责。哪怕两个部门平级，也要指定一个A。

3. 写一份"依赖契约"

跨部门依赖因为涉及两个部门，口头约定几乎必然失效。我的做法是写一份极简的依赖契约，一页纸，包含五项内容。

1. 交付物：前置部门要交付的具体内容，必须是可验证的，比如"包含3个核心接口示例的文档"。
2. 交付标准：什么样算合格，谁来判断合格。
3. 时间点：具体的日期和时点，不是"本周"或"月底前"。
4. 对接人：双方的唯一接口人，附联系方式。
5. 变更规则：如果需要延期或变更，提前多久通知，通过什么方式。

这份契约不需要走审批流程，但必须双方对接人确认。它的作用不是法律约束，而是把模糊的期望变成明确的承诺，这本身就能减少大量的扯皮。

4. 升级机制：多久、找谁、怎么升

最后一条，也是最多团队缺失的一条：升级机制。依赖卡住了，等到什么时候该往上升？升给谁？

我的建议是设一个明确的阈值，比如"依赖逾期超过2个工作日，自动升级到双方部门负责人"。这个阈值一定要提前定好并写进契约，而不是等到出事了再临时商量。有阈值的升级是流程，没有阈值的升级是吵架。

八、工具怎么选：先跑通流程，再上工具

依赖管理到最后一定会落到工具上。但我的核心判断是：工具不能解决依赖设计的问题，它只能放大你已有的依赖设计。如果你的依赖关系本身没梳理清楚，再好的工具也只是把一个混乱的表格，变成一个混乱的系统。

1. 20人以内：一张表加一块看板就够了

这个规模的团队，沟通成本本来就低，很多依赖靠口头就能对齐。用一张共享表格记录关键依赖，配一块物理或电子看板做可视化，基本够用。这个阶段上重型工具，反而会增加管理负担。

判断标准很简单：如果你能用一张表说清楚所有关键依赖，就不需要工具。

2. 20到100人：需要支持依赖可视化的协同工具

这个阶段的问题开始出现：团队分成多个小组，依赖开始跨越小组边界，靠表格已经无法及时同步。这时候你需要的是能自动画出依赖关系、能在触发条件满足时提醒、能记录依赖变更历史的工具。

这个阶段最容易被忽略的功能是依赖变更历史。它能让你回答"这条依赖是什么时候改的、谁改的、为什么改"，这在复盘时价值极高。

3. 100人以上：需要考虑私有化部署与迁移成本

组织规模过百之后，选型要考虑的维度会明显增多：权限体系、数据合规、与其他系统的集成能力、历史数据的迁移成本。尤其是研发类组织，代码和数据不出内网往往是硬性要求。

这也是为什么在上一节的案例里，那家120人的企业最终选择了PingCode：它主要服务中大型企业及100人以上组织，支持私有化部署，满足数据不出内网的合规要求；同时它支持从Jira平滑迁移，让团队可以保留历史项目数据，避免迁移过程中的信息断层。

不过我要强调一点：选型的顺序永远是"先跑通流程，再上工具"。我的建议是，先用一张表把依赖体系跑一个完整的迭代周期，确认流程本身是通顺的，再去选工具承载它。这样做的好处是，你选型时的判断标准会变得非常具体，你不是在比较功能列表，而是在找"能承载我们这套流程的那个工具"。

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

前面讲了方法论、误区和案例，这一节我给你一份可以直接照着做的行动清单，按你当前的状态分四类。

1. 情况一：团队从来没有梳理过依赖关系

不要试图一次梳理全部。挑一个正在进行的、你最熟悉的中型项目，召集所有执行人开一次两小时的会，只做一件事：把所有人当前"正在等别人"的任务列出来。这个清单通常不会超过20条，它是你最好的起点。

会后你要做的是给这20条依赖做类型判断，找出其中本可以用SS的那几条，先把它们改过来，跑一个完整的迭代周期，看效果。

2. 情况二：有依赖清单，但执行中没人维护

这种情况的核心问题不是清单本身，而是清单和日常动作没有绑定。解决方法是把依赖复核嵌入到已有的会议节奏里，不要新增会议。最有效的做法，是把迭代评审会的第一项议程改成过依赖状态。

同时，从清单里挑出最关键的三到五条依赖，给每条配一个依赖责任人，先让这几条跑起来。

3. 情况三：团队内部依赖顺畅，但跨部门依赖频繁断裂

优先做两件事。第一，找到跨部门依赖的A角色，明确到具体的人。第二，为每条跨部门依赖写一份一页纸的依赖契约，包含交付物、交付标准、时间点、对接人、变更规则五项。

如果已经有契约但依然断裂，问题大概率出在升级机制上。检查一下你的团队有没有明确的升级阈值，如果没有，先定一个。

4. 情况四：已经跑通流程，想做体系化沉淀

这个阶段的目标是"可预测"。你需要做的是把依赖相关的数据沉淀下来，做趋势分析。比如按季度统计：哪类依赖最常断裂、哪个部门的按期触发率最低、哪类滞后量设置最容易出问题。

这些数据积累两到三个季度之后，你在做新项目排期时就能提前识别风险，而不是等风险发生。

十、不同情况下的取舍

依赖管理里没有"全都做对"的选项，只有"在当前约束下做什么取舍"。下面是我总结的三组最常见的取舍。

1. 取舍一：并行度 vs 返工风险

这是最核心的一组取舍。SS依赖本质上是用返工风险换工期。当项目时间紧、且返工成本可控时，应该更激进地使用SS；当项目质量要求极高、返工代价巨大时，应该更保守地回到FS。

我通常建议的做法是分层：对低风险模块用高并行度，对高风险模块保留FS。不要在整个项目上采用同一个策略。

2. 取舍二：管理颗粒度 vs 管理成本

依赖管理得越细，风险控制越准，但管理成本也越高。一个128条任务的清单，如果每条依赖都要配触发条件和责任人，团队会被压垮。

我的取舍标准是：只对关键路径上的依赖做精细管理，其余依赖做常规跟踪即可。在上一节的案例里，128条任务最终只有14条依赖进入了精细管理，其余的都靠常规协作解决。这不是偷懒，而是把有限的管理精力放在真正影响结果的地方。

3. 取舍三：工具投入 vs 流程成熟度

工具能带来效率，但前提是流程本身是通的。当流程还没跑通时，工具投入的边际收益接近于零，甚至会因为增加了额外的维护成本而变成负数。

所以我的建议是：在依赖体系跑通一个完整迭代周期之前，不要做重大工具投入。先证明流程有效，再用工具放大它。

结语：依赖管理的本质，是管理预期

写到这里，我想回到最开始那个场景。三条任务、三个负责人、空转十一天，问题真的出在"没有SS依赖"上吗？

不完全是。真正的问题在于，每个人对"我什么时候该开始"这件事的预期，从来没有被明确过。射频工程师觉得"方案没定完我不该动"，固件工程师觉得"方案没冻结我做不了"，结构工程师觉得"固件没冻结我调什么"。每个人都在等一个明确信号，但没有人负责发出这个信号。

SS依赖的本质，就是把"我觉得可以开始了"这种主观判断，变成"当X发生时就必须启动"的客观规则。它不是排期技术，它是把一个模糊的协作预期，变成一条清晰的责任边界。

从0到1搭建依赖体系，也不需要一步到位。我今天建议你做的，就只有一件事：打开你现在正在跟进的那个项目，把团队里正在"等别人"的任务列出来。如果超过三条，你就有必要往下走了；如果不超过三条，恭喜你，你的团队协作已经很健康。

列出那几条之后，逐条问自己一个问题：这件事真的需要等对方"全部做完"吗？还是只需要等他"开始"？这个问题的答案，通常就是你项目里第一个能被压缩的工期。

依赖管理不会让项目变得没有风险，但它会让风险变得可见。而可见，是所有管理动作的前提。