共同里程碑信息项清单要解决的是项目集层面“多个项目共同承诺的关键节点”如何被统一记录、跟踪和验收。本文提供一张可直接复制填写的空白表格，按里程碑主信息、关联项目与交付物、责任与验收三组列组织，并逐字段说明填写口径、划分必填与选填、给出完整填写示例和后续维护规则。字段设计围绕可追踪、可验收、可协同三个目标，读者可据此裁剪出适合自身项目集规模的版本。
要点总览（TL;DR）
- 清单按三组列组织：里程碑主信息（编号、名称、目标、计划日期、基线日期、状态）、关联项目与交付物（关联项目、交付物、依赖）、责任与验收（责任人、验收标准、变更记录、备注）。
- 必填字段保证可追踪与可验收：编号、名称、目标、计划日期、状态、关联项目、责任人、验收标准；基线日期、交付物、依赖、变更记录、备注可按项目集规模裁剪。
- 计划日期随调整更新，基线日期在评审通过后冻结，两者差值用于识别进度偏差，是评审的重点输入。
- 变更记录采用追加方式保留历史，状态使用统一取值；里程碑新增、延期、取消时同步更新关联项目的交付节点。
- 清单落地时可映射为里程碑工作项与关联项目，在系统中完成状态更新与变更留痕，清单作为评审和汇报的汇总视图。
可复制空白模板：共同里程碑信息项清单表
下表为空白清单，可直接复制到文档或表格工具中逐行填写。列按三组排列：前六列为里程碑主信息，中间三列为关联项目与交付物，后四列为责任与验收。实际使用时建议一行对应一个共同里程碑，同一里程碑涉及多个项目时，在关联项目列内分行或分号列出，不拆成多行重复主信息。
| 组别 | 字段 | 填写内容 |
|---|---|---|
| 里程碑主信息 | 里程碑编号 | |
| 里程碑名称 | ||
| 里程碑目标 | ||
| 计划日期 | ||
| 基线日期 | ||
| 状态 | ||
| 关联项目与交付物 | 关联项目 | |
| 交付物 | ||
| 依赖 | ||
| 责任与验收 | 责任人 | |
| 验收标准 | ||
| 变更记录 | ||
| 备注 |
若需要横向表头直接粘贴到电子表格，可复制下面这一行纯文本，字段之间用竖线分隔，粘贴后按分隔符拆列即可：
里程碑编号 | 里程碑名称 | 里程碑目标 | 计划日期 | 基线日期 | 状态 | 关联项目 | 交付物 | 依赖 | 责任人 | 验收标准 | 变更记录 | 备注
空白行可按需复制多行。建议在表格上方另加一行清单元信息：项目集名称、清单版本号、最后更新日期、维护人，便于后续版本管理。
字段说明：每个信息项填什么、怎么填
字段说明与上表字段一一对应，填写口径统一后，不同项目提交的里程碑信息才具备可比性。下表逐字段给出含义、填写口径和示例值。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 里程碑编号 | 项目集内唯一标识 | 采用“项目集缩写-序号”格式，一经分配不再复用，取消的编号保留并标注 | PGM01-M03 |
| 里程碑名称 | 里程碑的简短称呼 | 用动宾结构描述达成的结果，控制在20字以内，避免只写阶段名 | 统一身份认证平台上线 |
| 里程碑目标 | 该里程碑要实现的业务或交付结果 | 写清“谁在什么范围获得什么结果”，可衡量；一段话说明，不写过程性任务 | 完成认证服务切换，三个业务系统接入统一登录，旧登录入口下线 |
| 计划日期 | 当前承诺的达成日期 | 随计划调整实时更新，精确到日；调整时同步写入变更记录 | 2025-06-30 |
| 基线日期 | 评审通过后冻结的基准日期 | 在里程碑评审通过时写入并冻结，不随日常调整变化；用于与计划日期对比识别偏差 | 2025-06-15 |
| 状态 | 里程碑当前进展 | 从“未开始、进行中、已达成、已延期、已取消”中选一，按统一口径定期更新 | 进行中 |
| 关联项目 | 共同承担该里程碑的项目 | 列出项目名称及在该里程碑中的角色，多个项目用分号分隔，注明主责项目 | 认证平台项目（主责）；门户改造项目；数据中台项目 |
| 交付物 | 达成里程碑必须产出的成果 | 逐项列出可检查的成果及所在位置，避免只写“相关文档” | 认证服务上线记录；三系统接入测试报告；旧入口下线确认单 |
| 依赖 | 达成该里程碑的前置条件 | 写明依赖对象、依赖内容和需要的时间点，区分项目内依赖与跨项目依赖 | 依赖数据中台完成用户主数据清洗，需在2025-05-20前交付 |
| 责任人 | 对里程碑达成负责的人 | 填一名主责任人，可另列各关联项目的接口人；主责任人负责汇总进展和发起验收 | 张明（项目集经理）；各项目接口人：李华、王芳、陈刚 |
| 验收标准 | 判定里程碑达成的条件 | 写成可核验的条目，每条对应交付物或可观察结果，避免“基本完成”这类表述 | 三系统统一登录成功率≥99%；旧入口访问量归零并保留7天监控记录 |
| 变更记录 | 日期、状态、范围等变化的留痕 | 按“日期+变更内容+变更原因+确认人”记录，追加不覆盖 | 2025-05-08 计划日期由06-15调整为06-30，原因：主数据清洗延期，确认人：张明 |
| 备注 | 其他协同或风险信息 | 填写不归属上述字段但影响里程碑达成的信息，如风险提示、沟通安排 | 上线窗口需避开季度结算期 |
计划日期与基线日期的区别需要在填写时特别注意：计划日期反映当前最新承诺，允许随实际情况调整；基线日期是评审确认后的参照点，保持冻结。两者不一致时，差值即为进度偏差，这也是后续评审的重点输入。
必填与选填：哪些字段不能空
必填字段的底线是保证每个共同里程碑可追踪、可验收。缺少编号或名称，清单无法被引用；缺少计划日期和状态，无法判断进展；缺少关联项目和责任人，无法定位协同方；缺少验收标准，里程碑达成与否只能靠口头判断。以下为必填与选填的划分及理由。
| 字段 | 必填/选填 | 缺失后果或适用场景 |
|---|---|---|
| 里程碑编号 | 必填 | 缺失则无法在会议、报告和变更记录中稳定引用 |
| 里程碑名称 | 必填 | 缺失则清单不可读 |
| 里程碑目标 | 必填 | 缺失则无法判断里程碑是否值得设立 |
| 计划日期 | 必填 | 缺失则无法排入项目集时间轴 |
| 状态 | 必填 | 缺失则无法跟踪进展 |
| 关联项目 | 必填 | 缺失则无法确认哪些项目共同承担 |
| 责任人 | 必填 | 缺失则进展无人汇总、验收无人发起 |
| 验收标准 | 必填 | 缺失则达成判定缺乏依据 |
| 基线日期 | 选填 | 适用于需要偏差管理的项目集；首次评审前可暂空 |
| 交付物 | 选填 | 适用于交付物较多的里程碑；简单里程碑可并入验收标准 |
| 依赖 | 选填 | 存在跨项目前置条件时填写，无外部依赖可空 |
| 变更记录 | 选填 | 首次填写可空，发生调整后必须追加 |
| 备注 | 选填 | 按需填写 |
裁剪建议按项目集规模区分。小型项目集（关联项目三五个、共同里程碑十个以内）可保留全部必填字段，选填字段中优先保留交付物和变更记录，依赖和基线日期可按需启用。大型项目集建议保留全部字段，并额外增加评审记录列，记录每次评审的参与人、结论和遗留问题，避免多项目协同中信息在传递中丢失。
状态与变更记录有最低要求：状态必须使用统一取值，不能各项目自造说法；变更记录即使选填，一旦计划日期、范围或责任人发生变化就必须填写，且采用追加方式保留历史，不覆盖原记录。这两项是清单长期可用的基础。
填写示例：一个共同里程碑的完整一行
以下示例行为演示数据，展示各字段如何配合形成从计划到验收的信息闭环。示例对应字段说明表中的同一组字段，可逐项对照。
| 字段 | 示例取值 |
|---|---|
| 里程碑编号 | PGM01-M03 |
| 里程碑名称 | 统一身份认证平台上线 |
| 里程碑目标 | 完成认证服务切换，三个业务系统接入统一登录，旧登录入口下线 |
| 计划日期 | 2025-06-30 |
| 基线日期 | 2025-06-15 |
| 状态 | 进行中 |
| 关联项目 | 认证平台项目（主责）；门户改造项目；数据中台项目 |
| 交付物 | 认证服务上线记录；三系统接入测试报告；旧入口下线确认单 |
| 依赖 | 依赖数据中台完成用户主数据清洗，需在2025-05-20前交付 |
| 责任人 | 张明（项目集经理）；各项目接口人：李华、王芳、陈刚 |
| 验收标准 | 三系统统一登录成功率≥99%；旧入口访问量归零并保留7天监控记录 |
| 变更记录 | 2025-05-08 计划日期由06-15调整为06-30，原因：主数据清洗延期，确认人：张明 |
| 备注 | 上线窗口需避开季度结算期 |
这一行的信息闭环体现在三处。第一，关联项目写明了主责与配合关系，交付物逐项对应到具体项目产出，读者能看出三个项目各自要交什么。第二，依赖写明了依赖对象、内容和时间点，与变更记录中的延期原因相互印证，说明计划日期调整有据可查。第三，验收标准写成可核验的量化条目，与交付物一一对应，验收时按条目逐项确认即可，不需要另行解释。基线日期与计划日期的差值（15天）直接反映当前偏差，可作为项目集评审的输入。
调整与维护方法：清单如何随项目集演进
清单列好只是起点，项目集运行过程中里程碑会新增、延期或取消，维护规则决定了清单能否长期作为可信的协同依据。以下按变更类型、留痕方式、评审节奏和计划衔接四个方面给出规则。
里程碑新增、延期、取消时的字段更新规则：
- 新增里程碑：分配新编号，填写全部必填字段，经项目集评审确认后写入基线日期；新增原因记入变更记录。
- 延期：更新计划日期和状态，在变更记录中写明原日期、新日期、原因和确认人；基线日期保持不变，以便对比偏差。
- 取消：状态改为“已取消”，编号保留不复用，在变更记录中写明取消原因和已投入工作的处置方式；关联项目的交付节点同步调整。
- 范围变化：里程碑目标或验收标准发生变化时，视为一次重新确认，需重新评审并更新基线日期，旧基线在变更记录中保留。
变更记录与基线对比的维护方式：变更记录采用追加方式，每次调整一行，不删除历史；基线日期在评审通过后冻结，日常调整只改计划日期。定期将计划日期与基线日期对比，偏差超过约定阈值的里程碑列入评审议题。这样既保留了承诺的参照点，也容纳了合理的计划调整。
定期评审的参与角色与检查点：建议由项目集经理牵头，各关联项目接口人和主责任人参加，按固定节奏（如每两周或每个里程碑前）评审。检查点包括：状态是否与实际进展一致；计划日期与基线日期的偏差及原因；依赖是否按期满足；验收标准是否仍然适用；变更记录是否完整。评审结论回写到清单，形成闭环。
清单与各项目计划的衔接方式：共同里程碑的日期和交付物应作为约束条件进入各关联项目的计划，项目内任务排期不得晚于里程碑要求的时间点；项目计划发生调整时，接口人负责判断是否影响共同里程碑，受影响则发起清单变更。清单中的依赖字段与项目间的前置关系保持同一口径，避免两处记录不一致。
当项目集涉及多个项目、里程碑状态需要频繁流转时，清单的承载方式会影响维护成本。ONES 项目集管理支持制定项目里程碑并结合甘特图查看进度，借助项目集总览汇总多项目信息，便于把清单中的里程碑与关联项目放在同一视图下对照（依据官网产品页描述，具体版本能力以实际确认为准）。在瀑布项目管理场景中，ONES 支持用里程碑标记重要时间点、事件或决策点，并可设置项目计划和里程碑基线、对比计划与执行的偏差、通过版本对比追溯变更，这与本文“计划日期随调整更新、基线日期冻结对比”的维护规则相对应。落地时可将清单字段映射为里程碑工作项及其关联项目，状态更新和变更留痕在系统中完成，清单作为评审和汇报的汇总视图使用。
常见问题
共同里程碑和单个项目里的里程碑有什么区别，清单要分开列吗？
共同里程碑由多个项目共同承诺、共同交付，单个项目里程碑只在一个项目范围内达成。清单按共同里程碑逐行记录，关联项目列写明各项目在该里程碑中的角色和主责项目；各项目内部的里程碑留在项目计划中管理，不重复搬进共同清单。判断标准是：该节点是否需要两个及以上项目协同才能达成，若是则列入共同清单。
项目集刚启动、基线还没评审，基线日期这一列怎么处理？
基线日期在首次评审通过前可以留空，此时以计划日期作为排期依据。评审确认后写入并冻结基线日期，此后日常调整只改计划日期。若项目集启动阶段就要求偏差管理，可先以启动会确认的日期作为临时基线，并在变更记录中注明“临时基线，待正式评审确认”，避免后续对比时口径混乱。
一个共同里程碑涉及多个项目时，交付物和验收标准怎么写才不会各说各话？
交付物按项目逐项列出，每项写明产出内容和存放位置；验收标准写成可核验的条目，并与交付物一一对应，尽量量化到可检查的程度。建议在里程碑评审时由主责任人组织各项目接口人共同确认验收标准，确认后写入清单并纳入基线，后续验收按条目逐项核对，减少口头解释。
清单里的依赖字段和项目间的依赖管理是什么关系？
清单中的依赖字段只记录影响共同里程碑达成的前置条件，写明依赖对象、依赖内容和需要的时间点，用于评审时判断里程碑能否按期达成。项目间依赖的识别、跟踪和协同处置属于另一层工作，两者应保持同一口径，避免同一依赖在两处记录不一致。清单不替代依赖管理流程，只承载与里程碑直接相关的关键依赖。
清单维护在文档里做还是在项目管理工具里做更合适？
取决于更新频率和协同范围。里程碑数量少、评审节奏较慢的项目集，用文档或表格维护清单即可，成本低、便于传阅。里程碑状态需要频繁流转、关联项目较多时，把清单字段映射为里程碑工作项及其关联项目，在系统中完成状态更新和变更留痕，清单作为评审和汇报的汇总视图使用，可减少两处记录不一致的情况。ONES 项目集管理支持制定项目里程碑并结合甘特图查看进度，也支持设置里程碑基线、对比计划与执行的偏差（依据官网产品页与方案页描述，具体版本能力以实际确认为准）。
