里程碑清单用一张表把项目的关键节点、交付物、验收标准和责任人固定下来，便于跟踪和交接。本文提供可直接复制的空白表格，逐字段说明填写口径，划分必填与选填，并给出一个产品发布项目的完整填写示例和后续维护方法。
要点总览（TL;DR）
- 空白模板包含12列主表字段：编号、里程碑名称、所属阶段、目标完成日期、交付物、验收标准、负责人、参与角色、前置依赖、状态、完成日期、备注，另配一张变更记录表。
- 必填字段为编号、名称、目标完成日期、交付物、验收标准、负责人、状态七项；所属阶段、参与角色、前置依赖、完成日期、备注按项目复杂度选填。
- 产品发布示例覆盖立项、需求、开发、测试、发布六个里程碑，验收标准均写成可核对的是非条件，日期偏差在表内直接可见。
- 维护要点是固定状态更新节奏、明确日期调整触发条件、按阶段复核清单，并把细粒度任务排期与阶段评审决策留在清单之外。
可复制空白里程碑清单模板
下面这张主表覆盖从节点定义到完成确认的常用字段，可以直接复制到文档或表格工具中，按项目实际情况增删列。单元格留空，供填写时使用。
| 编号 | 里程碑名称 | 所属阶段 | 目标完成日期 | 交付物 | 验收标准 | 负责人 | 参与角色 | 前置依赖 | 状态 | 完成日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
里程碑日期或范围发生调整时，用下面这张变更记录表留痕，与主表放在同一文档中，按时间顺序追加行。
| 变更日期 | 变更内容 | 原因 | 提出人 | 确认人 |
|---|---|---|---|---|
每个字段填什么：字段说明
字段说明与上面的模板列一一对应。填写时把握一个原则：让没有参与讨论的人读这张表，也能判断这个节点要交什么、由谁负责、什么算完成。
| 字段 | 含义与填写口径 | 常见写法 |
|---|---|---|
| 编号 | 清单内的唯一标识，便于在会议和变更记录中引用 | M01、M02，按时间顺序编排 |
| 里程碑名称 | 用结果性表述描述节点达成后的状态，避免写成动作或过程 | “完成需求评审并冻结范围”“发布候选版本通过验收” |
| 所属阶段 | 对应项目阶段划分，便于按阶段汇总查看 | 立项、设计、开发、测试、发布 |
| 目标完成日期 | 计划达成的日期，是排期和偏差对比的基准 | 2025-06-30 |
| 交付物 | 该节点需要产出的、可检查的具体成果，写名称和形态 | 《需求规格说明书》V1.0、可安装的测试包 |
| 验收标准 | 判定节点通过的条件，写成可核对的是非判断 | 评审纪要中遗留问题全部关闭；冒烟用例通过率100% |
| 负责人 | 对该节点结果负责的单一责任人，负责推进和汇报 | 填写一个人名或岗位 |
| 参与角色 | 需要配合的协作方，按角色列出即可 | 产品、开发、测试、运维 |
| 前置依赖 | 本节点开始或完成所依赖的其他里程碑、外部输入或决策 | M03 完成；采购合同签署 |
| 状态 | 节点当前进展，使用统一取值，避免各写各的 | 未开始、进行中、待验收、已完成、已延期 |
| 完成日期 | 实际达成的日期，节点确认通过后填写，与目标日期对照看偏差 | 2025-07-02 |
| 备注 | 补充说明风险、例外情况或关联文档位置 | 依赖第三方接口，存在两周不确定性 |
名称类字段的关键是写“达成了什么”，例如“完成架构方案评审”比“架构评审”更容易判断是否完成。时间类字段要区分计划与实际：目标完成日期在计划阶段确定，完成日期只在验收通过后填写，两者之差就是该节点的进度偏差。交付物和验收标准要成对写，交付物回答“交什么”，验收标准回答“怎样算通过”，只写交付物不写标准，节点是否完成就容易产生分歧。负责人只填一人，参与角色可以多人，这样责任清晰又不遗漏协作方。前置依赖写清依赖的具体对象，状态取值在项目启动时统一约定并在全表沿用。
必填与选填怎么划分
字段并非越多越好。必填字段保证清单能被独立读懂和跟踪，选填字段按项目复杂度和协作范围补充。下表给出划分建议。
| 字段 | 建议 | 理由与适用场景 |
|---|---|---|
| 编号 | 必填 | 支撑引用、依赖描述和变更记录定位 |
| 里程碑名称 | 必填 | 清单的基本识别信息 |
| 目标完成日期 | 必填 | 没有日期就无法排期和对比偏差 |
| 交付物 | 必填 | 明确节点产出，避免“完成了但不知道交了什么” |
| 验收标准 | 必填 | 节点是否通过需要可判定的依据 |
| 负责人 | 必填 | 单一责任人是推进和汇报的前提 |
| 状态 | 必填 | 日常跟踪的主要依据 |
| 所属阶段 | 选填 | 阶段划分清晰的中大型项目建议填写，便于分组汇总 |
| 参与角色 | 选填 | 跨团队协作时填写，单人或小团队可省略 |
| 前置依赖 | 选填 | 节点之间存在明显先后关系时填写，独立节点可留空 |
| 完成日期 | 选填 | 节点完成后回填，用于计算偏差；只做前瞻计划时可暂不设列 |
| 备注 | 选填 | 记录风险与例外，按需使用 |
小型项目可以只保留编号、名称、目标日期、交付物、验收标准、负责人和状态七列，清单保持一屏可读。跨团队项目建议补上所属阶段、参与角色和前置依赖，因为节点交接多、责任边界容易模糊，这些字段能减少沟通成本。状态字段推荐统一使用“未开始、进行中、待验收、已完成、已延期”五个取值：前四个描述正常推进过程，“已延期”单独标出，便于在例会上快速筛出需要关注的节点。取值集合一旦确定，全项目沿用，不在中途临时新增含义相近的状态。
完整填写示例：一个产品发布项目的里程碑清单
以下示例为演示情景，项目名称、日期和交付物均为虚构，用于展示字段之间的配合关系。示例列与空白模板完全一致。
| 编号 | 里程碑名称 | 所属阶段 | 目标完成日期 | 交付物 | 验收标准 | 负责人 | 参与角色 | 前置依赖 | 状态 | 完成日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| M01 | 完成立项评审并确认项目范围 | 立项 | 2025-03-14 | 立项报告、范围说明 | 立项报告经决策人签字；范围说明中的功能清单无未决项 | 项目经理 | 产品、技术负责人 | 无 | 已完成 | 2025-03-14 | 范围变更需走变更记录 |
| M02 | 完成需求评审并冻结需求基线 | 设计 | 2025-04-11 | 需求规格说明书 V1.0、评审纪要 | 评审纪要中遗留问题全部关闭；需求条目均有优先级 | 产品负责人 | 开发、测试、项目经理 | M01 完成 | 已完成 | 2025-04-15 | 较计划延后4天，原因见变更记录 |
| M03 | 完成核心功能开发并提测 | 开发 | 2025-05-30 | 可安装的测试包、提测说明 | 提测说明列出的功能全部可运行；冒烟用例通过率100% | 开发负责人 | 测试、产品 | M02 完成 | 进行中 | 第三方接口联调存在不确定性 | |
| M04 | 完成系统测试并关闭严重缺陷 | 测试 | 2025-06-20 | 测试报告、缺陷清单 | 严重及以上缺陷全部关闭；测试报告经评审通过 | 测试负责人 | 开发、产品 | M03 完成 | 未开始 | ||
| M05 | 发布候选版本通过上线评审 | 发布 | 2025-06-30 | 发布方案、上线评审纪要 | 评审纪要中上线条件全部满足；回滚方案已确认 | 项目经理 | 运维、开发、测试 | M04 完成 | 未开始 | 上线窗口需与运维确认 | |
| M06 | 完成正式发布并确认线上稳定 | 发布 | 2025-07-04 | 发布记录、线上监控报告 | 发布后连续48小时无严重告警；关键业务指标正常 | 运维负责人 | 开发、测试、产品 | M05 完成 | 未开始 |
从示例可以看出几个配合关系：M02 的目标日期是4月11日，完成日期是4月15日，偏差在表内直接可见；M03 的前置依赖写“M02 完成”，读者能顺着编号找到上游节点；每个验收标准都写成可核对的条件，例如“冒烟用例通过率100%”“严重及以上缺陷全部关闭”，评审时逐条对照即可判定通过与否。交付物写的是具体文档或包，而非笼统的“开发成果”。
模板的调整与维护方法
模板落地后需要随项目类型调整字段，并在执行过程中持续维护状态和变更记录。以下操作清单可直接对照执行。
- 按项目类型增删字段。交付物形态复杂的项目（如硬件、集成类）可增加“交付物存放位置”列；涉及外部供应商的项目可增加“外部依赖方”列；纯内部小项目则删去参与角色和备注，保留核心七列。判断标准是：删掉这一列后，是否还有人需要靠它做判断或交接。
- 明确日期调整的触发条件。前置依赖延期、范围发生变更、关键资源不可用时，评估是否调整目标完成日期。调整须在变更记录表中写明变更内容、原因、提出人和确认人，主表同步更新日期，原日期可在备注中保留，便于回溯。
- 固定状态更新节奏。建议由各节点负责人在每周例会前更新自己节点的状态，项目经理在例会上核对“进行中”和“已延期”节点，确认下一步动作。节点验收通过后，由负责人填写完成日期并将状态改为“已完成”。
- 设置定期复核检查点。在每个阶段结束时复核一次清单：检查即将到来的节点是否有负责人和验收标准、前置依赖是否仍然成立、已延期节点是否已有应对措施。复核结果记入会议纪要，需要调整的走变更记录。
- 划清与任务排期、阶段评审的边界。里程碑清单只管理关键节点，节点内部的细粒度任务拆分和任务间依赖放在任务排期工具中；阶段评审的决策规则和组织流程属于评审机制，清单只记录评审作为节点的验收标准，不承载评审议程和决策记录。
当清单从文档迁移到项目管理工具中跟踪时，节点状态、依赖关系和变更留痕需要由系统承载。在 ONES 中，可以用里程碑标记项目中的重要时间点、事件或决策点，并为任务设置前后置依赖，让节点之间的关联在计划中直接可见；设置项目计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本对比追溯变更细节。深圳农商银行曾依托 ONES 瀑布项目模板对关键里程碑和交付物进行规范化管理，这一实践可作为参考，具体做法需结合自身项目情况调整。工具中的状态取值和基线能力范围以实际版本为准，迁移前建议先用一个小项目验证字段映射是否完整。
常见问题
里程碑清单和任务排期表需要同时维护吗，会不会重复？
两者管理粒度不同，可以并存。里程碑清单只记录关键节点及其交付物、验收标准，任务排期表管理节点内部的细粒度任务拆分和任务间依赖。常见做法是里程碑清单给出节点日期和验收条件，任务排期表把每个节点展开为具体任务，节点完成时回填完成日期并更新状态。如果项目很小、节点内部任务很少，也可以只保留里程碑清单，避免两套表反复同步。
里程碑目标日期调整后，原日期还要保留吗？
建议保留。主表更新为目标日期后，可在备注中注明原日期和调整原因，同时在变更记录表中写明变更内容、原因、提出人和确认人。这样后续复盘时能看出计划偏差的来源，也便于向相关方解释进度变化。若使用带基线能力的项目管理工具，设置基线后可直接对比计划与执行的差异，追溯变更细节。
状态字段的取值可以按团队习惯自己定吗？
可以，关键是全项目统一并保持稳定。推荐使用“未开始、进行中、待验收、已完成、已延期”五个取值，前四个描述正常推进过程，“已延期”单独标出便于例会上快速筛选。取值集合确定后，避免中途新增含义相近的状态，否则统计和汇报口径容易混乱。若在工具中跟踪，状态取值需与工具中的工作项状态配置对应。
跨团队项目的里程碑清单要额外加哪些字段？
跨团队项目节点交接多，建议在核心七列基础上补上所属阶段、参与角色和前置依赖。所属阶段便于按阶段分组汇总；参与角色列出需要配合的团队，减少交接时的责任模糊；前置依赖写清依赖的具体里程碑编号或外部输入，让上下游关系可追溯。涉及外部供应商时，还可以增加外部依赖方一列，记录对接人和合同节点。
清单迁移到项目管理工具后，变更记录还需要单独维护吗？
取决于工具的留痕能力。若工具支持基线设置和版本对比，日期与范围的调整可以通过基线偏差和版本细节追溯，变更记录表可以简化为关键决策的说明。若工具只记录当前状态，建议继续保留变更记录表，与主表放在同一位置。迁移前先用一个小项目验证字段映射是否完整，确认状态、依赖和日期都能对应后再全量切换。
