我第一次认真把 SS 依赖单独拎出来研究，是因为一次三周迭代里的"双卡"事故。甘特图上，前端页面开发和后端接口开发两条线并排启动，看起来并行得非常漂亮；到第 6 天，两边同时停摆，前端在等接口字段定义，后端在等前端确认页面结构。那天下午我干了一件事：把一个迭代里的 37 条依赖线全部摊开，一条条问"它到底约束了什么"。最后删掉了 21 条，剩下 16 条里真正属于 SS 类型的只有 5 条。
这篇文章就是那次复盘之后的完整沉淀。它不打算把四种依赖类型平均讲一遍，而是只深挖 SS 这一种，并且重点回答一个更少人问的问题：SS 依赖什么时候必须连，什么时候是自找麻烦。
一、先给结论：SS 依赖最容易在三个地方想错
如果你只想从这篇文章带走三句话，就是下面这三条。它们都和我后来在十几个项目里反复验证过的判断有关，不是从教材上抄的。
第一，SS 依赖约束的是"触发"，不是"完成"。很多人把它理解成"两个任务同时做"，这是错的。SS 的真正含义是：B 任务的开始时间，被 A 任务的开始时间锁定。它管的是入口，不是出口。一旦理解成"同时做"，后续所有的排期逻辑都会跑偏。
第二，没有滞后量的 SS 依赖等于没有约束。如果你的 A 和 B 都从同一天开始，那么这条依赖线只表达了一个事：它们同一天开始。这不需要连接依赖，写同一行就行。只有当"B 必须在 A 开始之后 N 天才能动"的时候，SS 才产生真正的排期价值。
第三，判断一条 SS 该不该连，先问"如果删掉它会怎样"。如果答案是"也没什么影响，就是图没那么好看"，那就该删。依赖不是越严谨越好，过度连线会让整个排期僵化到无法响应变化，这是我踩过最深的坑。
二、概念对齐：SS 依赖到底在约束什么
1. 四种依赖类型的快速定位
先把四种类型用一句话各自定性，然后我们把全部笔墨留给 SS。
FS（Finish-to-Start，完成，开始）：A 完成后 B 才能开始。这是最直觉、最常用的一种，也是绝大多数排期工具默认的连接方式。
SS（Start-to-Start，开始，开始）：A 开始后 B 才能开始。它的核心场景是并行推进，通常需要配合滞后量使用。
FF（Finish-to-Finish，完成，完成）：A 完成后 B 才能完成。多用于收尾对齐，比如"数据报表必须和月度结算同时完成"。
SF（Start-to-Finish，开始，完成）：A 开始后 B 才能完成。实际项目中极少使用，如果你在排期图里看到它，第一反应应该是查一下是不是连错了。
2. SS 依赖的本质：用"开始事件"作为触发条件
我习惯把依赖关系翻译成一句人话。FS 翻译过来是"你干完了我才敢开始"，SS 翻译过来是"你动了，我才有条件动"。
注意后半句里的"才有条件"，这是 SS 的关键。它表达的不是"我想和你同时开始"，而是"我的启动条件依赖你的启动动作"。比如后端接口开发的启动条件，是数据模型评审会开始并且产出了初版字段；前端页面开发的启动条件，是设计稿开始进入标注阶段。
这两件事的触发源不同，但因为都挂在一个前置动作上，在排期图里就会被画成一条 SS 线。所以SS 依赖往往不是两个任务之间的关系，而是两个任务共同依赖同一个"启动信号"。
3. 滞后量（Lag）为什么是 SS 依赖的必需品
滞后量是 SS 依赖真正发挥作用的那个参数。它表示"B 在 A 开始之后，需要等待多久才能启动"。
举个具体例子。假设"接口字段定义"这项工作从周一启动，需要 3 天才能产出足够前端开工的信息。那么前端联调的 SS 依赖应该设成 lag = 3d，而不是 lag = 0。如果滞后量设为 0，排期工具告诉你前端周一也能开工，但现实里前端周一拿不到任何可用字段，只能干等。
所以我在评审排期时有一个固定动作：凡是看到 lag = 0 的 SS 依赖，一律要求补齐滞后量依据。这个动作帮我挡掉过很多"纸上并行"。
4. 一个常见混淆：SS 依赖不等于并行任务
很多人把"两个任务并行"和"两个任务之间存在 SS 依赖"当成同一件事，这是两回事。
并行任务只是说这两件事在时间上有重叠，它们之间可以完全没有任何依赖。而 SS 依赖是一个带方向的约束，它会限制排期的自由度。你排一条 SS 依赖，就等于告诉排期系统"这两个任务的启动顺序不能随便调"。
所以我常跟团队说：如果你只是想让两个任务看起来并排，不需要连依赖线，只需要把它们排在同一时间段。连了线，就多了一个将来会跳出来咬你的约束。
三、什么情况下必须连 SS 依赖
下面这五类场景，是我在真实项目里反复确认过"确实需要 SS"的情况。每个场景我都会给出可代入的设定，你可以直接对照自己的排期看。
1. 上下游交替推进的迭代型工作
最典型的是设计稿迭代和前端开发。设计不会一次性冻结，而是分批交付：首页冻结一版，前端就开始做首页；详情页冻结一版，前端接着做详情页。
假设你在做一个 3 周迭代，设计交付分三批：第 3 天、第 7 天、第 12 天。前端开发的启动条件不是"设计全部完成"，而是"第一批设计开始交付"。这条依赖就是 SS，滞后量取决于设计从开始到可交付的间隔。
如果不连这条 SS，排期工具会把前端开发排成设计全部完成之后才开始，你的迭代周期会凭空长出 5 到 7 天。
2. 前置任务只需部分交付即可启动
测试用例编写和功能开发就是这类。测试同学不需要等功能全部开发完，只要需求评审开始、关键流程确定，就可以开始写用例。
它的 SS 依赖建在"需求评审开始"这个动作上，滞后量可能是 2 天，给测试同学留出理解需求的时间。这类依赖的最大价值是把串行的时间压成并行，它直接决定了迭代能不能压进 2 周。
3. 资源受限下的错峰并行
这一条比较反直觉。如果两个任务都要用同一个后端同学，那它们不可能真正并行。这时候排 SS 依赖不是为了同时开工，而是为了用滞后量错开高峰。
比如后端要支持 A、B 两个模块的开发，两个都挂在"架构设计开始"这个触发点上。我通常会给 B 设一个 5 天的滞后量，让 A 先占用后端的主要精力，B 稍后启动。这样图上看起来还是并行，但资源占用被错开了。
4. 需要严格同步启动的联调、评审、上线窗口
还有一类是硬约束：多端联调必须同时开始，否则一端在跑一端没动，联调就是无效的；评审会必须多角色同时到场，缺一个就开不成。
这类场景的 SS 依赖滞后量通常是 0，但它和第 2 节说的"lag = 0 要警惕"并不矛盾。区别在于：这条依赖是硬约束还是软假设。硬约束可以设 0，软假设必须给出等待时间。
5. 五问判断清单：满足几条才值得连
每次有人要往排期里加 SS 依赖，我都会让他先回答下面五个问题。三题以上答"是"，才值得连。
- 这两个任务之间，是否真的存在"B 的启动条件依赖 A 的启动"这种因果关系？
- 如果不连这条依赖，排期会不会出现明显不合理的排列？
- 这条依赖的滞后量，我能不能说出一个具体的依据（而不是拍脑袋）？
- 这条依赖的失效时间或解除条件，我能不能写出来？
- 这条依赖由谁负责跟踪？出了问题谁来判断它是否还成立？
四、四个最容易踩的坑
这一节是我认为全文最有价值的部分。下面四个坑，我都在真实项目里踩过至少一次，每一个都付出了排期返工的代价。
1. 伪并行：看起来同时开工，实际互相等
症状：甘特图上两条任务线从同一天起跑，颜色并排，团队也按这个计划分配了人力。
后果：任务启动后第 3 到第 5 天，两条线同时停滞。前端在等接口定义，后端在等前端确认交互细节，双方都在做"等对方先动作"的事。实际有效工作日可能只占计划的一半。
改法：把伪并行拆成"真串行 + 明确滞后量"。具体动作是打开排期图，找到所有 lag = 0 的 SS 依赖，逐条问"下游任务在第一天的具体产出物是什么"。如果答不上来，这条 SS 就该拆掉，或者补一个负责任的滞后量。
2. 责任稀释：两个任务都在动，出问题找不到人
症状：两个任务并行推进，都延误了，复盘会上没有人认领。
后果：延误原因在两条任务线之间来回推。前端说"因为接口没定"，后端说"因为前端没确认页面结构"。因为两条线都是"进行中"状态，没有明确的交接点，责任被时间模糊掉了。
改法：给每条 SS 依赖指定一个触发责任人和接收责任人。触发责任人负责在约定时间给出启动信号，接收责任人负责在收到信号后确认条件是否满足。这两个字段写进依赖台账，比开三次协调会都管用。
3. 依赖蔓延：全图连成蜘蛛网，改一处动全身
症状：排期图上的连线密度高到看不清任务本身，任何一个任务的时间调整都会引发连锁反应。
后果：项目经理不敢动排期，因为一动就要重算全图。团队逐渐放弃更新排期，排期变成一次性交付物，之后没人看。
改法：设一条硬规则，每条依赖必须能说出删掉它之后的具体后果。说不出来的，直接删。我做过一个统计，某次迭代里 37 条依赖删到 16 条之后，排期的平均变更响应时间从两天缩短到半天。
4. 滞后量拍脑袋：数字没有依据，等于没设
症状：滞后量填 2 天、3 天、5 天，但问依据时回答"感觉差不多"。
后果：滞后量变成一个新的不可信参数。团队既不信排期，也不信排期里的并行关系，最终还是靠群里刷进度。
改法：滞后量只有三个合法来源：历史同类任务的真实耗时分布、明确的交付物产出周期、或者多方协商确认的等待窗口。任何一个都不是"感觉"。下面这张图对比了三种估算方式的偏差。
五、落地清单：把 SS 依赖真正管起来
概念和坑讲完了，接下来是能直接抄进自己排期模板的部分。我按字段、规则、节奏、会议、检查表五块来写。
1. 字段设计：一条 SS 依赖至少要记录什么
下面这套字段是我们在一个 60 人规模的交付团队里跑了一年多、逐步砍到最小的版本。字段太少会失控，太多没人填。
| 字段 | 说明 | 是否必填 |
|---|---|---|
| 依赖编号 | 全局唯一，用于在会议和台账里被引用，例如 DEP-018 | 必填 |
| 依赖类型 | FS / SS / FF / SF，必须明确写清 | 必填 |
| 触发任务 | 上游任务编号与名称 | 必填 |
| 接收任务 | 下游任务编号与名称 | 必填 |
| 滞后量 | 带单位的工作日，例如 3d。SS 类型下不允许留空 | 必填 |
| 触发条件 | 具体到什么状态算"已开始"，例如"接口字段冻结 v1.2" | 必填 |
| 触发责任人 | 负责给出启动信号的人 | 必填 |
| 接收责任人 | 负责确认条件满足的人 | 必填 |
| 复核周期 | 每周 / 每双周 / 每迭代 | 必填 |
| 失效日期 | 超过这个日期依赖自动作废，需重新评估 | 建议填 |
| 备注 | 历史变更理由，便于回溯 | 选填 |
2. 录入规则：谁有权加依赖
我们的规则是：任何人都可以提出，但只有项目经理或排期负责人可以录入。这个设计不是为了设卡，而是为了保证每条依赖都经过一次完整的五问检查。
录入前必须回答的三个问题是：
- 这条依赖的触发条件和滞后量依据分别是什么？
- 删掉它会带来什么具体后果？
- 它由谁来跟踪，多久复核一次？
三个问题答不全的，允许先把依赖写进"待定清单"，但不进正式排期图。这个缓冲地带很关键，它让讨论可以继续，同时不污染排期的可信度。
3. 维护节奏：顺延、解除、失效的判断标准
依赖不是一次录入就完事的。我把它分成三种状态变化，每种都有明确的判断标准。
顺延：触发任务的实际开始时间晚于计划，且滞后量仍然成立。这时只需按差值整体平移接收任务，不需要重新评估依赖本身。
解除：接收任务的启动条件已经不再依赖触发任务，或者两个任务被合并。这时必须显式删除依赖并记录理由，不能只是"先放着"。
失效：超过失效日期仍未触发。这时依赖自动作废，需要重新走一遍五问检查才能恢复。
更新频率上，我的建议是：SS 依赖在迭代内每周至少复核一次，跨迭代的依赖每个迭代边界复核一次。
4. 会议机制：依赖变更在哪个会上确认
我们最终固定在两个场合处理依赖，避免它变成一个随时被拉出来讨论的悬案。
第一个是每日站会后的 10 分钟"依赖快评"，只处理当天可能触发的依赖，不讨论变更方案。第二个是每周的排期评审会，处理依赖的新增、解除和滞后量调整。所有变更当场录入台账，会后不追认。
5. 一页版检查表（可直接复制使用）
下面这段是可直接落进配置文件或工具字段的依赖记录结构，我用的 YAML 格式，字段顺序和上面的表一致。
dependencies:
id: DEP-018
type: SS # Start-to-Start
from: TASK-231 # 触发任务：接口字段定义
to: TASK-244 # 接收任务：前端页面联调
lag: 3d # 滞后量：3 个工作日
trigger_condition: "接口字段冻结 v1.2 并同步至前端仓库"
trigger_owner: "张宇" # 触发责任人
receiver_owner: "李然" # 接收责任人
review_cycle: weekly
expire: "2026-03-28"
rationale: "字段未冻结前前端无法编写请求层，返工风险高于等待成本"
这段结构里有三个字段是我认为最关键、也最容易被省掉的：trigger_condition、receiver_owner、rationale。前两个决定这条依赖能不能被执行，最后一个决定它将来能不能被合理地删掉。
六、工具的能力边界：以 PingCode 为例
1. 甘特图能画依赖，画不出资源冲突
这一点必须先说清楚，否则后面所有工具讨论都会跑偏。甘特图擅长表达时间关系和依赖方向，但它无法表达"这两个并行任务的执行者是同一个人"。
所以你会看到一种很常见的现象：排期图完美，资源完全冲突。两个任务并行、依赖正确、滞后量合理，但只有一个后端能做，于是其中一条必然延期。这不是工具画错了，而是工具的能力边界。
2. PingCode 在依赖管理与迁移上的实际表现
PingCode 主要服务中大型企业及 100 人以上组织，这个定位决定了它在依赖管理上要考虑的问题和十人小团队完全不同：跨项目依赖、跨团队资源、多层级的排期视图。
我在实际使用中关注的是三件事。第一，SS 依赖与滞后量能否在排期视图里直接维护，而不是只能在某个隐藏的字段面板里改。第二，依赖变更能否留下变更记录，因为中大型团队里"谁什么时候改了这条依赖"是复盘的关键证据。第三，依赖视图能否按团队或项目维度切开看，100 人以上的组织里，一张全局依赖图是没法看的。
另外值得一提的一点是迁移成本。PingCode 支持私有化部署，支持从 Jira 平滑迁移，这一点对于已经在用 Jira 做依赖管理、又需要国产替代的中大型团队来说，是实打实降低切换风险的因素，历史依赖关系能不能过来、字段映射会不会丢，往往是这类团队最关心的问题，而不是界面好不好看。
3. 工具之外的兜底：依赖台账 + 看板如何配合
不管用什么工具，我都会建议额外维护一份轻量的依赖台账。原因很简单：工具的依赖视图是给排期看的，台账是给复盘和交接看的。
台账不需要复杂，五列就够：依赖编号、类型、触发条件、责任人、最后复核日期。它和工具里的排期图形成互补，图看趋势，台账看责任。当项目中途换人时，台账能让人在半小时内接手全部依赖关系，这比翻排期图高效得多。
七、不同场景下的行动建议
同样的方法论，在不同规模的团队里落地方式差别很大。下面按四种典型情况给建议。
1. 10 人以下团队：先别急着连依赖
这个规模下，沟通成本低于维护成本。我的建议是只连硬约束依赖，也就是那些"不连就一定会出事故"的。软假设类的 SS 依赖，直接用口头约定加每日同步解决。
这个阶段最重要的不是依赖图，而是把每次迭代实际发生的等待时间记录下来。这些记录是将来设定滞后量的唯一可靠依据。
2. 10 到 50 人团队：建立依赖台账
到了这个规模，口头约定开始失效。你需要一份轻量台账，字段不用全，但触发条件、两个责任人、复核周期这四项必须有。
这个阶段最容易犯的错是直接上重流程。先跑三个月的最简台账，看哪些字段真的被用到，再决定要不要加。我见过太多团队一开始就设计了 15 个字段的模板，两个月后没人填。
3. 50 到 200 人团队：区分项目内依赖和跨项目依赖
这个规模的关键变化是依赖开始跨项目。项目内的依赖可以让项目经理管，跨项目的依赖必须由 PMO 或同级别的角色统一裁决，否则会出现两个项目各改各的、互相不通知的情况。
这个阶段也是引入工具收益最明显的阶段。像 PingCode 这类面向中大型组织的平台，在跨项目依赖视图和变更留痕上的价值会真正体现出来。
4. 多团队跨部门：把依赖升级成接口协议
当依赖跨越部门边界时，它已经不是一个排期问题了，而是一个协作协议问题。这时候我的做法是：把每条跨部门 SS 依赖写成一份简短的接口说明，明确交付物、交付格式、交付时间和验收标准。
这样做的好处是，依赖从"排期图上的线"变成了"可验收的承诺"。出问题时讨论的不再是"你为什么不配合"，而是"约定的交付物没有按格式给出"。
八、取舍：什么时候该主动删掉依赖
这一节是全文我最想强调的反向观点。依赖管理的终点不是把依赖管好，而是减少依赖。
1. 三种应该主动删掉依赖的情形
第一种：无法指定责任人的依赖。如果一条 SS 依赖找不到明确的触发责任人和接收责任人，它就永远不会被有效执行，只会成为复盘时互相推诿的素材。
第二种：滞后量长期无法稳定估算的依赖。如果一条依赖的滞后量每次复核都要重新拍一遍，说明这两个任务之间的关系本身就不够清晰，更适合拆成更小的任务。
第三种：连续两个迭代没有触发过的依赖。这说明它在这个节奏下已经是冗余约束，留着只会增加排期的调整成本。
2. 删依赖前后的指标变化
我在一个 60 人规模的交付团队里做过一次对比观察：把该迭代的依赖从 37 条清理到 16 条，其余条件不变，观察了两个迭代的排期相关指标。
| 指标 | 清理前 | 清理后 | 变化方向 |
|---|---|---|---|
| 排期平均变更响应时间 | 2 个工作日 | 0.5 个工作日 | 显著缩短 |
| 迭代内实际并行任务占比 | 41% | 58% | 明显提升 |
| 因依赖误连导致的返工次数 | 每迭代 4.2 次 | 每迭代 1.3 次 | 明显下降 |
| 排期图周更新率 | 52% | 88% | 显著提升 |
| 站会讨论依赖问题的时长占比 | 约 35% | 约 12% | 明显下降 |
这组数据是我们团队内部两个迭代的观察记录，样本量不大，不能外推成通用结论。但它至少说明一件事：删依赖带来的收益，往往大于加依赖。
九、下一步怎么做：从这一周开始
如果你读到这里，我建议不要试图一次性把所有依赖都重构掉。依赖管理不是一个能靠一次整理解决的问题，它更像是一个需要养成的习惯。
这一周可以只做三件事。第一，把当前排期里所有 lag = 0 的 SS 依赖挑出来，逐条问"下游任务第一天的具体产出是什么"，答不上来的先标记待删。
第二，给你认为必须保留的 SS 依赖，补齐触发条件、两个责任人和复核周期这三个字段。不用建复杂系统，一张表就够。
第三，在下一次迭代评审会上，专门用 15 分钟过一遍这份清单，当场决定哪些删、哪些留。会后不追认，改了就是改了。
最后我想把这篇内容的核心判断再收一次：SS 依赖是一种成本很高的排期工具。它的成本不在连接的那一刻，而在后续每一次排期变更时的连带调整。所以它值得被更谨慎地使用，只在真正存在启动条件依赖、且滞后量能被说清楚的时候才连。其余时候，让它留在排期图外面，可能才是更专业的做法。
常见问题解答（FAQ）
1. SS 依赖和 FS 依赖到底差在哪，什么情况下必须用 SS？
我以前排期基本只会拉一条“完成，开始”的线，后来带一个迭代项目，前后端要同步开工又互相等对方的接口，同事说这里得用 SS 依赖，我至今没完全搞明白它和 FS 的本质区别，也不敢乱连。
先分清四种依赖：FS 是前置完成、后置才开始；SS 是前置一开始、后置就能开始；FF 是两者同完成；SF 极少用。SS 的本质不是“大家一起做”，而是“我只能等你动了才能动”，所以它必须配滞后量才有约束力，否则等于强行同时开始。
判断该不该用 SS，就问三件事：后置任务能不能靠前置任务的中间产出动工、是否需要抢同一个交付窗口、如果改成 FS 会不会明显拖长关键路径。三条都答“是”才值得连 SS；如果后置任务必须等前置任务全部做完才有意义，就老老实实用 FS，别为了图表好看硬连成并行。
2. 我加依赖的时候 lag 那一栏直接空着，系统就显示两个任务同一天开始，结果前置任务还在搭环境，后置任务全员干等，进度会上被问“这个三天是怎么来的”，我答不上来。
滞后量是 SS 依赖的生效开关，空着等于宣布“同时开始”，只适用于真正需要同步启动的场景，比如联调、评审、上线窗口。定滞后量建议按三种口径取其一并写清依据：一是历史数据口径，取同类任务过去实际间隔的中位数；二是交付节拍口径，看前置任务第几天能产出可用的中间件（比如接口文档冻结、数据库表建好）；
三是缓冲口径，给评审、提测、返工预留时间。落地时在依赖旁边加两列：“滞后量依据”和“复核日期”，没有依据的数字一律先不填，宁可先按经验值加一周缓冲，等复盘数据出来再收窄。
怎么判断我连的 SS 依赖是真并行，还是看起来并行的“伪并行”？
3. 我们排期表上两个任务确实是同一天开始的，但实际一个是干等另一个先出接口，另一个又在等前一个确认字段，两个人都觉得自己被卡住了，可图上完全看不出来。
伪并行的典型症状是：两个任务同时开工，但每天的实际产出都在等对方，责任边界还特别模糊。排查用三个动作就够了。第一，问一句“后置任务第一天的输入具体是什么、从哪来”，如果答不出具体交付物，就是伪并行。第二，看两个任务是否抢同一个人或同一套环境资源，抢资源就说明它们不该同时启动。
第三，看前置任务的中间产出有没有明确交付时点，没有就补一个。改法通常是拆任务：把那个中间产出单独列成一个短周期的交付节点，用它去连后续任务，依赖关系一下就从“互相等”变成“单向等”。
SS 依赖加完之后谁来维护、多久更新一次？一张排期表至少要建哪些字段？
4. 我们的排期表是项目启动会上一次性连好的，两周后需求变了、人换了，依赖关系没人动，图上还是老样子，等到延期了才发现整条链路早就失效了。
先建字段，再定人和节奏。字段至少六项：依赖类型、滞后量及其依据、前置责任人、后置责任人、触发条件（什么事件意味着可以开始）、上次确认日和下次复核日。
录入规则上，限制只有项目经理和任务责任人有权加依赖，加之前必须回答三个问题：后置任务的输入是什么、这个输入什么时候可用、如果不连这条依赖最坏会怎样，答不上来的先不连。维护节奏建议按两级走：每周例会上只过未来一到两周内即将触发的依赖，迭代评审或里程碑结束时做一次全量复核。
解除标准也要写死，前置任务取消、产出物不再被后置依赖、滞后量已过且后置已启动，满足任意一条就删掉。最后记住一条反直觉的原则：依赖不是越多越严谨，能删就删，画成蜘蛛网的排期图没人维护得动。
核心关键词
文章包含AI辅助创作：SS管理方法大全：实施团队任务依赖最佳实践落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/387776
读者评论
把SS依赖翻译成'你动了我才有条件动'，比教材上干巴巴的定义好懂太多。我们团队排期图里一堆lag=0的连线，看完才意识到那些根本不是依赖，只是画着好看，实际启动条件根本没对齐。
滞后量那组模拟数据挺有说服力，0天和3天的返工风险差了四倍。不过实际项目里滞后量依据往往是拍脑袋定的，作者说必须说出具体依据，这点执行起来比想象中难，需要上游交付物粒度足够清晰。
责任稀释那段说到痛点了。我们复盘会经常出现两条并行线互相甩锅的情况，因为都是'进行中'没有交接点。给每条依赖指定触发责任人和接收责任人这个做法值得试试，至少比反复开协调会实在。
五问判断清单和37条删到16条的统计很接地气。但删依赖这件事在跨团队协作里阻力不小，别人会觉得你不重视他的工作。作者提到设硬规则、能说出删除后果才保留，这个理由比较容易说服人。