打开一份不是您写的项目计划，去找找里面的里程碑。您常常会发现类似“第 2 阶段完成”这样的东西——一个横跨日历上两周的条形，没有任何负责人，也没有书面定义说明“完成”到底意味着什么。
那不是里程碑。那是一项乔装打扮的任务，它永远不会向您发出任何警告。
里程碑是项目管理中成本最低的预警系统。不需要额外的工具，不需要额外的会议，也许只需要二十分钟的设置。但只有按特定的方式构建，它们才能发挥作用，而大多数计划并没有做到。下面就是行之有效的做法。
里程碑是一个时刻，而不是一段工作
《PMBOK 指南》把里程碑定义为项目、项目集或项目组合中的一个重要时点或事件。关键词是时点。里程碑的工期为零：它不消耗时间、不消耗预算，也不占用人员。
这个零不是技术细节。它就是整个机制所在。
任务可以完成 60%。里程碑不能。它要么在某个特定日期达成，要么没有达成，正是这种二元性让它可以作为控制点使用。一旦您给里程碑设定了开始日期和结束日期，就等于给了团队把它报告为“差不多了”的空间——而“差不多了”正是四周的延误一直隐形、直到发布前一周才暴露的原因。
四问测试
在把一个里程碑加入计划之前，先用以下问题检验它：
- 它是二元的吗？如果有人可以合理地回答“部分完成”，那您看到的就是一项任务。
- 下游会因此发生变化吗？真正的里程碑会解锁工作、释放资金或转移责任。如果第二天一切照旧，它就只是装饰。
- 交付团队以外的人会在意吗？里程碑既是排程工具，也是沟通工具。只有您的团队才能理解的检查点应该放在任务列表里，而不是放在里程碑那一栏。
- 您能用一句话写出它的验收标准吗？如果写不出来，就没有人能对它是否已达成取得一致。
最后一个问题的作用最大。“测试”不是里程碑。“测试完成，未关闭的严重缺陷为零”才是。后者在还有三个严重缺陷未关闭时，就不能被宣布为已达成，而这正是关键所在：精确的验收标准能治好“99% 完成综合征”——一个检查点被标记为完成，而背后还有两周的收尾工作在悄悄继续。
然后指定一位负责人。不是为该里程碑做前期工作的人——而是依据这些标准宣布它达成或未达成的那一个人。一个属于“整个团队”的检查点，就是一个没有人需要为之辩护的检查点。
多少个里程碑才合适？
有两种失败模式。一个九个月的项目集只有三个里程碑毫无用处——第一个真实信号要到第四个月才出现。一个十二周的项目设置四十个里程碑同样毫无用处，因为当一切都是检查点时，就没有什么是检查点了。
一条实用的规则：合理安排里程碑的间隔，使项目中任何一段时间都不会超过两到四周没有里程碑，并把总数控制在一张状态汇报幻灯片放得下的范围内。在大多数项目中，这个数字落在五到十二个之间。
一套几乎适用于任何领域的默认里程碑：
- 计划获批并设定基线
- 范围冻结
- 设计或规格签核
- 构建完成 / 功能冻结
- 移交给客户、顾客或 QA
- 正式上线
里程碑需要前置任务，而不只是日期
这是一个会悄悄让整个系统失效的结构性错误：把里程碑停放在某个日期上，却没有任何依赖关系指向它。
没有前置任务的里程碑是一个断言。它停在 11 月 14 日，只是因为有人输入了 11 月 14 日。周围的任务纷纷延误，菱形却纹丝不动，而您的计划还在不断公布一个三周前就已不再成立的日期。
有前置任务的里程碑是一个计算结果。把所有必须在宣布该检查点之前完成的任务都链接进来——以完成-开始关系连到菱形上——里程碑就会变成这些完成日期中最晚的那个。任何一个前置任务延误，里程碑都会在同一天、在图表上随之移动，不需要任何人去留意。
有两个后果值得在规划时考虑。第一，有许多入向链接的里程碑是一个汇聚点，而汇聚点会集中风险：六个前置任务就意味着六次独立的延误机会，全都落在同一个日期上。第二，里程碑和网络中的其他节点一样会继承时差。时差为零的里程碑位于关键路径上，这意味着它不是一个可以悄悄错过的检查点。
跟踪里程碑：里程碑趋势分析
一旦里程碑被正确地接入进度计划，您就能解锁项目管理中信息量最大、却最少被使用的图表。
里程碑趋势分析很简单。在每个汇报周期，记录每个里程碑当天的预测日期——并保留历史记录，而不是覆盖它。把汇报日期放在横轴上，把预测的里程碑日期放在纵轴上。
每周跟踪一个上线里程碑，可能会得到这样的结果：
| 评审日期 | 预测上线日期 |
|---|---|
| 第 1 周 | 11 月 14 日 |
| 第 2 周 | 11 月 14 日 |
| 第 3 周 | 11 月 19 日 |
| 第 4 周 | 11 月 26 日 |
| 第 5 周 | 12 月 3 日 |
平直的线表示预测是稳定的。上升的线表示里程碑正在离您远去，而斜率才是真正的信号。从第 3 周开始，这个项目每周损失七天，这意味着上线日期后退的速度恰好与日历前进的速度一样快。这不是一个能在后半程挽回的项目。这是一个计划与现实已经脱节的项目——而图表在日期被正式错过的三周前就已经发出了信号。
有一条纪律能让这一切奏效，而且它违反直觉：记录延误，而不是修改原始日期去迎合现实。每当有人悄悄把里程碑拖到它现在所在的位置，一个数据点就被销毁了，趋势也会被拉平成一个令人安心的谎言。
在 LoopGantt 中如何运作
在 LoopGantt 中，里程碑是一个工期为零的任务，每种视图都有意以不同的方式呈现它。
- 在甘特图上，它显示为菱形而不是条形，因此计划中的检查点一眼可辨，关键路径高亮也能立即显示其中哪些已经没有剩余时差。
- 在表格视图中，它的开始日期和结束日期相同，“天数”列为空。这让审核别人的计划变得很快：任何标为里程碑却显示了工期的项，都不是真正的里程碑。
- 在日历视图中，菱形只占据它所在的那一天，而不是跨越多个单元格，旁边是那些跨越单元格的任务。
- 在 WBS 树中，里程碑显示为菱形节点，与圆形的任务节点并列，让您能看出每个阶段是否真的以一个检查点收尾。
仪表盘是里程碑真正发挥价值的地方。它有一个专门的“里程碑”面板，列出每个里程碑的日期和状态，还有一个“进度检查”区域，会标记出网络分析认为有问题的里程碑——例如，里程碑有风险：“项目启动”——请在此里程碑之前增加缓冲时间，或缩小前置任务的范围。这些检查直接根据依赖关系图和时差计算得出，因此会即时显示，并且不消耗任何 AI 额度。
对于上文的趋势分析，基线会存储您的计划日期，让您可以把计划日期与当前的里程碑日期进行比较，而不必依赖记忆或旧截图。甘特图、依赖关系、里程碑和关键路径分析都包含在 Free 套餐中；基线和偏差跟踪属于 Pro 功能，Teams 套餐则按成员计费。点此查看当前价格。
值得避免的四个错误
- 给里程碑设定工期。这样它就可以被报告为部分完成，而这恰恰是检查点绝不能出现的情况。
- 不加链接。没有链接的里程碑不会延误，所以它也无法向您发出警告。它会一直守着原定日期，直到被错过的那一天。
- 不写验收标准。没有验收标准，“完成”就会在状态会议上由最自信的那个人说了算。
- 修改日期而不是记录延误。这感觉像是良好的维护习惯，却会毁掉唯一能向您展示趋势的数据集。
总结
一个有用的里程碑具备五个属性：零工期、二元结果、指定的负责人、书面的验收标准，以及真正指向它的前置任务。把这些做对，您的计划就会在问题发生前几周发出预警。做错了，您得到的就只是装饰用的菱形。
如果您当前的计划中已经有里程碑，这周就做一次审核。逐个打开它们，检查有哪些任务链接到它上面。那些上游什么都没有的里程碑，就是在对您撒谎的里程碑。