当里程碑只是幻灯片上的一个日期
设想 2021 年春天的一项中型设施升级工程。团队分散在各自的居家办公室和一个只配了一半人手的工地之间，一套交期很长的电气组件卡在某个拥堵的港口，发起人想要确认项目仍在正轨上。项目经理——就叫她 Dana 吧——拿出了一份排程，上面有六个信心满满的里程碑，每一个都是甘特图上工整的菱形：设计完成、采购完成、工地进场、管线敷设完成、调试、移交。发起人放下心来。大家各自继续忙活。四个月后，项目晚了十一周，却没人说得清究竟是从哪里开始出问题的。
问题不在排程本身。问题在于 Dana 的里程碑只是装饰。它们标注了日历，却什么都不检验。这是里程碑规划中最常见的失败，而且就明摆在眼前，因为那张图看上去很负责任。
为什么这些里程碑失效了
逐一回看，规律就清楚了。「设计完成」没有约定的定义，于是在菱形被判定通过、打成绿色之后，设计仍被反复修改了好几周。「采购完成」完全依赖一家从没人确认过能否交货的供应商，可这个里程碑却赫然列在计划里，仿佛它在团队的掌控之中。「调试」把三周性质各异的工作压缩成一个点，于是它一旦滑期，根本没有更早的预警。每个里程碑都是一个标签，而非检查点。它们既不迫使任何决策，也无法证明某件真实的事情已经完成。
有分量的里程碑长什么样
有用的里程碑是一个可核验的节点，在那里项目可被检视、决策可被作出。它不是工作量，本身也没有时长；它是某件重要之事得到确认的完成，并以一种任何人都能判断它是否真正发生的方式被界定。好的里程碑有几个共同特征。
它有退出标准。 「设计完成」应当意味着一组具体、列明的交付物已获签署，而不是设计团队觉得大体差不多了。
它标志一次真实的交接。 好的里程碑落在控制权在各方之间移交之处，或一个阶段真正使下一阶段成为可能之处，因此漏掉一个会带来看得见的后果。
它是二元的。 要么达成，要么没达成。一个「完成了 80%」的里程碑不是里程碑；那是一项披着菱形外衣的活动。
它有归属。 由一位具名的人负责宣布它已达成，而此人不能靠悄悄把日期往后挪来让报告保持绿色。
换作现在，Dana 会怎么做
重新规划同一个项目时，Dana 会把采购里程碑挂钩到供应商确认的交货日期，而不是一个一厢情愿的内部目标，并加上一个更早的检查点——「长交期物料已下单并获回执」——好让滑期提前数月暴露。她会把调试拆成各有验收闸口的若干阶段。对每个里程碑，她都会写下一行所有人事先认可的退出标准。结果是里程碑更少、更重，团队和发起人都能真正信赖，因为每一个都是让现实与计划当面对照的时刻，而非一个被悄悄重画的日期。
这种纪律在条件动荡时最为关键，就像那一年。当交期难以预料、人员各处分散，排程上的那些菱形往往是发起人对进度唯一的共同认知。倘若这些菱形什么都不检验，项目可能一连数月地漂移，而每一份状态报告却始终是绿色。
如果你想要经得起推敲的里程碑，以及发起人可以依靠的排程，XNM 的项目群与项目交付咨询可以帮你把它们建立起来。