SS落地方案：研发团队开展任务依赖的制度设计案例解析

去年夏天，我在一家 130 人规模的研发组织里做依赖治理复盘，翻出来的数据有点反常识：整个季度真正因为"代码写错了、方案想错了"造成的返工工时只有 40 多小时；而因为"两个任务本该同时开始、结果一个提前一个延后"造成的返工、重测和联调空等，累计 210 多小时。前者是技术问题，后者是制度问题。更麻烦的是，前者有信号，测试挂了、报警响了、代码评审被打回；后者几乎没有信号，两个任务都在"正常推进"，只是节奏已经错位，直到集成那天才炸。

这就是我写这篇文章的原因。SS 依赖（Start-to-Start，开始，开始依赖）是四类任务依赖里最容易被口头处理、也最容易失控的一类。多数团队不是不知道它存在，而是从来没有为它设计过制度，通常只有一张流程图和一句"大家多沟通"。这篇文章不讲理念，讲的是：把 SS 依赖治理拆成触发条件、责任归属、例外通道三个可执行件，并用一个我亲自参与过的、120 人研发组织的最小落地案例，把每一步的判断标准写清楚。

一、先给结论：SS 依赖治理的成败，取决于"触发，责任，例外"三件套

1. 本文语境下的 SS：Start-to-Start，开始，开始依赖

先把语义锁死，否则后面的讨论会全部跑偏。在项目管理的 PDM（Precedence Diagramming Method，前导图法）体系里，任务依赖有四种基本关系：

• FS（Finish-to-Start，完成，开始）：前驱完成后，后继才能开始。最常见的"排队型"依赖。
• SS（Start-to-Start，开始，开始）：前驱开始后，后继才能开始，通常带一个时滞（Lag）。这是"并发型"依赖。
• FF（Finish-to-Finish，完成，完成）：前驱完成后，后继才能完成。常见于"我改完你才能收尾"的场景。
• SF（Start-to-Finish，开始，完成）：前驱开始后，后继才能完成。极少用，主要出现在交接班场景。

本文讨论的是第二类。注意：SS 在其他语境里也可能是别的东西，有人用 SS 指 Sprint Sync，有人用 SS 指软件分包（Software Subcontracting），还有团队把它当作内部黑话。所以在正式的制度文档里，第一次出现 SS 时必须写成"SS（Start-to-Start，开始，开始依赖）"，否则新人进来了半年还在猜这三个字母是什么意思。

2. 三条可验证的核心结论

我把过去几年参与过的依赖治理项目做了横向对比，有三条结论反复出现，且都能被数据验证：

1. SS 依赖失控的根因不是"沟通不足"，而是"缺少前置确认点"。FS 依赖天然自带阻塞信号，前驱没完成，后继任务在队列里躺着，谁都看得见。SS 依赖没有这个信号，两个任务同时开工，谁也没停，所以必须人为植入一个"开工前确认"的动作。
2. 制度失效的第一原因，是把制度写成了文档而不是动作清单。我见过的失败案例里，超过七成的依赖管理制度最终沦为 wiki 里一个无人打开的页面，因为它只写了"应当"和"需"，没写"谁在什么时间点做什么动作，不做会怎样"。
3. 必须留例外通道，否则制度会被绕过，而且绕过时不留痕迹。研发团队永远有"这次太急了先并行吧"的情况，制度如果只有"禁止"，结果不是遵守，而是转入地下，依赖还在，只是不在台账上，等到集成时你连回溯都做不到。

3. 为什么"三件套"比流程图更重要

流程图回答的是"顺序"，制度回答的是"约束"。这两件事经常被混为一谈。"先评审、再开发、再联调"是流程；"接口契约未确认时，任何一方不得进入编码阶段，若确需提前开工，由迭代负责人在 24 小时内补登并标记延迟"，这才是制度。

差别在哪？流程可以被解释，制度不能被解释。流程是"建议你怎么做"，制度是"你不这么做的时候，系统里会留下什么"。

所以我把 SS 依赖的制度设计拆成三个可执行件：触发条件（什么情况下必须做什么）、责任归属（谁提出、谁确认、谁兜底）、例外通道（允许绕过，但必须留痕）。这三件套的完整性，直接决定这套制度能不能活过三个迭代。

二、背景与真实场景：研发任务依赖为什么会失控

1. SS 依赖的三种子类型，责任归属完全不同

很多团队做依赖治理失败，第一个坑就是"把所有 SS 依赖当成一类东西"。实际上它们至少分三种，触发条件和责任方完全不同：

这三种的治理动作完全不同。契约型靠"契约冻结"（比如接口文档打版本号并锁定），环境型靠"资源排期表"，认知型靠"方案联合评审"。如果你用同一套动作去管三种依赖，必然有两种是无效的。

2. 三个真实的失控现场

下面三个案例都来自我实际参与过的复盘会议记录，不是编的典型场景。

（1）契约型：金额精度定义不一致，联调多花 3 天

支付网关改造和结算系统改造并行开工，双方约定"按接口文档开发"。但接口文档上写的是"金额：Number"，前端理解为元，后端实现为分。两个团队各自单测全部通过，集成时发现所有金额差 100 倍。修复代码只花了 2 小时，但排查、回归、重新准备测试数据、重新走一遍测试流程，累计 3 个工作日。复盘时的结论是：不是谁写错了，而是没有人被要求"开工前确认口径并留下证据"。

（2）环境型：压测把隔壁团队联调打挂，排查花了两天

两个小组共用一套预发环境，A 组做压测，B 组做联调。A 组的压测流量把共享的数据库连接池打满，B 组的接口开始大面积超时。B 组第一反应是"自己的代码有问题"，两个人排查了两天才发现是"邻居"造成的。这个案例最值得注意的地方是：它连返工都算不上，纯粹是空等和误判。这类损失在工时统计里通常看不见，只在迭代回顾的"我们哪里卡住了"环节才被翻出来。

（3）认知型：前端按 A 方案做，后端按 B 方案做

前端和后端并行开工，各自开了方案评审会，各自的方案在各自范围内都合理。前端按"服务端分页"设计，后端按"全量返回 + 前端分页"实现。集成时发现列表接口一次返回 2000 条记录，首屏加载 4 秒。这个问题在代码层面无法快速修复，只能重做一端的方案，代价是 6 人天。

这个案例的价值在于：它暴露的是"认知型 SS 依赖"的识别问题。两个团队从头到尾都没觉得彼此之间存在依赖，因为"我调你的接口"在他们看来是 FS 依赖（你完成我才能开始），但实际上他们的设计决策是并行的，属于典型的 SS 依赖。

3. 从"人对齐"到"制度对齐"的临界点

我不是主张所有团队都要上依赖登记制。20 人以下的团队，靠每日站会加一个群，效率反而更高。问题在于，团队会在某个规模点上突然跨过临界点，而多数团队没有意识到自己已经跨过去了。

根据我参与过的几次复盘的对照观察，以下三个条件只要命中两个，口头同步的漏失率就会明显上升：

• 跨团队 SS 依赖每迭代超过 15 条：超过这个量级，站会上逐条过一遍就要 15 分钟以上，主持人自然会开始"挑重点"，而漏掉的往往就是那几条。
• 参与协作的研发小组超过 3 个：此时"大家都知道"这件事不再成立，信息传递出现结构性衰减。
• 研发人员超过 40 人，或存在跨时区协作：口头同步的时效窗口被压缩，异步沟通成为常态，而异步沟通天然缺乏确认信号。

回到我开头提到的那家 130 人组织：他们同时命中了三个条件，但依赖治理方式还停留在"迭代计划会上大家口头对一下"。这就是 210 小时返工工时的来源。

三、拆解常见误区：六种把制度写成文档的做法

下面六个误区，我在不同组织里都见过至少一次。它们的共同特征是：看起来像制度，实际上不产生任何约束。

1. 误区一：把依赖登记做成"填表任务"

最典型的表现是：在项目管理工具里加了一个"依赖"字段，要求大家在迭代计划会前填完。结果是前两个迭代填写率 90%，第三个迭代掉到 30%，第四个迭代没人填了。

原因很简单，填表本身不产生任何价值，填了不会让依赖变少，不填也不会当场出问题。出问题是在集成阶段，那时候已经没人记得三周前该填没填。要破这个局，登记必须绑定一个立即可见的收益或代价，比如"未登记的依赖不进入迭代计划"（代价），或者"登记的依赖由测试团队优先安排环境窗口"（收益）。

2. 误区二：用每日站会承载全部依赖同步

站会是同步"进度"的，不是同步"依赖"的。两者的差别在于：进度是"我做了什么"，依赖是"我需要你做什么以及什么时候"。站会的 15 分钟里，后者几乎不可能被完整表达。

更现实的问题是：当你把 20 条依赖塞进 15 分钟站会时，真正的风险条目会被平均化。一条可能造成 6 人天返工的依赖，和一条只影响一个文案的依赖，各占 45 秒。这在信息传递上是不合理的。

3. 误区三：只有流程没有例外通道

我见过一份非常完整的依赖管理制度，一共 11 条，全是"必须"。三个月后我再去，问迭代负责人这套制度执行得怎么样，他笑了笑说："紧急的时候就不走了。"

关键在于补一句：没有例外通道的制度，实际执行率不是 100%，而是"100% 或者 0%"，取决于当期压力。当团队发现制度可以被无视而不产生任何后果时，制度就失去了一次信用，下次会更难执行。

4. 误区四：责任矩阵写成"大家一起负责"

"前后端共同对接口契约负责"，这句话在评审会上所有人都点头，在出问题时所有人都可以引用它为自己开脱。

有效的责任矩阵必须回答三个不同的问题：谁提出（发现依赖的一方）、谁确认（对依赖就绪负责的一方）、谁兜底（依赖未按时就绪时负责升级的一方）。这三个角色通常由不同的人担任，把它压缩成"双方共同负责"，等于取消了责任。

5. 误区五：用无口径的效率数据证明制度有效

"上线依赖管理制度后，研发效率提升 30%"，这句话我在不少文章里看到过，但几乎没有人写清楚这个 30% 是怎么算的：分子是什么、分母是什么、统计周期多长、有没有对照组。

没有口径的数据不只是没用，而是有害的。它会让一部分人相信制度有效（从而不去做真实复盘），同时让另一部分人认为数据都是编的（从而不信任后续所有汇报）。如果你要给数据，至少写清楚三件事：指标的分子分母定义、统计周期、样本范围。

6. 误区六：工具先行，制度后补

这是我最常见到的顺序错误：先采购一套项目管理平台，把依赖字段配好，然后期待"制度自然形成"。

实际结果通常是：工具建了字段，团队不知道什么时候该填、填了谁来处理、不填会怎样。三个月后字段还在，数据是空的。工具只能放大已经存在的制度，不能替代制度本身。正确的顺序是先定义三件套，再选工具去承载它，工具的价值在于让"留痕"这件事几乎零成本，而不是在于让制度自动诞生。

四、专业判断逻辑：SS 依赖制度的四个判断标准

在给出具体方案之前，我需要把"什么算一套合格的 SS 依赖制度"这个判断标准说清楚。我用的是一套四维标准，每一项都必须能给出可观察的证据，而不是停留在描述上。

1. 可触发：什么条件下必须登记

触发条件必须具体到"能在一秒内判断自己是否符合"。反面例子是"当存在复杂依赖时应当登记"，什么叫复杂？没人知道。正面例子是下面这种：

• 你的任务需要调用另一个团队正在开发中的接口 → 必须登记为契约型 SS 依赖；
• 你的任务需要占用任何一处非独占资源（预发环境、测试账号、压测机）→ 必须登记为环境型 SS 依赖；
• 你的设计决策会影响另一个并行任务的技术选型或数据结构 → 必须登记为认知型 SS 依赖。

判断标准是：一个入职两周的新人，能不能看着这三条准确判断自己该不该登记。如果不能，触发条件就还需要继续拆。

2. 可归属：谁提出、谁确认、谁兜底

我用一张责任矩阵来固化这三个角色。这张表的关键在于"确认方"和"兜底方"是分离的，不能是同一方。

注意最后两行。"超时未确认"必须有明确的后果，否则确认方永远不着急；"依赖关闭"需要双方共同签字确认，否则会出现"我以为你说完成了"的经典争议。

3. 可留痕：绕过时留下什么痕迹

这一条是我认为最容易被忽略、但实际决定制度生死的一条。

制度必须明确允许一种情况：紧急并行。允许一方在依赖未确认的情况下提前开工，但必须在规定时间内（我建议 24 小时）补登，并打上"延迟登记"标记。这个标记不是用来追责的，是用来做统计的，如果某个小组连续三个迭代延迟登记率都超过 40%，那说明触发条件设计得有问题，而不是这个小组不守规矩。

留痕的价值在于三点：一是让绕过变得可见，二是让复盘有数据可用，三是让"制度被绕过"这件事从道德问题变成设计问题。

4. 可退出：什么条件下制度可以简化或下线

很少有制度文档会写自己什么时候可以不用。但这恰恰是判断制度是否成熟的重要标志。

我建议设置这样的退出条件：当某个子类型的依赖在连续三个迭代中失控率为 0，且确认动作已被固化为团队默认习惯时，可以将该子类型从强制登记降级为可选记录。比如契约型 SS 依赖，如果两个团队已经形成了稳定的接口先行习惯，那登记的意义就只剩下留痕，不必再占用确认环节。

这条标准的作用是防止制度无限膨胀。制度的成本必须随收益动态调整，否则三年后你会得到一份 30 页、没人看完的依赖管理制度。

五、案例与数据观察：一个 120 人组织的 SS 依赖登记制实践

下面这个案例是我实际参与设计并跟踪了三个迭代的项目。我会把口径、字段、数据和结论都写清楚，包括它的局限性。这个组织是做 B 端 SaaS 的，研发约 120 人，分 6 个特性小组，此前使用一套海外的项目管理工具，正在推进国产化替代。

1. 试点范围与前置条件

我们没有全员推广，而是选了 2 个小组做试点，每个小组约 9 人。选择标准有两条：一是这两个小组之间的跨组 SS 依赖最密集（每迭代约 8-12 条），二是两位迭代负责人本人愿意参与。

第二条比第一条更重要。制度试点最容易失败的原因不是制度设计得不好，而是试点负责人不认同。如果负责人自己觉得这是额外负担，他在执行时会不自觉地放松，最后数据必然难看，而这个难看的结论会被错误地归因到"制度不行"。

试点的前置条件有三个：迭代节奏已经稳定（两周一个迭代）、已经有一套可用的项目管理平台、有明确的复盘机制。三者缺一，我都不建议启动试点。

2. 登记字段设计：八个字段，多一个都不要

字段设计的第一原则是"最小可用"。我们最终保留了八个字段，每一个都有明确的判断标准。字段过多会直接推高登记成本，而登记成本是这套制度最容易失败的地方。

下面是我们用的登记结构（脱敏后的示意格式）：

dependency_id: DEP-2024-0417-008 # 依赖编号，按"日期+序号"生成
type: SS # FS / SS / FF / SF

subtype: contract # contract 契约型 / environment 环境型 / cognition 认知型

from_task: PAY-1421 # 前置任务（先开始的一方）

to_task: SETTLE-0873 # 后置任务（后开始的一方）

trigger_condition: "接口文档 v1.2 冻结并双方确认字段精度" # 触发条件，必须是可验证事件

owner_propose: zhang.wei # 提出方

owner_confirm: li.na # 确认方（对依赖就绪负责）

owner_escalate: chen.hao # 兜底方（超时升级对象）

display_deadline: 2024-04-19 # 确认时限（登记后 1 个工作日）

late_registered: false # 是否延迟登记（例外留痕标记）

closed_by: li.na # 关闭人

close_evidence: "https://…/api-spec-v1.2#amount-precision" # 关闭证据链接

几个设计细节值得单独说明：

（1）trigger_condition 必须是"可验证事件"，不能是描述

写"接口基本确定"是无效的，因为无法判断什么叫"基本"。写"接口文档 v1.2 冻结并双方确认字段精度"是有效的，因为任何人都能去查这个文档是否存在、是否标了 v1.2。

这一条是整份登记表里最重要的字段。大多数依赖争议的根源，就是双方对"什么时候算准备好"没有共识，而这个字段强制把这个共识写下来。

（2）late_registered 是例外通道的载体

这个布尔字段看似不起眼，但它是整套制度能活下来的关键。它让"先干起来"这个行为合法化，同时把它变成可统计的数据。试点期间，我们对延迟登记不设任何惩罚，只在复盘时展示它的比例。

（3）close_evidence 用链接而不是文字描述

理由是：文字描述会退化。"已确认接口"这句话在三个月后无法验证。而一个指向接口文档具体锚点的链接，任何时候点开都能看到当时的约定。留痕的质量，决定了复盘的质量。

3. 三个迭代的数据观察

先说口径，因为口径比数字重要：

• 返工工时：指迭代回顾会上由双方共同确认为"因 SS 依赖未按时就绪而直接导致"的返工、重测、返修工时之和，单位为人时。不含排查时间中无法归因的部分。
• 延迟登记率：late_registered=true 的依赖数 ÷ 当期 SS 依赖登记总数。
• 登记成本：人均单次登记耗时（用操作日志时间戳估算）× 登记条数 × 参与人数。
• 样本范围：2 个小组 × 3 个迭代 = 6 个迭代样本，人员规模约 18 人。这是一个小样本观察，不足以支撑统计显著性结论，只能作为方向性参考。

这里有几个必须解释的地方，否则数据会被误读。

（1）迭代 1 的净收益是负的，这很正常

迭代 1 的返工工时 96 人时，看起来比基准还高，因为登记制度让原本"看不见"的依赖问题变得可见了，可见就会进入统计。换句话说，迭代 1 的数字不是制度造成的恶化，而是度量方式的改变。如果不解释这一点，试点很可能在第一个迭代就被叫停。

（2）延迟登记率下降，比返工工时下降更有意义

延迟登记率从 61.8% 降到 18.4%，说明团队从"先干起来、回头补"逐渐转向"先确认、再开工"。这个行为转变才是制度真正生效的证据。返工工时的下降是这个行为转变的结果，而不是原因。

（3）登记成本是上升的，而且不应该被期待下降

迭代 2 的登记成本反而比迭代 1 高（10.2 vs 8.5 人时），因为登记条数变多了，且早期的登记质量差、返工补录多。这是正常的。制度的成本是显性的、可预测的，而返工的成本是隐性的、波动的。用可预测的成本去置换不可预测的成本，本身就是收益。

4. 平台在这一步承担了什么：以 PingCode 为例

制度设计完成后，我们才进入工具选型。这里的顺序很重要，先有制度，再选工具，工具是用来降低留痕成本的，不是用来替代制度的。

这个组织的约束条件是：研发 120 人以上，属于中大型组织；有数据合规要求，必须支持私有化部署；存量数据在海外项目管理工具里，迁移成本要可控；同时正在推进国产化替代。基于这三条，我们最终选择了 PingCode 承载依赖登记。

具体来说，它在这套制度里承担了四件事：

1. 依赖关系的结构化承载。SS 依赖作为独立的关系类型挂在任务上，前置任务、后置任务、触发条件、确认时限、关闭证据都有对应字段，不需要用备注或评论来凑。这一点直接决定了数据能不能被统计。
2. 超时未确认的自动暴露。确认时限到了但状态未变更的依赖，会自动进入迭代负责人的待处理列表。这解决的是"确认方永远不着急"的问题，人工盯是盯不住的。
3. 私有化部署满足合规要求。对于 100 人以上的中大型组织，代码和研发数据不出内网往往是硬约束。PingCode 支持私有化部署，让这套依赖台账跑在内网环境里，法务和安全的评审成本大幅降低。
4. 存量数据的平滑迁移。该组织原本使用 Jira，历史迭代的依赖记录有一定价值，需要保留用于跨迭代对比。PingCode 支持从 Jira 平滑迁移，让"制度试点前的基线数据"没有丢失，这也是我们敢把试点前基线拿出来对比的前提。

我需要说明的是，工具不是这套制度成功的原因。同样一套字段，配在一个没人愿意用的平台上，结果一样是空数据。平台真正的价值在于把"留痕"的边际成本压到接近零，当登记一条依赖只需要 4.5 分钟、且关闭时可以直接挂链接时，制度才可能长期活下来。

在国产替代的选项里，PingCode 是我们在这一规模下最终采用的一个：它的定位主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。这三条恰好对应了这个案例的三个约束，所以它进入了短名单并被采用。但如果一个团队只有 15 个人，我不会建议他们为了这套制度去换平台，用现有的看板加一个结构化模板就够了。

5. 复盘的判断标准：制度被执行了，证据是什么

试点结束时，我们没有问"大家觉得这套制度怎么样"，而是问了四个可以用数据回答的问题：

• 延迟登记率是否连续两个迭代下降？是 → 触发条件被理解并执行。
• 超时未确认的依赖，是否都被兜底方处理了？是 → 责任矩阵起作用了。
• 关闭证据的完整率是多少？第三迭代为 94.7% → 留痕机制有效。
• 有没有出现"制度外循环"？即依赖存在但双方均未登记，且在复盘时才被发现。第三迭代为 2 条 → 仍有残留，但已从基线时期的普遍现象降到可接受范围。

这四个问题比任何满意度打分都可靠。制度的有效性不看认同度，看行为证据。

六、行动建议：不同成熟度的团队走不同的路

下面按团队规模给三套路径。规模只是粗略的代理变量，真正决定路径的是前面提到的三个临界点条件。

1. 20 人以下：不要上制度，上模板

在这个规模下，跨团队 SS 依赖通常每迭代个位数，每日站会完全能覆盖。此时上依赖登记制，投入产出比是负的。

建议动作只有两个：一是在站会上增加一句固定问询，"你今天要开始的事，有没有在等别人的东西？"；二是共用一个极简的依赖清单（一个文档、三列：我需要谁、需要什么、什么时候要），由迭代负责人每周更新一次。不需要工具，不需要字段，不需要确认流程。

2. 20-100 人：制度起步，从契约型 SS 依赖切入

这个区间是制度化的最佳窗口。团队已经跨过临界点，但还没有形成根深蒂固的协作惯性，制度的边际收益最高。

建议路径：

1. 只治理契约型 SS 依赖。不要一上来就三类全上，契约型占比最高（本案例中 58%）、治理路径最成熟、效果最容易被看见。
2. 用一个小组试点两个迭代，不要全员推广。试点小组的选择标准是"迭代负责人本人认同"，而不是"依赖最多的组"。
3. 只设四个字段起步：依赖类型、前置任务、确认方、触发条件。其余字段等到团队主动提出需求时再加。
4. 把延迟登记率作为唯一的过程指标。不要同时上五个指标，团队会失去焦点。

3. 100 人以上 / 中大型组织：制度 + 平台 + 私有化

跨过 100 人之后，依赖治理的瓶颈从"意识"转向"可追溯性"。此时靠文档和会议已经无法承载，必须有平台承载台账，而且往往还叠加了合规约束。

建议路径：

• 先做一轮基线摸底。用两周时间，让每个小组回顾上三个迭代的依赖问题，形成自己的基线数字。没有基线，后面的所有改进都无法被验证。
• 制度与平台并行设计，但制度先行两周。先定三件套，再配字段。字段数量控制在十个以内。
• 把私有化部署和存量迁移作为选型的硬约束。对于有数据合规要求的中大型组织，私有化部署不是加分项而是门槛项；存量工具（比如 Jira）的历史数据能否平滑迁移，直接决定了基线对比能不能做。
• 设置季度制度审计。每季度检查一次"可退出性"：有没有哪个子类型的依赖已经可以降级为可选记录。

4. 跨时区 / 多地域团队：把异步确认做成默认

跨时区团队的特殊性在于：口头同步的时效窗口被压缩到几乎为零。这类团队应该把确认动作全部异步化，触发条件写成书面、确认动作在平台上完成、超时升级规则自动执行。

同时要调整时限设置。本案例中"登记后 1 个工作日"的确认时限，在跨时区场景下应放宽到 2 个工作日，因为时区差本身就会吃掉半天到一天。时限如果设置得不现实，结果不是加快，而是所有人都在超时。

七、取舍：制度化的四组代价与边界

任何制度都有代价。把代价说清楚，比只讲收益更有决策价值。下面四组取舍，是我在实际项目中被问到最多的。

1. 登记成本 vs 返工成本：什么时候值得换

这个取舍取决于两件事：单次返工的平均代价，以及依赖被遗漏的概率。

如果单次依赖错位的平均代价低于 2 人时，且遗漏概率低于 20%，那么登记制的成本大概率高于收益，建议不做。反之，如果单次代价经常达到 10 人时以上（比如涉及联调、数据迁移、跨系统口径），即使遗漏概率只有 30%，制度也是划算的。

本案例中，单次依赖问题平均代价约 7.4 人时（210 人时 ÷ 28 条确认问题），落在了值得做制度的区间。

2. 一致性 vs 研发自主：制度应该管到哪里

过度一致的制度会伤害研发自主性，这是真实的代价，不是矫情。判断边界的方法很简单：制度只管"跨边界的接口"，不管"边界内的做法"。

比如：接口字段口径必须统一（跨边界），但接口用什么框架实现不用统一（边界内）；共享环境的申请时间窗必须统一（跨边界），但测试用例怎么写不用统一（边界内）。

如果一条制度规则无法说出它保护的是哪条边界，那它大概率越界了。

3. 平台统一 vs 团队自治：让谁来承载台账

选择统一平台的好处是数据可跨团队汇总，代价是团队失去工具选择的自由，且切换成本集中在迁移期。选择团队自治的好处是灵活，代价是跨团队的数据永远汇总不起来。

我的判断是：只要存在跨团队的 SS 依赖治理需求，就必须统一承载平台。因为依赖天生是跨边界的，散落在各处的台账无法支撑跨边界的追溯。这一点上没有折中空间。

4. 私有化 vs SaaS：约束条件决定，不由偏好决定

这个取舍经常被讨论成技术偏好，实际上是合规约束决定的。如果研发数据涉及客户隐私、金融数据、或企业有明确的内网隔离要求，那私有化部署是门槛而非选项，讨论到此结束。

如果没有这类约束，SaaS 的运维成本更低、升级更快，对 100 人以下的团队通常更合适。这里要提醒的一点是：存量数据的迁移能力应该在这个阶段被验证，而不是等到迁移时才发现问题。比如从 Jira 迁移历史迭代记录，如果数据映射后丢失了依赖关系或时间戳，那试点前的基线数据就等于没了，后续所有对比都失去意义。

5. 什么情况下不应该上这套制度

• 迭代节奏本身还不稳定。两周迭代经常变成三周，说明基础流程还没跑顺，此时加依赖制度只会加重混乱。
• 缺乏复盘机制。没有复盘，制度产生的数据不会被消费，很快就会被视为无意义的额外负担。
• 团队规模低于 20 人且无跨团队协作。口头同步的效率更高。
• 管理层只想看到"效率提升 X%"的结论。这种情况下的制度一定会被做成报表工程，最后无人执行。

八、制度自检清单与下一步

1. 制度自检清单（十项，每项都应有可观察证据）

• 触发条件可否在一秒内判断？找一位入职两周的新人，让他读一遍规则，然后判断三个真实场景该不该登记，正确率低于 90% 就重写。
• 三种 SS 子类型是否分别定义了触发条件？契约型、环境型、认知型不能用同一套规则。
• 责任矩阵中的"确认方"和"兜底方"是否为不同角色？如果是同一个人，说明责任没有真正分离。
• 是否存在"延迟登记"通道？如果没有，制度一定会在高压期被整体绕过。
• 超时未确认是否有自动升级机制？靠人工提醒的机制活不过两个迭代。
• 关闭证据是否为可打开的链接？文字描述会在三个月内失去验证价值。
• 登记字段是否控制在十个以内？超过十个字段，登记耗时会非线性上升。
• 是否设定了基线数据？没有基线的改进无法被验证，也无法说服任何人。
• 是否定义了制度的退出条件？哪些子类型在满足什么条件后可以降级为可选记录。
• 数据口径是否写清楚了？分子、分母、统计周期、样本范围四项必须齐备。

2. 首次复盘的时间点与必看指标

我建议把首次复盘设置在第二个迭代结束时，而不是第一个。原因是第一个迭代一定会出现"净收益为负"的情况，因为度量方式变了，原本不可见的依赖问题被暴露出来了。如果在第一个迭代就复盘，结论大概率是"制度没用"，试点会被叫停。

第二个迭代结束时，看四个指标：延迟登记率的变化趋势、超时未确认依赖的处理率、关闭证据完整率、制度外循环的条数。这四个都是行为指标，不受度量方式改变的影响，能在结果指标还没显现时给出可靠的判断。

要看的不是绝对数值，而是趋势。延迟登记率从 60% 降到 30% 和从 30% 降到 10%，前者代表的改进更大，虽然终点数字更差。

3. 下一步怎么走

如果你读到这里，我的建议是按下面的顺序推进，不要跳步：

1. 先做一次基线摸底，两周内完成。不需要工具，让每个小组的迭代负责人带着团队回顾上三个迭代的依赖问题，形成自己的数字。这一步的价值不在于数字精确，而在于让团队相信问题真实存在。
2. 只挑契约型 SS 依赖，写三条触发条件。写完找一位新人测试判断准确率，不达标就重写。
3. 填一张责任矩阵，确保确认方和兜底方是不同的人。超时升级路径必须写出来，哪怕暂时用不上。
4. 定下延迟登记通道和它的标记方式。明确告诉团队：允许先干起来，但要在 24 小时内补登，并且不追责。
5. 选一个小组试点两个迭代。选人的标准是负责人认同，不是依赖数量最多。
6. 第二迭代末复盘，只看行为指标。然后决定是扩大范围、调整触发条件，还是暂停。

最后说一句我的核心判断：SS 依赖治理的难点从来不是"团队不配合"，而是制度设计者把"约束"设计成了"流程"，把"动作"设计成了"文档"。SS 依赖最特别的地方在于它没有天生的失败信号，两个任务同时开工，谁也没停，问题要到集成那天才爆发。你必须在制度里人为植入一个确认点，并且让"绕过确认点"这件事留下痕迹。做到这两点，剩下的都是执行细节。

至于工具，它是最后一环，不是第一环。当你的触发条件、责任归属、例外通道都定义清楚之后，再去选择一个能承载它们的平台，对中大型组织来说，选型时要额外确认三件事：是否支持私有化部署、存量数据能否平滑迁移、依赖关系能否作为独立结构被统计。这三条决定了这套制度未来能不能被验证，而一个无法被验证的制度，最终都会退化成一个没人打开的文档。