指南 › 指南

里程碑计划模板

里程碑计划，是发起人真正会读的那个版本的项目。十五个有日期的节点，胜过三百个任务，前提是每个节点都有意义，旁边写着一个人的名字。

什么算里程碑

里程碑是一个没有持续时间的时间点，标志着某件实实在在的事已经达成：一项决策做出、一个交付物被验收、一个系统上线。如果您说不出怎样证明它已经发生，那它只是披着里程碑外衣的任务。

长期项目大致每两到四周设一个里程碑。太少，您会失去早期预警；太多，计划又变回了任务清单。

• 好的例子：合同签订、设计获批、上线完成。
• 弱的例子：开始开发、测试进行中、工作推进中。
• 每个里程碑都是在结束某件事，而不是描述一段活动。
• 尽量把里程碑与付款、审批或阶段关口挂钩。

模板的列

把这张表复制到电子表格里，每个里程碑占一行。两个日期列是核心：基线日期未经批准不得改变，预测日期则随事实变化而随时更新。

• 编号和里程碑名称。
• 完成证据：能看到、能签字或能演示的是什么。
• 负责人：一个明确的人。
• 基线日期（商定后保持不变）和预测日期（每周更新）。
• 两者之间以工作日计的偏差，附 RAG 状态和一句话原因。
• 依赖于：必须先完成的里程碑或任务。

定下可信的日期

从依赖项往回推，而不是从愿望往前推。按工作日计算，扣除公共假期和已知的休假，估算不确定的地方加上应急余量，不要指望运气。团队自己都不相信的日期，是不会按时达成的。

• 先请负责人给出日期，再问什么会让它延误。
• 把每个日期对照关键路径检查。
• 不要把三个里程碑堆在同一天。
• 在外部截止日期之前留出余地。

汇报延误

每周把基线、预测和偏差并排展示。一个里程碑移动一次，是一条信息；移动四次，就是一种规律，发起人应当从您这里听到，而不是自己发现。

预测日期可以随时调整，基线日期只能通过变更控制来改。否则计划会悄悄改写自己的历史，什么都不会显得延误。

• 预测超出容差时标为黄色。
• 没有决策就会错过日期时标为红色。
• 在 RAID 日志中记录每次延误的原因。
• 展示趋势：相对基线是在收窄还是在扩大？

放在哪里

里程碑计划保持一页，叠在详细计划之上，并确保它由详细计划生成，这样两者不会互相矛盾。在 Senshin 中，里程碑与其下的任务位于同一份计划和甘特视图里，汇总与明细共用同一套日期。

• 每次指导委员会会议都复查这份清单。
• 里程碑达成后移出关注，但保持“已完成”可见。
• 如果某项决策总被遗忘，就为它加一个里程碑。

它在 Senshin 中的位置

常见问题

更多指南

最后更新: 2026-10-22