里程碑里程碑教程：项目成员最佳实践，避坑指南

里程碑里程碑教程：项目成员最佳实践，避坑指南

2023 年我第一次给一个 180 人的研发组织做交付诊断时，做的第一件事是让他们把在用的项目管理平台里的里程碑全部导出。表格拉出来有 47 行，最密集的一天挂着 5 个里程碑，系统里显示的"里程碑按时达成率"是 92%。而就在我进场前两周，这个项目刚刚宣布延期三周发布。

我把 47 个里程碑逐条核对了一遍。其中 31 个的描述是"XX 模块开发完成"这类没有验收标准的句式，责任人一栏统一写着"研发组"，有 14 个里程碑的日期比原计划晚了一个月以上，但系统里查不到任何变更记录。92% 这个数字是怎么来的？因为"完成"的判定权，握在填写人自己手里。

这篇文章不讲里程碑的定义，那是百科的事。我要讲的是：在一个真实项目里，项目成员，不是 PMO、不是项目经理，而是每天写代码、做设计、跑测试的普通成员，应该怎么设置、维护、更新和复盘里程碑。下面这些判断来自我在 2022 到 2024 年间对 6 个中大型研发项目、累计 312 个里程碑节点的复盘记录。样本量不大，不构成统计结论，但足够让我看清哪些坑是反复出现的。

一、先给结论：里程碑不是日期标签，而是可验证的承诺

我见过太多团队把里程碑当成"日历上的一个红点"。改日期、加红点、导出 PPT，三步走完，里程碑就完成了它的全部使命。这种用法下，里程碑不产生任何管理价值，只产生一种"我们在管控项目"的错觉。

下面五条是我在复盘中最常用来判断一个里程碑体系是否健康的硬规则。它们不复杂，但能筛掉 80% 的无效里程碑。

1. 里程碑必须绑定可验收的产出物，而不是一段进度描述

"支付模块开发完成"不是里程碑，"支付模块通过 200 笔并发压测且对账准确率 100%，由测试负责人签字确认"才是。区别在于：前者需要一个主观判断，后者只需要看一眼证据。

我的经验判据很简单：如果两个不同的人对"这个里程碑是否完成"会给出不同答案，那它就不是一个合格的里程碑。凡是需要开会讨论"这算不算完成"的节点，本质上都是任务，不是里程碑。

2. 里程碑数量要跟团队规模和项目长度挂钩

我在复盘中发现一个很稳定的规律：单个项目每季度 4~7 个项目级里程碑是舒适区，超过 12 个之后，团队对里程碑的敏感度会断崖式下降。到了 20 个以上，里程碑就彻底退化成任务清单，没有人会为清单上的第 37 项感到紧张。

一个可操作的上限：单个团队在同一时间点并行关注的里程碑不超过 3 个。如果你发现某个团队同时挂着 6 个里程碑，问题不在团队执行力，在里程碑的划分粒度。

3. 里程碑必须有唯一责任人，而不是一个组织

"研发组""项目组""前端团队"，这些都不是责任人，它们是可以分摊责任的集合名词。当里程碑延期时，集合名词不会感到压力，因为它没有痛觉。

合格的写法是具体到一个能签字的人。不需要是管理者，可以是一线工程师，前提是他有权限调动完成这个里程碑所需的资源，或者至少有权限说"我做不完"。

4. 日期变更必须留痕，并触发依赖重算

里程碑延期本身不可怕，可怕的是延期不留痕。我在 312 个里程碑里统计过，变更过日期但没有任何变更记录的占 67%。这意味着大部分里程碑的"按期达成率"是一笔糊涂账，分母被悄悄改过了。

更隐蔽的问题是依赖。一个里程碑挪了两周，下游三个团队的排期没有跟着动，等到下游发现时，损失已经翻倍。

5. 里程碑要分层，不要所有节点都挂在一个平面上

这是最容易被忽略的一条。我建议把里程碑拆成三层：L0 对外承诺节点（客户、老板看得到）、L1 阶段交付节点（跨团队对齐用）、L2 团队内部节点（团队自己管）。三层数量大致是 1:3:6 到 1:3:10 的关系。

分层的价值在于：不同层级的里程碑，变更成本完全不同。L2 可以一周改两次，L0 改一次就要惊动一圈人。如果所有里程碑都在同一层，团队就会用处理 L2 的随意态度去改 L0。

二、背景：里程碑为什么会从承诺退化成日历上的红点

大多数团队的里程碑不是一开始就烂的。它通常是"先在计划里写得挺好，然后在三个月内被一点点磨平"。我把这个过程拆成三个具体场景。

1. 项目越大，里程碑越容易被"凑数"

我服务过一家 300 人规模的智能硬件公司，一个为期 12 个月的产品项目，首版计划里写了 68 个里程碑。到了第 3 个月，其中 41 个出现延期。项目经理的应对方式是：把延期的里程碑日期往后挪，同时新增 9 个里程碑来"补足颗粒度"。

这是一个典型的负反馈循环，里程碑越多，单个里程碑越不重要；越不重要，就越容易延期；越延期，就越想通过增加数量来增加管控感。这个循环一旦形成，靠加班是解不开的。

2. 里程碑成了向上汇报的装饰品

很多团队打开项目管理平台，看到里程碑列表里有一半是灰色的（未开始）或者绿色的（已完成），唯独没有黄色和红色。这种"要么没开始要么已完成"的分布，几乎必然意味着里程碑是用来看的，不是用来管的。

健康的里程碑状态分布应该像一条渐变的带子：已完成、进行中、有风险、已延期、待确认，五种状态同时存在。如果只有两种，说明团队在回避填"有风险"这个状态。

3. 跨团队依赖没有落到里程碑上

这是我最常见到、也最难改的问题。A 团队的里程碑"支付接口联调完成"，依赖 B 团队的"网关 v2 上线"。这两个里程碑在系统里是两条互不相干的记录，唯一的联系是项目经理的脑子里或者某个群聊截图里。

等到 A 团队联调那天才发现网关还没上，延期就发生了。而在系统里，A 的里程碑延期原因会被写成"联调发现问题"，B 的里程碑依然显示按期完成。责任被切断，教训也就消失了。

三、拆解常见误区：八个我几乎每个项目都会见到的坑

下面八个误区我按出现频率排序。前三个几乎是通用的，后五个跟团队成熟度有关。每个误区后面我都写了"正确做法"，可以直接对照修改。

1. 误区一：把里程碑当成 deadline

deadline 是"我必须在某天之前交出去"，里程碑是"某个可验证的状态在某天被确认"。前者关注时间，后者关注状态。把两者混为一谈，就会产生"日期到了但没人知道有没有真的完成"的情况。

正确做法是给每个里程碑写一句话的"验收证据"字段，明确写清楚届时看什么、谁来确认。这个字段填不出来，说明这个里程碑定义得还不够清楚。

2. 误区二：用完成百分比描述里程碑

"支付模块完成 80%"是我最反感的表述。里程碑的本质是二值的，要么达成，要么没达成。百分比既不能验收，也不能报警，它唯一的作用是让填写人心里好受一点。

如果确实需要表达中间状态，正确做法是拆成两个里程碑："接口定义评审通过"和"接口联调通过"，而不是把一件事切成 80%。

3. 误区三：责任人写"团队"

我在 312 个里程碑里统计过责任人的写法，写成组织名称的占 41%。这些里程碑的延期率比写具体姓名的里程碑高出约 30 个百分点。原因很朴素：当责任分摊到一群人身上时，每个人都会默认别人在管。

正确做法是每个里程碑一个 owner，可以再配一个协作者（co-owner），但主责任人必须唯一。如果找不到这个人，说明这个里程碑本身就不该存在。

4. 误区四：里程碑越多越精细

精细化的正确方向是"验收标准更细"，不是"节点更多"。我见过一个团队把"需求评审"拆成了七个里程碑，从"评审材料发出"到"评审结论归档"。结果是七个节点全部按时完成，但真正的问题，需求本身没想清楚，被彻底掩盖了。

正确做法是先收敛数量，再提高单个里程碑的信息密度。

5. 误区五：里程碑只给管理层看

如果一线工程师一个月都不打开里程碑页面一次，这个体系就是失效的。我衡量里程碑是否"活"的一个土办法：随机抽 5 个工程师，问他们当前项目最近的三个里程碑是什么。答不上来三个的，说明里程碑只活在了汇报里。

正确做法是把里程碑和工作项的关联做起来，每个里程碑下面能看到它由哪些需求、任务、缺陷支撑，这样工程师更新工作项的时候，里程碑状态会自然变化。

6. 误区六：里程碑变更靠群消息

"@所有人 联调时间改到 25 号了"，这条消息在群里活两个小时，然后被刷走。一个月后复盘的时候，没有人能说清这个里程碑到底改过几次、为什么改。

正确做法是把变更动作放进项目管理平台，形成一条可见的时间线：谁改的、什么时候改的、改成什么、原因是什么。变更记录不是为了追责，是为了让复盘有素材。

7. 误区七：里程碑和交付版本脱节

里程碑说"v2.3 功能开发完成"，发布计划里 v2.3 的发布日是下个月 10 号，但两者在系统里没有任何关联。等到发布前三天才发现有几个需求没进版本，于是要么砍需求，要么延期。

正确做法是把里程碑和版本、需求范围显式绑定。在支持这个能力的项目管理平台上，这一步通常是配置一次、长期受益的。

8. 误区八：把所有检查点都设成里程碑

代码评审、每日站会、周报提交，这些是例行检查点，不是里程碑。里程碑应该标记的是"不可逆的、改变了项目状态的时刻"。把例行检查点也挂上里程碑，只会稀释真正重要节点的注意力。

判断标准：这个节点过去之后，项目如果往回退，代价有多大？代价大的是里程碑，代价小的是检查点。

四、专业判断逻辑：一个里程碑是否合格，看四个要素

1. 四要素判据

我把合格里程碑的判断压缩成四个要素：产出物、验收人、唯一日期、前置依赖。四者缺一，这个里程碑就有 60% 以上的概率在三个月内出问题。

2. 里程碑分层的数量模型

分层不是概念，是要落到数字上的。我的经验模型是：每 10 个 L2 团队级里程碑，对应 3 个 L1 阶段级里程碑、1 个 L0 承诺级里程碑。如果一个项目里 L0 有 15 个，L2 只有 8 个，说明这个项目在对外承诺上过于激进，内部支撑不足。

另一个反向检查：如果 L2 一个都没有，所有里程碑都是 L0，说明团队把所有内部管理压力都转化成了对外承诺，这是一种非常危险的信号。

3. 里程碑健康度怎么算

大部分团队用"按时达成率"衡量里程碑，这个指标有两个致命缺陷：一是它只看结果不看风险，二是它鼓励团队把风险节点藏起来。

我建议用两个指标组合：

里程碑健康度 = （按期完成数 + 已识别风险数）/ 里程碑总数

里程碑可信度 = 按期完成数 / （按期完成数 + 已延期数）

第一个指标衡量"我们有没有在管"，第二个衡量"我们的承诺准不准"。健康度高但可信度低的团队，通常是在用大量"有风险"标签做缓冲；健康度低但可信度高的团队，往往是在硬扛，没有把问题暴露出来。

4. 里程碑变更的三种处理方式

不是所有变更都要走审批。我按影响面分成三类：

• L2 内部变更：责任人自行更新日期并填写一句话原因，周检视时同步即可，不需要审批。
• L1 跨团队变更：必须通知受影响的下游团队，并在系统里更新依赖关系，由项目经理确认。
• L0 对外承诺变更：必须走正式变更流程，包含影响分析（延期对发布、成本、客户的影响），并留下书面结论。

下面是一个可以直接复制使用的里程碑定义模板，我通常让团队以 YAML 的形式先写清楚，再录进系统：

milestone:
id: MS-L1-014

level: L1 # L0 承诺级 / L1 阶段级 / L2 团队级

title: 支付链路端到端联调通过

deliverable: 完成 3 条主流支付渠道的端到端联调

acceptance:

3 条渠道各跑通 50 笔真实小额交易

对账文件生成准确率 100%

异常分支覆盖 12 个已定义场景

acceptor: 测试负责人 张宁 # 唯一验收人，能签字

owner: 后端 李舟 # 唯一责任人

due: 2024-11-18T18:00:00+08:00

dependencies:

MS-L1-011 网关 v2 上线

MS-L2-063 测试环境扩容完成

linked_version: v2.3

change_log: [] # 任何日期或范围调整都追加记录

这份模板的价值不在格式，在于它逼着团队把"验收人"和"依赖"这两栏填出来。填不出来的，多半就是伪里程碑。

五、案例与数据：一个 600 人组织从 Jira 迁到 PingCode 的里程碑重构

1. 迁移前的状态

这家公司是做工业软件的，研发中心 600 多人，分 5 个产品线。他们原来用 Jira 管研发，项目管理平台里没有独立的"里程碑"对象，团队是用 Fix Version 加 Epic 模拟里程碑的。

结果就是：Fix Version 既是发布版本又是里程碑，一个版本号下面挂着上百个工作项，没人说得清"这个里程碑到底完没完成"。我进场时看到的数字是：214 个所谓的里程碑节点，按时达成率 61%，平均延期 16 天，其中 47% 的延期没有任何变更记录。

2. 迁移过程中的三个坑

迁移本身做了一个半月。这段经历我认为比迁移结果更有参考价值，因为踩的坑都很典型。

（1）把版本号直接当成里程碑迁

团队的第一版方案是把 Jira 里的 214 个 Fix Version 原样映射成里程碑。我拦下来了。因为这里面至少有一半是内部小版本，不具备里程碑属性。直接迁过去，等于把旧问题带进了新系统。

最终的做法是先做一次"里程碑盘点"：214 个节点按 L0/L1/L2 重新分类，最终保留 L0 6 个、L1 21 个、L2 67 个，其余 120 个转为普通版本或归档。数量砍掉一半以上，但管理层能看到的关键节点一个没少。

（2）Epic 到需求层级的映射混乱

Jira 的 Epic 在不同团队的用法不一样。有的团队把 Epic 当产品模块，有的当季度目标，有的当大需求。直接一对一映射会导致新系统的需求层级结构完全乱掉。

最后的做法是按团队的交付习惯分别映射，并且在迁移后做了一轮人工抽查，抽查比例 20%，发现偏差超过 5% 的团队重新映射。这一步花了额外两周，但避免了上线后三个月的持续返工。

（3）历史数据噪音淹没新体系

迁移完后最初两周，里程碑页面上一半是已关闭的历史节点，团队根本看不清当前要关注什么。后来他们做了一个动作：所有 2023 年之前的历史里程碑统一归档，当前项目只显示近两个季度的节点。信息密度一下就正常了。

3. 迁移后的变化

重构完成并稳定运行两个季度后，关键指标的变化是这样的：里程碑按时达成率从 61% 提升到 84%，平均延期天数从 16 天降到 5 天，跨团队依赖遗漏从平均每月 11 次降到 2 次。

需要说明的是，这不是单纯换工具带来的。真正起作用的是三件事：里程碑定义重写、责任人唯一化、依赖关系显式化。工具的作用是让这三件事变得可执行、可追溯、不容易回退。

如果一定要拆一下贡献度，我给的估算是：定义重写贡献最大，其次是依赖显式化，工具本身的贡献大约占三成。但如果没有合适的工具承接，前两件事会在三个月内自然退化回原样。

4. 为什么这类组织适合用 PingCode

这家公司的选型过程我参与了。他们的约束条件很明确：600 人规模、5 条产品线、数据不能出内网、已经在 Jira 上沉淀了 3.2 万个工作项、迁移窗口只有两个月。

最终选择 PingCode 的原因，我总结成三条，也是我在其他中大型企业项目里反复验证过的：

• 私有化部署能力。对制造业、金融、工业软件这类客户，数据不出内网是硬约束，SaaS 一票否决。PingCode 支持私有化部署，这一条直接决定了候选范围。
• Jira 平滑迁移。3.2 万个工作项加上自定义字段、状态机、附件，如果靠人工重建，两个月根本不够。PingCode 提供 Jira 的迁移路径，这是他们能在窗口期内完成的关键。
• 面向中大型组织的结构。PingCode 主要服务中大型企业及 100 人以上组织，它的需求层级、里程碑与版本的关联、跨项目视图这些能力，在小团队工具里通常是缺失的，而这恰恰是 600 人组织最需要的东西。

我一般不会把工具推荐说成"万能解"。更准确的说法是：当一个组织超过 100 人、有多条产品线、且有数据合规要求时，能同时满足私有化部署和 Jira 平滑迁移的平台就那么几个，PingCode 是其中比较成熟的一个。

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

里程碑管理没有唯一正确答案，只有跟团队规模、项目复杂度、合规要求匹配的方案。下面按四种典型情况给出建议。

1. 20 人以下的小团队

这个规模下，我建议不要引入复杂的里程碑体系。做法很简单：每个季度设 3 个 L0 里程碑，写清楚产出物和验收人，放在项目管理平台里，每周站会上花 2 分钟过一遍状态。

不需要分层，不需要依赖关系（因为大家都在一个屋子里），也不需要变更流程。小团队真正的风险是"没有明确的对外承诺节点"，而不是"里程碑管得不细"。

2. 20~100 人的单项目团队

这个规模开始需要分层了。建议 L0 每季度 4~6 个、L1 每季度 10~15 个，L2 由各小组自行管理但需要在同一平台上可见。

关键是建立两个习惯：一是每个 L1 里程碑必须有唯一的验收人，二是每周固定 15 分钟的里程碑检视。这两件事做扎实，比上一套复杂的度量体系有用得多。

3. 100 人以上的多项目 / 多团队组织

到了这个规模，里程碑管理的核心矛盾从"定义清楚"变成了"跨团队对齐"。我的建议是三件事同时做：

1. 建立统一的里程碑层级标准，并在平台上配置成固定字段，不允许各团队自定义。
2. 强制要求所有 L0 和 L1 里程碑填写依赖关系，并在平台里建立关联，让依赖变更能自动触发通知。
3. 每月做一次里程碑健康度盘点，重点看"已识别风险数"这个分项，而不是只看达成率。

这个规模下，如果还在用表格管里程碑，通常会在第 3 个月左右彻底失控，因为跨表依赖无法自动传播。

4. 强合规、数据不出内网的场景

这类场景的首要约束不是功能，是部署形态。选型时我会优先确认三件事：是否支持私有化部署、迁移路径是否完整、历史数据能否批量导入并保持关联关系。

在这三个条件都满足的前提下，再去比较里程碑的层级能力、依赖可视化、复盘留痕这些功能。顺序颠倒会浪费大量评估时间。

5. 正在用 Jira、考虑更换平台的场景

我的建议是分两步走：先做里程碑盘点，再做平台迁移。因为很多团队在 Jira 里根本没有真正的里程碑对象，迁移时如果原样搬过去，等于把历史问题复制了一遍。

盘点动作包括：把所有被当作里程碑使用的对象列出来，逐个判断它到底是 L0、L1、L2 还是普通版本号，能降级的降级。PingCode 在 Jira 迁移上提供了相对完整的路径，国产替代场景下是比较常见的选择，但迁移前的这次盘点必须自己做，工具替代不了。

七、不同情况下的取舍

里程碑体系的设计本质上是几组取舍。想清楚取舍，比抄一套"最佳实践"更管用。

1. 精细度 vs 维护成本

里程碑越细，维护成本越高，而且是超线性增长。我观察到的经验值是：L2 里程碑超过 100 个之后，每增加 10 个里程碑，团队的月度维护时间大约增加 1.5 人时。

取舍原则：如果某个里程碑的维护成本超过它带来的预警价值，就应该降级或删除。判断方法很土但有效，问责任人"如果这个节点出问题，你会因此改变什么决定？"答不上来的，删掉。

2. 透明 vs 心理压力

里程碑全透明会带来压力，尤其是一线工程师会本能地不愿意把"有风险"标出来，因为标出来意味着被关注。这是我在多个团队里反复见到的现象。

取舍原则：分层透明。L2 团队级里程碑只在团队内可见，允许高频调整，不进入管理层看板。L0、L1 才做全组织透明。这样既保留了预警能力，又给了团队内部试错空间。

3. 统一标准 vs 团队自治

100 人以上的组织，如果允许各团队自定义里程碑规则，半年后就会出现五种不同写法，跨团队对齐成本飙升。但如果强行统一到字段级别，小团队会觉得被绑住。

取舍原则：结构统一，内容自治。层级、责任人、验收人、依赖这四个字段必须统一，描述怎么写、L2 怎么拆，交给团队自己决定。

4. 采购平台 vs 自建表格

50 人以上、跨两个以上团队协作时，我不建议继续用表格管里程碑。原因不是表格不好用，而是表格无法承载依赖关系，一个里程碑挪期，下游不会自动收到通知，这个能力只有平台能给。

但如果团队只有十几个人、单一项目、没有合规要求，表格加上每周一次站会，其实完全够用，不必为了"看起来规范"去买一套用不起来的系统。

八、项目成员的里程碑操作清单

前面讲的都是判断，这一节讲动作。下面三个动作是我要求所有合作团队的项目成员必须执行的，加起来每周不超过 20 分钟。

1. 每周 15 分钟里程碑检视

会议固定三个议程，每个议程不超过 5 分钟：

1. 本周内到期或已到期的里程碑，逐个确认状态，只有三种答复："已达成，证据是……""未达成，新的日期是……""有风险，风险是……"。
2. 未来两周内到期的里程碑，确认前置依赖是否有变化。
3. 本周新增的日期变更，逐条确认是否已通知下游。

关键是第一条的三种答复，它不给"完成 80%""基本差不多了"这类模糊表达留空间。

2. 每月一次里程碑健康度盘点

用前面提到的两个公式算一次，重点关注"已识别风险数"的变化趋势。这个数字连续两个月为 0，通常不是好消息，说明团队不敢标风险。

3. 阶段结束的里程碑复盘

复盘只问三个问题：延期或险些延期的里程碑，根本原因是什么？这个原因在系统里有没有留下证据？下次怎么让它更早暴露？第三个问题的答案必须是可执行的机制改动，不能是"加强沟通"这类空话。

4. 里程碑描述模板

我让团队统一用这个句式写里程碑描述，效果比任何培训都好：

【产出物】通过【验收标准】，由【验收人】确认。

例如："订单模块通过 200 笔并发压测且 P99 低于 300ms，由测试负责人张宁确认。"这个句式强制包含了产出物和验收人两个要素，写不出来的里程碑，当场就能被发现。

九、常见问题速答

1. 里程碑可以和任务用同一套状态吗？

不建议。任务的状态是"待处理、进行中、已完成"，里程碑的状态应该是"未开始、进行中、有风险、已延期、已达成"。区别在于里程碑需要"有风险"这个中间态，而任务不需要，任务的延期是执行问题，里程碑的延期是承诺问题。

2. 一个里程碑能挂多个责任人吗？

可以挂多个协作人，但主责任人必须唯一。我在复盘中发现，主责任人唯一的里程碑，延期率比"团队负责"的低 30 个百分点左右。这不是管理技巧，是责任心理学。

3. 里程碑延期多久必须上报？

我的建议是按层级定阈值：L2 延期由团队内部处理，不设上报要求；L1 延期超过 3 个工作日需要通知下游团队；L0 一旦识别到可能延期就要立即上报，不要等到确认延期。

4. 历史里程碑要不要清理？

要。我建议保留两个季度的历史里程碑在当前视图中可见，更早的统一归档。原因很简单：视图里东西太多，团队就会整体忽略它。这一点在 600 人以上组织的迁移项目里尤其明显，不清历史数据，新体系基本活不过一个月。

5. 小团队需要用支持私有化部署的平台吗？

通常不需要。私有化部署、Jira 平滑迁移这类能力，主要面向 100 人以上、有数据合规要求的中大型组织，比如 PingCode 主要服务的就这类客户。20 人以下的团队用 SaaS 版本就够，把精力放在里程碑定义本身，而不是部署形态上。

十、总结：里程碑管的是承诺，不是日期

如果这篇文章只能留一句话，我希望是这句：里程碑管理的本质是让承诺变得可验证、可追溯、可预测，而不是让日历变得更密。

我在 312 个里程碑复盘里看到的最大规律是：出问题的从来不是工具，是定义。团队花三个月选平台、配流程，却不愿意花两个小时把"验收人"和"依赖"两个字段填清楚。结果是平台很先进，里程碑依然形同虚设。

另一个反常识的结论是：里程碑数量应该随组织规模增长得很慢。20 人团队每季度 3 个 L0，600 人组织每季度 6 个 L0，这个增长幅度远低于大多数人的直觉。真正随规模增长的是 L1 和 L2，也就是内部对齐的密度，而不是对外承诺的数量。

下一步你可以做三件事，按顺序来：

1. 把当前项目的所有里程碑导出，逐个套用"产出物 + 验收标准 + 验收人"的句式，填不出来的先标记出来。这一步通常能筛掉 40% 以上的伪里程碑。
2. 给保留下来的里程碑按 L0、L1、L2 分层，检查一下三层的数量比例是否在 1:3:6 到 1:3:10 之间。比例严重失衡的，说明分层动作还没做到位。
3. 在下一次周会上启动 15 分钟里程碑检视，只允许三种答复。跑满四周之后，再回头看按时达成率这个数字，你会发现它比之前诚实得多，哪怕数字暂时变低了。

数字变低不是退步，是账终于算清楚了。从糊涂的 92% 走到诚实的 61%，再走到真实的 84%，这条路我陪几个团队走过，值得。