里程碑计划最佳实践：跨部门团队里程碑数据分析，常见问题

三年前我接手一个跨部门交付治理项目时，看到的第一份里程碑报表上写着"准时率 94%"。同一周，业务负责人在群里发了一条消息：这个季度承诺的功能，我们实际只拿到了原计划的六成。两个数字都是真的，但它们描述的不是同一件事。这也是我后来在跨部门团队里反复讲的一句话：里程碑数据分析最容易出的问题，不是数据不准，而是用一组正确但错位的数据，回答了一个没有人真正关心的问题。

《里程碑计划最佳实践：跨部门团队里程碑数据分析，常见问题》这个题目，绝大多数内容会从"如何制定里程碑"讲起，给你一个 SMART 原则、一张甘特图模板、一套周报格式。但我过去六年参与过的十一个跨部门交付治理项目告诉我，真正让里程碑数据失效的，几乎从来不是"里程碑定得不够 SMART"，而是数据在跨部门流转的过程中被系统性地稀释、美化、延后了。这篇文章只讲一件事：怎么让里程碑数据变成可以驱动决策的信号，而不是一份好看的汇报材料。

一、先给结论：里程碑数据分析回答的不是"完成了没有"

我把结论放在最前面，因为大部分团队读到第三段就会开始对照自己的报表，这时候有一个明确的判断锚点会更省时间。

1. 里程碑准时率是结果指标，不是诊断指标

准时率告诉你"发生了什么"，不告诉你"为什么发生"。一个 78% 的准时率，可能来自五类完全不同的原因：需求变更、资源被抽调、上游交付延迟、估算偏差、验收标准临时加码。这五类原因的处置动作完全不同，但在准时率这一个数字里全部被抹平了。

我见过太多团队拿着 78% 这个数字开会，会上讨论了四十分钟"是不是大家不够重视"，散会时没有任何一个具体动作落到具体的人身上。只统计准时率的里程碑报表，本质上是一份情绪报表。

2. 跨部门里程碑的延迟，绝大多数发生在"交接缝隙"里

这是我最想强调的一条判断。在单团队内部，里程碑延迟的主因通常是执行能力或估算偏差；但在跨部门场景里，我把六年中记录到的 431 个延迟里程碑做过归因，其中约 61% 的延迟时间消耗在"上游已完成、下游尚未启动"或"下游已启动、上游返工"的缝隙中，而不是消耗在任何一个部门的实际工作里。

换句话说：三个部门各自都很准时，整体里程碑照样可以延期两周。这个现象在甘特图上看不出来，在部门周报上也看不出来，只有把交接时间单独拎出来统计，它才会显形。

3. 必须把"计划变更"和"执行失败"分开统计

这是我在所有项目里推行的第一条硬规则。里程碑在原承诺日之后完成，可能是两件性质完全不同的事：一件是我们双方同意把日期往后挪了（计划变更），另一件是我们没做到（执行失败）。前者是正常的项目治理行为，后者才是需要复盘的问题。

把两者混在一个"准时率"里，会导致两个反向的恶果：团队为了保数字，不敢提变更，于是把变更藏到最后一刻；管理层看到准时率不差，误以为执行力没问题，直到业务方投诉才发现真相。

4. 承诺质量比准时率更能预测风险

我后来在所有项目里用"承诺偏差中位数"替代"准时率"作为核心指标。它的算法很简单：对每个里程碑，计算实际完成日与首次承诺日的天数差，取绝对值后求中位数。这个指标衡量的是"这个团队的承诺值多少钱"，而不是"这个团队有多努力"。

一个准时率 85%、承诺偏差中位数 2 天的团队，和一个准时率 92%、承诺偏差中位数 11 天的团队，前者的交付可预期性明显更高。因为前者说"下周三"就是下周三，后者说"下周三"时你心里得留两周缓冲。

5. 里程碑粒度决定数据可信度

我做过一个横向对比：把同一批项目按里程碑平均跨度分成三组，跨度在 5 个工作日以内的、6 到 15 个工作日的、16 个工作日以上的。结果很反直觉，粒度越粗的里程碑，准时率越高，但业务方的满意度评分越低。

原因不难理解：一个跨度 30 天的里程碑，中间有足够多的机会悄悄吸收掉偏差；一个跨度 5 天的里程碑，偏差无处可藏。粗粒度里程碑的高准时率，很大程度上是缓冲垫堆出来的假象。

6. 数据采集频率必须匹配决策节奏

我见过最极端的反例是一支 40 人的团队，要求每个里程碑每天更新一次进度百分比。三个星期后，填报数据全部变成 100% 或者 80% 两个值，大家开始编了。里程碑数据的更新频率应该由"这个数据多久会被用于一次决策"决定，而不是由"我们想看得多细"决定。

二、为什么跨部门里程碑的数据总是失真：三个真实场景

上面是结论，下面是这些结论是怎么来的。我挑三个我亲身经历、并且在不同公司重复见到的场景展开，它们能解释大部分跨部门里程碑数据失真的机制。

1. 场景一：三个部门全部准时，整体延期 14 天

这是 2021 年一个支付系统重构项目。里程碑 M3 是"新清算引擎上线"，它依赖三个部门的产出：A 部门完成接口协议定稿、B 部门完成网关适配、C 部门完成对账模块开发。

看部门周报，三件事都在自己的计划内完成了。但整体上线日期比原计划晚了 14 个工作日。我把时间轴拉出来后发现了问题：A 部门在周二下午把接口协议发到了群里，B 部门的负责人那周在出差，周五回来才看到；C 部门一直在等 B 部门确认适配结果，又等了 4 天。14 天里，真正的工作时间是 0 天，全部是等待。

这类事情的可怕之处在于，没有任何人做错什么。A 完成了，B 完成了，C 完成了，每个人的考核都是绿的。但项目整体红了。如果里程碑数据分析只看"每个里程碑是否按时完成"，这个项目会被记录成"执行良好、偶发延期"。

2. 场景二：准时率 96%，业务方满意度 3.1 分

第二个场景来自一家做企业级 SaaS 的公司，200 多人研发规模。他们的季度里程碑准时率长期维持在 95% 以上，但每个季度的业务方满意度调研都在 3 分左右徘徊。

我去翻了他们三个季度的原始数据，发现问题出在"改期"这个动作上。他们的流程允许项目经理直接在系统里修改里程碑日期，修改后不留痕、不需要审批、不计入统计。结果就是：一个里程碑原定 6 月 30 日，到 6 月 28 日发现做不完，改成 7 月 15 日，最后 7 月 14 日完成，系统里记录的是一次"准时完成"。

三个季度累计，这类静默改期发生了 127 次，平均每个里程碑被改期 1.8 次。业务方看到的永远是那个被改过的日期，所以体感上"你们总是在拖"，而研发看到的永远是"我按时完成了"。

3. 场景三：季度末的脉冲式完成

第三个场景几乎所有中大型组织都会有。我把一个团队连续 12 周的里程碑完成时间画出来后，发现了一个非常明显的分布：每周完成 2 到 4 个，但每个季度的最后一周会完成 11 到 15 个。

这不是效率突然提升，而是三种行为叠加的结果：验收标准在季末被临时放宽；部分里程碑其实早已实质完成，只是没走完流程，季末集中批量关闭；以及少数里程碑确实在最后一周被全力推完，但质量债务留到了下个季度。

如果里程碑数据只在季度末采集一次，你永远看不到这个分布；只有按周采集完成时点，才能把它暴露出来。

三、拆解常见误区：我踩过的和见别人踩过的七个坑

这一节我按"错误认知，导致的后果，修正做法"的结构写，每条都对应一个我实际见过的项目。

1. 用任务完成率替代里程碑健康度

最常见的做法是：把里程碑展开成 30 个任务，看任务完成率。任务完成率 80% 就认为里程碑健康度 80%。这是错的。

任务完成率的分布高度不均匀，前 80% 的任务可能只花了 40% 的工作量，剩下 20% 的任务压着 60% 的工作量和几乎全部的技术风险。修正做法是：里程碑的进度只用"关键路径上的剩余工作量"来衡量，非关键路径的任务不计入里程碑健康度。

2. 里程碑责任人挂部门，不挂具体的人

"这个里程碑由数据平台部负责"，这句话在跨部门场景里等于没有人负责。我统计过一个项目的责任归属，挂到部门的里程碑中，逾期率是挂到具体个人的 2.3 倍。

修正做法是引入单一责任人机制：每个里程碑必须有一个明确的 DRI（直接责任人），部门只作为资源提供方出现。DRI 不一定是最资深的人，但必须是对这个交付物最终形态负责的人。

3. 把改期当作正常操作，不留痕、不统计

这是场景二里的核心问题，也是我认为对数据质量破坏最大的一条。允许改期是对的，允许静默改期是致命的。

修正做法有三个要点：改期必须填写原因分类（不是自由文本，是枚举值）；改期记录必须进入统计，作为"计划变更率"指标；同一个里程碑连续改期两次以上，自动触发上级评审。

4. 只统计"是否准时"，不统计偏差分布

"准时"是二值判断，会丢掉大量信息。一个里程碑提前 30 天完成，和一个里程碑按时完成，在准时率里是一样的；但提前 30 天说明估算过于保守，是流程问题。

修正做法是同时输出三个分布指标：提前完成天数分布、延后天数分布、偏差绝对值中位数。

5. 忽略依赖链上的静默期

这是场景一里的核心问题，也是跨部门场景区别于单团队场景的关键。我把它定义为"交接静默时长"：从上游交付物完成，到下游负责人在系统中确认接收并启动工作之间的时间间隔。

在三个项目的统计中，交接静默时长的中位数分别是 2.8 天、3.6 天、5.1 天。把一个 12 个里程碑的项目里所有静默时长加起来，平均占总工期的 17%。

6. 把里程碑数量当作管控力度

"这个项目设了 80 个里程碑，管控很细。"，我在很多汇报里听到过这句话。但 80 个里程碑意味着 80 次状态更新、80 次验收、80 次沟通，管理成本会吃掉它带来的收益。

我的经验值是：一个 3 到 6 个月的跨部门项目，核心里程碑控制在 12 到 25 个之间；一个季度迭代，控制在 6 到 12 个之间。超过这个范围，团队会开始用"批量更新"应付填报。

7. 数据只在项目复盘时看一次

里程碑数据最大的价值是"提前预警"，而不是"事后归因"。如果只在月度或季度复盘会上看，数据的历史使命已经完成了。

修正做法是设定触发规则：某里程碑的偏差超过承诺跨度的 30% 时自动预警；某部门的交接静默时长连续两周上升时自动预警；依赖链上有两个以上里程碑同时进入预警状态时，升级到项目级。

四、专业判断逻辑：从准时率到承诺质量

这一节说方法论。我会讲清楚三个核心指标怎么定义、一个归因框架怎么搭、以及判断的阈值从哪里来。

1. 里程碑的定义必须包含三要素和一个否定项

三要素是：可验收的交付物、明确的验收人、一个具体的承诺日期。缺任何一个，这个节点就不是里程碑，只是一个任务节点。

否定项是：里程碑不能表述为"完成 XX 阶段的工作"这类模糊说法。"完成第一阶段开发"不是里程碑，"订单模块通过 200 并发压力测试并出具测试报告"才是。

2. 建立五分类的漂移归因框架

我把里程碑未在首次承诺日完成的归因固定为五类，不允许自由填写。选择枚举而不是自由文本，是因为自由文本在统计时会变成一锅粥。这五类是：

• 需求变更类：范围增加、验收标准调整、优先级变化导致的。
• 上游依赖类：等待上游交付物，或上游交付物质量不达标导致返工。
• 资源冲突类：关键人员被抽调、被高优项目挤占。
• 估算偏差类：工作本身没有变化，但实际耗时超出估算 50% 以上。
• 外部约束类：第三方接口、合规审批、客户环境等不可控因素。

这五类的处置动作完全不同：需求变更类要改的是变更评审机制，上游依赖类要改的是交接协议，资源冲突类要改的是排期规则，估算偏差类要改的是历史数据积累，外部约束类要改的是风险缓冲的设置方式。

3. 三个核心指标的定义和阈值

我在项目里固定输出三个指标，替代传统的单一准时率。

这三个阈值的来源是我在六个项目里的实际分布：把每个项目的指标值和最终的业务方满意度打分做相关性分析，发现这三个指标与满意度的相关性显著高于准时率，因此用它们的分布分位点作为阈值。

需要说明的是，这三个阈值适用于 100 人以上、有专职项目管理角色的组织；小团队可以放宽，因为沟通成本本身较低，静默时长天然更短。

4. 依赖链健康度：用阻塞时长而不是里程碑数量衡量

跨部门项目里，我建议计算一个"依赖阻塞指数"：把项目周期内所有里程碑的等待上游时长加总，除以项目总工作日。这个指数超过 0.15，说明项目有超过 15% 的时间在等人，必须优先治理交接流程，而不是催执行。

5. 粒度校准：用 5 到 15 个工作日作为默认区间

基于前面气泡图的观察，我把 5 到 15 个工作日定为里程碑跨度的默认区间。低于 5 天的节点归为任务，不单独做里程碑管理；高于 15 天的节点要拆，或者明确它的缓冲是如何设置的。

如果某个里程碑确实必须跨 30 天以上（比如需要外部审批的合规节点），我给它的处理方式是：保留为里程碑，但强制要求设置至少两个中间检查点，并记录每个检查点的偏差。

6. 数据采集的实现：用配置而不是靠自觉

我推行的做法是把指标口径写进系统配置，而不是靠人填表。比如在支持里程碑视图和依赖关系的平台里，可以用一段结构化配置定义归因枚举和改期规则：

milestone_policy:
attribution_required: true # 改期必须选择归因分类

attribution_options: # 固定五分类，禁止自由文本

requirement_change # 需求变更

upstream_dependency # 上游依赖

resource_conflict # 资源冲突

estimation_deviation # 估算偏差

external_constraint # 外部约束

re_plan_threshold: 2 # 同一里程碑连续改期2次触发上级评审

silence_alert_hours: 24 # 交接静默超过1个工作日自动提醒下游

drift_alert_ratio: 0.30 # 偏差超过承诺跨度30%自动预警

span_limits:

min_working_days: 5 # 低于5天降级为任务

max_working_days: 15 # 高于15天强制拆分或设置检查点

把规则写进系统之后，数据质量的提升往往比讲十次培训更明显。原因很简单：人不会主动遵守口头约定，但会遵守系统里填不进去的必填项。

五、数据观察：一个 260 人组织的六个季度记录

这一节我讲一个具体的项目，包含背景、迁移过程、数据变化和三个我事先没预料到的发现。所有数据来自项目周报和系统导出的脱敏记录，样本为该组织 2022 年第二季度到 2023 年第三季度的全部跨部门里程碑。

1. 案例背景

这是一家做工业软件的企业，研发加产品约 260 人，横跨五个部门：平台架构、应用开发、数据、测试、交付实施。跨部门里程碑平均每季度 19 个，涉及外部客户交付的项目占六成。

治理前的问题非常典型：里程碑准时率 88%，但客户交付延期投诉每个季度平均 4.2 次；项目经理每周花 6 到 8 小时手工汇总各部门周报；里程碑改期在邮件和群里散落，没有任何地方能查到全貌。

2. 平台选择与迁移的现实考量

这个项目在选型阶段评估了四类方案：继续用原来的任务管理工具加 Excel、用海外项目管理平台、用国内轻量工具、用面向中大型组织的研发管理平台。最终他们选择迁移到 PingCode，我在过程中参与了部分配置建议。

选择理由有三条是我认为值得记录的。第一是私有化部署，他们的部分项目涉及客户现场数据，不能出内网，这一条直接淘汰了所有纯 SaaS 方案。第二是从原有平台的平滑迁移能力，他们有两年多的历史工单和项目数据，迁移过程中字段映射、附件、历史评论的完整程度直接决定了迁移后能不能做趋势分析。第三是 PingCode 主要服务中大型企业及 100 人以上组织，里程碑视图、依赖关系、版本规划这些能力是按这个规模组织的实际工作方式设计的，而不是给小团队做的工具再往上加功能。

迁移过程本身花了大约五周：两周做数据映射和试迁移，一周做字段清洗（主要是历史里程碑的日期格式和责任人字段），两周做双系统并行验证。这里有个具体的坑值得说：历史数据里的"完成日期"有三种不同口径，有的是实际交付日，有的是系统关闭日，有的是项目经理手动填的日期。如果不统一口径就迁移，迁完之后做趋势分析会得到完全错误的结论。我们的做法是统一以"验收人确认日"为准，无法追溯的标记为未知并从趋势分析中排除。

3. 六个季度的数据变化

治理动作分三批上线：第一批是归因枚举和改期留痕（第 2 季度），第二批是交接静默提醒和依赖关系可视化（第 3 季度），第三批是预警规则和中间检查点（第 4 季度）。数据变化如下：

注意一个反直觉的地方：这个组织的"准时率"在治理期间其实下降了，从 88% 降到了 81%。原因是改期不再被隐藏，那些原本会被静默改期掩盖的偏差，现在如实进入了统计。如果我们只看准时率，会得出"治理失败"的结论；但看承诺偏差中位数从 8.5 天降到 2.8 天，客户的延期投诉从 4.2 次降到 1.1 次，真实情况恰恰相反。

这也是我在文章开头说的那句话的具体证据：用错位的指标，会得出完全反向的结论。

4. 三个我事先没预料到的发现

（1）交接静默时长的下降，比任何流程改造都更有效

我们原本预期最大的收益来自归因分析，但数据显示，静默时长中位数从 4.2 天降到 0.9 天这个变化，单独解释了客户延期投诉下降幅度的约六成。原因是在这个组织的实际场景里，大部分等待并不是因为工作量大，而是因为"没人知道该自己动了"。

（2）归因分类上线后，第一月的"资源冲突"占比远超预期

第一个月里，资源冲突类归因占了 34%。这个比例高得反常，追查后发现一个具体原因：五个部门共用两名架构师，而这两名架构师在系统里被同时挂在了 11 个里程碑上。这个问题在治理前从来没被量化过，因为每个部门都觉得自己只是在"借用一下"。

（3）里程碑粒度调整后，团队反而觉得管控变松了

我们把原本 43 个里程碑压缩到 21 个，把低于 5 个工作日的节点降级为任务。按理说管控应该变松，但团队的反馈恰恰相反：因为每个里程碑都变得更有分量，验收标准更明确，反而更清楚自己要交付什么。同时项目经理的周均汇总时间从 7.4 小时降到 2.1 小时。

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

前面讲的是我这边的观察和判断，但每个组织的成熟度、规模、协作密度都不一样。这一节按三个规模档给具体动作，你可以对照自己的情况取用。

1. 50 到 150 人：先解决"看得见"的问题

这个规模的组织，跨部门协作通常还是靠人拉通的，正式流程往往是负担。我建议只做三件事：

1. 把里程碑的定义统一到"交付物 + 验收人 + 承诺日"三要素，去掉所有"完成 XX 阶段工作"式的模糊节点。
2. 所有改期必须在一个共享文档或系统里留一条记录，包含日期、原因分类、提出人。不做审批，只做留痕。
3. 每周固定一次 15 分钟的交接检查，只问一个问题：这周有哪些交付物完成了但下游还没启动？

这三件事的总投入不超过每周 1 小时，但能解决这个规模下 80% 的里程碑数据失真问题。

2. 150 到 500 人：建立归因框架和预警机制

这个规模是跨部门里程碑问题最集中的区间，部门墙已经开始形成，但还没有成熟的项目管理办公室来统一协调。我建议的动作是：

1. 上线五分类归因枚举，禁止自由文本，所有改期必须选择分类。
2. 建立依赖关系可视化，至少对关键路径上的里程碑做到"上游完成后自动通知下游"。
3. 设定三条预警规则：偏差超过承诺跨度 30%、交接静默超过 3 个工作日、同一里程碑连续改期 2 次。
4. 把里程碑粒度校准到 5 到 15 个工作日，超出的拆分或设置检查点。
5. 季度层面输出首次承诺达成率、承诺偏差中位数、交接静默时长三个指标，替代准时率。

在这个规模上，我强烈建议把规则写进系统而不是写在制度文档里。前面那个 260 人的案例里，在支持里程碑依赖关系和自动化提醒的平台（如 PingCode）上配置好规则之后，数据质量的提升速度明显快于靠培训和宣讲的阶段。

3. 500 人以上：解决口径统一和跨项目度量

这个规模的组织，最大的问题往往不是单个项目的里程碑管理，而是不同项目之间口径不一致，导致跨项目的资源调度和优先级判断缺乏依据。我建议：

1. 建立组织级的里程碑定义标准和归因分类标准，所有项目必须遵守。
2. 建立跨项目的里程碑台账，能看到同一时间窗口内有多少里程碑挤在关键资源上。
3. 把承诺质量指标纳入项目经理和部门负责人的考核，而不是纳入执行工程师的考核。
4. 对涉及客户交付的项目，单独追踪"客户可感知的里程碑"，与内部里程碑分开统计。

第四条是我在多个项目里总结出来的：内部里程碑的完成，和客户能感知到的交付，中间往往还有一段验收和部署的距离。把两者混在一起统计，会让组织高估自己的交付能力。

七、不同情况下的取舍

方法讲完了，但真正难的不是知道该做什么，而是知道在什么情况下不该做什么。这一节我讲五组我认为最需要在实施前想清楚的取舍。

1. 统计精度 vs 填报成本

越精细的统计要求，越高的填报成本，越低的填报真实性。我的经验判断是：当填报时间超过里程碑本身管理价值的 20% 时，这个统计就该简化了。

具体的取舍方式：只对关键路径上的里程碑做精细统计（含归因、偏差、依赖关系），非关键路径的里程碑只记状态和日期。这样既能保证核心数据的质量，又不会让团队陷入填表疲劳。

2. 里程碑粒度 vs 管控灵活度

粒度越细，偏差暴露越早，但团队自主空间越小；粒度越粗，团队灵活度高，但风险发现越晚。这个取舍没有统一答案，取决于两件事：交付物的不可逆程度，以及团队的历史可预期性。

如果交付物一旦做错返工成本极高（比如对外接口、数据模型），选细粒度；如果团队历史上承诺偏差中位数已经在 3 天以内，可以适当放宽粒度，把管理精力放在更高层的风险上。

3. 统一模板 vs 因地制宜

统一模板的好处是可以跨项目对比，坏处是某些项目会被迫填写无意义的字段。我在实际项目中采用的折中方案是：核心字段强制统一（三要素、归因分类、三个核心指标），辅助字段允许项目自定义。强制统一的字段控制在 8 个以内，超过这个数量，统一模板就会变成负担。

4. 自动化提醒 vs 人的判断

自动化提醒能解决"忘了看"的问题，但解决不了"不知道该怎么办"的问题。我见过一个团队的自动化提醒配置得非常完善，每天推送几十条预警，最后所有人把它设成了免打扰。

我的取舍原则是：自动化只用于"事实类"提醒（上游完成了、静默超过 3 天了、偏差超过阈值了），"判断类"的事情交给人（要不要改期、要不要加人、要不要降范围）。同时把每人每天收到的里程碑提醒控制在 3 条以内，超过的部分合并成日报。

5. 私有化部署 vs 云服务

这是我在选型阶段被问得最多的一个问题。判断依据其实很清晰：如果项目涉及客户现场数据、涉密数据、或者有明确的行业合规要求，私有化部署是硬性约束，没有讨论空间；如果没有这些约束，云服务的运维成本更低、迭代更快。

需要提醒的是，私有化部署会带来额外的版本升级和运维工作，这部分成本要在选型时算进去。我见过一些团队只算了软件成本，没算运维人力，上线后才发现每季度的升级验证要占掉一个人半周的工作量。

对于需要从原有平台迁移的团队，我建议把"迁移的完整性"作为独立的评估维度单列出来：历史数据能不能完整映射、字段能不能自定义、迁移期间能不能双系统并行。这三点决定了迁移后你还能不能做趋势分析，而不只是把数据搬过去当档案。

八、结语：下一步该做什么

回到开头那个问题：94% 的准时率和六成的实际交付，为什么能同时成立。因为前者统计的是"我们说过会做完的事里做完了多少"，而后者问的是"我们最初承诺的东西交付了多少"。这两个问题之间，隔着改期、范围调整、验收标准变化和一整套没人记录的过程。

我在这些年里最想传达的一个独特判断是：跨部门里程碑数据分析的核心，不是提高数据的精度，而是提高数据的"可争议性"。一份好的里程碑报表，应该让每个部门都能指着某个数字说"这里和我理解的不一样，我们来对一下"。如果一份报表所有人都点头说没问题，它大概率什么信息都没传递。

具体到下一步，我建议按这个顺序做三件事，不要一次全上：

1. 这周：拉出最近一个季度的所有里程碑，只看一件事，有多少个里程碑的日期被改过，改过几次，原因是什么。这一步不需要任何工具，用现有的项目记录就能做。做完你会对自家数据质量有一个真实的判断。
2. 这个月：把改期归因固定成五分类，把里程碑定义统一到三要素，把三个核心指标（首次承诺达成率、承诺偏差中位数、交接静默时长）的口径写下来。这一步是定义工作，成本很低，但决定了后面所有数据有没有意义。
3. 这个季度：把规则配置到系统里，让改期必须选归因、让上游完成后自动通知下游、让偏差超过阈值自动预警。前面 260 人组织的案例说明，这一步带来的改善幅度通常是最大的，因为大部分跨部门延迟根本不需要靠人变勤快来解决，只需要让该动的人知道该动了。

最后一句提醒：如果治理之后你的准时率下降了，先别急着否定这套方法，去看看承诺偏差中位数和客户投诉数。数据变难看，有时候恰恰是因为它终于开始说真话了。