里程碑检查要回答的是“这个节点能不能按约定通过”，判断依据来自四类材料：计划基线、交付物证据、状态与风险数据、决策授权依据。检查范围限于关键节点本身，不展开细粒度任务排期。下面给出依据清单、五步检查流程、角色分工与记录模板，并用一次版本发布里程碑演示如何逐项核验、形成结论。
要点总览（TL;DR）
- 里程碑检查的依据分四类：计划基线（目标、日期、前置交付物清单、基线版本）、交付物证据（评审记录、测试报告、验收单、签认）、状态与风险数据（进度偏差、未关闭问题、变更、依赖确认）、决策授权依据（准入准出标准、评审结论、责任人签认）。
- 检查按五步推进：确认范围与基线版本、逐项核验交付物证据、核对状态与风险、对照准入准出标准形成结论、登记遗留项与后续动作，每步都有明确输出和完成标志。
- 依据缺失或版本不一致时先标记后判定：缺失项列为待补并明确责任人和时限，版本冲突由里程碑负责人确认以哪版为准，待补关闭前结论只能是有条件通过或不通过。
- 检查记录应包含里程碑名称、基线版本、依据核验结果、状态核对结论、逐条标准判定、结论、遗留项与签认，经签认后归档供后续节点检查和复盘使用。
- 常见缺口包括依据版本过期、证据无签认、依赖方仅口头确认、变更未同步到基线，自检时逐项排查可避免结论失真。
里程碑检查的核心依据清单
里程碑检查的依据可以按用途分成四类。四类材料齐全且相互一致，检查才有完整的事实基础；缺少任何一类，结论都只能停留在“有条件通过”或“待补证”。
| 依据类别 | 具体内容 | 在检查中的用途 | 责任提供方 |
|---|---|---|---|
| 计划基线 | 里程碑定义与目标、计划完成日期、前置交付物清单、基线版本号 | 确认本次检查的对象和范围，判断实际完成情况是否对应原定目标 | 里程碑负责人、项目经理 |
| 交付物证据 | 评审记录、测试报告、验收单、文档版本与签署记录 | 证明交付物已产出、已评审、达到约定质量，而非仅有口头说明 | 各交付物责任人 |
| 状态与风险数据 | 进度偏差、未关闭问题清单、变更记录、依赖方确认 | 判断节点是否受未解决问题、范围变更或外部依赖影响 | 项目经理、问题责任人、依赖方接口人 |
| 决策授权依据 | 准入准出标准、评审结论、责任人签认 | 为“通过/有条件通过/不通过”的结论提供规则和授权基础 | 质量或评审角色、项目决策者 |
计划基线是检查的参照系。里程碑目标写清楚“这个节点要达成什么”，前置交付物清单写清楚“达成之前必须完成哪些产物”，两者共同界定检查边界。基线一经确认，后续检查都对照同一版本进行。
交付物证据要能回答三个问题：产物是否存在、是否经过评审、是否达到约定标准。评审记录和测试报告证明过程，验收单和签署记录证明结果被相关方接受。仅有文档标题或链接、没有评审与签认的材料，只能算“已提交”，不能算“已核验”。
状态与风险数据用于解释偏差。进度偏差说明实际与计划的距离，未关闭问题说明还有哪些事项可能影响节点，变更记录说明范围是否发生过调整，依赖方确认说明外部条件是否具备。这四类信息共同支撑对节点成熟度的判断。
决策授权依据决定谁有权下结论、按什么规则下结论。准入准出标准应在检查前明确，评审结论和责任人签认则把结论落到具体的人，避免检查记录停留在描述层面。
里程碑检查的操作步骤
把四类依据转化为动作，可以按五步推进。每一步都有明确输入、做法和输出，完成标志是输出物已形成并可被下一环节使用。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确认范围与基线版本 | 里程碑定义、计划日期、前置交付物清单、基线版本号 | 核对本次检查对应的里程碑与基线版本，确认交付物清单无遗漏 | 检查范围说明 | 范围与基线版本经里程碑负责人确认 |
| 2. 核验交付物证据 | 评审记录、测试报告、验收单、文档版本 | 逐项核对证据是否存在、版本是否为最新、是否有评审与签认 | 证据核验表 | 每项交付物标注“齐全有效/待补/无效” |
| 3. 核对状态与风险 | 进度数据、问题清单、变更记录、依赖确认 | 比对计划与实际偏差，确认未关闭问题的影响，核实变更是否已同步基线 | 状态与风险核对结果 | 偏差、问题、变更、依赖四项均有明确结论 |
| 4. 对照标准形成结论 | 准入准出标准、前两步核验结果 | 逐条对照标准，判定通过、有条件通过或不通过 | 检查结论 | 结论有对应标准条目支撑并经决策者确认 |
| 5. 记录遗留项与后续动作 | 检查结论、待补证据、未关闭问题 | 登记遗留项、责任人、完成时限和复检方式 | 检查记录 | 遗留项均有责任人和时限，记录完成签认 |
第一步的关键是锁定版本。里程碑目标或交付物清单在检查前发生过调整的，要先确认调整是否已走变更流程、基线是否已更新，再以更新后的基线作为检查依据。用旧基线检查新范围，或反之，都会让后续核验失去意义。
第二步按交付物清单逐项过，不建议抽样。每项证据记录三个信息：文件或记录名称及版本、评审或测试结论、签认人。发现证据缺失或版本过期的，当场标记为待补，并记录补交责任人和时限。
第三步把定量数据和定性判断结合。进度偏差看关键路径上的交付物是否受影响；未关闭问题按严重程度排序，确认是否存在阻断节点的问题；变更记录与基线比对，确认范围调整是否已被纳入本次检查；依赖方确认以书面回复为准。
第四步对照准入准出标准逐条判定。标准中要求“全部交付物通过评审”的，有一项未通过就不能判为通过；标准允许“非阻断问题带条件通过”的，要在结论中写明条件和复检时间。结论由项目决策者确认，检查执行人负责提供事实依据。
第五步把结论落成可跟踪的记录。遗留项写明是什么、由谁负责、何时完成、如何验证关闭。检查记录经签认后归档，作为后续节点检查和项目复盘的输入。
角色分工与检查记录模板
里程碑检查涉及提供依据、核验事实、做出决策三类动作，角色分开可以让依据的提供者与结论的判定者各负其责。
| 角色 | 主要职责 | 在检查中的动作 |
|---|---|---|
| 里程碑负责人 | 对节点整体结果负责 | 确认检查范围与基线版本，组织依据收集，牵头处理遗留项 |
| 交付物责任人 | 对具体交付物质量负责 | 提交交付物及评审、测试、验收证据，响应核验中的问题 |
| 质量或评审角色 | 对证据有效性负责 | 核验证据齐全性与有效性，对照准入准出标准给出核验意见 |
| 项目决策者 | 对检查结论负责 | 确认通过、有条件通过或不通过的结论，批准遗留项处理方案 |
检查记录是检查工作的主要产物，字段设计要能支撑复核。一份完整的记录至少包含以下内容：
- 里程碑名称与所属项目、检查日期；
- 基线版本号及本次检查对应的交付物清单；
- 依据清单及逐项核验结果，标注齐全有效、待补或无效；
- 进度偏差、未关闭问题、变更与依赖确认的核对结论；
- 对照准入准出标准的逐条判定；
- 检查结论：通过、有条件通过或不通过；
- 遗留项、责任人、完成时限与复检方式；
- 里程碑负责人、核验人、决策者的签认。
记录承载方式可以按团队现有工具安排。使用 ONES 的团队可以在项目计划中设置里程碑与基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节；检查记录、遗留项和签认信息随里程碑一并留存，便于下一次节点检查时调取。深圳农商银行依托 ONES 瀑布项目模板对关键里程碑、交付物进行规范化管理的实践，可作为这种承载方式的参考，具体做法需结合自身项目情况调整。
示例：一次版本发布里程碑检查
以下为演示情景，用于说明依据如何逐项核验并形成结论。
背景与目标：某系统计划于6月30日完成V2.3版本发布里程碑，里程碑目标为“完成功能开发、测试通过并取得业务方验收”。基线版本为B1.2，前置交付物清单包括需求规格说明书、测试报告、发布说明和业务验收单四项。
逐类核验过程：
- 计划基线：核对B1.2基线，确认里程碑日期与交付物清单未发生变更，检查范围锁定。
- 交付物证据：需求规格说明书版本为V2.3且已评审签认；测试报告显示用例执行率100%，遗留2个一般缺陷；发布说明已提交但尚无评审记录；业务验收单已签署。发布说明被标记为“待补评审”。
- 状态与风险：进度偏差为关键路径延迟2天，已通过加班追回；未关闭问题为2个一般缺陷，均不影响核心功能；变更记录显示一项非核心功能延至下版本，已同步基线；依赖方运维团队书面确认发布窗口可用。
- 决策授权：准入准出标准要求“全部交付物通过评审、无阻断级缺陷、业务方验收通过”。对照后，发布说明评审缺失构成一项未满足条件。
结论与遗留项处理：检查结论为“有条件通过”。条件为发布说明在6月28日前完成评审并签认，2个一般缺陷在发布后首个补丁版本修复。遗留项登记为：发布说明评审，责任人文档负责人，时限6月28日；缺陷修复，责任人开发负责人，时限7月15日。复检方式为发布前由质量角色核验评审记录，缺陷关闭情况纳入下个里程碑检查。记录经里程碑负责人、核验人和决策者签认后归档。
完成检查与常见遗漏
检查结束前，用以下自检项确认记录可以支撑复核和后续跟踪：
- 检查范围与基线版本已确认，交付物清单与基线一致；
- 每项交付物证据均标注核验结果，待补项有责任人和时限；
- 进度偏差、未关闭问题、变更、依赖四项均有明确核对结论；
- 结论逐条对应准入准出标准，无标准外的主观判断；
- 遗留项写明内容、责任人、时限和复检方式；
- 记录已完成相关角色签认并归档。
依据收集中常见的缺口有四类。一是版本过期，用旧版本文档或旧基线作为检查依据，导致核验对象与实际不符；二是证据无签认，材料存在但缺少评审结论或责任人确认，无法证明有效性；三是依赖方未确认，外部条件仅凭口头沟通，检查时无法核实；四是变更未同步到基线，范围已调整但基线未更新，检查结论与实际范围脱节。
依据缺失或版本不一致时，处理原则是先标记、后判定，不直接判为通过。具体做法是：将缺失项列为待补，明确补交责任人和时限；版本不一致的，由里程碑负责人确认以哪一版为准，涉及范围调整的发起基线变更或补充评审；在待补项关闭前，检查结论只能是有条件通过或不通过，并在记录中写明条件和复检安排。待补项完成后，由核验人复核并更新记录，必要时由决策者确认结论调整。
常见问题
里程碑目标和交付物清单在检查前调整过，应该以哪个版本作为检查依据？
先确认调整是否已走变更流程、基线是否已更新，再以更新后的基线作为检查依据。如果变更尚未完成审批，本次检查仍对照原基线进行，同时把范围调整作为遗留项登记，注明待变更完成后复检。用旧基线检查新范围，或拿新范围套旧基线，都会让核验结果与实际脱节。
交付物证据只有文档链接、没有评审记录和签认，能算核验通过吗？
只能算“已提交”，不能算“已核验”。交付物证据要同时回答产物是否存在、是否经过评审、是否达到约定标准三个问题。缺少评审记录或签认的，在证据核验表中标记为待补，写明补交责任人和时限；在待补项关闭前，检查结论按准入准出标准判定为有条件通过或不通过。
外部依赖方只做了口头确认，检查时怎么处理？
以书面回复为准。口头确认无法在检查记录中留痕，也无法在后续复检时核实。处理方式是把该依赖项标记为待确认，请依赖方接口人提供书面确认（邮件、会议纪要签认或系统内确认均可），明确确认内容和有效期。待确认期间，依赖条件视为未具备，结论中写明该条件和复检安排。
检查结论为“有条件通过”后，遗留项关闭由谁复核、结论是否需要重新确认？
遗留项完成后由核验人复核证据并更新检查记录，涉及结论变化的由项目决策者重新确认。复核时要核对遗留项的内容、完成证据和时限是否符合原记录约定；如果遗留项在约定时限内未关闭，需要重新评估对节点的影响，必要时调整结论。更新后的记录保留原结论和调整说明，便于追溯。
里程碑检查记录可以用项目管理工具承载吗？
可以按团队现有工具安排。使用 ONES 的团队可以在项目计划中设置里程碑与基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节；检查记录、遗留项和签认信息随里程碑一并留存，便于下一次节点检查时调取。深圳农商银行依托 ONES 瀑布项目模板对关键里程碑、交付物进行规范化管理的实践，可作为承载方式的参考，具体做法需结合自身项目情况调整。
