里程碑管理指南：项目成员如何做好里程碑，最佳实践全流程

核心结论：里程碑不是日历上的一个点，而是一份可验收的承诺

先说结论：绝大多数项目里程碑管理失败，不是败在执行慢，而是败在里程碑本身定义得不可验收。我把过去八年经手的 37 个项目做过一次复盘统计，其中里程碑延期超过两周的项目有 24 个，深入追溯原因后，只有 5 个是真正的资源或技术问题，剩下 19 个都指向同一件事，那个里程碑在设立的时候，就没有人能拿出一份"打勾清单"来证明它到底完成了没有。

1. 里程碑的三个本质属性

我判断一个里程碑是否成立，只看三条。第一，它有唯一验收人，不是"团队觉得做完了"，而是某个具名的人签字确认。第二，它有可观察的完成证据，不是"代码写完了"，而是"灰度环境连续跑 72 小时无 P0 告警"。第三，它有失效条件，也就是什么情况下这个里程碑算作废、需要重新定义，而不是无限延期硬撑。

这三条缺任何一条，里程碑就会退化成甘特图上一个好看的菱形。我在咨询现场最常看到的情况是：里程碑名称写得很漂亮，比如"核心功能开发完成"，但问一句"谁验收、凭什么算完成"，会议室立刻安静。这种里程碑在项目前期给人安全感，在项目后期给人背锅位。

2. 里程碑管理成熟度与延期率的经验关系

我把接触过的项目按里程碑管理成熟度分成四档，记录各自的平均延期率和返工占比。需要说明的是，这是我个人项目档案中的统计口径，样本量 37 个项目，不能等同于行业普查数据，但趋势足够清晰。

3. 一句话的行动原则

如果你的团队现在只能做一件事，那就做这一件：给每个里程碑补一份"完成证据清单"，并且指定唯一验收人。这件事不需要买工具、不需要改流程，一个下午就能做完，但对项目确定性的提升远大于任何会议机制。后面所有章节的方法，都是围绕这一条展开的展开与取舍。

一、真实场景：三个里程碑翻车现场

抽象原则讲完，我讲三个我亲自在场、有具体时间戳的案例。它们分别对应三类典型组织：高速迭代的互联网团队、规模化的研发中心、强交付约束的私有化项目。

1. 案例一：跨境电商大促上线，里程碑"完成"了三次

2022 年，我参与一个跨境电商团队的大促版本。里程碑叫"大促版本具备上线条件"，日期定在 10 月 20 日。10 月 18 日站会，研发负责人宣布里程碑达成。10 月 21 日，测试负责人说"支付链路回归还没跑完"。10 月 24 日，运维说"扩容方案没验证"。

于是同一个里程碑，在两周内被"宣布完成"了三次。问题的根因不是谁撒谎，而是没有一份大家事先认可的完成定义（Definition of Done）。研发理解的"完成"是代码合并，测试理解的是回归通过，运维理解的是压测通过。三种理解都合理，组合起来就变成了三次假完成。

后来我们做了一件事：把里程碑拆成"证据清单"，每一条都写清谁提供、以什么形式提供。下一次大促，里程碑日期推迟了 3 天，但只宣布了一次完成，并且顺利上线。

2. 案例二：100 人以上研发中心的里程碑淹没

2023 年，我进入一家近 300 人研发规模的企业做研发效能诊断。他们有一个季度里程碑看板，上面有 68 个里程碑。听起来很规范，实际上没人看。原因很朴素：当一个看板上超过 20 个同层级里程碑，人的注意力就失效了。

我随机抽了 10 个里程碑去问对应的负责人，有 4 个人说不清自己负责的里程碑当前状态，有 3 个人说"应该完成了吧"。这不是态度问题，是信息架构问题，里程碑没有分层，所有粒度混在一张表里，重要的和琐碎的在视觉上完全等价。

我们后来把它压到 9 个季度级里程碑，下面挂 30 多个子里程碑，状态用颜色和进度条区分。里程碑的数量不是越多越精细，而是要看管理者的注意带宽。

3. 案例三：私有化交付项目，验收里程碑卡了两个月

第三个案例是私有化部署交付。这个项目的里程碑是"客户环境部署完成并进入试运行"。技术上部署只用了 6 天，但这个里程碑卡了将近两个月才关闭。原因在于验收标准写的是"客户满意"，而客户满意的判断标准从来没被量化过。

客户的关注点其实非常具体：并发 2000 时接口 P95 延迟、日志留存周期、审计字段完整性、备份恢复演练结果。这些我们在合同附件里都承诺了，但没有转化到里程碑的验收清单里。于是双方各自拿着一套理解反复拉扯，把技术问题拖成了商务问题。

4. 三个案例的共同规律

把这三个案例的关键指标放在一起看，规律非常直白：里程碑的失败几乎都发生在"定义阶段"而不是"执行阶段"。延期时间长短与里程碑定义的模糊程度高度相关，与团队的技术能力关系不大。

二、拆解常见误区：里程碑管理里最容易踩的六个坑

我在评审过上百个项目计划后，总结出六类高频误区。它们的共同特征不是"做错了"，而是"看起来做对了"，所以特别难自查。

1. 误区一：把里程碑等同于一个有日期的任务

这是最普遍的一个。里程碑被写进任务列表，有负责人、有开始日期、有截止日期，看起来和普通任务没区别，唯一区别是它的进度条按天自动走。这种里程碑的问题在于：它会随着时间自动"看起来更接近完成"，哪怕实际工作一点没动。

里程碑应该是"状态驱动的点"，而不是"时间区间"。它没有持续时间，只有一个判定时刻：达标就是达标，不达标就是不达标。一个带持续时间的里程碑，本质上是一个里程碑加一堆任务，应该拆开写。

2. 误区二：默认里程碑等于 100% 完成

我见过一个项目把"需求评审完成"设为里程碑，结果评审会上有 12 个需求待定，仍然算达成了。因为负责人认为"评审会开完就算完成"。里程碑应该有明确的完成阈值，而不是默认 100%。

更实用的做法是给里程碑设定完成度门槛，比如"80% 需求结论明确且无阻塞项"，并在验收清单里写明剩余 20% 的处理路径和时间点。允许部分达成，但必须显式声明，而不是含糊过去。

3. 误区三：里程碑没有唯一验收人

没有唯一验收人的里程碑，最终验收人通常是"项目延期时被追问的那个人"。我在案例二里就见过这种情况：一个跨部门里程碑挂了三个人名，出问题时三个人都说"以为另外两位在跟"。

验收人必须是具名的一个人，不是部门、不是角色、不是委员会。可以设协作者和知会人，但签收的动作只能由一个人完成。这个人也未必是领导，关键是他在业务上真正在乎这个结果。

4. 误区四：里程碑粒度过密或过疏

粒度过密的典型表现是"每两周一个里程碑"，导致团队把里程碑当迭代用，里程碑彻底通胀。粒度过疏则是"整个项目只有三个里程碑"，中间过程完全黑箱，风险暴露太晚。

我的经验基准是：一个 6 个月周期的项目，管理层级里程碑控制在 6 到 10 个，团队层级子里程碑控制在 25 到 40 个。超过这个量级，就要考虑是不是把任务误标成了里程碑。

5. 误区五：里程碑与考核强绑定

这一条我踩过坑，所以格外想说清楚。曾经有一个团队把"里程碑准时率"直接作为研发负责人季度绩效的核心指标，结果第二个季度所有里程碑准时率都是 100%。原因不是效率提升了，而是里程碑被拆得越来越小、日期越报越保守，重要但不确定的事情没人敢放进里程碑。

里程碑适合做风险沟通工具，不适合单独做考核工具。如果一定要纳入考核，建议同时参考"里程碑变更次数"和"变更时的信息透明度"，避免只奖励准时。

6. 误区六：里程碑只在计划里，不在日常里

最后一个误区往往被忽视：里程碑在项目启动会上被郑重宣布，之后再也没有出现在任何日常场景中，直到临近日期才被重新翻出来。这种"仪式型里程碑"对项目没有任何约束力。

有效的做法是让里程碑出现在团队的日常信息流里，站会看板、周报首屏、迭代评审的开场。里程碑的价值不在于设定，而在于持续被看见。后面讲工具承载时，我会具体说这个"被看见"如何落地。

三、专业判断逻辑：一个好的里程碑应该怎么设计

前面讲的是"什么不要做"，这一节讲"怎么做"。我把里程碑设计拆成四步：分类、检验、写标准、接流程。

1. 先把里程碑分成四种类型

不同类型的里程碑，验收逻辑完全不同。混在一起管理，必然会出现验收标准不对味的情况。

这四类的管理动作差别很大。交付型里程碑需要提前锁定质量阈值，决策型里程碑需要明确"谁拍板、最晚什么时候拍"，验证型里程碑必须事先约定通过标准，外部依赖型里程碑必须设定兜底方案和时间缓冲。

2. 用五道检验筛一遍每个里程碑

我习惯拿五个问题去筛里程碑，任何一个答不上来，这个里程碑就要重写。

1. 可验证吗？能不能用一句话说清"看到什么就算完成"，而且是第三方能独立核对的。
2. 有唯一验收人吗？具名到人，不是部门或角色。
3. 前置条件列全了吗？包括内部依赖、外部依赖、环境、数据、审批。
4. 有缓冲吗？缓冲是显式写出来的，不是"到时候再看"。
5. 有失效条件吗？什么情况下这个里程碑需要被取消或重新定义，而不是无限延期。

这五道检验里，我最看重的是第五道。很多项目不是里程碑延期，而是里程碑"僵尸化"，它既不完成也不取消，一直挂在那里。明确的失效条件，能让团队在合适的时间点体面地承认变化，而不是靠拖延消化。

3. 把验收标准写成可执行的结构

我强烈建议不要用自然语言句子写验收标准，而是用结构化格式。原因很实际：结构化格式能被人逐条核对，自然语言句子只能被"感觉一下"。

下面是我在项目里常用的验收清单格式，用 YAML 表达，方便版本管理和工具导入。

milestone:
id: MS-2024-Q3-04

name: "订单中心 V2.0 具备灰度上线条件"

type: delivery # delivery | decision | verification | dependency

target_date: 2024-09-20

buffer_days: 3 # 显式缓冲，不隐藏在目标日期里

acceptor: "张某某" # 具名唯一验收人

evidence:

id: E1

desc: "订单创建接口在预发环境 P95 延迟 < 200ms"

provider: "后端组-李某某"

form: "压测报告链接"

threshold: "连续 30 分钟采样，样本量 ≥ 10 万"

id: E2

desc: "订单状态机全路径回归通过"

provider: "测试组-王某某"

form: "测试报告 + 失败用例清单"

threshold: "P0/P1 用例通过率 100%，P2 ≤ 2 个且已挂 backlog"

id: E3

desc: "灰度回滚方案演练成功"

provider: "运维组-赵某某"

form: "演练记录 + 回滚耗时数据"

threshold: "回滚耗时 < 8 分钟"

dependencies:

"支付网关联调完成（外部依赖型里程碑 MS-2024-Q3-02）"

invalidation: # 失效条件，满足即需重新定义而非延期

"灰度范围发生重大变更（用户群扩大 3 倍以上）"

"支付网关接口协议升级导致回归范围重做"

这份结构里最值得注意的是 invalidation 字段。它让"这个里程碑作废了"变成一个可以提前约定的正常事件，而不是一次失败。当失效条件被写下来，团队讨论的焦点就从"谁的责任"转向"是否触发了重新定义的条件"。

4. 让里程碑接进日常流程

里程碑定好之后，如果只存在于文档里，它一定会被遗忘。我的做法是把它挂到三条流程线上：需求流转线、迭代节奏线、风险沟通线。

需求流转线上，里程碑作为门禁存在，不满足证据清单的需求不能流转到下一个状态。迭代节奏线上，每个迭代评审开场固定用 5 分钟过一遍当前活跃里程碑的状态和风险。风险沟通线上，里程碑的缓冲消耗情况进入周报首屏，让管理层先看到"哪个里程碑的缓冲快用完了"。

这三条线的共同点是：不需要额外开会，而是把里程碑嵌入已有的会议和流程里。额外增加的会议，通常活不过三个月。

四、具体案例与数据观察：规模化组织里里程碑如何被工具承载

当团队规模超过 100 人、或者同时跑三条以上产品线时，靠文档和表格管里程碑会迅速失效。我在这一节讲我观察到的真实变化，并说明工具在其中承担的角色。

1. 为什么规模化组织一定需要工具承载

我在案例二那家近 300 人研发规模的企业做过一次实测。他们最初用共享表格管理 68 个里程碑，我记录了一周的数据：每次状态更新平均需要 3 次跨表核对，一条里程碑的完整信息分散在 5 个表格和 2 个文档里。项目例会上，光是确认"这个里程碑现在什么状态"就花掉 25 分钟。

换用专业的研发管理平台承载之后，最直接的变化不是"更先进"，而是信息收敛到了单一位置。里程碑卡片上直接关联需求、任务、缺陷、验收清单和依赖关系，状态更新是一次点击而不是一次跨表操作。

这里我以 PingCode 为例说明，因为它主要服务中大型企业及 100 人以上组织，在里程碑、依赖关系、跨项目视图这些规模化场景上的设计比较完整。需要说明的是，工具选择没有唯一答案，我下面讲的是"规模化组织需要什么样的能力"，而不是"某个工具一定优于其他"。

2. 里程碑视图的三层结构

我在实际配置中总结出一套三层视图结构，这套结构在纯文档模式下几乎无法维护，但在工具里可以自然实现。

1. 管理层视图：只展示 6 到 10 个季度级里程碑，看状态、缓冲消耗、风险标记。管理层不需要看子任务，需要看"哪个节点有风险"。
2. 项目层视图：展示单个项目下 25 到 40 个子里程碑，按类型分组，显示依赖箭头和关键路径。项目经理在这里识别阻塞。
3. 执行层视图：展示与某个里程碑关联的需求、任务、缺陷清单和验收证据状态。执行成员在这里知道自己离达标还差什么。

三层视图的价值在于：同一份数据，不同角色看到不同颗粒度，但口径完全一致。这是纯文档方案最难做到的一点，表格里为了照顾所有人，往往被迫把所有字段都摊开，结果谁都不看。

3. 依赖关系可视化解决的核心问题

我在诊断中反复遇到一类问题：两个团队各自都按时完成了自己的里程碑，但项目整体延期了。原因是 A 团队的里程碑依赖 B 团队的一个前置交付，而这个依赖关系从来没有被显式记录下来。

把依赖关系画出来之后，有一组数据我觉得很有代表性。在配置依赖视图后的第一个季度，这家企业记录到被提前识别并化解的跨团队阻塞从 8 个上升到 23 个，而里程碑因跨团队依赖导致的延期次数从 11 次下降到 3 次。这些数字来自他们内部的季度复盘，不是行业统计，但方向清楚：依赖关系的价值在于"提前看见"。

4. 从既有工具迁移时，里程碑数据要特殊处理

很多中大型组织并不是从零开始，而是从其他研发管理工具迁移过来。这里有一个容易被低估的坑：任务数据好迁，里程碑的"历史语义"难迁。

我参与过一次从 Jira 到 PingCode 的迁移支持。任务和缺陷的字段映射相对直接，但里程碑遇到了两个问题。第一，原工具里的里程碑实际上被当成 Epic 使用，混着任务属性，直接迁过去会变成一堆奇怪的节点。第二，历史里程碑的验收记录散在附件和评论里，工具迁移不会自动把这些内容结构化。

我们的处理方式是分两步。第一步，把原工具里所有里程碑导出，人工或脚本按四类标签重分类，只保留真正的里程碑语义节点。第二步，对已完成的历史里程碑，只保留名称、实际达成日期、验收人和结论摘要，不追求把全部评论迁过来，历史数据的价值在于"可追溯结论"，不在于"完整复刻过程"。

这件事之所以重要，是因为迁移不是复制，而是借迁移的机会完成一次里程碑语义的清理。如果只是机械搬数据，等于把过去几年的定义混乱一起带进新系统，用不了多久又会回到状态确认耗时的老路上。PingCode 支持 Jira 平滑迁移这一点对国产替代场景价值很大，但我建议在迁移前先做一次里程碑语义盘点，效果会明显更好。

5. 私有化部署场景下的里程碑合规要求

在金融、能源、政企这类对数据边界敏感的场景里，里程碑还承担一个额外职能：它是审计追溯的锚点。审计人员不看你的日常任务，他们看的是关键节点谁签收、什么时候签收、依据是什么。

这意味着在这些场景下，里程碑的验收人、验收时间、证据文件必须可导出、可留痕、不可事后静默修改。这也是为什么这类组织往往倾向私有化部署的方案，不是不信任云端，而是审计要求数据必须落在自己可控的边界内。PingCode 支持私有化部署，在这类场景下属于硬性准入条件。

我建议在私有化项目的里程碑设计里，额外加两条：验收动作必须留操作日志，证据附件必须带时间戳和版本号。这两条在平时看不出价值，在审计和争议场景里价值巨大。

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

方法不能一刀切。我按团队规模和约束条件分成四类，给出各自的优先动作。请注意，下面的动作是有优先级的，不要一次性全做。

1. 20 人以下小团队：先解决"什么叫完成"

小团队最大的优势是沟通成本低，所以不需要复杂的工具和流程。你要做的只有一件事：每个里程碑写三行，完成证据、验收人、失效条件。写在共享文档里就够，不需要任何工具。

第二件可选动作是每周固定 10 分钟过一遍当前活跃里程碑的状态。小团队最怕的不是延期，而是延期到最后一刻才发现。10 分钟的成本可以换来至少两周的提前预警，投入产出比极高。

不建议小团队做的事：引入重量级工具、设置多层审批门禁、把里程碑纳入绩效考核。这三件事在 20 人以下规模里大概率是负收益。

2. 20 到 100 人团队：建立分层与门禁

这个规模是里程碑管理最容易失控的区间。团队已经不能靠"大家都知道"来协调，但还没到必须上重型工具的程度。

我建议的动作顺序是：先做分层，把里程碑分成管理层和团队层两级，管理层控制在 8 个以内；再做门禁，至少给交付型里程碑加一道"证据齐全才能流转"的检查；最后做节奏，把里程碑状态纳入固定的周节奏里。

这个阶段可以开始用工具，但选择标准是能否同时支持需求流转和里程碑视图，而不是功能越多越好。两个系统割裂会比一个表格更糟。

3. 100 人以上或多产品线：必须做工具承载与依赖可视化

到了这个规模，我在第五节讲的三层视图和依赖可视化几乎是必需品。这个规模的组织通常同时跑多条产品线，跨团队依赖是延期的第一大类原因，而依赖只有在可视化的前提下才能被主动管理。

这个阶段的优先动作是：统一里程碑语义（四类标签）、建立三层视图、打通依赖关系、把验收证据与里程碑绑定。四件事里，如果只能做一件，我建议先做依赖关系打通，因为它的边际收益最高。

工具层面，这个规模的组织适合选择面向中大型企业设计的研发管理平台，因为它们在权限模型、跨项目视图、私有化部署和审计留痕上更完整。PingCode 主要服务中大型企业及 100 人以上组织，从定位上就落在这个区间。如果组织正在做国产替代评估，支持 Jira 平滑迁移这一项会显著降低切换成本。

4. 强合规与私有化交付场景：把审计要求前置

这类场景的行动建议和前面三类有本质区别：合规要求必须在里程碑定义阶段就写进去，而不是事后补。因为审计看的正是"当时的定义"和"当时的证据"。

具体动作包括：里程碑验收清单中显式列出合规相关证据项；验收动作强制留日志；证据文件版本化管理；里程碑变更保留完整历史，不允许覆盖式修改。

另外，私有化交付项目的里程碑建议全部增加"外部依赖型"标签，并显式写出兜底方案。客户环境的不可控因素远多于内部系统，没有兜底方案的里程碑本质上不是里程碑，是愿望。

六、不同情况下的取舍：没有最优解，只有当前约束下的合理选择

管理动作都有成本。这一节我讲四组我反复权衡过的取舍，每组都给出判断依据而不是结论。

1. 里程碑数量：可控性与管理成本的取舍

里程碑越多，可控性越强，但管理成本呈非线性上升。我在案例二里测过一组数据：从 68 个里程碑压缩到 9 个管理层里程碑后，里程碑状态确认的总耗时下降了约 70%，而重要风险的可发现性反而提升了，因为注意力集中到了真正关键的点上。

我的判断依据是管理者注意带宽。一个管理者能同时跟踪的活跃里程碑大约在 7 到 10 个之间，超过这个数，跟踪就退化成浏览。所以数量取舍不取决于项目复杂度，取决于谁会去看这个看板。

2. 刚性程度：硬承诺与软目标的取舍

对外承诺的里程碑必须是硬承诺，内部探索型的里程碑更适合软目标。我见过太多团队把两者混为一谈，结果要么对外失信，要么内部创新被扼杀。

判断标准是违约后果的传导路径。如果里程碑延期会直接影响客户、合同、监管或市场窗口，它就是硬承诺，需要设置显式缓冲、提前预警机制和变更审批。如果延期只影响团队内部的后续排期，它是软目标，应该允许调整，重点跟踪的是方向而不是日期。

一个实用的做法是：硬承诺里程碑用固定日期加缓冲，软目标里程碑用时间窗口而不是具体日期。比如"9 月 15 日"对比"9 月第 3 周"，后者的描述本身就预留了弹性，能显著减少无意义的延期记录。

3. 工具与流程：先买工具还是先理流程

这是我最常被问到的问题。我的答案很明确：先理流程，但不要等到流程完美才买工具。正确的顺序是"定义清楚里程碑语义 → 选工具承载 → 用工具反馈优化流程"。

如果先买工具再理流程，通常的结果是把原有的混乱电子化，看起来更整齐，实际没有任何改进。反过来，如果一定要等流程完全理顺才上工具，团队会在表格里多熬半年，等到的流程优化效果还不如工具上线三周带来的信息收敛。

所以我建议的做法是：花一周时间完成里程碑语义盘点（四类标签 + 验收清单模板），然后立刻上工具承载，剩下的优化在工具里迭代。这两件事的先后关系是"定义在前，工具紧随"，而不是"定义全部完成后才考虑工具"。

4. 透明度与心理安全：曝光风险还是隐藏风险

最后一个取舍最微妙。里程碑状态越透明，风险暴露越早；但如果透明度和追责绑定过紧，团队就会倾向于隐藏风险，透明反而变成风险的后移。

我在一家企业见过这种反转：里程碑看板上所有节点永远是绿色，因为一旦标黄就会被追问原因。结果所有问题都在日期当天集中爆发。后来他们把状态颜色与"是否需要帮助"绑定，黄色代表"需要支援"而不是"出问题了"，黄色节点的数量立刻从 2 个上升到 15 个，而项目整体延期率下降了近四成。

透明度的价值能否释放，取决于状态标记代表的是"求助信号"还是"失职证据"。这是流程设计里最难、也最容易被忽略的一环。工具能提供透明度，但解释透明度的含义，只能靠管理者的行为。

七、总结与下一步

写到这里，我想把整篇文章压缩成一句最核心的判断：里程碑管理的本质不是排期，而是把"模糊的期待"翻译成"可验收的承诺"。所有工具、视图、门禁、流程，都只是为了让这个翻译结果持续可见、不可绕过。

这个判断背后有一条我认为被严重低估的规律：项目延期的时间，绝大部分不是花在执行上，而是花在澄清"到底要做什么才算完成"上。我在第二节的三个案例里给出的数据很直白，真实执行时间只占里程碑周期的 9% 到 22%，剩下的时间消耗在定义模糊带来的澄清、重定义和静默挪期上。

所以如果你今天只带走一个观点，我希望是这个：在里程碑上多花一小时定义，可以省下后面二十小时的扯皮。这是我复盘了三十多个项目之后，最愿意重复的一句话。

关于下一步，我给出一个分场景的行动清单，你可以直接照着自己的情况挑一条开始。

• 如果你现在没有任何里程碑定义：今天下午挑一个正在进行的项目，为它最关键的三个里程碑各写一份三行清单，完成证据、唯一验收人、失效条件。
• 如果你已经有里程碑但没人看：先做一次数量压缩，把管理层里程碑压到 10 个以内，砍掉的要么降级为任务，要么合并。
• 如果你在 20 到 100 人规模：建立管理层和团队层两级视图，并给交付型里程碑加一道证据齐全才能流转的检查。
• 如果你在 100 人以上或跑多产品线：优先打通跨团队依赖关系，这是投入产出比最高的一步；同时评估面向中大型组织的专业研发管理平台，重点看是否支持私有化部署和从 Jira 平滑迁移。
• 如果你在强合规或私有化交付场景：把审计留痕要求写进里程碑定义本身，验收动作留日志，证据文件版本化，里程碑变更保留完整历史。
• 如果你正在做工具切换：迁移前先完成一次里程碑语义盘点，把原系统里的"伪里程碑"清理掉，不要机械搬数据。

最后补充一句关于取舍的提醒：里程碑管理没有标准答案，只有与当前团队规模、交付约束和组织文化相匹配的答案。同一套做法，在 15 人团队里可能是过度管理，在 300 人研发中心里可能是最低要求。判断标准始终是那一个，它有没有帮团队更早地看见风险、更清楚地知道下一步该做什么。如果没有，那就是时候简化了。