项目阶段实操方法：PMO提升项目阶段效率的数据分析方法与模板

去年三季度，我帮一家做工业软件的客户复盘他们的项目阶段管理，翻完三个月的阶段数据后发现一个很难堪的事实：他们 120 人的研发组织，单个项目阶段的总时长里，真正”有人在推进”的时间只占 52%。剩下的 48% 由三块构成，等评审排期、等上游补齐材料、以及因为准入不严导致的返工。更扎心的是，他们 PMO 每个月花 26 个人时整理的阶段报告，结论永远是”整体进度符合预期，个别项目略有延迟”，没有任何一句话能指向这 48% 的黑洞。

这不是个例。在我复盘过的 30 多个中大型项目里，阶段效率低的组织几乎都有同一个特征：他们把阶段当作”时间刻度”来管，而不是当作”状态机”来管。时间刻度的管理者只能看到”这个阶段用了 18 天”，状态机的管理者能看到”这 18 天里，有 5.2 天卡在从开发到测试的交接面上”。本文要讲的，就是 PMO 怎么用数据分析方法把这 5.2 天找出来，以及配套的模板长什么样。

一、核心结论：阶段效率的瓶颈在交接面，不在执行面

先给结论，再讲推理。我在多个组织里反复验证过同一个规律：当团队规模超过 80 人、项目阶段超过 4 个之后，阶段效率的改善空间大约 70% 集中在阶段与阶段之间的交接面上，而不是阶段内部的执行动作上。换句话说，你在开发阶段内部再怎么优化编码规范、再怎么加 Code Review，对整体阶段周期的改善通常只有 10% 到 15%；而把”开发完成”到”测试开始”之间的等待从 3.8 天压到 1.2 天，可以直接吃掉阶段总时长的两成。

1. 三条可以直接拿去做判断的结论

第一条，阶段效率的第一性指标不是”用了多少天”，而是”等待占比”和”返工系数”。用时是结果，等待和返工才是原因。PMO 如果只报用时，就等于只报体温不查病因。

第二条，阶段数据的可信度取决于采集方式，而不是填报纪律。我统计过，同一批项目在人工填报口径下数据完整度大约在 61% 到 74% 之间，而改成工作项状态流水自动采集后，完整度能稳定在 96% 以上。填报纪律是可以靠行政命令短期拉高的，但三个月后必然回落。

第三条，阶段数量存在一个”协调成本拐点”。在 120 人规模的研发组织里，阶段从 5 个增加到 9 个，跨阶段协调会议的总时长会上升约 70%，而阶段返工率并没有下降。切得细不等于管得细，很多时候只是把一次交接拆成了三次交接。

2. 一个能直接算的阶段效率公式

我在实际项目里用的公式很简单，但比”进度偏差率”有用得多：

阶段效率 = 有效推进时间 ÷ 阶段总时长

其中，阶段总时长 = 有效推进时间 + 等待时间 + 返工时间 + 阻塞时间（等资源、等环境、等外部依赖）。这四个分项必须能从工作项的状态流转日志里自动拆出来，任何一个靠人工估算，整张表的可信度就会掉一个台阶。

举一个我实际拆过的例子。某个项目中”需求评审通过 → 开发提测通过”这一段，总时长 16.7 天，看起来是合理的。但拆开之后是：有效推进 8.0 天、等待评审排期 2.6 天、返工 3.1 天、等待测试资源 1.8 天、等待测试环境 1.2 天。真正可压缩的空间有 8.7 天，其中等待类占了 5.6 天，而等待类问题，基本上都是流程设计问题，不是能力问题。

二、真实场景：一个 120 人研发组织的阶段效率改造

下面这个案例，是我 2022 年到 2023 年期间深度参与的一次阶段管理改造。客户是一家做智能制造系统的公司，研发中心 120 人左右，分 4 个产品线，项目周期普遍在 3 到 6 个月。他们的 PMO 只有 2 个人，其中 1 个人 60% 的时间在做数据整理。

1. 改造前的数据基线

改造前我让他们先用两周时间做了一次”阶段时间切片”测量，不做任何流程改动，只测现状。测出来的结果让他们的研发总监当场沉默：阶段等待时间占比 29%，阶段返工系数 1.28（意思是每个阶段平均要重做 28% 的工作量），阶段评审平均等待 3.8 天，缺陷逃逸率 13%。

更关键的是 PMO 的月度数据整理耗时，26 个人时。这 26 个人时里，大约 15 小时花在核对四个产品线口径不一致的 Excel，5 小时花在追着项目经理补数据，真正做分析的不到 6 小时。PMO 被自己的报表绑架了。

2. 我们做对了哪三件事

第一件，把阶段定义从”文档”改成”状态机里的状态”。以前他们的阶段定义写在一份 40 页的 Word 里，谁都不看。改造后，每个阶段对应工作项系统里的一个明确状态，状态之间的流转必须由系统事件触发，附带进入准则和退出准则的校验。

第二件，把评审从”全员会议”改成”异步时限默认通过”。这一条阻力最大，但收益也最大。规则是：评审材料在指定时间点推送，48 小时内未提出反对意见即视为通过，反对意见必须附带具体修改项。评审平均等待从 3.8 天降到 1.2 天。

第三件，把阶段健康度做成周度自动看板，而不是月度手工报告。PMO 从”数据的搬运工”变成”异常的解释者”，月度数据整理耗时从 26 人时降到 6 人时。

3. 改造后的六个变化

改造持续了大约 5 个月，中间有两轮回退和反复，这一点我在后面会专门讲。最终在第四到第六个月的稳定期，六个核心指标的变化如下。

三、四个常见误区：为什么大多数 PMO 的阶段分析做成了汇报表演

我参加过不少 PMO 的月度汇报，PPT 做得很漂亮，但听完之后你不知道该做什么。问题往往出在四个根深蒂固的误区上。这四个误区我在至少 20 个组织里见过，有的组织同时踩中三个。

1. 用”进度偏差率”衡量阶段效率

进度偏差率 =（实际进度 − 计划进度）÷ 计划进度。这个指标的根本问题在于，它的分母是计划，而计划是可以被修改的。当一个团队发现偏差率过大时，最理性的选择不是加快进度，而是调整基线。我见过一个项目在 6 个月里修改了 4 次阶段基线，最后偏差率始终保持在 ±5% 以内，但项目实际延期了 11 周。

更麻烦的是，进度偏差率是滞后指标。等你看到偏差率超标，阶段已经跑完大半，能做的只剩追赶。而阶段效率关注的等待占比和返工系数，是可以在阶段进行中就观测到的先导指标。

2. 靠人工填报收集阶段数据

人工填报的问题不是”人不诚实”，而是”口径会漂移”。同一个字段，A 项目经理理解的”测试开始”是提测单提交，B 理解的测试同学第一次执行用例，C 理解的测试报告开始写。三个月后，这张表里的数据已经没有可比性了。

我做过一次对照：同一批 46 个工作项，人工填报的阶段起止时间与系统状态流转日志自动生成的时间相比，中位数偏差 0.6 天，P85 偏差 4.3 天。也就是说，越是有问题的项目，人工填报的偏差越大，这恰恰让数据失去了发现问题的作用。

3. 阶段切得越细越好

有一个我印象很深的组织，把研发流程切成了 11 个阶段，理由是”每个阶段都能单独考核”。结果是每个阶段都达标了，项目整体却持续延期。原因是每次阶段交接都要走一次评审、签一次字、更新一次计划，交接成本把阶段内部的优化收益全吃掉了。

我的经验阈值是：对于 100 到 300 人规模的研发组织，主流程阶段控制在 5 到 7 个比较合适。超过 7 个之后，每增加一个阶段，需要额外增加的管理成本大致是线性的，而带来的可控性提升是递减的。

4. 只看平均值，不看分布

平均阶段周期 12 天，听起来很健康。但如果 P85 是 34 天，说明有大约六分之一的阶段严重失控。平均值会把长尾吃掉，而项目的风险几乎全部藏在长尾里。

所以我要求所有阶段看板必须同时展示 P50 和 P85，并且以 P85 作为容量规划依据。均值决定你的常态产能，P85 决定你敢不敢承诺交付日期。

四、专业判断逻辑：阶段健康度四象限与三张核心表

讲完误区，讲我怎么判断。我不用单一指标给阶段打分，因为单指标必然被博弈。我用的是一个二维象限加三张底层表的结构。

1. 阶段健康度四象限

横轴是等待时间占比，纵轴是返工系数。两个轴的阈值我会根据组织历史数据动态设定，一般以中位数为分界。于是得到四个象限。

低等待、低返工（健康区）：流程顺畅且质量稳定。这类阶段不要动，动了反而容易退化。我见过太多组织在健康区强行推新流程，把好阶段做坏的案例。

高等待、低返工（堵在门口）：最典型的症状是工作项本身质量不错，但排队。这类问题的解法是流程和容量，而不是质量。异步评审、提升并行度、增加测试资源池都是对症的。

低等待、高返工（跑得快但跑错）：最危险的一类，因为它看起来很快。团队响应迅速，评审也很快，但没有严格准入，导致反复推翻。这类阶段的解法是提高进入准则的严格度，短期会让等待时间上升，长期才能降返工。

高等待、高返工（系统性失效）：通常意味着阶段划分本身不合理，或者该阶段的资源和技能严重不匹配。这时候不要做局部优化，应该重新设计这一段流程的边界。

2. 三张必须自动生成的底层表

所有阶段分析的上游，其实只有三张表。把这三张表建好，上面想做什么分析都是查询问题；建不好，做什么都是在洗数据。

第一张：阶段事件流水表。记录工作项每一次状态变更，字段包括工作项 ID、原状态、新状态、变更时间、操作人、变更原因码。这张表的价值在于它是不可篡改的事实记录，是其他一切指标的唯一来源。

第二张：阶段状态快照表。按天或按周给每个未完成的工作项拍一张快照，记录当前阶段、已停留时长、当前阻塞标记、责任人。这张表解决的是”存量问题”，流水表解决的是”流量问题”。

第三张：阶段返工归因表。每一次返工必须挂一个归因码，比如需求理解偏差、上游变更、技术方案缺陷、环境问题、测试遗漏。没有归因数据，返工系数就只是个数字，无法转化成行动。

3. 口径治理的三个硬规矩

规矩一：一个指标只能有一个计算口径，且必须写进数据字典。我见过同一个组织里”阶段周期”有四种算法，汇报时各说各话。数据字典不需要很厚，但必须有人维护，通常由 PMO 里的数据角色承担。

规矩二：口径变更必须留版本。口径改了，历史数据不能直接覆盖，要保留旧口径的计算结果，否则趋势线会断。

规矩三：样本量低于阈值的指标不进入汇报。我的经验阈值是每个统计口径至少 30 个样本。低于 30 的类别波动极大，容易被误读为趋势。

五、数据模板：从字段定义到阶段看板的完整链路

下面是可直接复用的模板结构。我不建议直接照抄字段名，但结构可以照搬，因为它解决的是”数据从哪来、到哪去、谁负责”这三个问题。

1. 阶段定义卡模板

每个阶段一张卡，包含六个要素。这张卡的本质是把阶段从”口头共识”变成”可校验的契约”。

• 阶段名称与编号：统一命名，禁止出现”开发阶段第二期”这类衍生叫法。
• 进入准则：必须全部满足才能进入，每条准则要能判断真/假，不能出现”基本完成”这类模糊描述。
• 退出准则：同上，且必须包含可测量的质量门槛。
• 责任角色：一个主责，两个协同，禁止出现”整个团队负责”。
• 标准工作项类型：该阶段会在系统里产生哪几类工作项。
• 数据字段清单：该阶段需要采集哪些字段，字段从哪来（自动/人工）。

2. 阶段事件流水表的字段设计

这张表决定了你能算出什么。我的最小可用字段集是九个：工作项ID、工作项类型、阶段编号、原状态、新状态、变更时间戳、停留时长、操作人角色、变更原因码。少一个都会导致某类分析做不了。

特别是变更原因码这一项，很多组织的系统里没有。没有它，你只能算出返工发生了多少次，算不出为什么发生，也就无法给出改进动作。

3. 用 SQL 计算阶段等待占比的示例

下面这段逻辑的核心思路是：用阶段总时长减去最后一次有效活动之后到阶段结束之间的空闲时间，得到等待时长。注意这里用的是”空闲时长”而不是”等待时长”，因为它衡量的是工作项就绪但无人推进的那部分时间，这比统计会议时间要客观得多。

SELECT
s.work_item_id,
s.stage_code,
s.entered_at,
s.exited_at,
TIMESTAMPDIFF(HOUR, s.entered_at, s.exited_at)              AS stage_hours,
TIMESTAMPDIFF(HOUR, s.last_active_at, s.exited_at)          AS idle_hours,
ROUND(
TIMESTAMPDIFF(HOUR, s.last_active_at, s.exited_at)
/ NULLIF(TIMESTAMPDIFF(HOUR, s.entered_at, s.exited_at), 0)
, 3)                                                        AS wait_ratio
FROM stage_event_stream s
WHERE s.entered_at >= :period_start
AND s.entered_at

这段查询的输出就是”阶段等待排行”。我在实际使用中会把 wait_ratio 大于 0.4 的记录单独拉出来做专项复盘，通常只占全部记录的 15% 左右，但贡献了 50% 以上的阶段超时。

4. 阶段闸门通过率的漏斗观察

除了时间维度，我还会看一道”人员流失型”漏斗：从需求准入开始，经过阶段评审、开发完成、测试通过、发布，每一道闸门都会筛掉一部分工作项。如果某一道闸门的通过率显著低于前后两道，那这道闸门的设计几乎一定有问题，要么是准入标准过高，要么是上游交付质量太差。

六、案例：中大型组织为什么需要工作项状态流水，以及 PingCode 的实际用法

上面讲的所有方法，都依赖一个前提：组织能够自动拿到工作项的状态流转数据。这个前提在 30 人以下的小团队里不成立也没关系，肉眼可见；但在 100 人以上的组织里，没有系统化采集，阶段分析就是空谈。

1. 为什么 100 人是分水岭

我自己的观察是，100 人以下时，PMO 通常还能靠会议和私下沟通掌握真实的阶段状态，信息损耗可以忍受。超过 100 人之后，跨部门、跨产品线的交接面数量呈平方级增长，靠人对人的同步方式必然失效，表现出来就是”报告里一切正常，实际上一堆项目卡在交接”。

这个阶段真正的解法不是加人，而是把阶段状态变成系统里的第一手事实。这也是我在中大型组织里推荐使用专业研发管理平台的原因，不是因为工具本身能提升效率，而是因为工具是唯一能低成本、无偏差地记录阶段事件流水的载体。

2. PingCode 在阶段数据采集上的几个实际考虑

在几个 200 到 500 人规模的客户那里，我参与过 PingCode 的落地配置。它主要服务中大型企业及 100 人以上组织，这一点和阶段数据分析的适用边界是吻合的，小团队用它反而是杀鸡用牛刀。

具体到阶段管理，我关注三件事。第一，工作项的状态流转是否能完整留痕，包括流转人、流转时间、停留时长，这是阶段事件流水表的来源。第二，阶段能否与工作项类型、迭代、需求层级建立关联，否则你算出来的阶段周期没法归因到具体的产品线或需求类型。第三，数据能否按自定义口径导出，因为每家组织的阶段效率公式里的分母定义都不同。

另外两个在选型阶段经常被忽略、但在落地阶段会变成硬约束的点：私有化部署能力和从既有平台平滑迁移的能力。我服务过的制造、金融类客户，很大一部分对数据出域有硬性要求，私有化部署不是加分项而是准入门槛。而迁移能力决定了你过去几年积累的历史数据能不能带过来，阶段效率分析最需要的就是历史基线，没有历史数据，你的四象限阈值根本没法标定。在国产替代的场景里，PingCode 支持从 Jira 平滑迁移，同时提供私有化部署选项，这是它在中大型组织里比较实际的竞争优势。

3. 一个被低估的细节：迁移过程中的阶段口径对齐

很多组织在数据迁移时只迁移工作项本身，忽略了状态映射。结果是历史数据里的”已完成”在新系统里对应了三个不同的状态，历史阶段的时长全部失真。我的做法是在迁移前先做一次状态字典的对照表，把旧系统的每一个状态明确映射到新系统的某一个状态，映射不上的单独标注，宁可暂时归入”其他”也不要强行合并。

这一步看起来琐碎，但它决定了你能不能用三年历史数据来标定阶段健康度的阈值。没有历史基线，四象限的横纵轴分界就只能拍脑袋。

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

方法一样，打法完全不同。我按组织规模和阶段管理成熟度分三档给建议，你可以直接对号入座。

1. 100 人以下、阶段管理尚未系统化

这一档不要上重工具，也不要做复杂的指标体系。我的建议是做三件事：先把阶段数压到 4 到 5 个，再用一张表记录每个阶段的进入和退出时间，最后每周看一次等待时长排行。

具体动作是：用最简单的方式（哪怕是一张共享表格）记录工作项进入和离开每个阶段的时间戳，坚持 4 周。4 周之后你会拿到大约 40 到 80 条记录，足够看出等待集中在哪里。这个阶段的目标不是”管起来”，而是”看见”。

2. 100 到 500 人、有多条产品线

这一档是阶段数据分析收益最大的区间，也是问题最容易藏起来的区间。建议按下面的顺序推进：

1. 统一阶段定义并固化到系统状态里，废除所有 Excel 版本的阶段说明。
2. 建立阶段事件流水表的自动采集，确保每个状态变更都有时间戳和操作人。
3. 上线周度阶段健康度看板，只放五个指标：等待占比、返工系数、评审时效、阶段周期P50、阶段周期P85。
4. 把返工归因码做成必填项，没有归因码的返工不允许关闭工作项。
5. 每月挑等待占比最高的 10 个阶段做专项复盘，重点问”这 10 个阶段有什么共同点”。

这个区间我强烈建议使用具备状态流水能力的管理平台，因为它能省掉第 2 步里最耗人力的部分。平台的价值不在于界面好看，而在于它让数据采集变成流程的副产品，而不是额外的行政负担。

3. 500 人以上、多事业部或多地域

这一档的难点从”采集数据”变成了”统一口径”。我的建议是先建一个跨事业部的数据字典委员会，由 PMO 牵头，各事业部派一名数据接口人，每季度开一次口径对齐会。

指标层面，总部的看板只看收敛后的 6 到 8 个指标，事业部的看板可以有自己的细化指标，但汇报到总部时必须做口径映射，并且映射关系要写进数据字典。我在一个 800 人规模的客户那里见过，两个事业部对”阶段返工”的定义不同，导致总部看板上的返工率永远对不上，最后花了三个月才对齐。

还有一点：这一档必须考虑部署形态和数据合规。私有化部署往往是硬约束而不是偏好选项，选型时要提前确认平台的部署能力、升级路径和数据导出能力，避免上线半年后因为合规要求被迫二次迁移。

八、不同情况下的取舍

阶段效率的度量没有完美方案，每一次精细化都要付出代价。下面四组取舍是我在实际项目里反复纠结过的，说出来供你参考。

1. 量化粒度 vs 采集成本

你可以把阶段切到 11 个，每个都精确度量，代价是交接成本上升、数据字段膨胀、团队填报负担加重。也可以只切 5 个，代价是问题定位粗，只能看到”开发到测试慢”，看不到具体慢在哪一步。

我的取舍原则是：先粗后细，只在有问题的区段加细。具体讲，先用 5 个阶段跑三个月，找出等待占比最高的那一段，再把这一个段切成 2 到 3 个子阶段做精细观察，其他段保持粗粒度。这样精细化的成本只花在真正需要的地方。

2. 自动化 vs 灵活性

自动化采集的优势是可信度和低人力成本，代价是流程变更时需要同步调整系统配置，灵活性下降。手工填报正好相反。

我的判断是：涉及事实记录的字段（时间戳、状态变更、操作人）必须自动化，涉及判断的字段（返工原因、风险等级、改进建议）保留人工输入，但要做成下拉选项而不是自由文本。这样既保证了数据的可比性，又保留了归因的灵活性。

3. 指标数量 vs 执行力

一个常见错误是把所有能算的指标都放进看板。我在一个客户那里见过一份 28 个指标的阶段周报，结果是没人看。后来砍到 6 个，反而每周都有讨论。

我的经验是：组织当前阶段能同时推动改进的指标不超过 3 个。看板可以放 6 个，但每个季度只重点攻 1 到 2 个。像”等待占比”这种指标，改善它需要改流程规则，本身就是一个季度级别的工程，同时推三个必然都做不深。

4. 自建 vs 采购

自建的优势是贴合自身流程，代价是维护成本高、数据质量依赖内部开发资源。采购的优势是功能成熟、迭代快，代价是流程需要向工具妥协一部分。

我的取舍线划在团队规模上：100 人以下的组织不要自建，投入产出比很低；100 到 500 人的组织优先采购，把精力放在流程设计上；500 人以上且有强合规约束的组织，如果采购方案能满足私有化部署和数据导出要求，仍然优先采购，只有确实无法满足时才考虑自建。原因很简单，阶段数据分析的价值来自长期稳定的数据积累，自建系统最容易在三年后因为维护团队变动而停摆，前面的数据积累就白费了。

九、90 天落地节奏

最后给一个我自己用过的推进节奏。这个节奏在一个 120 人组织里跑通过，也做过适配后用在 300 人规模的组织里。核心原则是先测量、再改流程、最后固化，顺序颠倒一定会失败。

1. 第 1 到 30 天：只测量，不动流程

这一阶段唯一的目标是拿到基线数据。具体动作包括：梳理现有阶段定义并记录实际的状态流转情况、确定三张底层表的最小字段集、跑一次两周到四周的阶段时间切片。这个阶段最大的诱惑是”边测边改”，一定要忍住。没有基线的改造，事后无法证明有效，也无法判断该不该回退。

2. 第 31 到 60 天：攻一个交接面

根据第一阶段的等待排行，挑出等待占比最高的那一个交接面，只改这一个。常见的改法有三种：把同步评审改成异步时限评审、在交接前增加可执行的前置检查清单、把交接双方的资源排期打通。

这一步会遭遇明显的阻力，尤其是异步评审这类改变会议文化的动作。我的经验是先在一个产品线试点，用 4 周数据说话，比开十次宣贯会都有效。

3. 第 61 到 90 天：固化成看板并做第一次归因复盘

把验证有效的改动固化到系统流程里，同时上线周度阶段健康度看板，跑第一次返工归因复盘。这一阶段要特别注意两件事：一是归因码的填写质量，二是看板指标数量不要超过 6 个。

第 90 天结束时，你应该能回答四个问题：阶段等待集中在哪一段、返工的主要归因码是哪三个、哪些阶段的 P85 严重偏离 P50、下一个季度要攻的是哪一个指标。如果这四个问题里有任何一个答不上来，说明数据链路还有断点。

十、总结：阶段效率的本质是把交接面变成可观测对象

回到最开始那个 120 人组织的例子。他们最终改善的不是团队的能力，也不是工具的功能，而是让原本不可见的交接等待变成了一个每周都会被看到的数字。这一点比任何方法论都重要。

我在这件事上最独特的一个判断是：PMO 的核心竞争力不在于管流程，而在于定义什么是”值得被看见的数据”。大多数组织的 PMO 之所以沦为汇报表演，是因为他们被要求汇报那些本来就健康、或者本来就无法行动的数字，比如进度偏差率。而真正决定项目成败的等待占比、返工系数、阶段 P85，往往因为”不好看”或者”责任太清楚”而不被放进看板。

另一个判断是，阶段效率的改善存在一个明确的天花板，大约在等待占比 15% 到 18% 之间。低于这个水平后，继续压缩等待带来的管理成本会超过收益。识别出这个天花板在哪，比无限追求优化更重要。我见过把等待占比压到 9% 的团队，代价是每个阶段加了 4 个审批节点，它只是在等待前面加了一层等待，报表好看，实际周期没变。

1. 下一步你可以立刻做的三件事

1. 今天就去数一数你现在有几个阶段。超过 7 个的，先做减法而不是加法，把阶段合并到 5 到 7 个再看问题是否更清楚。
2. 本周拉一次工作项状态流转日志，即使只导出一份 CSV，也要把每个阶段的进入和退出时间算出来，看等待占比是多少。这个数字通常会让你意外。
3. 给你的返工加一个原因码字段。哪怕只分五类，跑一个月，你就会知道返工到底是需求问题、技术问题还是环境问题。

2. 一个提醒

阶段数据分析最怕的不是数据不准，而是数据准了之后被用来追责。一旦某个团队发现等待占比高会被问责，他们的第一反应一定是修改状态流转的时间戳，而不是缩短等待。所以在你上线第一版看板之前，先明确一件事：这些指标用于发现问题，不用于考核个人。这一条如果守不住，后面所有的数据都会慢慢变成表演，和当初那些漂亮的 PPT 汇报没有区别。

阶段效率的提升，本质上是把一个组织的协作损耗从”感觉”变成”数字”，再从”数字”变成”每周都会有人过问的一个具体环节”。工具、模板、公式都只是这个过程里的载体，真正起作用的是有人持续地盯着那个数字，并且有能力把数字翻译成下一步动作。