里程碑报告要回答三个问题：节点到哪了、和计划差多少、需要谁做什么决定。下面给出一份填写完整的示例，覆盖表头、里程碑清单、偏差说明、风险与决策请求，并逐项解释字段写法。示例中的项目、人名、日期与数据均为演示情景，不代表真实客户案例。
要点总览（TL;DR）
- 里程碑报告把节点状态、偏差原因和决策请求放在同一份材料里，收件人能在几分钟内看清每个节点到哪了、差多少、需要谁做什么决定。
- 完整示例包含报告基本信息、里程碑清单、偏差说明、风险与待决策事项、下期关注节点五部分，清单固定六列：节点名称、计划日期、实际/预计日期、状态、完成度、验收证据。
- 状态口径在表头统一定义并跨期沿用；完成度后面跟可核对的证据；偏差按计划、预计、差异天数、原因、影响五段写；决策请求写清决策人、选项、后果和截止时间。
- 套用到其他项目时按规模调整：小型项目合并偏差说明、精简验收证据；强合规或对外交付项目补充签字记录、交付物版本号和变更审批信息。
- 示例中的项目、人名、日期与数据均为演示情景，不能当作行业基准；里程碑变更建议保留原计划日期、新日期、原因和批准人。
这份里程碑报告示例要解决什么问题
这份示例面向需要定期向上级、客户或跨部门相关方汇报项目关键节点的项目负责人、项目经理和PMO。它演示一份里程碑报告从表头到决策请求的完整写法，读者可以对照自己的项目直接改写。判断一份里程碑报告是否合格，标准很直接：收件人能否在几分钟内看清每个节点的状态、偏差有多大、自己需要做什么。
示例聚焦关键节点，不展开细粒度任务排期。任务排期处理的是任务之间的依赖关系、人员分配和每日进度，属于执行层的工作安排；里程碑报告只抽取对项目方向有影响的节点，说明其状态与影响。组织级阶段评审则关注阶段准入准出、资源投入和重大决策机制，里程碑报告可以作为评审的输入材料之一，但两者承担的管理职责不同。示例中的报告周期、节点数量和字段深度，都按一个中等规模版本发布项目的常见情况设定。
完整示例：某版本发布项目的里程碑报告
以下为一份填写完成的里程碑报告示例，项目名称为“演示项目：客户门户 V3.2 版本发布”，所有日期、人名与数据均为虚构，仅用于展示写法。
报告基本信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 客户门户 V3.2 版本发布（演示项目） |
| 报告周期 | 2025年3月3日—2025年3月14日（双周报） |
| 编制人 | 项目经理 张示例 |
| 分发对象 | 产品负责人、研发负责人、测试负责人、客户成功经理 |
| 状态口径 | 未开始 / 进行中 / 已延期 / 已完成（全项目统一沿用） |
| 报告日期 | 2025年3月14日 |
里程碑清单
| 节点名称 | 计划日期 | 实际/预计日期 | 状态 | 完成度 | 验收证据 |
|---|---|---|---|---|---|
| 需求范围冻结 | 3月5日 | 3月5日 | 已完成 | 100% | 需求评审纪要（3月5日）、范围清单V1.0 |
| 接口联调完成 | 3月12日 | 预计3月18日 | 已延期 | 70% | 联调记录：12个接口中8个通过 |
| 系统测试准入 | 3月14日 | 预计3月20日 | 进行中 | 40% | 测试用例评审完成，环境待就绪 |
| 版本发布评审 | 3月21日 | 预计3月26日 | 未开始 | 0% | — |
偏差说明
接口联调完成：计划3月12日完成，当前预计3月18日，偏差6天。原因是第三方支付接口的沙箱环境在3月10日至12日不可用，联调窗口被压缩；12个接口中8个已通过，剩余4个集中在退款与对账场景。影响：系统测试准入顺延，版本发布评审预计同步后移5天。
系统测试准入：计划3月14日，当前预计3月20日，偏差6天。原因是联调延期导致测试环境无法按原计划部署完整版本。当前测试用例评审已完成，环境就绪后即可开始准入测试。
风险与待决策事项
| 事项 | 类型 | 影响 | 需要谁决策 | 可选方案 | 截止时间 |
|---|---|---|---|---|---|
| 退款场景联调依赖第三方排期 | 风险 | 若第三方3月17日前仍无法提供环境，联调再延3天 | — | — | 3月17日观察 |
| 是否缩减首发范围 | 决策 | 保住3月26日发布窗口，或维持全量范围接受延期 | 产品负责人 | 方案A：首发不含对账功能；方案B：整体顺延一周 | 3月18日 |
下期关注节点
3月17日至3月28日重点关注：接口联调收尾（3月18日）、系统测试准入（3月20日）、版本发布评审（3月26日）。若3月18日决策未定，发布评审日期需再次调整，届时在下一期报告中更新。
逐项解释：每个字段为什么这样填
示例中的字段不是装饰，每个都对应一个判断动作。下面按状态、完成度、偏差和决策请求四类拆解填写逻辑，并列出常见错误。
状态口径要统一
状态字段的价值在于跨期可比。示例在表头固定了“未开始 / 进行中 / 已延期 / 已完成”四个口径，并约定全项目沿用。判断规则可以这样定：实际日期已过计划日期且未完成，记为已延期；预计日期晚于计划日期但尚未到期，也建议提前标为已延期或在备注中说明，避免到期才发现。常见错误是同一项目里“延期”“滞后”“风险”混用，导致读者无法横向比较。
完成度必须挂验收证据
完成度写百分比容易变成主观估计，示例的做法是让每个百分比后面跟一条可核对的证据。接口联调写“12个接口中8个通过”，比写“70%”更有信息量；系统测试准入写“测试用例评审完成，环境待就绪”，读者能判断剩余工作是什么。常见错误是只写百分比不写依据，或者用“基本完成”“接近完成”这类无法核验的表述。
偏差描述写事实与影响
偏差说明回答两个问题：差多少天、为什么差、影响到谁。示例中接口联调写明了计划日期、预计日期、偏差天数、具体原因（沙箱环境不可用）和下游影响（测试准入与发布评审顺延）。常见错误是写成情绪化判断，例如“第三方配合度差”“进度压力很大”，这类表述无法帮助收件人判断严重程度，也容易引发争议。
决策请求写清对象、选项与截止时间
决策请求是里程碑报告区别于普通进度汇报的关键。示例中“是否缩减首发范围”一条，写明了决策人（产品负责人）、两个可选方案及其后果、截止时间（3月18日）。收件人读完就知道自己要在什么时间做什么选择。常见错误是只写“请领导指示”，没有选项和时间，决策被无限期搁置。
| 字段 | 推荐写法 | 常见错误 |
|---|---|---|
| 状态 | 使用表头统一定义的四类口径 | 延期、滞后、风险混用 |
| 完成度 | 百分比加可核对的证据 | 只写百分比或“基本完成” |
| 偏差说明 | 计划、预计、差异天数、原因、影响 | 情绪化判断，缺影响范围 |
| 决策请求 | 决策人、选项、后果、截止时间 | 只写“请指示” |
从这份示例能迁移出哪些写法
示例的价值在于结构可以复用。固定表头和固定字段让不同周期的报告可以直接对比，读者能看出某个节点是持续延期还是单次波动。里程碑报告与周报的分工是：周报覆盖任务级进展和人员安排，里程碑报告只抽取关键节点，篇幅更短、决策导向更强；与阶段评审材料的分工是：评审材料需要完整的阶段准入准出论证，里程碑报告提供节点状态和待决事项作为输入。
报告频率可以按节点密度调整。节点密集的发布冲刺期用双周报甚至周报，节点稀疏的早期阶段用月报即可。判断依据是：下一个节点是否在报告周期内到期，或者是否有决策需要在周期内做出。
在协作工具中，可以把里程碑作为工作项类型或属性，把状态、计划日期、实际日期、验收证据沉淀为固定字段，跨期汇总时直接按字段筛选，减少每次手工整理。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，对比计划与执行的偏差，追溯变更细节；借助项目列表可以查看项目状态与当前进展。对于采用阶段化管理的研发项目，ONES 也可围绕项目计划、阶段推进和任务协同支持节点管理。深圳农商银行曾依托 ONES 瀑布项目模板对关键里程碑和交付物进行规范化管理，该案例为单一客户实践，具体做法需结合自身项目情况判断。
可迁移的写法清单：
- 表头固定项目名、报告周期、编制人、分发对象、状态口径五项。
- 里程碑清单固定节点名称、计划日期、实际/预计日期、状态、完成度、验收证据六列。
- 偏差说明按“计划—预计—差异—原因—影响”五段写。
- 决策请求固定决策人、选项、后果、截止时间四项。
- 每期报告末尾列出下期关注节点及其日期。
示例的适用边界与调整方式
示例按中等规模版本发布项目设定，套用到其他项目时需要调整。小型项目可以精简字段：节点少于五个时，偏差说明可以合并为一段，决策请求可以并入风险清单；验收证据保留最关键的一条即可。强合规或对外交付项目则需要补充：节点验收的签字记录、交付物版本号、变更审批单号，以及对外承诺日期与内部计划日期的对应关系。
示例中的日期、偏差天数和完成度均为演示数据，不能当作行业基准或参考均值使用。不同项目的节点密度、依赖复杂度和外部协作方数量差异很大，偏差天数的合理范围需要结合自身历史数据判断。
里程碑变更本身也需要记录。计划日期调整时，建议在报告中保留原计划日期、新日期、变更原因和批准人，而不是直接覆盖。这样跨期对比时能看出变更发生在哪个节点、由谁批准。若项目设置了里程碑基线，变更后可通过基线对比追溯差异。变更是否需要正式审批，取决于项目的管理要求和合同约定，对外交付项目通常需要书面确认。
常见问题
里程碑报告和项目周报可以合并成一份吗？
可以合并，但要保留两层信息。周报覆盖任务级进展、人员安排和本周完成事项，里程碑报告只抽取关键节点的状态、偏差和决策请求。合并时建议把里程碑部分放在开头，用固定表格呈现节点清单，任务级进展放在后面作为支撑材料。这样上级和相关方先看到节点层面的判断，需要细节时再往下读。如果项目节点密集、决策频繁，分开出两份材料反而更清晰，避免关键信息被任务流水淹没。
节点预计会延期，但还没到计划日期，状态该怎么标？
建议提前标为已延期，或在状态旁加备注说明预计日期晚于计划日期。理由是里程碑报告的价值在于让相关方提前看到偏差，等到计划日期过了才标延期，留给决策和调整的时间就被压缩了。示例中接口联调在报告日尚未到计划完成时间，但因为预计日期已经后移，直接标为已延期并写明偏差天数。前提是团队对“预计日期”有可靠判断，避免凭感觉提前报警。
决策请求发出后没人回应，报告里怎么跟进？
在下一期报告中保留该事项，并更新状态：已决策的写结论和执行人，未决策的标注已等待时长和新的截止时间。示例中“是否缩减首发范围”约定3月18日决策，若届时未定，下一期报告应写明该事项已超期，并说明对发布评审日期的连带影响。把未决事项的等待时间显性化，比反复催促更能推动决策，也便于事后复盘决策链条卡在哪一环。
多个项目并行时，里程碑报告要每个项目单独出一份吗？
通常按项目各出一份，再汇总一份跨项目视图。单项目报告保留完整的节点清单、偏差说明和决策请求，供项目相关方使用；跨项目汇总只保留各项目的关键节点状态、重大偏差和需要上升决策的事项，供管理层横向比较。汇总时沿用同一套状态口径和字段定义，否则无法对比。项目数量多、节点稀疏时，汇总频率可以低于单项目报告频率。
里程碑计划日期变更需要走审批吗？
取决于项目的管理要求和合同约定。对外交付项目、有固定验收节点的项目，计划日期变更通常需要书面确认，报告中应保留原计划日期、新日期、变更原因和批准人。内部项目可以简化，由项目负责人确认后在报告中记录即可。无论是否审批，建议保留变更痕迹而不是直接覆盖原日期，这样跨期对比时能看出变更发生在哪个节点、由谁批准。若设置了里程碑基线，变更后可通过基线对比追溯差异。
