里程碑管理指南：产品经理如何做好里程碑，制度设计全流程

去年 11 月，我参与复盘一个 180 人产研团队的季度交付。季度初他们定了 9 个里程碑，季度末系统里 8 个显示”已完成”，1 个”延期中”。听上去是个能写进汇报的漂亮结果。但我把 9 个里程碑逐个拆开看交付物时，真正通过验收人确认的只有 3 个，另外 5 个所谓的”完成”，是把还没过 UAT 的功能标成”已发布”，把 5% 灰度说成”上线”，把需求文档初稿当成”需求冻结交付物”。

这不是个例。过去两年我复盘过 23 个产研团队、147 个季度里程碑，一个反复出现的规律是：里程碑的数量和它的可信度成反比，而”完成率”这个指标本身，往往是团队自我欺骗的第一现场。更麻烦的是，大部分团队出问题的地方不在执行，而在制度设计，里程碑怎么切、谁定义、谁验收、改了怎么算，这四件事在季度初就已经决定了季度末的结果。

一、先给结论：里程碑是承诺系统，不是进度刻度

如果你只想从这篇文章里拿走一句话，那就是：里程碑管理不是进度管理，而是承诺管理和风险管理。进度是连续的、可以估算的、允许波动的；承诺是离散的、必须二元判定的、有成本的。把这两件事混在一起，是绝大多数里程碑制度失效的根因。

1. 里程碑的本质是”不可逆的承诺节点”

我在带团队时有一个很硬的判断标准：一个里程碑如果可以被”部分完成”，那它就不是里程碑，而是一个任务。里程碑只有两种状态，过了，或者没过。没有 70% 过、80% 过。

为什么强调”不可逆”？因为里程碑的真正价值不是记录”我们做到哪了”，而是标记”从这一刻起，我们不再担心某类风险了”。需求冻结里程碑过了，意味着”需求还会大改”这个风险被消除了；技术验证里程碑过了，意味着”方案根本跑不通”这个风险被消除了；上线里程碑过了，意味着”交付不出去”这个风险被消除了。

如果一个节点过了之后，团队依然要为同一类风险反复开会、反复确认、反复返工，那这个里程碑就是假的。它只是日历上的一个刻度，不是承诺。

2. 判断一个里程碑合不合格，只问四个问题

我在评审任何团队的里程碑计划时，只问四个问题，答不上来任何一个，这个里程碑就退回重写：

1. 交付物是什么？不是”完成开发”，而是”XX 模块的 12 个接口在预发环境通过全部 47 条自动化用例，报告链接可查”。
2. 谁验收？必须是一个具体的人名或角色，不能是”产品团队””相关方””领导”。没有单一验收人的里程碑，等于没人验收。
3. 验收标准怎么测？必须是可复现的动作或可读取的数据，不能是主观评价。比如”灰度用户次日留存 ≥ 42%，连续 7 天”，而不是”用户体验良好”。
4. 什么情况下判定为失败？这一条 90% 的团队从来没写过。没有失效条件的里程碑，延期了也无从追责、无从复盘。

3. 里程碑数量上限：一个季度 3 到 5 个

这是一个经验值，但它有很强的解释力。我统计过一个 100 人左右的 SaaS 团队连续 6 个季度的数据：季度里程碑 8 个以上时，按期达成率 43%；压缩到 4 到 5 个时，按期达成率升到 78%；进一步压到 2 到 3 个时，反而是 71%。

最后一段下降很有意思，里程碑太少，团队失去了节奏感，季度中段容易松懈，反而在季度末堆积交付。所以 3 到 5 个是甜点区，而不是越少越好。

为什么里程碑一多就崩？因为每增加一个里程碑，就增加一次跨部门对齐、一次验收判定、一次变更决策。当这些动作超过团队的管理带宽时，团队就会自动降级处理，把验收变成口头确认，把变更变成默认接受，把里程碑变成汇报日历。制度不是被推翻的，是被稀释的。

4. 制度设计的关键：定义权、验收权、变更权必须分离

这是我认为最容易被忽略、但收益最大的一条制度设计原则。很多团队之所以里程碑形同虚设，是因为产品经理同时握有三种权力：

• 定义权：决定里程碑什么时候定、包含什么交付物；
• 验收权：决定这个里程碑算不算过；
• 变更权：决定里程碑能不能改期、改范围。

三权合一的结果是可预测的：里程碑会自动向着”容易通过”的方向漂移。交付物写得模糊一点，验收标准写得主观一点，范围变更批得快一点。这不是人品问题，是结构问题。

我在团队里的做法是：产品经理持有定义权，业务方或技术负责人持有验收权，变更权交给一个三人小组（产品、技术、业务各一人），单人不得改期。这三权分离之后，里程碑的按期达成率在一个季度内从 51% 提到了 74%，而且没有增加任何会议。

二、真实场景：三个我亲历的里程碑失控现场

抽象原则讲完了，下面是我真实经历过、并且有完整数据记录的三次失控。我把它们写出来，是因为几乎每个团队都会经历其中至少一个。

1. 场景一：9 个里程碑的”全员完成”

就是我开头提到的那个 180 人团队。季度末汇报时，9 个里程碑里 8 个绿、1 个黄，汇报材料看起来非常健康。但我做了一次交叉核验，把系统状态和实际证据做对照，结果是这样的：

• 系统显示”已完成”：8 个；
• 能拿出交付物的：5 个（其余 3 个只有一句”已完成”的备注）；
• 通过指定验收人书面确认的：3 个；
• 上线 30 天后达到预期业务指标的：1 个。

注意最后一行。前三个数字的差距是”管理质量”问题，最后一个数字的差距是”制度导向”问题。这家团队的所有里程碑都切在交付侧（开发完成、测试通过、上线发布），没有一个切在价值侧。结果就是团队正确且高效地完成了所有该做的事，然后发现用户的激活率没有变化。

2. 场景二：需求冻结日变成”冻结了个寂寞”

另一个 60 人团队，制度上写得很清楚：第 6 周为需求冻结日，冻结后变更需走评审。执行情况是，冻结后 4 周内共产生 37 次需求变更，其中 31 次在 1 个工作日内”评审通过”，平均评审时长 22 分钟。

我去看了这 31 次评审的记录，绝大多数只有一句话：”业务紧急，同意变更。”没有影响评估，没有工期补偿，没有对其他里程碑的连锁影响分析。当变更评审的平均时长低于一顿午饭的时间，这个流程就已经不是流程，是盖章。

我们后来做了一件事：在变更流程里强制加两个字段，”影响的里程碑编号”和”补偿措施（砍掉哪条需求）”。仅仅加了这两个字段，变更次数在下一个季度从 37 次降到 14 次。不是流程变复杂了，是改的人终于意识到改是有代价的。

3. 场景三：从另一套工具迁到 PingCode 时的里程碑重建

第三个场景发生在一家约 300 人的智能制造企业。他们原来用的是一套海外项目管理工具，跑了三年，42 个项目、18.3 万条工作项、26 万条评论。决定迁到 PingCode 的原因是私有化部署 + 国产替代的合规要求，同时也要解决里程碑数据长期不可信的问题。

这里我特别想讲一个细节：数据迁移最难的从来不是字段映射，而是历史里程碑的语义重建。老系统里”里程碑”字段被当成标签用，同一个项目下挂了十几个，有的表示阶段、有的表示版本、有的表示交付批次。如果直接平迁，等于把三年来积累的混乱原样搬进新系统。

我们最后定的方案是：只迁移最近 2 个季度的里程碑作为历史基线，更早的全部降级为普通工作项标签，保留可查性但不参与度量。同时在新系统里重建里程碑模板。整个过程用了 11 个工作日，其中数据迁移 3 天、语义清洗 5 天、制度重建 3 天。用 PingCode 做 Jira 平滑迁移时，真正的时间瓶颈在语义清洗，不在工具本身。

三、误区拆解：七个最常见的里程碑错误

下面这七个误区，我按”出现频率 × 破坏力”排序，每一条都附上我在真实团队里看到的表现形式。

1. 把里程碑当成汇报日历

表现是：里程碑的日期不是根据交付节奏推出来的，而是根据月度会、季度会、集团汇报节点倒排出来的。月初一个、月末一个、季末一个，非常整齐。

这种里程碑的唯一功能是让汇报有内容可写。它不消除任何不确定性，也不绑定任何交付物。判断方法很简单：如果某个里程碑的日期在定下来的时候，团队还没想清楚要交付什么，那它就是一个汇报日历。

2. 用百分比汇报里程碑进度

“这个里程碑完成了 70%。”这句话我听了十年，至今没有听到过一个能自洽的解释，70% 是按什么分母算的？剩余 30% 是什么？为什么不是 65% 或 75%？

更严重的是行为后果：百分比进度是延期最好的掩护。一个里程碑从 60% 爬到 90% 可以爬三个月，而且每次汇报都是”稳步推进”。二元判定则没有这个空间，到日子就是过或不过，逼着团队提前暴露问题。

3. 里程碑只挂在开发侧

典型的一串里程碑是：需求评审完成 → 开发完成 → 测试完成 → 上线发布。四个节点全部在研发内部，业务方只在最后一个节点出现。

后果是：需求验证、用户培训、数据迁移、灰度策略、客户侧环境准备这些真正容易掉链子的环节，一个里程碑都没有。上线当天才发现客户侧的接口权限还没批，或者运营的培训材料还没写。里程碑应该覆盖”端到端”，而不是覆盖”研发部”。

4. 把 100% 达成率当成健康信号

我在评审时看到”连续四个季度里程碑 100% 达成”，第一反应不是表扬，是去查两件事：范围是不是没有冻住？验收标准是不是太软？

真实的产品研发一定包含不确定性，一定会有判断失误。如果所有里程碑都按期通过，最可能的解释是：里程碑被定义成了”一定能做到的事”。这种制度看起来很健康，实际上已经失去了风险暴露功能。

5. 里程碑只对上，不对下

很多团队的里程碑只出现在给管理层的汇报材料里，团队成员的日常看板上根本没有。结果是：一线同学不知道自己正在为哪个承诺负责，也不知道这个承诺哪天验收、验收标准是什么。

里程碑必须落在团队的日常视图里，而且必须和每个人的任务有明确挂接。否则它就不是团队的里程碑，是管理者的 Excel。

6. 变更没有成本

这是我见过的最隐蔽的杀手。因为”变更没有成本”，所以”计划也没有约束力”。当团队发现改期只需要说一句”业务需要”，整个里程碑体系就变成了一个事后描述系统，先干活，再补里程碑。

健康的做法不是禁止变更，而是让每次变更都产生一次显式的取舍：改了这个里程碑，就要砍掉某条需求、或推迟某个里程碑、或增加某个人力。没有取舍的变更审批，本质是橡皮图章。

7. 把里程碑和 OKR 的 KR 混用

里程碑是”我们打算在什么时间点交付什么、由谁验收”，KR 是”我们希望在季度末看到什么结果”。前者是承诺，后者是目标。把两者混在一起，会出现两种糟糕情况：要么里程碑写得像愿景（”用户满意度显著提升”），要么 KR 写得像任务清单（”完成 12 个接口开发”）。

我的处理方式是：里程碑归项目/版本管理，KR 归目标管理，两者通过”价值验证里程碑”这一个节点连接。也就是说，季度里唯一一个既出现在里程碑列表、又直接支撑 KR 的节点，就是上线后的价值复盘。

四、专业判断逻辑：里程碑该怎么切、怎么定、怎么验收

这一节是整篇的方法论核心。我把它拆成切分、定义、验收、变更四件事，每件事都给出可以直接抄走的结构。

1. 切分原则：按”不确定性消除”切，不按”部门交付”切

这条原则我反复对团队讲。按部门切，你会得到”设计完成、开发完成、测试完成”这种里程碑，它们的共同问题是：不消除任何外部不确定性。按不确定性切，你会得到完全不同的东西。

在私有化交付型项目里，我常用的切法是：

1. 需求冻结：消除”范围还会变”的不确定性；
2. 技术方案验证：消除”方案根本走不通”的不确定性；
3. 功能完备：消除”功能做不完”的不确定性；
4. 客户环境就绪：消除”交付不出去”的不确定性；
5. 价值验证：消除”做了没人用”的不确定性。

五个节点，每一个都对应一类具体的风险。团队在任何一个节点不过时，都知道下一步该干什么，因为风险是明确的。

如果是 SaaS 迭代型产品，我会把第 4 个换成”灰度发布完成”，把第 5 个提前到上线后 14 天，因为 SaaS 的价值反馈周期更短。

2. 四要素模板：可以直接复用

下面是我在一年内迭代了 7 版、目前认为最稳定的里程碑定义模板。我用它评审过 200 多个里程碑，最大的价值是让”含糊”无处藏身。

里程碑名称：M2 技术方案验证通过
目标日期：2024-03-22

责任人：张 XX（技术负责人）

【交付物】

技术方案文档 v1.0（含架构图、接口清单、性能预算）
可运行的端到端 Demo（覆盖 3 条主链路）
压测报告：单节点 QPS ≥ 800，P99 ≤ 220ms
【验收标准】

Demo 在预发环境连续运行 72 小时无 P0/P1 缺陷

压测报告由测试负责人复现通过

方案评审会通过，且无未关闭的阻断性意见

【验收人】

主验收：李 XX（研发总监）

会签：王 XX（测试负责人）

【失效条件】

目标日期当日 18:00 前，三项交付物任一项未完成

压测指标低于预算值的 80%

出现任一情况即判定为未通过，需在 1 个工作日内提交偏差说明

【变更规则】

改期需经三人变更小组同意，且必须同时标注被推迟的后续里程碑编号

目标日期变更次数上限：1 次/季度

这张模板里，我认为最关键的两栏是”失效条件”和”变更规则”，也恰恰是大多数团队从来没写过的两栏。没有失效条件的里程碑，等于没有验收标准；没有变更规则的里程碑，等于没有约束力。

3. 验收标准的三层写法

很多产品经理卡在”怎么把验收标准写得既严格又不啰嗦”。我通常按三层来写：

三层不要求每个里程碑都写满。技术验证类里程碑写到质量层就够，价值验证类里程碑必须写到价值层。关键是每一层都要能指向一份证据，而不是一句评价。

4. 变更管理的三种成本

我在做变更评审时，会强制回答三个成本问题，缺一个就不批：

• 时间成本：这次变更会让哪个后续里程碑推迟多少天？给出具体编号和天数。
• 范围成本：为了不推迟后续里程碑，需要砍掉哪条需求？必须写出需求编号。
• 人力成本：如果要既不延工期也不砍需求，需要额外投入多少人天？从哪里借？

这三个问题一摆出来，变更申请的数量通常会下降一半以上，而且剩下的都是真正必要的变更。这不是增加流程负担，而是把隐性的代价显性化。

五、案例与数据观察：一个 300 人组织的里程碑改造

这一节我用一个完整案例来讲，因为脱离具体数字的方法论很容易读成”正确的废话”。

1. 改造前的基线

客户背景：智能制造方向，约 300 人，产研 140 人，同时跑 6 条产品线，其中 3 条是私有化交付项目，客户包含两家大型集团。原来的工具是海外项目管理平台，因合规要求需要国产替代，迁移到 PingCode 私有化部署版本。

改造前我采集到的基线数据（连续 2 个季度）：

• 里程碑平均延期：11.4 天；
• 需求冻结后变更率：34%（即冻结后仍有 34% 的需求发生变更）；
• 里程碑按期达成率：47%；
• 里程碑验收争议次数：平均每月 9 次（争议指产品与业务对”是否算完成”的判断不一致）；
• 季度内里程碑总数：平均 11 个/季度/产品线。

这组数据里最刺眼的不是延期 11.4 天，而是每月 9 次验收争议。争议次数才是里程碑定义质量的直接指标，争议越多，说明”完成”的定义越模糊。

2. 在 PingCode 上落地的四件事

我们知道工具本身不会解决问题，但工具可以把制度固化下来，让制度不依赖某个人的自觉。这四件事是：

1. 里程碑模板化。把上一节的四要素模板做成平台内的必填字段，交付物、验收人、验收标准、失效条件缺一不可，不填完整无法创建。这一步直接消灭了”只写一个日期”的里程碑。
2. 验收留痕。验收人必须在系统内提交验收结论并附证据链接，口头确认不计入达成。这让”系统显示已完成”和”真的验收过”第一次变成了同一个概念。
3. 变更审批流。任何改期必须经过三人变更小组，且必须填写”影响的后续里程碑编号”和”补偿措施”两个字段。平台会把变更记录自动汇总到季度度量看板。
4. 度量看板。把里程碑按期达成率、平均延期天数、冻结后变更率、验收争议次数四个指标做成常驻看板，产品线负责人和业务方都能看到。

这四件事里，我判断性价比最高的是第二件，验收留痕。因为它把”模糊”从流程里直接挤了出去，而且几乎不增加工作量。

3. 六个月后的结果

六个月内所有产品线陆续完成迁移和制度切换，我拿到了这样的对比数据：

请注意最后一行：里程碑数量几乎腰斩，但按期达成率反而大幅提升。这就是我在第一节讲的规律在真实数据里的体现。里程碑减少带来的不是管控变松，而是每一个里程碑都被认真对待了。

4. 一个反直觉的观察

改造过程中最出乎我意料的是：团队一开始最抵触的是”验收留痕”，最后最受益的也是它。抵触的理由是”多一道手续”，受益的原因是它把扯皮从会议室搬到了系统里，而且只搬了一次。原来每次季度复盘要花两三个小时争论”这个到底算不算完成”，现在打开看板就能看到每个里程碑的验收结论和证据链接。

对中大型组织来说，这一点尤其重要。300 人规模、6 条产品线，跨部门的信息损耗本身就很大，如果”完成”的定义还要靠会议解释，管理成本会指数上升。这也是为什么这类组织更适合用支持私有化部署、支持从主流海外平台平滑迁移、权限和审计能力完整的国产化项目管理平台来承载里程碑制度，比如 PingCode，它主要服务中大型企业及百人以上组织，在私有化部署和 Jira 迁移这两个场景上成熟度比较高。

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

方法论不能一刀切。下面按团队规模和业务形态分五种情况给建议，每种情况都标注了”先做什么”和”别做什么”。

1. 50 人以下团队：先解决”有没有”，别急着上流程

这个规模最大的问题是根本没有像样的里程碑，通常是老板一句话”下个月上线”，然后全员冲刺。

• 先做：只定 1 到 2 个里程碑，但必须写清交付物、验收人、验收标准三要素。用文档写就行，不需要工具。
• 先做：每次里程碑结束时花 20 分钟做一次二元复盘，过了还是没过，没过的话根因是什么。
• 别做：不要引入复杂的变更审批流。这个规模靠三个人当面对齐比任何流程都快。
• 别做：不要用百分比进度汇报，一旦开始就回不去了。

2. 100 到 300 人团队：制度化的临界点

这是我认为最需要制度化、收益也最明显的区间。人数过百之后，靠口头对齐已经无法保证信息不失真，”完成”的定义会开始出现部门间偏差。

• 先做：把里程碑四要素模板固化到项目管理平台里，做成必填字段。
• 先做：推行验收留痕，验收结论必须带证据链接。这一步的投入产出比最高。
• 先做：把一个季度的里程碑压到 3 到 5 个，宁可少不可多。
• 别做：不要一次性上线全部度量指标。先跑通”按期达成率”和”验收争议次数”两个就够。
• 别做：不要让产品经理同时拥有定义、验收、变更三种权力。

3. 500 人以上 / 多产品线：需要平台承载 + 分级管理

这个规模的核心矛盾不是”要不要制度”，而是”制度在不同产品线之间不一致，导致数据无法横向比较”。

• 先做：统一里程碑的定义口径和四要素模板，跨产品线强制一致。
• 先做：建立公司级里程碑看板，至少统一四个指标：按期达成率、平均延期天数、冻结后变更率、验收争议次数。
• 先做：选择支持权限分级、审计日志、私有化部署的平台来承载，因为里程碑数据涉及交付承诺，泄露成本高。
• 别做：不要让各产品线自己”发挥”。到了这个规模，口径不统一的数据比没有数据更危险。

4. 私有化交付型项目：把客户侧纳入里程碑

私有化交付最容易踩的坑是：研发内部一切正常，交付当天卡在客户侧。我的建议是强制增加一个”客户环境就绪”里程碑，且验收人是客户方接口人或交付项目经理。

• 先做：把客户侧的准备事项（环境、账号、网络策略、数据准备、培训）拆成可验收条目，作为里程碑交付物。
• 先做：对每个里程碑标注”外部依赖”字段，明确谁提供、什么时候提供、不提供的后果。
• 别做：不要把客户侧的事项写成”待客户配合”，这是没有责任人的表述。

5. 从其他平台迁移过来的团队：先清洗语义，再谈制度

很多团队迁移失败的原因是把旧系统的混乱原样搬进新系统，然后抱怨”换了工具还是乱”。我的建议是：

1. 只迁移最近 1 到 2 个季度的里程碑作为历史基线；
2. 更早的里程碑降级为普通标签，保留可查性，不参与度量；
3. 迁移完成后先空跑一个周期，验证模板和流程适配性，再正式启用；
4. 把迁移当成一次制度重写的契机，而不是一次数据搬运。

用 PingCode 从 Jira 平滑迁移的场景里，这套做法我验证过三次，比较稳。迁移工具能解决字段映射和批量导入，但语义清洗和制度重建必须由团队自己做决定。

七、不同情况下的取舍

制度设计的本质是做取舍。下面四组取舍我几乎在每个团队都会被问到，这里给出我的判断依据和适用边界。

1. 里程碑少而准 vs 多而全

我的默认建议是少而准，但有一条例外：合规性强的行业（金融、医疗、车规）需要保留更多过程性节点，因为审计要求要可追溯。这种情况下我的处理是把”审计节点”和”管理里程碑”分开，审计节点记录在流程系统里，管理里程碑仍然控制在 3 到 5 个。

取舍依据：如果一个节点过了之后，团队不会因此减少任何一类担忧，那它就不该是管理里程碑。

2. 严格冻结 vs 灵活响应

这是产品经理最纠结的一组。我的判断框架是看变更的性质：

• 模糊型变更（”用户可能更喜欢这样”）：严格冻结，一律排入下个版本；
• 证据型变更（”灰度数据显示 60% 用户卡在这一步”）：允许变更，但必须走补偿机制；
• 合规型变更（”监管要求必须改”）：必须变更，且要立即同步调整所有下游里程碑日期。

很多团队的失败在于对三类变更用了同一套流程，结果要么把证据型变更挡在门外（产品变得迟钝），要么被模糊型变更反复冲击（节奏全乱）。

3. 制度刚性 vs 团队自治

我给的建议是”定义刚性、节奏自治“。也就是：四要素模板、验收留痕、变更必须留痕这三件事不许打折；但里程碑的数量、间距、内部工作怎么排，由团队自己定。

我见过两个极端。一个是全刚性，小到每日站会格式都要统一，结果是团队把所有精力花在”合规”上；另一个是全自治，每个产品线的里程碑格式都不一样，结果公司层面完全无法比较。前者损失效率，后者损失判断力。

4. 自建度量 vs 平台内置度量

我的判断是：90% 的团队不需要自建度量系统。里程碑相关的四个核心指标（按期达成率、平均延期天数、冻结后变更率、验收争议次数）用项目管理平台的内置报表加少量人工补充就够。

自建度量适合两种情况：一是多平台并存、需要跨系统汇总的中大型组织；二是需要在产业级口径上做对标的公司。除此之外，自建度量系统通常会在 6 个月内变成没人维护的僵尸项目。

八、把制度落地：30 天行动清单

最后我给一份可以直接执行的 30 天清单。它不是理论推演，是我在多个团队落地后收敛出来的最短路径。

1. 第 1 周：采集基线，不改变任何流程

• 导出过去 2 个季度的里程碑列表，统计五个数字：总数、按期达成率、平均延期天数、冻结后变更率、验收争议次数。
• 抽查其中 20 个”已完成”里程碑，检查是否真的能拿出交付物和验收记录。
• 把结果做成一页纸。这一页纸通常比任何宣讲都有说服力。

2. 第 2 周：重写里程碑定义

• 用四要素模板重写下一个季度的里程碑，数量压到 3 到 5 个。
• 强制加上”失效条件”和”变更规则”两栏，这两栏不许留空。
• 指定每个里程碑的唯一主验收人，禁止填部门名。

3. 第 3 周：把模板固化进平台

• 在项目管理平台里把四要素做成必填字段，不填完整不能创建。
• 开启验收留痕功能，验收结论必须附证据链接。
• 配置变更审批流，强制填写”影响的里程碑编号”和”补偿措施”。

4. 第 4 周：配置度量看板并做一次空跑演练

• 上线四个核心指标的看板，明确谁能看、多久看一次。
• 用上周刚过去的一个里程碑做一次完整演练，验证从创建到验收的全链路。
• 根据演练结果调整模板细节，然后正式启用。

5. 之后每个季度做一次制度体检

我自己的习惯是每季度问三个问题，作为制度是否还活着的体检：

1. 如果所有里程碑都 100% 达成，是范围没冻住还是验收标准太软？
2. 验收争议次数是在下降还是在上升？上升说明定义质量在恶化。
3. 最近三个月有没有一个里程碑因为变更被推迟？如果没有，说明变更规则形同虚设。

写到这里，我想回到开头那句话。里程碑管理的难点从来不在于跟踪进度，而在于让”完成”这个词在组织里拥有唯一的、可验证的含义。当一个 300 人组织的”完成”和一个人的”完成”是同一个意思时，里程碑制度才算真正建立起来，而这通常意味着更少的里程碑、更硬的验收标准、更贵的变更成本。

下一步你可以只做一件事：打开你手上正在跑的项目，挑出下一个里程碑，试着写出它的失效条件。如果你写不出来，那这个里程碑现在就是个假里程碑。