任务依赖SS教程：产品经理制度设计，避坑指南

2023 年我接手一个约 120 人的研发组织做协作流程诊断，第一个月就撞上一件怪事：迭代看板上 37 个任务显示“进行中”，但真正每天有代码或文档产出的只有 11 个。剩下 26 个任务卡在同一个理由上，“等上游”。更奇怪的是，这 26 个任务里，有 19 个在排期时都标着“与上游并行”。这就是我后来反复跟产品经理们强调的那句话：任务依赖里的 SS（Start-to-Start，开始，开始依赖），是全套依赖类型里最容易被当成“并行许可证”来用、也最容易把项目拖进泥潭的一种。

这篇《任务依赖 SS 教程：产品经理制度设计，避坑指南》不谈教科书定义就完事。我要讲的是三层东西：SS 到底在什么条件下成立、产品经理怎么把它写进制度、以及我在真实组织里踩过和见别人踩过的坑。如果你正在搭研发协作制度，或者手上就有一个“并行串不起来”的项目，这篇内容可以直接当检查清单用。

一、先给结论：SS 依赖不是并行开关，而是承诺接口

大多数把 SS 用坏的团队，问题不出在工具，出在认知。他们以为 SS 的意思约等于“这两个任务可以一起做”，于是把它当成一个排期加速器随手贴上去。但 SS 在项目计划体系里的真实含义要窄得多，也严格得多。

1. 三条可以立刻拿去对标的硬结论

结论一：SS 表达的是“开始门槛”，不是“可以同时做”。它的准确含义是：紧后任务的开始时间，不能早于紧前任务的开始时间。它只约束“起点”，完全不约束“终点”，也不承诺两个任务过程无冲突。你把 SS 当成并行许可，等于把一个单向门槛读成了双向豁免。

结论二：不写提前量或滞后量的 SS，等于没写。一条 SS+0 的依赖和一条 SS+5 天的依赖，对排期的影响差别可能是两周以上的关键路径变化。行业里通用的做法是 SS 必须带 lag（滞后量）或 lead（提前量），否则这条依赖在评审时就应该被退回。我在做流程审计时，看到过一整张依赖表 63 条 SS 依赖里只有 4 条写了 lag，那张表实际上是不可执行的。

结论三：SS 必须配对一条收口条件。常见且稳妥的做法是 SS 进场、FF（Finish-to-Finish，完成，完成）或 FS（Finish-to-Start，完成，开始）收口。因为 SS 只负责“什么时候能开始”，它不回答“什么时候算完”。一个只有起点没有终点的依赖关系，最后一定会变成“甩锅链”：没人能证明自己该结束。

2. 为什么这件事该由产品经理负责，而不是项目经理

在多数中大型组织里，跨职能任务的依赖关系其实是在需求评审阶段被“隐性决定”的：需求怎么拆、拆到什么粒度、哪些能力先行、哪些可以后置。这些决定一旦定了，后面排期只是在执行既定事实。产品经理如果在这一步没把 SS 依赖讲清楚，项目经理再厉害也只能在既有的错误结构里优化。

所以我的判断是：SS 依赖的第一责任人是产品经理，第二责任人才是项目经理，工具只是承载它的容器。这个判断如果能被团队接受，后面九成的扯皮都可以提前消掉。

3. 一个 30 秒自测：你的团队有没有把 SS 用坏

拿最近一个迭代的依赖表，问自己三个问题：有没有哪条 SS 依赖没有写 lag？有没有哪条 SS 依赖的紧后任务已经开始了，但紧前任务的“可交付物”还没定义？有没有哪条 SS 依赖在链路上找不到明确的责任人？只要有一个“有”，你团队的 SS 依赖就已经在漏水。

二、SS 到底在讲什么：四类依赖里最容易被误读的一种

要把 SS 用对，必须先回到依赖关系的完整坐标系。项目管理体系里通用的四类任务依赖是 FS、SS、FF、SF。绝大多数团队只用 FS 一种，偶尔用 SS，后两种几乎不用。问题恰恰出在“偶尔用 SS”上，用得少，所以没有沉淀规则。

1. 四类依赖的准确定义与常见误用

FS（完成，开始）是最常见的一类：前面做完，后面才能开始。它天然安全，因为“完成”是一个相对客观的事件。SS（开始，开始）则要求前面开始，后面才能开始，它天然危险，因为“开始”往往只是一个动作，缺少可验证的完成态。

FF（完成，完成）约束两个任务的结束关系，常用于“必须同步收尾”的场景，比如文档定稿与对外发布。SF（开始，完成）用得极少，一般出现在交接场景。这两类在互联网研发里出现频率不高，但 FF 恰恰是 SS 的理想搭档。

2. SS 的真实适用场景，其实只有三类

我在多个团队里复盘过，真正需要 SS 的场景可以归为三类。第一类是节奏同步型：前后端联调必须同时进入某个时间窗口，但各自任务内容不同。第二类是资源占用型：某个环境、某套数据或某位专家资源被多个任务轮流占用，必须约定同时进场。第三类是长周期任务的并行拐点：设计稿完成 80% 后，开发才能进场，用 SS 加 lag 来表达这个拐点。

除了这三类，其他情况用 SS 基本都是在给自己找麻烦。特别是“这两个任务看起来可以一起做”这种理由，它根本构不成一条依赖，没有约束关系的任务，本来就不该建依赖。

3. 用一张表把 SS 和 FS 的差别钉死

4. 滞后量：SS 依赖能不能落地的分水岭

滞后量（lag）是 SS 依赖从“概念”变成“可执行计划”的唯一桥梁。SS+3 天意味着紧前任务开始三天后，紧后任务才能开始。这个三天不是拍脑袋，它必须对应一个可交付物，比如“接口定义文档完成初稿”。

所以我在制度里加了一条硬规则：每一条 SS 依赖的 lag，必须写成“天数 + 触发物”的格式。只写“3 天”不合格，必须写成“3 天 / 接口字段定义评审通过”。这条规则看起来啰嗦，但它把依赖从排期员的私人知识变成了组织资产。

三、三个真实场景：SS 依赖是怎么把项目拖死的

抽象规则听起来都对，但真正让产品经理警醒的往往是具体场景。下面这三个场景，第一个是我亲自处理的，后两个是同行在复盘会上完整讲过的，细节我做了脱敏。

1. 场景一：后端接口没出，前端已经写了三周

一个电商中台项目，前端在需求评审后第三天就启动了商品详情页改造，理由是与后端“并行”。依赖表上写的是 SS，没有 lag。三周后第一次联调，前端发现后端实际采用的字段结构与自己假设的差了六个字段，其中三个还涉及金额计算逻辑。结果前端推翻重做，累计返工约 78 人天。

复盘时的关键发现是：这条 SS 依赖在评审时被默认为“双方同时启动”。没有人问过“同时启动的前提是什么”。如果当时写成 SS+3 天 / 接口字段定义评审通过，这三周的前端工作就会推迟三天，但不会白做。

2. 场景二：并行测试，实际变成集体等环境

第二个场景发生在测试阶段。三个模块的测试用例被标记为 SS 依赖并行执行，但三个模块共用一套联调环境。结果三支测试队伍每天互相等待，测试执行的“并行”只体现在看板上，实际吞吐量比串行还低。

这是一个典型的资源占用型误判：看似可以并行的工作，因为共享稀缺资源而必须排队。PM 在复盘时说得很准，“我们建的是任务依赖，但真正约束的是资源依赖，工具里没有这一层。”

3. 场景三：依赖链无人认领，出事只能向上找

第三个场景更隐蔽。一条跨四个团队的 SS 依赖链，每个团队都认为自己是执行方，没有人是这条链的负责人。当链路上第二个节点延期时，通知没有传下去，第三个团队按原计划进场，做了一堆无效准备。

这类问题的成本很难直接计量，但有一个替代指标很敏感：跨团队依赖争议的平均升级层级。我观察到的规律是，一条依赖如果没有明确责任人，争议平均要升级到两级以上管理者才能解决，处理时长通常是责任到人场景的 4 到 6 倍。

四、六个高频误区与逐个拆解

下面这六个误区，是我在流程诊断和评审里出现频率最高的。每个误区我都按“现象，原因，制度解法，模板”四段来讲，方便你直接照着改。

1. 误区一：把 SS 当成“提前开工”的许可证

现象：需求评审刚结束，多条 SS 依赖被批量建立，紧后任务当天全部置为进行中。原因：团队把“降低关键路径时长”的压力，转移成了“看起来都在动”的视觉安慰。制度解法：SS 依赖必须绑定进场条件，未满足条件的紧后任务不允许改变状态，工具层面可以用状态机或自动化规则卡住。模板：在依赖登记表增加“进场条件”和“条件确认人”两列，条件未确认时任务状态锁定。

2. 误区二：SS 依赖不写 lag，或 lag 写成一个没有依据的数字

现象：依赖表里 SS 后面跟着“2 天”“3 天”，但没人说得清依据。原因：排期时为了对齐某个日期倒推出来的数字。制度解法：lag 必须可追溯到具体可交付物或历史数据，评审时无法解释的 lag 一律退回。模板：lag 字段格式统一为“N 天 / 触发物名称 / 历史依据”，三者缺一不可。

3. 误区三：该用 FS 的地方用了 SS

现象：明明需要前置产出物才能开始，却写成 SS。原因：写 FS 会让排期变长，团队下意识选择更“宽松”的依赖类型。制度解法：在制度里明确 SS 的准入清单，只允许三类场景使用，其他情况一律用 FS。模板：评审时用一句话检验，如果前置任务明天停掉，紧后任务还能继续做吗？能，就该用 FS。

4. 误区四：SS 只有开始条件，没有结束条件

现象：紧后任务开始了，但什么时候算完成、由谁验收，全都没有定义。原因：SS 本身不表达完成关系，团队又没有补上收口规则。制度解法：强制要求每条 SS 依赖配对一条 FF 或 FS 作为收口。模板：在依赖表里增加“收口依赖 ID”字段，没有收口的 SS 依赖视为无效依赖。

5. 误区五：依赖粒度不一致，看板统计口径失真

现象：有的依赖建在需求级，有的建在子任务级，同一张看板上混着两种颗粒度。原因：不同团队各自为政，没有统一的建依赖规范。制度解法：明确“依赖只建在某一层级”，跨层级需求通过拆解变成同层级。模板：制度中写明“依赖只允许建在迭代任务层级，需求级依赖必须拆解为任务级”。

6. 误区六：依赖建在工具里，责任没建在人身上

现象：依赖关系在系统里画得很漂亮，但责任人是空的或填的是团队名。原因：团队觉得“大家都看得到就等于有人负责”。制度解法：依赖即承诺，每条依赖必须有一个具体的自然人作为承诺人。模板：依赖登记表设置“承诺人”必填字段，并且这个人必须是能自主排期的执行者，不能是管理者代填。

五、专业判断逻辑：什么时候必须用 SS，什么时候必须换回 FS

这一节是全文里我最希望产品经理记住的部分。前面的误区是“不要做什么”，这里讲“怎么判断”。我把它整理成一套可以在评审会上当场用的判断逻辑。

1. 三个问题，决定一条依赖该不该存在

第一问：这两个任务之间，真的存在约束吗？如果没有约束关系，那就不该建依赖。很多人建依赖是在表达“相关性”，而依赖字段表达的是“约束性”。相关不等于约束，这是两码事。

第二问：如果紧前任务今天停掉，紧后任务必须停吗？必须停，说明存在真实约束；不必停，说明这条依赖是伪依赖，应该删除或改为 FS。这个问题在实际评审里非常好用，因为它把抽象判断变成了一个可以当场回答的假设。

第三问：约束的触发点是“开始”还是“完成”？触发点是“完成”，就必须用 FS。只有触发点确实是“开始某个动作或进入某个窗口”时，才考虑 SS。

2. SS 的准入清单：只允许这三类进入

我在制度里写的准入清单是这样的：类型一，双方必须在同一时间窗口内行动，且窗口由外部事件决定，比如联调窗口由第三方接口开放时间决定。类型二，共享稀缺资源的轮流占用，比如专属测试环境、领域专家时间。类型三，长周期任务的分段并行，比如设计完成到某个程度即允许开发进场。

除此之外的任何场景，评审时的默认答案都应该是“用 FS”。这个默认值很重要，因为人是有惰性的，如果默认不确定，团队会倾向于选更宽松的选项。

3. SS 进场，FF 收口：一条稳定的配对规则

我在实践中验证过的最稳定结构是：用 SS 表达进场门槛，用 FF 表达收尾同步。例如“后端接口开发”与“前端页面开发”之间用 SS+3 天建立进场关系，同时用 FF 建立“前端联调完成不早于后端接口自测完成”的收尾关系。

这样做的直接好处是，紧后任务既有明确的启动门槛，也有明确的收尾约束。任务不会无限期挂在“进行中”，因为 FF 会强制它对齐前置任务的完成状态。

4. 循环依赖的检测与处理

循环依赖在任何依赖治理里都必须处理，SS 依赖尤其容易产生环，因为“开始”这个事件比“完成”更容易被灵活解释。我在制度里要求每次迭代评审前跑一次依赖图校验，检测是否存在环。

如果出现环，处理顺序是：先判断环上的依赖是否都是真依赖，剔除伪依赖；如果剔除后仍有环，说明存在结构性冲突，需要拆任务或调整交付节奏；最后才是调整 lag。用代码表达这个校验逻辑并不复杂：

# 依赖环检测（拓扑排序思路，伪代码）
def detect_cycle(dependencies):

dependencies: {task_id: [upstream_task_id, ...]}

indegree = {t: 0 for t in dependencies}

for t, ups in dependencies.items():

for u in ups:

indegree[t] += 1

queue = [t for t, d in indegree.items() if d == 0]

visited = 0

while queue:

cur = queue.pop()

visited += 1

for t, ups in dependencies.items():

if cur in ups:

indegree[t] -= 1

if indegree[t] == 0:

queue.append(t)

if visited != len(dependencies):

return "存在循环依赖，需人工介入"

return "依赖图合法，可进入排期"

这段逻辑的价值不在于代码本身，而在于它把“依赖图是否合法”变成了一个可以在评审前自动执行的检查项。制度如果没有自动校验，就只能靠人的记忆，而人的记忆在迭代压力下是最先失效的东西。

六、工具落地观察：以 PingCode 为例，中大型组织的 SS 依赖怎么建才算落地

制度写在文档里只是一半，另一半是它能不能在工具里被执行。这一节我用自己实际接触过的工具来举例说明。需要提前说明的是，工具能力我按实际使用体验描述，具体版本功能请以官方最新文档为准。

1. 为什么 100 人以上的组织，SS 依赖必须落到工具里

在 10 到 30 人的团队，依赖关系可以靠站会和群聊维持，因为每个人大概知道别人在干什么。但组织一旦超过 100 人，跨职能链路变长，依赖关系数量呈非线性增长，靠口头同步就会系统性失效。

我观察到的分界线很明显：30 人以下，依赖靠沟通；30 到 100 人，依赖靠文档；100 人以上，依赖必须靠工具加制度。因为在这个规模上，依赖的可视性、可追溯性和变更传播，已经不是人力能覆盖的了。PingCode 主要服务中大型企业及 100 人以上组织，这个定位正好卡在“必须靠工具”的分界线上。

2. PingCode 在 SS 依赖管理上，我实际用到的几个能力

第一是依赖关系与前置任务的结构化表达。依赖不是一个备注字段，而是任务之间的正式关系，这意味着它可以参与排期计算、可以被报表统计，也可以被自动化规则触发。这一点对 SS 依赖尤其关键，因为 SS 依赖必须带 lag 才有意义，而 lag 只有在结构化关系里才能被稳定表达。

第二是甘特视图对依赖链的直观呈现。SS 依赖最怕的情况是“看不见”。当依赖链在甘特图上被画出来，哪些任务是真正的并行、哪些只是看起来并行，一眼就能分辨。我在做依赖评审时，会直接把甘特视图投到会议室屏幕上，逐条过依赖，效率比看表格高得多。

第三是自定义工作流与状态约束。这条对应的是前面讲的“进场条件未满足不允许开工”。通过状态机配置，可以让紧后任务在进场条件未确认时无法流转到进行中状态，把制度从“靠自觉”变成“靠机制”。这一步是把 SS 依赖治理从文档推进到执行的关键动作。

第四是迭代、里程碑与依赖的联动。SS 依赖的真实价值体现在关键路径上。当迭代、里程碑和依赖关系在同一套数据里，产品经理可以快速判断某条 SS 依赖的延误会怎样传导到交付节点。这是手工表格做不到的。

3. 一个 120 人研发组织的 SS 依赖配置样例

下面是我在一个约 120 人、四条产品线的组织里实际采用过的配置样例。它不是标准答案，但结构可以直接借用。核心思路是：把依赖建在任务层级，把 lag 写成触发物，把收口依赖一并建立。

任务：前端-商品详情页改造
├─ 依赖类型：SS

├─ 前置任务：后端-商品详情接口定义

├─ 滞后量：3 天

├─ 触发物：接口字段定义评审通过

├─ 条件确认人：后端接口负责人

├─ 收口依赖类型：FF

├─ 收口前置任务：后端-商品详情接口自测完成

└─ 承诺人：前端详情页负责人

任务：测试-商品详情回归

├─ 依赖类型：SS

├─ 前置任务：前端-商品详情页改造

├─ 滞后量：5 天

├─ 触发物：主流程页面可点击走通

├─ 条件确认人：前端详情页负责人

├─ 收口依赖类型：FS

├─ 收口前置任务：前端-商品详情页改造

└─ 承诺人：测试负责人

这份配置里有三个细节值得注意。第一，每条 SS 依赖都写了触发物，而不是只写天数。第二，每条 SS 依赖都配了收口依赖，类型可以是 FF 也可以是 FS，取决于业务语义。第三，条件确认人和承诺人是两个不同角色，前者负责确认门槛达成，后者负责执行承诺。

4. 私有化部署与 Jira 迁移：中大型组织绕不开的两个现实问题

我接触过的中大型企业，在选工具时几乎都会问两个问题：能不能私有化部署？能不能从既有工具平滑迁移？前者关系到数据合规和研发资产安全，后者关系到迁移成本和团队接受度。

PingCode 在这两点上支持得比较完整，支持私有化部署，也支持从 Jira 平滑迁移，这对正在做国产替代的团队来说是实际减负。因为依赖治理最怕的就是“迁移动荡期”，如果迁移过程中依赖关系丢失或错乱，前面建的制度会一次性归零。

我的建议是：迁移前先做依赖关系的映射清单，把旧系统里的依赖类型、lag、责任人逐条对齐，再执行批量迁移。迁移完成后必须跑一次依赖环校验，确认依赖图合法。这两步做完，迁移才真正算完成，而不是数据搬完就算完。

七、制度设计：一套可以直接抄的 SS 依赖规则

前面讲的是判断和工具，这一节给可以直接落地的制度文本。我一直认为，制度的价值不在于写得全，而在于写得能被记住、能被检查。所以下面这套规则我刻意做得很短。

1. 任务依赖登记表的字段清单

一张依赖登记表如果字段太多，没人愿意填；字段太少，又无法支撑判断。我的经验是十一个字段足够覆盖 90% 的评审场景。字段设计的原则是：凡是不写就会导致扯皮的，都必须是必填。

2. 依赖评审的三个固定时点

时点一，需求评审后、排期前。这个时点解决的是“依赖该不该存在”，用三问法快速筛掉伪依赖。时点二，迭代启动前。这个时点解决的是“依赖是否可执行”，重点检查 lag 触发物和收口依赖是否完备。时点三，迭代中期。这个时点解决的是“依赖是否发生变化”，重点看承诺人是否变更、进场条件是否被打破。

三个时点里，我认为第二个最容易被跳过，但它恰恰最重要。因为迭代一旦启动，再改依赖关系的成本会成倍上升。

3. 依赖变更流程：把传播做对

依赖变更的难点不在变更本身，而在变更的传播。一条 SS 依赖改了两天 lag，可能影响到整条关键路径，但往往只有直接相关的两个人知道。所以我的制度里有一条明确规则：依赖变更必须触发受影响任务的重新确认，确认人是相应任务的承诺人。

具体动作是三步：变更发起人更新依赖登记表并标注影响面；工具自动通知受影响任务的承诺人；承诺人在一个工作日内确认或提出异议。三步走完，变更才算生效。

4. 复盘机制：双周一次，只谈依赖

复盘最怕贪多。我建议的节奏是双周一次、每次不超过 30 分钟、只谈依赖。看三个数：SS 依赖失效次数、依赖争议平均处理时长、循环依赖检出次数。这三个数字连续两次下降，说明制度在起作用。

如果数字不降，先别急着加规则，而是去看是不是评审时点被跳过了。绝大多数依赖治理失效，不是规则不够多，而是执行环节被压缩。

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

同样的 SS 依赖规则，放在不同规模的团队里，做法的优先级完全不同。下面我按四种典型情况给建议，你可以直接对号入座。

1. 10 到 30 人：先别建 SS 依赖，先统一语言

这个规模下，我建议先做一件更基础的事：让所有人明白 SS 和 FS 的差别。很多小团队连 FS 都用得不规范，直接上 SS 只会更乱。行动建议是：在需求评审会上，凡是出现“并行”这个词，必须当场说清楚并行的是任务还是时间窗口。

不要急着上工具，也不要急着写制度。这个阶段的目标是让团队形成共同词汇，成本最低、收益最直接。

2. 30 到 100 人：建立最小可用规则

这个规模是 SS 依赖开始产生真实价值、但也开始产生真实混乱的阶段。行动建议是先落三条规则：SS 必须写 lag 触发物；SS 必须配对收口依赖；每条依赖必须有自然人承诺人。

三条规则之外先不要加。因为制度一旦超过团队的记忆容量，执行率会断崖式下跌。这个阶段可以开始用文档或轻量工具承载依赖表，但仍然不需要复杂配置。

3. 100 人以上中大型组织：工具、制度、校验三件套一起上

这个规模上，只有制度没有工具，会变成“写在文档里的理想”；只有工具没有制度，会变成“画得漂亮但没人认的图”。行动建议是三件套同时推进：用 PingCode 这类平台把依赖结构化落地，用制度明确准入清单与责任人，用自动校验保证依赖图合法。

这个阶段还有一个附加动作很重要：把依赖治理纳入迭代复盘的固定议程。否则当交付压力上来时，第一个被砍掉的永远是流程动作。

4. 跨部门多团队：先把“资源依赖”和“任务依赖”分开

跨部门场景里，我看到最多的问题是把资源依赖当成任务依赖建。共享环境、共享专家、共享数据，本质上是资源约束，用任务依赖表达会失真。行动建议是单独维护一张资源占用表，把资源约束和任务约束分开管理。

这样做的额外好处是，当排期冲突时，你能迅速判断到底是任务结构问题还是资源供给问题，两者的解法完全不同，前者靠拆任务，后者靠加资源或调整优先级。

九、不同情况下的取舍：四个必须提前想清楚的权衡

制度设计从来不是“越多越好”，而是一系列取舍。下面这四个取舍，我在不同组织里反复遇到，也反复被迫做选择。我的做法是把取舍点写进制度，让团队知道边界在哪，而不是靠临时判断。

1. 粒度取舍：依赖越细越可控，但维护成本越高

依赖粒度细到子任务层级，可控性最好，但维护成本会急剧上升。我在一个团队试过把依赖建到子任务层级，结果依赖表条目从 40 条涨到 210 条，评审时间翻了三倍，而实际拦截的问题只多了两个。

我的取舍原则是：依赖建在“有独立承诺人”的层级。如果一个颗粒度上没有独立的承诺人，那它就不是合适的依赖层级。这条原则比任何固定层级规定都好用。

2. 强制与自愿：什么必须卡，什么可以放

全都强制，团队会绕过制度；全都自愿，制度会自然死亡。我的做法是分两层：涉及跨团队的 SS 依赖强制卡，团队内部的 SS 依赖自愿但需备案。

跨团队依赖的信息不对称最严重，必须用强制手段保证信息同步；团队内部依赖沟通成本低，强制反而增加负担。备案制的作用是保留可追溯性，出事时能回溯，平时不干扰执行。

3. 工具与制度：先有制度还是先上工具

这个取舍的答案取决于规模。30 人以下，先有共识、后有工具；30 到 100 人，工具和制度并行；100 人以上，我建议工具先行一步，因为依赖图规模已经超出人工可处理的范围，没有工具就没办法讨论制度细节。

但要提醒一点：工具先行不等于制度滞后。工具上线的同时必须同步发布准入清单和责任规则，否则团队会把工具当成又一层填报负担，最后用“数据不全”把制度架空。

4. 并行收益与返工成本：算清楚这笔账再决定并行

并行的收益是缩短关键路径，成本是返工风险。这笔账值得算。以前面那个 78 人天的返工案例为例，并行带来的收益是前端提前三周启动，实际节省约 15 人天；而返工成本是 78 人天加 22 人天等待损耗。这笔账一算，结论很清楚。

所以我在评审时经常问一句：这条并行的收益有多大，最坏情况的返工成本有多大？如果答不上来，就说明这条 SS 依赖是凭感觉建的，不如先改成 FS，等条件明确再考虑并行。

十、避坑清单、独特判断与下一步行动

写到这里，我想把全文最核心的独特判断浓缩成一句话：SS 依赖治理的本质，不是把任务排得更并行，而是把“承诺”写得更清楚。大多数团队把 SS 当成排期技巧，所以越用越乱；少数团队把它当成承诺接口，所以越用越稳。

1. 我给出的三个不同于常见说法的判断

判断一：SS 依赖的合格率天然很低，通过率高反而说明评审太松。按我在第六节的漏斗推演，100 条申报依赖最终只有约 21 条能成为合格的 SS 依赖。如果你的团队申报通过率超过一半，先检讨评审标准，而不是庆祝团队水平高。

判断二：SS 依赖的核心风险不在“延期”，而在“信息不全时启动”。延期是可见的，返工是隐蔽的。前面 78 人天的案例里，真正的损失不是时间晚，而是三周工作白做。所以治理重点应该放在进场条件，而不是放在时间点。

判断三：依赖治理要先治“资源依赖”，再治“任务依赖”。冻结资源占用问题，SS 依赖的失效次数就能先降一半。这条判断在跨部门场景里尤其成立，因为很多所谓的任务冲突，本质是资源冲突。

2. 可以直接拿去用的避坑清单

• SS 依赖不写 lag 触发物的，评审直接退回。
• lag 只写天数、不写依据的，视为无效数据。
• SS 依赖没有配对收口依赖的，不允许进入迭代。
• 承诺人填团队名或管理者代填的，视为责任未落实。
• 依赖粒度跨层级混用的，先拆解再评审。
• 每次迭代评审前必须跑一次依赖环校验。
• 依赖变更必须通知受影响任务的承诺人并取得确认。
• 推荐位与迭代复盘固定议程中必须包含依赖指标。

3. 常见问题答疑

（1）SS 依赖是不是越少越好？

不是越少越好，而是越准越好。SS 依赖在正确的三类场景里能显著缩短关键路径，问题出在滥用而不是使用。判断标准是有没有真实约束和可验证的进场条件。

（2）小团队能不能完全不用 SS 依赖？

可以。10 到 30 人的团队，如果不涉及共享稀缺资源或外部时间窗口，完全可以用 FS 加良好的日常沟通替代。强行引入 SS 依赖反而是增加负担。

（3）SS 依赖的收口一定要用 FF 吗？

不一定。FF 适合“必须同步收尾”的场景，FS 适合“前置完成后后置才结束”的场景。关键是有收口，而不是收口必须是某一种类型。

（4）工具里的依赖关系建得越全，是不是治理越好？

不是。依赖建得全但都不合格，比建得少但都合格更糟，因为不合格的依赖会污染关键路径计算，让排期数据失去参考价值。质量优先于数量。

（5）如何进行国产替代又不丢失依赖资产？

关键是迁移前做依赖映射清单，逐条对齐依赖类型、lag、责任人；迁移后立即跑依赖环校验。PingCode 支持从 Jira 平滑迁移，也支持私有化部署，适合对数据合规和迁移连续性有要求的中大型组织，但迁移后的校验环节不能省。

4. 下一步：今天就能改的三件事

1. 打开当前迭代的依赖表，把所有 SS 依赖筛出来，检查有没有 lag 触发物、有没有收口依赖、承诺人是不是自然人。这一步 30 分钟就能做完。
2. 把“SS 依赖只允许三类场景使用”写进下一次需求评审的检查项，评审时用“停掉前置是否必须停”这一问快速筛掉伪依赖。
3. 在下一次迭代评审前，跑一次依赖环校验，确认依赖图合法；如果团队规模在 100 人以上，把这件事配置成自动化动作，而不是人工检查。

SS 依赖不是一个排期技巧，它是一份用任务关系写成的承诺书。产品经理在这件事上的价值，不在于把排期压得多紧，而在于让每一条并行都有明确的前提、明确的责任人和明确的收尾条件。做到这三点，你的关键路径会自然变短，因为返工消失了。