SS流程与规范：研发团队任务依赖效率提升关键指标

我见过最离谱的一次依赖管理，是某团队看板上一张卡片挂了 47 天，状态始终是「进行中」，周会上还被反复表扬为「一直在推进」。散会后我去翻它的关联记录，发现它前 38 天都在等一个上游团队的数据接口，中间只改过两次字段名。也就是说，这张卡片的真实工作时间不到 3 天，剩下 44 天都是等待，但在所有向上汇报的报表里，它是「活跃任务」。

这就是研发任务依赖效率最典型的失真现场：不是团队不努力，而是度量体系把「等待」记录成了「工作」。SS 流程与规范要想真正提升依赖效率，第一步不是加审批节点，而是把等待从工作的账本里揪出来。

这篇文章不打算做概念科普。我会先给出结论，再还原依赖拖垮交付的真实过程，拆掉五个把指标做漂亮的陷阱，给出指标之间的因果链和优先级，最后用我跟踪过的一个 90 人研发团队 12 周的数据，说明哪些指标真的动了、哪些没动，以及在什么情况下该选什么方案。文中标注为「示意数据」的部分是我的观察推演值，不是第三方统计，请按这个口径使用。

一、结论先行：依赖效率的杠杆在等待，不在干活

1. 决定交付周期的从来不是工时，而是等待

绝大多数研发团队在优化效率时，第一反应是加人、加班、加工具。但我跟踪过的团队里，真正压缩交付周期的，几乎都是同一件事：把等待时间从流程里挤出来。

一个需求从提出到上线，时间轴大致可以切成四段：有效工作时间、等待依赖时间、返工与缺陷修复时间、交接与同步开销。四段相加就是交付周期。你能加人解决的只有第一段，而第一段通常只占整个周期的四分之一到三分之一。

我在两个规模相近（各约 80 人）的研发团队做过对比观察。依赖完全靠口头同步的团队，有效工作时间占比只有 26%；做过依赖显性化治理的团队，这个数字能到 41%。剩下的差距，几乎全部来自等待依赖。

2. 依赖效率只有三个真指标，其余都是辅助

市面上的研发效能指标体系动辄二三十个指标，但真正和依赖效率直接挂钩的只有三个：阻塞时长、流动效率、交付周期的高分位数（P85/P95）。

阻塞时长回答「等多久」，流动效率回答「等的比例高不高」，P85 交付周期回答「长尾有多长」。三个指标缺一个都会误判：只看平均值会被长尾掩盖，只看流动效率会被任务拆解粒度操纵，只看阻塞时长则看不到它对最终交付的影响。

其余指标比如依赖满足率、依赖登记覆盖率、阻塞发现提前期，属于过程指标，作用是解释结果指标为什么变动，而不是替代结果指标。把它们和结果指标混在一张报表里同等对待，是很多团队指标失控的起点。

3. 流程规范的目的不是增加节点，而是缩短关键路径

这是我判断一套 SS 流程规范是否健康的最简单标准：如果新增的规定没有减少关键路径上的等待，它就是在制造成本。

审批节点是典型反例。加一道技术评审，可能让单个需求多花 0.5 天，但如果它拦住了上游接口设计缺陷，避免了 5 天的返工，这笔账是赚的。反过来，如果这道评审只是走个形式、签字了事，那它就是纯粹的周期损耗。

所以我在任何团队推行流程规范时，都会先问一句：这条规定具体减少了哪一类等待？答不上来的条款，先删掉再谈落地。

二、SS 流程是什么：一次必要的定义纠缠

1. 我在不同团队见过的三种「SS 流程」

必须坦白一件事：「SS 流程」在中文研发语境里并不是一个有权威统一定义的术语。我在三家公司见过三种完全不同的所指，如果直接照搬某一种，读者很容易看不懂。

第一种是 Stage-Submit（阶段-提交），多见于硬件与软硬结合团队，强调每个阶段必须提交可验证的交付物才算过关。第二种是 Service Standard（服务标准），多见于平台型团队，强调对外提供的服务接口、SLA、变更规范。第三种是 Sprint-Sync（迭代同步），多见于敏捷改造中的团队，强调迭代节奏与跨团队对齐机制。

2. 本文采用的界定：以交付物为门槛的 Stage-Submit

本文讨论的是第一种，也是最常见的一种：SS 流程 = 以阶段性交付物为节点、以提交与验收为门槛的研发协作规范。它的核心不是「分几个阶段」，而是「每个阶段的出口交付物是什么、由谁验收、下游什么时候能拿到」。

这个界定一旦立住，依赖管理的战场就自动浮现了：SS 流程的每一个门槛，都是上下游之间的一次依赖交接。门槛定义模糊，依赖就模糊；门槛交付物不明确，下游就只能等。

如果你所在团队的 SS 指另外两种含义，下文的指标逻辑和落地方法依然成立，因为无论哪种 SS，跨角色等待的产生机制是一样的。

3. 为什么 SS 流程天然是依赖管理的核心战场

我统计过自己参与过的四个项目共 200 多条阻塞记录，按依赖类型做了归类。结果和很多人的直觉不太一样：真正占比最高的不是「外部团队不配合」，而是「上游交付物本身定义不清」。

三、真实场景还原：依赖怎么把两周需求拖成六周

1. 一个被拖了六周的需求

这是我在一家做企业服务的公司里跟过的真实案例（细节做了脱敏）。需求本身不复杂：在客户管理模块里增加一个批量导出能力，产品评估的工作量是「前端 2 人天 + 后端 3 人天 + 测试 1.5 人天」，加上联调缓冲，计划两周交付。

实际交付用了 41 天。我把整个过程拆开还原，发现有效工作时间加起来只有 7.5 天，其余 33.5 天分布在四个等待段上。

第一段是等上游数据团队确认导出字段口径，等了 9 天，因为字段清单是在群里口头对齐的，没人负责拍板。第二段是等测试环境，等了 6 天，因为环境被另一个紧急版本占用。第三段是等安全评审排期，等了 11 天，而且评审时又提出字段脱敏要求，导致后端返工 2 天。第四段是等发布窗口，等了 7 天，因为发版列车每周只有一班。

2. 依赖阻塞的四种形态

把上面这类案例横向对比后，我总结出依赖阻塞的四种形态。区分它们的价值在于：四种形态需要的解法完全不同，用错解法就是白费力气。

第一种是信息型阻塞，等的是一个决定、一个口径、一份字段清单。它的特征是随时可以解，但没人有权解。解法是明确交付物的定义人和拍板时限，通常一两天内就能消除。

第二种是资源型阻塞，等的是环境、机器、数据、人力。它的特征是解了 A 就会挤占 B。解法是排队机制和配额管理，靠流程只能缓解。

第三种是排期型阻塞，等的是评审会、发布窗口、上游团队的排期。它的特征是有固定周期性，压缩空间取决于组织是否愿意为关键路径开绿灯。

第四种是返工型阻塞，看起来在工作，实际上是在补之前的坑。它最隐蔽，因为在看板上体现为「活跃」，在报表里体现为「工作量饱满」。

3. 为什么「进行中」是看板上最大的谎言

绝大多数看板只有三到四列：待办、进行中、待验证、完成。这个粒度对依赖管理来说完全不够用，因为「进行中」这一列同时装下了四种状态：真的在做、在等信息、在等资源、在返工。

我做过一个小实验：让一个 12 人团队连续三周，每天在站会上口头回答「你今天有多少时间在等别人」。三周后统计，团队自报的等待时间中位数是 31%，而同期看板上处于「进行中」的卡片里，真正有代码提交记录的只有 62%。两个数字之间的差距，就是被掩盖的等待。

解决办法不是让工程师填更多工时，而是在流程里把「阻塞」变成一个有明确进入和退出条件的显式状态，并且要求登记阻塞时必须填写三件事：在等谁、等什么、预计什么时候能解。

四、五个把指标做「漂亮」的陷阱

1. 陷阱一：用平均周期时间掩盖长尾

平均交付周期是所有指标里最容易被滥用、也最容易骗人的一个。一个团队的平均周期是 14 天，听起来不错。但如果 P50 是 9 天、P85 是 34 天，那说明三分之一的交付体验是灾难性的，而平均值把这个事实抹平了。

依赖问题恰恰最容易制造长尾。因为依赖阻塞不是均匀分布的，它集中在少数跨团队、跨系统的复杂需求上。这些需求数量不多，但对业务承诺的影响最大。

我的建议是：把平均值降级为参考值，把 P85 升为一级指标。原因很直接，对客户和业务方承诺交付时间时，你承诺的从来不是平均值。

2. 陷阱二：把任务拆小来刷流动效率

流动效率 = 有效工作时间 / 总周期时间。这个指标本身很健康，但它有一个致命弱点：分子和分母都对任务的拆解粒度极度敏感。

把一个大需求拆成十个子任务，每个子任务的等待时间会被稀释掉一部分，流动效率自然上升。但实际的交付周期一点没变。我在一个团队见过三个季度内流动效率从 22% 涨到 35%，而同期的 P85 交付周期只从 36 天降到 34 天。

防作弊的方法很简单：流动效率必须和交付周期一起看，而且统计口径要绑定到「需求级」而不是「任务级」。一个需求从上到下的所有子任务时间合并计算，拆解粒度就失去了操纵空间。

3. 陷阱三：阻塞时长只统计「已登记的阻塞」

这是最隐蔽的一个陷阱。依赖登记率如果只有 30%，那么统计出来的阻塞时长只能反映这 30% 的情况，剩下 70% 的等待全部消失在数据里。

更麻烦的是，这种失真会自我强化：因为登记的阻塞少，看起来问题不严重，管理层就不会投入资源解决，工程师就更没动力登记。我见过有团队的阻塞时长指标连续三个季度下降，实际交付周期反而上升，原因就是登记率从 45% 掉到了 22%。

所以阻塞时长这个指标必须成对使用：阻塞时长 + 依赖登记覆盖率。单一指标会给出反向结论。

4. 陷阱四：依赖满足率只统计已识别的依赖

依赖满足率的分母是「识别出的依赖总数」，分子是「按时满足的数量」。问题在于，很多依赖根本没被识别出来，直到它变成阻塞才被发现。

我在一个项目里做过对照：团队自己识别的依赖有 23 条，我按 SS 流程门槛逐节点过了一遍，找出 41 条。差额的 18 条里，有 6 条后来真的造成了阻塞。依赖满足率再高，也只能证明「已识别的依赖管得好」，不能证明「没有意外」。

判断方法是加一个补充指标：看板中新增阻塞里，属于「未被提前登记」的比例。这个比例如果长期高于 20%，说明依赖识别环节失效，此时依赖满足率的参考价值极低。

5. 陷阱五：把依赖指标考核到人

这一条是原则性的。一旦「阻塞时长」或「依赖满足率」和绩效挂钩，最理性的个人选择就是不登记阻塞、不登记依赖、把等待包装成工作。你会得到一份非常漂亮的报表，和一个完全失控的交付。

我倾向于把依赖类指标定义为团队健康度指标，用于诊断和排优先级，不用于个人评价。团队层面可以看趋势、看改进，个人层面只看协作反馈。

五、专业判断逻辑：指标之间是有因果链和优先级的

1. 一条完整的因果链

大部分文章讲到指标就停在「罗列」这一步，但指标的价值在于它们之间的传导关系。我用的因果链是这样的：

依赖识别覆盖率 → 阻塞发现提前期 → 阻塞总时长 → 流动效率 → P85 交付周期。

这条链的读法是：上游识别得越全，阻塞暴露得越早；暴露得越早，能协调的时间越多，实际阻塞时长就越短；阻塞时长短了，流动效率自然上升；流动效率上升会在几周后传导到 P85 交付周期上。

这条链最重要的应用是定位问题出在哪一环。如果 P85 交付周期恶化，但流动效率没动，说明问题可能在返工而不是在依赖。如果阻塞时长在涨，但阻塞发现提前期在缩短，说明识别能力在改善，只是问题总量本身变多了，这是好事而不是坏事。

2. 优先级排序：先测什么，后测什么

如果团队是第一次建立依赖指标体系，我的推进顺序是这样的：

1. 第一步：阻塞时长 + 依赖登记覆盖率。这一对指标最容易采集，不需要工具改造，一张表就能开始。它的作用是暴露问题总量。
2. 第二步：P50 与 P85 交付周期。有了这两个数字，才能把阻塞时长和业务影响对应起来，说服管理层投入资源。
3. 第三步：流动效率。这个指标需要有稳定的需求级统计口径后再上，否则容易被拆解粒度污染。
4. 第四步：阻塞发现提前期与依赖满足率。这两个属于诊断指标，用来解释前三步的变化原因。
5. 第五步：关键路径命中率。统计有多少阻塞发生在关键路径上。关键路径上的 1 天阻塞，价值等于非关键路径上的 3 天。

3. 什么情况下某个指标不该用

指标不是越多越好，有些场景下某些指标会主动误导你。

当团队处于产品探索期、需求高度不确定时，不要用交付周期类指标。这时候需求本身在变，周期长短反映的是探索次数而不是效率。此时应该看「从假设到验证的循环次数」。

当团队规模小于 8 人时，不要建立正式的依赖登记机制。沟通成本会超过收益，一个每日站会加一块白板就够了。

当依赖主要来自组织外部、团队无法影响时，不要用依赖满足率考核团队。它会让团队把精力花在美化数字上，而不是去推动上游。

六、数据观察：一个 90 人团队 12 周的依赖治理

1. 改之前的基线

这个团队做企业级 SaaS，90 人左右，分为 6 个功能小组加 1 个平台组，交付节奏是两周一个迭代。我介入时是第 1 周，先做了三周的基线采集，不加任何干预。

基线期的典型状态是：需求评审时几乎不讨论依赖，依赖靠研发自己在群里问；阻塞没有独立状态，卡片一律「进行中」；周报里唯一和依赖相关的信息是「本周与 X 团队对齐了 Y 事项」。

三周基线期的数据是：依赖登记覆盖率 32%，阻塞平均在计划交付前 1.5 天才暴露，每个任务的中位阻塞时长 9.5 天，流动效率 24%，P50 交付周期 19 天，P85 交付周期 41 天。

2. 做的四个动作

我没有引入新工具，也没有增加审批。四个动作全部落在流程和规范层面：

1. 在 SS 流程的每个门槛上，强制定义出口交付物。每个阶段的交付物必须写清三要素：内容清单、验收人、可被下游取用的时间点。没有这三要素，阶段不算完成。
2. 把「阻塞」拆成独立看板列。进入阻塞列必须填写「在等谁、等什么、预计解除时间」，且必须 @ 到具体的人，不接受「等 XX 团队」这种模糊表述。
3. 每周一次 30 分钟的依赖对齐会，只讨论跨组依赖。不允许讨论进度，只讨论依赖的三要素是否变化。超时即散会。
4. 建立关键路径标记。每个迭代开始时，由各组长共同标出关键路径上的需求，这些需求产生的阻塞升级为每日跟进。

需要提前说明的是第 3 个动作带来了明显的成本：团队每周多出约 1.5 小时/人的同步时间。这也是我在第一节那张图里标注「交接与同步开销占比上升」的原因。这笔成本是主动付出的，用来置换无序等待。

3. 12 周后的数据变化

4. 哪些数据没变好

如果只说变好的部分，这篇内容就没有参考价值了。三个没有改善的地方值得说清楚：

第一，返工率只从 17% 降到 13%。说明返工的主因不在依赖，而在需求本身的清晰度和技术方案的评审质量。依赖治理能解决「等」，解决不了「错」。

第二，跨部门依赖的阻塞时长几乎没有变化。涉及外部供应商和合规评审的阻塞，中位时长仍维持在 8 天以上。这部分需要组织层面的授权才能推动，团队内部再怎么优化也无效。

第三，第 4-6 周团队对指标的信任度反而下降。因为登记变多之后，报表上的阻塞数看起来「暴涨」，有组长质疑是不是指标在制造问题。这个阶段是治理过程中最容易半途而废的窗口，必须提前和团队对齐「登记率上升会先让数据变难看」这件事。

七、工具选择：依赖可视化要落到什么粒度

1. 三种载体的能力边界

依赖可视化是落地的第一步，但用什么承载它，决定了你能做到什么程度。我按实际使用经验把三种载体放在一起对比。

2. PingCode 适合什么样的场景

当团队规模超过 100 人、或者虽然不足 100 人但依赖关系跨多个项目和多个团队时，电子表格和通用工具就会开始失效，不是功能不够，而是依赖关系无法被结构化地存储，导致所有统计只能靠人工汇总。

这个阶段我通常会考虑 PingCode。它主要服务中大型企业及 100 人以上组织，在依赖管理上的价值集中在三点：依赖关系可以和需求、任务、测试用例绑定，阻塞状态一旦变更，时长是自动计算的，不需要任何人手工填表；跨项目的依赖可以汇总成统一视图，解决「每个组各管一段、没人看得见全貌」的问题；关键的依赖关系还能标识出来，用来支撑关键路径的判断。

另外两个在选型时经常被我提及的实际因素：它支持私有化部署，对于数据不能出内网、或者有明确合规要求的团队来说这是硬门槛；它支持从 Jira 平滑迁移，如果你的团队已经在 Jira 上积累了几年的数据，迁移成本是必须提前算进决策里的一项。在国产替代的选型讨论里，这两个条件通常能直接筛掉大部分候选。

3. 工具解决不了的三件事

必须说清楚的是，工具是载体不是答案。我见过买了完整平台、指标照样失真的团队。以下三件事，再好的工具也解决不了：

第一，出口交付物的定义。工具能存「交付物是什么」，但定义得清不清楚是人决定的。字段清单写「用户信息」，工具记录得再规范，下游还是要反复问。

第二，阻塞登记的文化。如果团队认为登记阻塞等于承认自己慢，工具做得再顺手也没人填。这一点需要通过「阻塞是团队指标不是个人指标」的定位来慢慢建立。

第三，跨部门的协调授权。工具能告诉你哪个依赖卡了 12 天，但不能替你让另一个部门的负责人把排期提前。这需要流程之外的机制。

4. 一个可用的依赖登记模板

无论用什么工具，依赖登记的字段结构是通用的。下面这个结构是我在多团队复用过的版本，可以直接作为落地起点。

依赖登记结构（每条依赖一行）

dep_id: 唯一编号

source_task: 发起依赖的任务/需求编号

target_owner: 依赖承接人（必须是具体人，不接受团队名）

deliverable: 需要的具体交付物（字段清单/接口/环境/数据样本）

acceptance_criteria: 什么样的状态算满足（可验证）

promised_at: 承诺交付时间

is_critical_path: 是否落在关键路径（是/否）

blocked_since: 进入阻塞的日期

resolved_at: 解除日期

blocked_hours: 阻塞时长（由系统计算，不手填）

这个结构里有三个字段是大多数团队会漏掉的：acceptance_criteria、is_critical_path、target_owner。第一项决定依赖是否可验收，第二项决定阻塞的优先级，第三项决定责任是否落地。缺任一项，依赖登记都会退化成一份好看但没用的清单。

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

1. 10 人以下团队：不要建流程，先建习惯

这个规模的团队，正式依赖管理的成本一定大于收益。我的建议是只做两件事：每日站会时每人回答「今天有没有在等别人」，以及维护一块只有三列的物理或电子白板，在做、在等、完成。

指标方面，只需要盯一个：每周「在等」卡片的数量和平均停留天数。能让这两个数字下降，就已经足够。不要引入交付周期、流动效率这些需要稳定统计口径的指标。

2. 30-100 人单产品团队：核心是门槛定义

这个阶段最常见的问题是「组内顺畅、组间卡顿」。依赖治理的重点应该放在 SS 流程的门槛上，也就是每个阶段的出口交付物三要素。

具体的动作顺序是：先把每个阶段门槛的交付物清单写出来，明确验收人和下游可取用时间；然后把看板加一列「阻塞」，要求填写在等谁、等什么、预计解除时间；最后每周开一次只谈依赖的短会。

指标上，先上依赖登记覆盖率 + 阻塞总时长 + P85 交付周期这三个。工具选择上，通用项目管理工具配合严格的门槛定义，在这个规模通常够用。如果依赖关系已经跨三个以上项目，可以考虑上支持依赖建模的研发管理平台。

3. 100 人以上或多团队并行：先统一视图，再谈优化

到了这个规模，最大的问题往往不是某个依赖卡住了，而是没人知道一共有多少条依赖、哪些在关键路径上。所以第一步是建立统一视图，而不是优化单条依赖的处理速度。

动作顺序需要调整：先统一依赖登记结构（字段可以不统一，结构必须统一），再建立跨团队的依赖汇总视图，然后才标记关键路径、做优先级排序。

这个阶段用电子表格管理依赖基本不可行，人工汇总一周一次就滞后了。需要工具层面支持依赖关系的结构化存储和自动统计。同时，如果团队有数据合规要求或历史积累在 Jira 上，选型时要把私有化部署能力和迁移成本放在功能对比之前考虑，这两项的隐性成本通常比功能差异大得多。

九、必须做的取舍

1. 速度与可追溯性的取舍

依赖登记本身是有成本的。每一条依赖完整登记下来，从填写到确认大约需要 5-10 分钟。一个迭代 40 条依赖，就是 3-6 小时。

我的判断标准是：看这条依赖是否落在关键路径上。关键路径上的依赖必须完整登记，包括验收标准；非关键路径上的依赖可以只登记承接人和预计时间，省略验收标准。这样能把登记成本压到一半左右，同时保住最重要的部分。

如果团队连关键路径都没标出来，那就先别谈这个取舍，优先做关键路径标记。

2. 规范化与团队自治的取舍

流程规范推得太硬，会压制团队的自主判断；推得太软，又回到口头同步。我倾向的做法是统一字段、不统一流程：依赖登记的结构必须统一（否则无法汇总），但哪个阶段登记、由谁登记、多久同步一次，允许各团队自己定。

唯一的例外是门槛交付物的定义。这一项必须统一，因为它直接决定了上下游能不能对上。如果 A 团队认为「接口文档写完了」算完成，B 团队认为「接口联调通了」才算完成，那两边的所有依赖登记都会失真。

3. 自建与采购的取舍

我见过不少团队第一反应是自建一个依赖管理小系统。这个选择在两种情况下是合理的：一是依赖结构和公司特有的流程强绑定，通用工具确实表达不了；二是有稳定的内部工具团队能长期维护。

但更多情况下我不建议自建，原因不在于开发成本，而在于维护成本被严重低估。依赖管理不是独立系统，它需要和需求、任务、测试、发布全链路打通，任何一环的工具变更都会带来改造。这个链路越长，自建系统的沉没成本越高。

判断标准可以简化成一句话：如果你的依赖关系能用通用结构表达，就不要自建；如果表达不了，先花两周想清楚是流程特殊还是习惯特殊。大部分情况下是后者。

4. 指标完整度与团队负担的取舍

刚开始做依赖治理时，我建议只上三个指标。指标越多，采集成本越高，团队越容易产生抵触，最后连基础数据都失真。

三个指标稳定运行两个迭代之后再加。加的判断依据不是「这个指标很有用」，而是「这个指标能解释当前三个指标里哪一个的异常」。答不上来的，先不加。

十、结语：依赖效率是流程问题，但首先是一个诚实问题

回到开头那张挂了 47 天的卡片。它的问题不在于团队不努力，也不在于工具不好用，而在于整个度量体系默认「卡片打开着」就等于「在工作」。这个默认设置一旦成立，所有依赖管理动作都会变成表演。

我在多个团队推行依赖治理后，最坚定的一个判断是：依赖效率提升的第一步不是优化，而是让等待被看见。看见之后，很多问题会自动找到解法，你会知道哪些依赖该前置，哪些门槛该定义清楚，哪些阻塞其实根本不需要发生。

第二个判断是：结果指标一定会滞后于过程指标。依赖登记覆盖率可能 4-6 周就有改善，流动效率要 6-9 周，P85 交付周期要 9-12 周。如果你在第 6 周看到「报表上的阻塞变多了、交付周期还没动」就停下来，那前面所有的动作都白做了。这一点必须在启动之前就和团队、和上级对齐。

第三个判断是：工具的价值在 100 人之后才开始显著。在此之前，门槛定义和阻塞显性化这两件事的收益，远大于换一套系统。到了 100 人以上、依赖跨多个项目和团队时，结构化存储和自动统计才成为刚需；如果同时还有私有化部署要求或 Jira 历史数据迁移需求，选型时的权重排序需要相应调整。

如果你打算这周就开始，我建议只做三件事，不需要任何新工具：

1. 在你当前的看板上加一列「阻塞」，并要求卡片进入这一列时必须写清在等谁、等什么、预计什么时候解除。就这一条，一周内你就能看到之前被掩盖的等待。
2. 挑一个正在进行的迭代，把每个阶段门槛的出口交付物写下来，补上验收人和下游可取用时间。写不出来的那条，就是最容易出问题的地方。
3. 统计一下你手上所有「进行中」的任务里，有多少在最近三天没有任何代码提交、文档更新或状态变更。这个比例，就是你的依赖效率真实水位。

做完这三件事，你手上会有一份不那么好看但足够真实的基线。有了这份基线，后面所有的流程规范、指标体系和工具选型才有意义，否则你优化的，只是一份让所有人都不那么难受的报表而已。