里程碑报告用于在关键节点上同步进度、交付物和需要拍板的事项。本文提供一份可直接复制到文档或表格工具中的空白模板，覆盖基本信息、计划与实际节点、状态、验收标准与交付物、偏差与风险、决策事项六组字段，并逐项说明填写口径、必填取舍和一份完整填写示例，适用于项目周报、阶段评审和向管理层汇报的场景。
要点总览（TL;DR）
- 模板由表头信息区、里程碑清单表和单里程碑详情区三部分组成，覆盖基本信息、计划与实际节点、状态、验收标准与交付物、偏差与风险、决策事项六组字段。
- 填写顺序建议先固定里程碑名称、负责人、计划完成日期和验收标准，再记录实际进展与偏差原因，最后写明需要谁在什么时间做出什么决定。
- 里程碑名称、负责人、计划完成日期、状态、验收标准和决策事项建议作为必填项；完成比例、风险等级、关联任务链接和附件证据可按项目规模选填。
- 计划完成日期以基线为准，变更时保留原日期并新增变更后日期；实际完成日期在验收通过后填写，延期里程碑留空而不填预计日期。
- 模板复用后需维护版本号与存放位置，新增字段经评审后生效，口径变更通知使用方，历史报告保持原样不回溯修改。
可复制空白里程碑报告模板
模板分为三个区域：表头信息区记录报告本身的基本信息，里程碑清单表按行记录每个里程碑，单里程碑详情区对需要重点说明的节点展开描述。复制时保留表格结构，按项目实际情况增删行即可。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 报告周期 | |
| 报告人 | |
| 报告日期 |
里程碑清单表
| 编号 | 里程碑名称 | 负责人 | 计划完成日期 | 实际完成日期 | 状态 | 完成比例 | 验收标准 | 交付物 | 偏差说明 | 风险与依赖 | 决策事项 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| M1 | |||||||||||
| M2 | |||||||||||
| M3 |
单里程碑详情区
| 项目 | 填写内容 |
|---|---|
| 里程碑编号与名称 | |
| 目标 | |
| 关键交付物清单 | |
| 验收证据 | |
| 未完成原因 | |
| 下一步动作与责任人 | |
| 决策事项（谁、何时、决定什么） |
每个字段记录什么、怎么填
同一份模板在不同团队流转时，最容易出现的问题是字段名相同、口径不同，例如“计划完成日期”有人填评审通过日，有人填交付物提交日。下表按字段组给出含义与填写口径，并列出常见错误，供填写前统一约定。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 项目名称 | 报告所属项目 | 使用立项时的正式名称，与项目台账一致 | 使用简称或代号，导致跨报告无法对应 |
| 报告周期 | 本报告覆盖的时间范围 | 写明起止日期，如“3月1日—3月31日” | 只写“本月”，跨月报告无法追溯 |
| 报告人 | 对报告内容负责的人 | 填写实际汇总人姓名，而非部门名称 | 填团队名，出问题时找不到责任人 |
| 报告日期 | 报告定稿日期 | 填写提交或评审当天的日期 | 与报告周期结束日混用 |
| 计划完成日期 | 里程碑原定达成的日期 | 以基线确认的日期为准，变更需留记录 | 随实际进度反复修改，失去对比意义 |
| 实际完成日期 | 里程碑实际达成的日期 | 以验收通过当天为准，未完成留空 | 交付物提交即填日期，未等验收 |
| 状态 | 里程碑当前所处阶段 | 从统一取值中选择，见下文说明 | 各人自造状态词，统计时无法汇总 |
| 完成比例 | 里程碑整体推进程度 | 按交付物完成项数估算，并注明估算依据 | 凭感觉填百分比，与交付物清单不符 |
| 验收标准 | 判定里程碑达成的条件 | 写成可核对的条件，如“评审纪要签字确认”“测试报告通过率达标” | 写“质量合格”“基本完成”等无法核对的表述 |
| 交付物 | 里程碑应产出的成果 | 逐项列出名称与形态，如文档、系统版本、签字文件 | 只写“相关材料”，验收时无法逐项核对 |
| 偏差说明 | 计划与实际之间的差距及原因 | 写明偏差天数或范围，并说明原因 | 只写“延期”，不写原因和影响 |
| 风险与依赖 | 可能影响里程碑达成的事项 | 写明风险内容、影响对象和依赖方 | 把已发生的问题写成风险，混淆两类信息 |
| 决策事项 | 需要上级或相关方拍板的事项 | 写明决定内容、决策人和期望决策时间 | 只写“待领导确认”，不写确认什么 |
状态字段建议统一为五个取值：未开始表示尚未启动；进行中表示已启动但未达验收标准；已完成表示验收通过并记录实际完成日期；延期表示已过计划完成日期且未达成；已取消表示该里程碑经决策不再执行，需在偏差说明中记录取消原因。取值确定后写入模板说明，避免同一项目内混用“完成中”“接近完成”等表述。
计划完成日期与实际完成日期的记录规则需要特别约定：计划日期以基线为准，发生变更时保留原日期并新增变更后日期，而不是直接覆盖；实际日期只在验收通过后填写。这样清单表本身就能呈现计划与执行的对比，无需另附说明。
必填字段与选填字段的取舍
字段并非越多越好。里程碑报告的核心作用是让读者判断“节点是否达成、差距在哪、需要谁做什么决定”，围绕这个目的保留必填字段，其余按项目复杂度补充。
| 字段 | 建议 | 理由 |
|---|---|---|
| 里程碑名称 | 必填 | 报告的基本识别信息 |
| 负责人 | 必填 | 明确跟进与汇报责任 |
| 计划完成日期 | 必填 | 判断是否延期的基准 |
| 状态 | 必填 | 快速识别节点健康度 |
| 验收标准 | 必填 | 避免“完成”定义分歧 |
| 决策事项 | 必填 | 报告的价值集中在推动决策 |
| 完成比例 | 选填 | 适合周期长、交付物多的里程碑 |
| 风险等级 | 选填 | 里程碑数量多时用于排序关注 |
| 关联任务链接 | 选填 | 便于追溯明细，小型项目可省略 |
| 附件证据 | 选填 | 验收材料较多时以附件承载 |
小型项目（里程碑数量少、参与角色集中）可只保留必填字段加一列备注，报告控制在一页内，重点写清状态和决策事项。大型项目或跨部门项目建议保留完整清单表，并增加风险等级与关联任务链接，便于多个读者按需下钻。无论怎样裁剪，里程碑名称、负责人、计划完成日期、状态、验收标准和决策事项这六项建议始终保留，它们是报告能够被独立读懂的最低字段集。
一份填好的里程碑报告示例
以下示例为演示情景，项目与数据均为虚构，用于说明各字段的实际写法。示例项目包含三个里程碑，报告周期为一个月，其中 M2 已延期。
表头区填写
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 客户门户系统升级项目 |
| 报告周期 | 4月1日—4月30日 |
| 报告人 | 李敏 |
| 报告日期 | 4月30日 |
清单表填写
| 编号 | 里程碑名称 | 负责人 | 计划完成日期 | 实际完成日期 | 状态 | 完成比例 | 验收标准 | 交付物 | 偏差说明 | 风险与依赖 | 决策事项 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| M1 | 需求规格确认 | 王强 | 4月10日 | 4月10日 | 已完成 | 100% | 需求评审纪要经业务方与研发方签字 | 需求规格说明书、评审纪要 | 无 | 无 | 无 |
| M2 | 核心模块开发完成 | 赵磊 | 4月25日 | — | 延期 | 80% | 核心模块单元测试通过，集成环境部署成功 | 模块代码、测试报告、部署记录 | 延期5天，第三方接口文档晚于约定提供，联调推迟 | 依赖第三方接口联调环境，对方承诺5月2日前提供 | 是否调整M3计划日期，需项目发起人5月6日前决定 |
| M3 | 上线试运行 | 李敏 | 5月20日 | — | 未开始 | 0% | 试运行一周无阻断级问题，运维交接完成 | 上线方案、试运行记录、运维交接单 | 无 | 受M2进度影响 | 无 |
M2 详情区填写
| 项目 | 填写内容 |
|---|---|
| 里程碑编号与名称 | M2 核心模块开发完成 |
| 目标 | 完成核心模块开发并通过单元测试，具备集成联调条件 |
| 关键交付物清单 | 模块代码（已提交主干）、单元测试报告、集成环境部署记录 |
| 验收证据 | 测试报告显示用例通过率达标；部署记录含部署时间与环境地址 |
| 未完成原因 | 第三方接口文档晚于约定时间提供，联调工作推迟，导致部署验证未完成 |
| 下一步动作与责任人 | 赵磊5月2日前完成联调环境部署；王强5月4日前协调第三方确认接口版本 |
| 决策事项 | 若5月2日仍未取得联调环境，是否将M3计划日期顺延一周，由项目发起人5月6日前决定 |
这份示例体现了延期里程碑的写法要点：实际完成日期留空而不填预计日期，偏差说明写明天数和原因，风险与依赖区分已发生的问题和尚未发生的影响，决策事项写明决策人、决策内容和时间。M1 与 M3 的填写则展示了已完成和未开始两种状态的简洁写法。
模板的调整与长期维护方法
模板在多个项目复用后，会逐渐暴露字段冗余或口径不清的问题。维护的重点是让变更可控：新增字段有触发条件，口径调整有通知，历史报告可追溯。
- 新增字段的触发条件：当同一类信息在连续多个报告周期内只能写在备注或偏差说明里，且影响阅读判断时，考虑将其提升为独立字段。新增前由项目管理负责人或模板维护人评审，确认字段含义、取值和填写人，避免个人临时加列。
- 口径变更的处理：字段含义或状态取值调整时，在模板说明中记录变更内容和生效日期，并通知所有使用该模板的项目。已提交的历史报告保持原样，不回溯修改；如需对比，在报告中注明所依据的模板版本。
- 版本号与存放位置：模板文件名或表头标注版本号与更新日期，统一存放在团队共享的模板库中，旧版本归档保留。避免多份副本在不同人手中各自演化。
- 定期复盘：每个季度或每个项目阶段结束时，抽查若干份已填写报告，检查是否存在长期空白的字段、反复填错的字段和从未被使用的字段。长期空白的选填字段可以删除，反复填错的字段需要补充填写说明而非直接取消。
当里程碑数量增多、跨项目汇总需求出现时，手工维护表格容易在状态同步上出现滞后。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，对比计划与执行的偏差，提早识别风险和问题；在瀑布项目场景中，也可按目标、交付物或阶段分解计划。将模板中的里程碑清单与系统中的里程碑记录对应起来，报告中的状态、偏差和交付物信息可以从工作项和文档中汇总，减少重复录入。深圳农商行曾依托 ONES 瀑布项目模板对关键里程碑、交付物进行规范化管理，该案例的具体做法以其实际使用范围为准。模板本身仍建议保留为独立文档，用于评审和归档。
常见问题
里程碑报告和项目周报需要分开写吗？
两者可以合并，也可以分开，取决于读者和汇报节奏。里程碑报告聚焦关键节点是否达成、差距在哪、需要什么决策，适合在节点到期、阶段评审或向管理层汇报时提交；项目周报覆盖一周内的任务进展和日常问题。若项目里程碑数量少、周期短，可在周报中嵌入里程碑清单表，减少重复填写；若里程碑跨部门、涉及决策事项较多，建议单独成文，便于评审留档和后续追溯。
里程碑计划日期发生变更时，报告里应该怎么记录？
建议保留原计划日期，同时新增变更后日期和变更原因，而不是直接覆盖原日期。这样清单表能同时呈现基线与调整后的计划，读者可以判断延期是执行问题还是计划本身调整。变更需要经过确认并留下记录，避免计划日期随实际进度反复修改，失去对比意义。若使用系统管理里程碑，可结合基线对比查看计划与执行的偏差。
里程碑数量很多时，报告如何避免变成流水账？
可以按状态和风险分层呈现：清单表保留全部里程碑的基本字段，正文只对延期、存在重大依赖或需要决策的里程碑展开详情区。已完成且无异常的里程碑在清单表中一行带过，不必逐个描述。同时启用风险等级字段对需要关注的节点排序，让读者先看到需要处理的事项。里程碑数量增多、跨项目汇总需求出现时，可借助系统记录状态与交付物信息，减少手工同步。
验收标准写多细才算合适？
验收标准以“第三方能否据此判断达成”为尺度，写成可核对的条件，例如“评审纪要经业务方与研发方签字”“测试报告用例通过率达到约定值”“运维交接单完成签署”。标准过粗会导致完成定义分歧，过细则增加填写负担。建议每个里程碑写一到三条关键条件，与交付物清单对应，验收时逐项核对即可。
模板中的决策事项由谁填写、如何跟进？
决策事项通常由里程碑负责人提出，报告人汇总，写明决定内容、决策人和期望决策时间。跟进时可在下一次报告中检查上次决策事项的落实情况，未决策的继续保留并注明原因。决策事项长期悬空会拖慢后续节点，建议在报告评审会上逐条过一遍，明确责任人和时间。
