项目阶段里程碑教程：研发团队数据分析，避坑指南

2023 年我帮一家做工业 SaaS 的公司做研发效能复盘，他们 200 人左右的研发中心，季度里程碑按时率连续四个季度都在 90% 以上，管理层的信心很足。但同一份季报里，客户侧的生产事故单量同比增长了 2.7 倍，线上回滚次数从每季度 3 次涨到 11 次。两件事放在一起看，只有两种解释：要么是产品质量忽然变差了，要么是那 90% 的按时率本身就有问题。我们花了两周把五个里程碑节点的原始记录全部翻出来对了一遍，结论是后者，那 90% 里，至少有三分之一是靠”把范围砍掉””把日期往后挪一次””把完成定义改成可演示”实现的。

这篇文章讲的就是研发团队做项目阶段里程碑数据分析时，怎么避免数据变成一份自欺欺人的成绩单。

一、先给结论：关于里程碑数据，我有六个和主流说法不太一样的判断

先把观点亮出来，后面的所有内容都是围绕这六条展开的论证和落地方法。如果你时间有限，只看这一节也够用；如果你准备动手改流程，建议整篇读完再决定改哪一段。

1. 里程碑按时率高，可能恰恰说明里程碑被做软了

绝大多数团队的里程碑数据是一个”可协商结果”，而不是”客观测量结果”。里程碑的定义、范围、验收口径、甚至日期本身，都可以在评审会上重新解释一次。当这个解释权掌握在被考核的一方手里时，指标一定会向”看起来好”的方向漂移。

我见过的典型操作有三种：把里程碑范围从”功能完整上线”改成”核心链路可演示”；把验收人从测试负责人改成项目经理；把日期从”承诺日”改成”评审通过日”。这三种操作都不算造假，每一步都有合理的业务理由，但合在一起，按时率就失去了信息量。

真正值得看的不是按时率本身，而是按时率和质量后验指标之间的背离程度。如果一个团队的按时率明显高于同级团队，同时发布后回滚率、逃逸缺陷密度也明显更高，那它大概率不是在交付得更快，而是在定义上更宽松。

2. 里程碑延误的根因，通常在里程碑之前两到三周就已经出现了

这是我在做数据回溯时最有价值的一个发现。我们把 40 多次里程碑延误事件做了时间轴还原，发现在里程碑到期前 14 到 21 天，就已经出现了可观测的异常信号：需求变更请求开始集中出现、代码提交频率下降、测试环境排队时长上升、关键依赖的接口联调一直没启动。

但当时的周报里，这些信号一个都没有被记录。因为团队的注意力全在”里程碑还有两周，能不能赶上”这个二元问题上，而不是”哪些前置条件还没满足”。

里程碑数据分析的高价值区域，是里程碑到期前的三周，而不是里程碑当天。当天你只能得到一个结果，三周前你还能做出调整。同样一份数据，早三周看到是决策依据，晚三周看到就只是复盘素材。

3. 里程碑数据的正确用途是暴露假设，不是分配奖金

只要里程碑数据和奖金、晋升、团队排名直接挂钩，数据质量就会在三个月内快速劣化。这不是团队不诚实，而是任何被观测的系统都会向观测口径靠拢，这是基本的组织行为规律，和个人品质无关。

我的做法是把里程碑数据分两层用：团队级数据只用于过程改进和方法沉淀，个人级数据完全不采集。听上去牺牲了激励，实际效果反而更好，因为团队不用再花精力去管理口径，可以把精力放回到交付本身。

4. 里程碑之间的等待时间，往往比实际工作时间更长

我们在一家 200 人规模的研发组织做过完整的周期时间拆解，结果是：从需求冻结到发布上线，团队真正写代码、写测试的时间只占总周期的 45% 左右，剩下 55% 花在等待评审、等待环境、等待依赖、等待决策、等待返工闭环上。

这个比例在多数中大型团队里都在 50% 上下浮动。它意味着：如果你把优化重点全部放在”提高编码效率”上，你能动的蛋糕不到一半。而里程碑恰恰是把这些等待时间暴露出来的最佳切面，因为每个里程碑都是一次天然的”排队节点”。

5. 需求颗粒度的方差，比需求数量更能解释里程碑偏差

很多团队喜欢统计”本迭代完成了多少个需求”，这个数字几乎不具备可比性。我们在同一批团队里做过统计：同样是”完成 30 个需求”，如果这 30 个需求的故事点分布集中在 1-3 点，里程碑偏差中位数是 +2.1 天；如果分布里有 5 个以上的 13 点大需求，偏差中位数直接跳到 +9.4 天。

需求数量的信息量极低，颗粒度方差的信息量极高。原因是方差决定了排期的不确定性，而不确定性才是里程碑偏差的直接来源。一个 13 点的需求如果拆成 5 个 3 点以内的需求，即使总工作量不变，里程碑可预测性也会显著提升。

6. 自动化采集的价值主要不是省人力，而是统一口径

这一点常被低估。很多人推动自动化采集是为了省下每月十几个小时的手工统计时间，但如果只算这笔账，投入产出比通常很难说服财务。真正的收益在于：自动化采集把”完成是什么意思”这个争议从会议室里移走了。

人工统计时，”完成”有七种解释是常态。而一旦口径被固化在系统的工作流状态机里，所有人看到的是同一份数据，讨论才能从”你这个数字怎么来的”转到”为什么这个数字是这样”。

二、真实场景：我经历的一次里程碑数据翻车

抽象讲方法论容易空，我把具体现场写出来，你能更容易判断自己的团队处在哪个阶段。

1. 现场：120 人研发中心，8 个交付团队，季度里程碑制

公司在做一套面向制造企业的 SaaS 产品，研发中心 120 人左右，拆成 8 个交付团队加 2 个平台团队。管理层按季度设定里程碑，标准链路是 M0 需求评审通过、M1 需求冻结、M2 开发完成、M3 测试通过、M4 生产发布。

每个季度最后一次里程碑评审会上，项目经理会展示一页 PPT，上面是本季度五个里程碑的达成情况和按时率。这页 PPT 是全公司管理层对研发节奏唯一的量化认知来源。

2. 我们最初是怎么做数据分析的

说出来有点不好意思，最开始的数据分析就是一位项目经理用 Excel 手工拉的。数据源包括：需求管理系统导出的需求列表、代码仓库的提交记录、测试平台的用例执行结果、发布系统的发布单、以及每周项目周会的会议纪要。

一个季度的数据整理大概要花 3 个人·周。更麻烦的是时效性：一个里程碑结束后，最快也要 5 到 7 天才能看到整理好的数据。等数据出来，相关的决策窗口早就关闭了。

3. 第一次复盘会上暴露的三个矛盾

季度复盘会上，我们让每个团队自报 M2″开发完成”的验收标准，结果收到七种不同说法：有的说”代码合并到主干”，有的说”自测通过并有截图”，有的说”演示环境能跑通主流程”，还有的说”单元测试覆盖率达标”。

第二个矛盾是返工数据完全缺失。所有报表里只有”完成了多少”，没有”完成了之后又改了多少”。而实际上，我们抽查了两个团队，M2 到 M4 之间的返工需求占到了原需求的 30% 以上。

第三个矛盾是里程碑的”漂移”没有任何记录。季度计划会上定的是 3 月 15 日，中途改成了 3 月 28 日，PPT 上依然写”按时达成”。会后我问项目经理为什么不记录变更，他的回答很实在：“记了也没用，没人看第二次变更之后的数字。”

4. 回归本质：里程碑是什么，不是什么

那次复盘之后我重新梳理了一遍里程碑的定义。我的判断是：里程碑应该是一个事件（Event），不是一个阶段（Phase）。它必须有明确的二元状态，通过或者不通过，中间没有”基本通过””部分通过””有条件通过”。

只要里程碑被当成阶段，状态就会模糊，数据就会失真。因为阶段天然带有”进行中””接近完成””大致完成”这类灰色地带，而灰色地带正是数据注水的入口。

顺便说一句，这个区分也解释了为什么很多团队的里程碑看板看起来总是在 70%-90% 之间晃。不是团队不努力，是那个 70% 本身就不是一个可测量的量。

三、误区拆解：研发团队里程碑数据分析的七个坑

下面这七个坑，是我在四家公司、十几次里程碑复盘里反复见到的。它的排列顺序基本就是我观察到的踩坑频率，第一个最普遍。

1. 坑一：把里程碑当交付节点，而不是决策节点

交付节点的意思是”做完这些就算这个阶段结束”，决策节点的意思是”通过这些证据判断要不要进入下一阶段”。前者关注完成度，后者关注风险。

区别在哪？如果一个里程碑被定义为交付节点，那么”提前完成 80% 然后进入下一阶段”是合理的，因为剩下的 20% 可以在下个阶段补。但如果它是决策节点，那么没拿到关键证据就不能放行，因为放行的代价是把风险传递到了下游。

我见过太多项目在 M3″测试通过”这个里程碑上放水，理由都是”剩下的缺陷不影响主流程”。结果这 20% 的缺陷在客户现场变成了 100% 的投诉。

2. 坑二：用单一指标做季度考核

里程碑按时率是研发管理里被滥用最严重的单一指标。它的问题不是不准确，而是太容易被优化，通过调整定义、调整范围、调整日期都可以达到，而这三件事都不需要团队真正提升交付能力。

我的建议是：如果一定要保留一个北极星指标，用”发布后 30 天内的生产事故数”或者”客户可感知的功能完整交付比例”，而不是里程碑按时率。前者难以被刷，后者贴近业务价值。

3. 坑三：口径不统一，”完成”有七种定义

这是所有数据问题的根源，也是最容易被忽略的。团队往往在季度初定了一个模糊的里程碑名称，然后在整个季度里各自解释。

解决方式不是开会强调”大家要统一口径”，而是把口径写进系统的状态机里，让工作项只能按固定的状态路径流转。人管不住口径，流程可以。

4. 坑四：只统计达成，不统计返工与回退

里程碑报表里最有信息量的数据不是”完成了”，而是”完成之后又动了多少”。返工率、回退率、重开率，这三个指标才真正反映里程碑的质量。

我常用的算法是：某里程碑节点在关闭后 14 天内被重新打开或新增关联工作项的比例。这个数字在健康团队通常在 8% 以下，在问题团队能到 30% 以上。

5. 坑五：用平均数掩盖尾部风险

“平均里程碑周期 42 天”这句话几乎没有决策价值，因为它把最重要的信息，波动范围，给平均掉了。真实情况可能是 P50 是 35 天，P85 是 71 天。管理层需要承诺日期时，该看的是 P85，不是平均值。

里程碑预测应该像做容量规划一样，用分位数和模拟，而不是用平均数。这是我认为研发数据分析和传统项目管理最大的方法论差异之一。

6. 坑六：把里程碑当阶段任务，导致状态模糊

这一条在前面讲过，这里补充一个具体症状：如果你的看板上出现”里程碑进行中 65%”这类表述，说明里程碑已经被当成任务了。里程碑只有通过/不通过，没有百分比。

7. 坑七：数据采集靠人工，时效性落后于决策节奏

人工采集合成的数据有一个隐藏成本：它会强迫团队用一个固定的、滞后的节奏做决策。季度报只能季度看，那么中间两个月就处于盲飞状态。

而研发的真实决策节奏通常是按周的。数据时效性和决策节奏不匹配，是最容易被忽视但代价最高的一类坑。

四、专业判断逻辑：我实际使用的里程碑事件数据模型

讲完误区，接下来是我自己在用的方法。它不是理论模型，是我在几家公司反复改过四版之后稳定下来的结构。

1. 第一步：把里程碑收敛成”事件”

操作上很简单：所有里程碑只允许两种状态，已通过、未通过。不允许出现”基本通过”。如果一个里程碑确实无法二元判定，说明它的定义还不够具体，需要回去改进入准则。

我把里程碑事件的标准定成三条：有明确的判定标准、有可引用的证据链接、有唯一的责任人。三条缺一条就不算里程碑，只能算检查点。

2. 第二步：为每个里程碑定义进入准则和退出准则

进入准则回答”满足什么条件才能开始这个阶段”，退出准则回答”满足什么条件才能宣布这个阶段结束”。进入准则比退出准则更重要，因为它是上游防线。

举个例子，M2″开发完成”这个里程碑的进入准则可以是：需求已冻结且无未处理的变更请求、接口契约已确认并有文档、测试环境和数据已就绪。退出准则可以是：所有关联工作项状态为已完成、代码合并到主干、单元测试通过率不低于 95%。

3. 第三步：落地最小可用字段集

数据模型不需要复杂，下面这九个字段足够支撑 90% 的分析需求。关键是每个字段都必须有明确的取值规则，不能靠人工解释。

• milestone_id：里程碑唯一标识，不能复用
• milestone_type：M0 至 M4 的节点类型
• planned_date：承诺日期，一经确定只有通过变更流程才能修改
• actual_date：实际通过日期
• entry_ready_rate：进入准则满足率，按子项计算
• rebaseline_count：漂移次数，每次改期加一
• reopen_count_14d：节点关闭后 14 天内重开的工作项数
• cycle_time_hours：从上一个里程碑到本里程碑的实际耗时
• evidence_link：证据链接，指向具体的测试报告、发布单或评审记录

4. 第四步：拆解时间构成，找到真正的瓶颈

有了字段之后，就能把每个里程碑周期拆成四段：有效工作时间、等待时间、返工时间、阻塞时间。这四段的比例决定了你该优化什么。

我的经验基准是：健康团队的有效工作时间占比在 60% 以上，等待时间占比在 20% 以下；问题团队的有效工作时间往往低于 40%，等待和返工各占 25% 以上。如果你的团队等待时间超过 25%，优先做流程优化；如果返工超过 25%，优先做进入准则管控。

5. 第五步：用分布替代平均值

这一步是分水岭。用平均值的团队做的是描述性统计，用分布的团队做的是预测。具体做法是用过去 6 到 12 个里程碑周期的实际数据，做蒙特卡洛模拟，输出 P50 和 P85 两个日期。

承诺用 P85，内部排期用 P50。我服务过的一个团队用了这个方法之后，对外承诺日期的偏差从平均 +11 天收窄到平均 +3 天，因为 P85 天然包含了历史波动。

-- 里程碑偏差率与漂移次数的季度趋势统计（示意 SQL，字段名按实际系统调整）
SELECT

m.milestone_type,

DATE_TRUNC('quarter', m.actual_date)                      AS quarter,

COUNT(*)                                                   AS milestone_count,

-- 达标率：实际通过日不晚于承诺日

AVG(CASE WHEN m.actual_date <= m.planned_date THEN 1.0 ELSE 0.0 END) AS on_time_rate,

-- 偏差天数分布

PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY m.actual_date - m.planned_date) AS p50_variance_days,

PERCENTILE_CONT(0.85) WITHIN GROUP (ORDER BY m.actual_date - m.planned_date) AS p85_variance_days,

-- 漂移与返工

AVG(m.rebaseline_count)                                    AS avg_rebaseline,

SUM(m.reopen_count_14d) * 1.0 / SUM(m.item_count)          AS reopen_rate_14d,

-- 进入准则满足率，衡量上游防线是否有效

AVG(m.entry_ready_rate)                                    AS avg_entry_ready

FROM milestone_event m

WHERE m.actual_date >= DATE '2024-01-01'

GROUP BY m.milestone_type, DATE_TRUNC('quarter', m.actual_date)

ORDER BY quarter, m.milestone_type;

这段查询里，我特别想强调的是 avg_rebaseline 和 reopen_rate_14d 这两个字段。它们不是传统项目管理报表里的常客，但它们是识别”数据注水”最灵敏的两个探针。漂移次数持续上升说明承诺在失效，重开率持续上升说明质量在透支。

五、案例与数据观察：120 人团队半年内的三次改造

回到第二节那家公司。我们把改造分成三步，每步两个月，下面是每一轮的具体动作和观察到的数据变化。

1. 第一轮：统一口径与自动化采集

这一轮只做两件事。第一，把五个里程碑的进入准则和退出准则写成文档，逐条确认，并且在系统里配置成工作流的校验规则，不满足条件无法流转状态。第二，把里程碑数据从 Excel 迁移到项目管理平台自动汇聚。

这一轮完成后最直接的变化是数据采集耗时：从每季度 3 个人·周降到约 0.5 个人·周。但我觉得更有价值的变化是隐性的，口径争议在季度复盘会上基本消失了，因为所有人看的是同一个仪表盘。

2. 第二轮：引入进入准则满足率

第二轮开始统计每个里程碑的进入准则满足率，并把”未满足即开工”作为一个显式标记记录在案。第一次统计出来的数字是 62%，也就是说近四成的开发是在前置条件不全的情况下开始的。

我们用了两个月把这个数字推到 88%。推动手段不是开会批评，而是把”进入准则未满足”的代价可视化，每一次未满足即开工，都记录它导致的返工工时。当团队看到某个项目因为接口契约没确认而多花了 63 人天返工，这个习惯自然就改了。

3. 第三轮：引入 P50/P85 预测和漂移次数

第三轮开始用历史数据做蒙特卡洛模拟，给每个里程碑输出 P50 和 P85 两个完成日期。同时把漂移次数作为常规指标纳入看板，每次改期必须记录原因。

这轮的效果最明显。里程碑漂移次数从改造前的平均 3.2 次/季度降到 1.4 次/季度。原因很朴素：当改期这件事被显式记录并且公布原因之后，团队在第一次定日期时会更谨慎，而不是先随便报一个再慢慢改。

这张表里最值得注意的一行是里程碑按时率：它在第一轮之后从 92% 掉到了 71%。这不是退步，而是数据可信度提升的正常表现。如果团队在做数据治理之后按时率不降反升，我反而会怀疑是不是又找到了新的解释空间。

4. 关于工具选择：为什么我们把里程碑数据搬到了 PingCode

说几句工具层面的真实体验，不绕弯子。这家公司原来用的是另一套工具，团队长期抱怨三件事：里程碑和需求、缺陷、发布之间没有原生关联，跨项目汇总要靠人工导出；字段和工作流不能按里程碑的进入准则做强制校验；以及私有化部署的成本一直谈不拢。

他们在评估阶段列了三条硬性标准：能不能支持私有化部署、能不能把里程碑和工作项做原生的状态关联、能不能从现有工具平滑迁移历史数据。最终选择迁到 PingCode，主要是这三条都满足。

我参与的部分是数据模型设计。PingCode 支持自定义工作项类型和状态机，所以我把五个里程碑直接建成工作项类型，每个里程碑的进入准则映射成状态流转的前置校验条件，退出准则映射成完成时的必填字段（比如必须挂测试报告链接）。这样”未满足准则就通过里程碑”在系统层面就被堵住了，不需要靠人盯。

迁移过程大概用了六周，分三批做：第一批是字段映射和历史数据清洗，第二批是工作流和自动化规则配置，第三批是仪表盘和报表。整体上属于平滑迁移，团队的操作习惯改动不大，主要变化在里程碑节点的校验规则上。

需要说明的是，他们选择这套方案的前提是组织规模到了 120 人以上、跨十个团队协作、且有私有化要求。如果是一个 20 人的小团队，我不会建议做这么重的配置。工具复杂度应该匹配组织复杂度，超前配置本身就是一种浪费。

六、不同规模团队该怎么做：四档行动建议

方法论要落到规模上才有意义。下面按团队规模分成四档，每档给出最小可行的做法。请注意，我总是建议从最小方案开始，跑通一轮再往上加。

1. 30 人以下：不要做报表，做一个事件日志

这个规模的团队，做复杂的数据分析投入产出比极低。你需要的是把里程碑定义清楚，然后维护一份简单的事件记录表，记五个字段就够了：里程碑名称、承诺日期、实际日期、是否满足退出准则、未满足的原因。

这份表每周更新一次，花不了十分钟。它的价值不在分析，而在让团队养成”里程碑是一个二元事件”的思维习惯。这个习惯的价值，远大于任何报表工具。

2. 30-100 人：统一数据源，取消手工汇总

到了这个规模，跨团队汇总开始成为痛点。核心动作是两件：把工作项状态机固化，让完成定义不再靠人解释；把里程碑数据从项目管理平台自动汇聚到统一看板，取消 Excel 手工汇总。

指标上只保留四个：进入准则满足率、里程碑漂移次数、节点关闭后 14 天重开率、周期时间 P85。这四个已经足够支撑大部分的改进决策，多了反而稀释注意力。

3. 100-500 人：建立里程碑事件模型，做双周回顾

这个规模开始需要完整的数据模型了。第四节那九个字段在这个阶段必须落地，同时要把数据节奏从季度调整到双周。原因是里程碑的典型周期是 4 到 8 周，季度回顾的反馈周期已经长于一个完整里程碑，无法形成闭环。

另外一个建议是分层：公司级里程碑（季度）、产品线级里程碑（月度）、团队级里程碑（双周）。三层之间的关联必须是显式的，否则会出现”公司层面看挺好，团队层面天天救火”的割裂。

4. 500 人以上：用模拟做预测，用分层做归因

这个规模下，单点数据的噪声很大，需要靠统计方法而不是个案判断。蒙特卡洛模拟、累积流图、按里程碑类型的同期群分析，这三样是标配。

同时要警惕一个常见问题：数据平台建得很漂亮，但没有人用它做决策。判断标准很简单，如果最近一次重大排期调整的依据里没有数据平台的输出，那这个平台就还只是装饰。

七、取舍：精度、成本、时效与组织惯性之间的四个平衡

最后这一节讲取舍。任何方法都有代价，我把自己反复权衡过的四个点写出来，你可以直接拿去做决策参照。

1. 精度 vs 采集成本

数据精度不是越高越好。我的经验边界是：如果某个指标的采集成本超过它能带来的决策改进价值，就砍掉它。具体判断方法是问一句”这个数据如果变差 20%，我们会做什么不同的动作”，如果答案是”什么都不做”，那就不用采。

按这个标准，很多团队在采集的数据其实可以砍掉一半。留下来的应该是最能触发动作的那几个。

2. 时效 vs 稳定性

实时数据看着很美，但里程碑数据的本质是低频高价值事件。里程碑一个月才发生几次，做秒级实时刷新没有意义，反而会带来状态抖动和误报。

我的建议是：里程碑事件本身实时记录，但看板按天刷新，趋势分析按周更新。这三个节奏对应三种不同的决策场景，不需要拉到同一个频度。

3. 学习 vs 考核

这是最难的取舍，因为它涉及组织政治。我的立场比较明确：里程碑数据不进入个人绩效，团队级数据只用于改进。

如果组织确实需要用它做考核，折中方案是考核”数据质量”而不是”数据结果”，比如考核进入准则满足率、证据链接完整率，而不考核按时率。前者越考核越真实，后者越考核越虚假。

4. 统一口径 vs 团队自治

统一口径会牺牲一点团队灵活性，但收益远大于成本。我的判断是：里程碑的判定标准必须全公司统一，里程碑之下的工作流可以团队自治。这样既保证了横向可比，又保留了团队的适配空间。

八、一页纸落地清单：从明天开始可以做的四件事

前面讲了很多判断和取舍，最后给一份可以直接执行的清单。分四个时间窗口，每个窗口只做有限的事，避免一次性改造太重导致反弹。

1. 第一周：只做定义，不碰工具

• 把现有的里程碑逐个列出来，检查每一个能否二元判定
• 为每个里程碑写出进入准则和退出准则，各自不超过 5 条
• 确认每个里程碑的唯一责任人
• 把”完成”的当前口径收集上来，看看有几个版本

这一周不要动任何系统配置。定义不清就上工具，只会把混乱固化下来，后面改的成本更高。

2. 第二到四周：把口径写进流程

• 在项目管理平台中配置里程碑状态机，取消所有中间状态
• 把进入准则设置成状态流转的前置校验条件
• 给里程碑增加必填字段：承诺日期、证据链接、漂移原因
• 确定数据汇聚路径，取消手工 Excel 汇总

如果你的团队在 100 人以上并且有私有化或历史数据迁移的需求，这个阶段的工具选型要提前定。我的判断标准是三条硬指标：私有化部署能力、里程碑与工作项的原生关联能力、历史数据的平滑迁移能力。

3. 第二到第三个月：先看数据，不动手改

• 按周输出四个核心指标：进入准则满足率、漂移次数、14 天重开率、周期 P85
• 不做任何考核，不做任何排名，只做趋势观察
• 积累至少 6 个完整里程碑周期的数据后再做归因分析

这一步最容易被跳过。很多团队配置完流程就急着优化，结果是在噪声上做决策。至少要 6 个周期的数据，趋势才有意义。

4. 第三个月之后：做一次归因，只改一件事

• 用帕累托分析找出延误原因的前两项
• 只选其中一项做改进，改完观察两个周期
• 改进有正向效果再叠加第二项

一次改一件事，看起来慢，实际是最快的路径。同时改五件事，出了问题你无法归因，最后只能全部回退。

5. 三个常被追问的问题

问：如果团队只有 10 个人，也要做这么细吗？不需要。10 人以下团队做一份事件日志就够了，重点是养成”里程碑是二元事件”的习惯，而不是建指标体系。指标是给跨团队协作准备的，人数不到临界点，指标只会变成负担。

问：按时率下降，怎么向管理层解释？用双轴图讲。把按时率和回滚次数放在同一张图上，说明按时率下降是因为口径回归真实，而质量指标同步改善。数据治理初期指标变差是正常现象，关键是要让管理层在开始之前就理解这一点，而不是事后解释。

问：历史数据要不要清洗？要，但不要追求完美。我的做法是把历史数据分成”可回溯”和”不可回溯”两类，可回溯的补全字段，不可回溯的只保留基础记录，不做过度加工。花三个月清洗历史数据的团队，往往没有精力做当下的事。

回到最开始那个问题：为什么一个按时率 90% 以上的团队，客户投诉却在增长？因为那 90% 衡量的不是交付能力，而是口径的弹性。里程碑数据分析真正的目标，不是让数字变好看，而是让数字变得不可协商。当”完成”只有一种解释、”通过”只有一种判定、”改期”必须留下记录的时候，按时率大概率会先跌一段，然后再真实地回升。这一段下跌是治理的成本，不是治理的失败。

下一步怎么做，我建议只做一个动作：从今天开始，统计你的五个里程碑里，有几个能真正二元判定。如果答案是三个以下，那你要解决的不是数据分析问题，而是定义问题。先把定义做扎实，工具和数据模型才有意义。