共同里程碑信息项清单怎么列：项目集模板与字段说明

共同里程碑信息项清单用来把项目集里各项目都要对齐的关键节点集中记录，避免同一节点在不同项目里日期、责任人和验收口径不一致。清单按“项目集层共同节点—关联项目承接节点—证据与判定”三层组织：先列共同节点，再列各项目的承接信息，最后补齐验收证据与变更记录。下面的空白表可直接复制到文档或表格工具中填写，字段说明与示例保持同一口径。

要点总览（TL;DR）

• 共同里程碑信息项清单用一张主表、一张承接子表和一块变更记录区承载，主表记录项目集层共同节点，子表按项目记录承接信息与证据。
• 核心字段分五类：标识（编号、名称、类型）、时间（基准日期、计划日期）、责任（项目集角色、项目负责人）、判定（完成判定标准、证据）、依赖与影响（前置依赖、影响范围）。
• 编号、名称、类型、基准日期、计划日期、责任角色、判定标准、状态、承接项目、项目负责人、承诺日期为必填；承接节点、偏差说明、前置依赖、影响范围可按治理要求裁剪。
• 暂不明确的信息用“待定”“待指派”“待补充”占位，并在节点进入执行前补齐，评审时把占位项数量作为完整性检查指标。
• 清单由项目集经理指定维护人按例会节奏更新，基准日期与判定标准变更需项目集层评审确认，收尾时归档最终版本及全部变更记录。

共同里程碑信息项清单空白模板

模板由两张表和一个记录区组成。主表放在项目集层，只记录所有项目都需要对齐的共同节点；承接子表按项目展开，记录各项目对该节点的承诺与证据；变更记录区保留节点调整的来龙去脉。复制时建议保留表头，删除示例行后再填写。

表一：项目集层共同里程碑主表

里程碑编号	里程碑名称	里程碑类型	基准日期	计划日期	责任项目集角色	完成判定标准	状态

表二：关联项目承接子表

里程碑编号	承接项目	项目负责人	承接节点	承诺日期	证据	偏差说明

变更与确认记录区

变更日期	变更内容	影响项目	确认人

两张表通过“里程碑编号”关联：主表一条记录对应子表若干条承接记录。填写顺序建议先主表、再子表、最后补变更记录，这样每个共同节点都有明确的项目承接方和证据来源。

每个字段填什么：字段说明与填写口径

字段口径统一，不同项目组填出来的清单才能横向比较。下表按标识、时间、责任、判定、依赖与影响五类说明含义和写法，示例仅示意格式，不代表真实项目数据。

字段名	含义	填写口径	示例写法
里程碑编号	共同节点的唯一标识	项目集简称加两位序号，全清单内不重复，编号一经使用不回收	PG-01
里程碑名称	节点要达成的结果	用“对象+动作+结果”描述，避免只写“评审”“上线”这类笼统词	核心系统集成测试通过
里程碑类型	节点的性质分类	在项目集内约定固定取值，如决策点、交付点、验收点、上线点	验收点
基准日期	经批准用于对照偏差的日期	填写批准后的基准，变更需走变更记录；精确到日	2025-06-30
计划日期	当前跟踪使用的日期	随执行更新，与基准日期不一致时在偏差说明中解释；精确到日	2025-07-05
责任项目集角色	项目集层对该节点负责的角色	写角色而非人名，如项目集经理、质量负责人，便于人员变动时交接	项目集经理
完成判定标准	判断节点是否完成的依据	写成可核验的条件，包含范围、数量或通过标准	全部集成用例执行完毕，遗留缺陷不超过约定等级
状态	节点当前进展	使用固定取值，如未开始、进行中、已完成、已延期	进行中
承接项目	对该节点有交付义务的项目	填写项目全称或项目集内统一简称	客户门户改造项目
项目负责人	承接项目侧的责任人	填写姓名加角色，人员变更时同步更新	张三（项目经理）
承接节点	该项目为支撑共同节点需完成的具体事项	比共同节点更细，写清本项目要交付的部分	完成门户端接口联调
承诺日期	承接项目承诺完成的日期	由项目负责人确认，晚于共同节点计划日期时需说明原因	2025-06-25
证据	证明承接节点完成的材料	写证据名称与存放位置，如测试报告、评审纪要、验收单	联调测试报告（项目文档库）
偏差说明	计划与承诺不一致的原因	只写事实和影响，不写评价；无偏差填“无”	接口依赖第三方，承诺日期顺延5天
前置依赖	节点开始前必须完成的事项	写依赖对象和依赖内容，跨项目依赖注明所属项目	数据迁移方案评审通过（数据平台项目）
影响范围	节点延期或变更波及的对象	写受影响的里程碑编号、项目或交付物	影响PG-03、PG-05及上线窗口

时间类字段要区分用途：基准日期用于对照偏差，批准后不随意改动；计划日期用于日常跟踪，可以随执行调整。两者分开记录，评审时才能看出节点是执行偏移还是基准本身发生了变化。责任类字段写角色加姓名，既保留问责对象，也方便人员调整后的交接。

必填与选填：哪些字段不能空

必填字段决定清单能否支撑跟踪和验收，选填字段用于补充上下文。必填项空缺时，清单就失去对照和判定作用，因此空缺必须有明确的占位写法和补齐时点。

字段	必填/选填	理由或适用场景
里程碑编号	必填	主表与子表的关联键，缺失则无法对应承接记录
里程碑名称	必填	识别节点内容的基础信息
里程碑类型	必填	决定后续评审和验收方式
基准日期	必填	偏差对照的基准，缺失则无法判断延期
计划日期	必填	日常跟踪依据
责任项目集角色	必填	明确项目集层的协调责任
完成判定标准	必填	没有判定标准的里程碑无法验收
状态	必填	汇总视图和风险识别依赖状态字段
承接项目	必填	共同节点必须有承接方，否则节点无人负责
项目负责人	必填	承接侧的联络与问责对象
承诺日期	必填	与计划日期对照，识别承接风险
证据	必填（完成时）	节点完成时必须有可核验材料，进行中可先写计划证据名称
承接节点	选填	承接事项较简单时可省略，复杂节点建议填写
偏差说明	选填	计划与承诺一致时填“无”，出现偏差时必填
前置依赖	选填	存在跨项目依赖时填写，无依赖可留空
影响范围	选填	节点变更或延期时填写，用于评估波及面

暂不明确的信息用统一占位写法，例如日期填“待定”、责任人填“待指派”、证据填“待补充”，并在备注或变更记录中写明补齐时点。占位项应在节点进入执行前补齐，评审时把占位项数量作为清单完整性的检查指标。项目集规模较小、治理要求较简时，可裁剪承接节点、前置依赖和影响范围三个字段，但编号、名称、日期、责任人、判定标准和证据不建议裁剪。

填写示例：一个项目集共同里程碑的完整填法

以下为演示情景：某项目集包含客户门户改造、数据平台、统一认证三个项目，共同节点围绕集成测试和上线准备设置。示例数据仅用于说明字段联动，不代表真实项目。

主表已填记录

里程碑编号	里程碑名称	里程碑类型	基准日期	计划日期	责任项目集角色	完成判定标准	状态
PG-01	集成测试环境就绪	交付点	2025-05-10	2025-05-10	项目集经理	三个项目测试环境部署完成，联调入口可用	已完成
PG-02	核心系统集成测试通过	验收点	2025-06-30	2025-07-05	质量负责人	集成用例全部执行，遗留缺陷不超过约定等级	进行中
PG-03	上线评审决策	决策点	2025-07-15	2025-07-15	项目集经理	评审会形成上线结论并记录决策意见	未开始

承接子表对应记录

里程碑编号	承接项目	项目负责人	承接节点	承诺日期	证据	偏差说明
PG-02	客户门户改造项目	张三（项目经理）	完成门户端接口联调	2025-06-25	联调测试报告（项目文档库）	无
PG-02	数据平台项目	李四（项目经理）	完成数据接口压测	2025-07-02	压测报告（项目文档库）	接口依赖第三方，承诺日期顺延5天
PG-02	统一认证项目	王五（项目经理）	完成认证链路回归	2025-06-28	回归测试记录（项目文档库）	无

变更记录区示例

变更日期	变更内容	影响项目	确认人
2025-06-18	PG-02计划日期由2025-06-30调整为2025-07-05，基准日期不变	数据平台项目、客户门户改造项目	项目集经理

核对一致性：主表PG-02的计划日期为2025-07-05，子表中数据平台项目承诺日期为2025-07-02，偏差说明解释了顺延原因；变更记录区保留了计划日期调整的确认信息，基准日期未动，便于后续对照偏差。三个承接项目的证据都指向可查的材料，完成判定标准与证据相互对应。

清单的调整与维护方法

清单列好只是起点，运行期需要有人负责更新、有人批准变更、有固定节奏复核。维护规则建议在项目集启动时确定，并与项目进度计划、依赖协同保持衔接。

• 维护责任人：由项目集经理指定一名清单维护人，负责汇总各项目更新；各项目负责人负责本项目的承接记录和证据。
• 更新频率：与项目集例会节奏一致，建议每周更新状态和计划日期，节点完成或变更时即时更新。
• 变更触发条件：基准日期调整、完成判定标准变化、承接项目增减、影响范围扩大时，必须走变更记录。
• 审批路径：计划日期调整由项目集经理确认；基准日期和判定标准变更需项目集层评审确认，并在变更记录区登记确认人。
• 衔接边界：清单只承载共同节点的信息项，单个项目的详细排期留在项目进度计划中；跨项目依赖的处理在依赖协同机制中跟进，清单只记录与共同节点相关的依赖。
• 版本与归档：每次评审后保存一个版本，文件名包含日期；项目集收尾时归档最终版本及全部变更记录。
• 完整性复核：每月检查一次必填字段空缺数量、占位项是否按期补齐、证据是否可查、变更记录是否与主表一致。

清单落地到协作工具时，可以把主表记录建成项目集层的工作项，承接子表作为关联工作项或子任务，状态和日期随执行流转，证据以附件或文档链接挂接。ONES 的项目计划支持创建工作分解结构并设置任务前后置依赖，里程碑可标记重要时间点、事件或决策点；项目计划和里程碑基线可用于对比计划与执行的偏差，并通过版本对比追溯变更。ONES Plan 提供项目集管理总览多项目信息，便于在项目集层查看各项目进展。具体字段配置和视图呈现以实际产品为准，清单本身仍按本文模板维护。

常见问题

共同里程碑的基准日期和计划日期分别什么时候改？

基准日期是经批准用于对照偏差的日期，批准后保持稳定，调整需要走项目集层评审并在变更记录区登记确认人。计划日期用于日常跟踪，随执行进展更新，与基准日期不一致时在偏差说明中写明原因。两者分开记录，评审时才能区分是执行偏移还是基准本身发生了变化。

承接项目较多时，子表按什么顺序排列更便于核对？

建议先按里程碑编号排序，同一编号下再按承接项目的承诺日期由早到晚排列。这样查看某个共同节点时，各项目的承诺时间一目了然，能快速发现承诺日期晚于共同节点计划日期的承接项。若项目集内项目数量较多，也可以先按承接项目分组，再在每个项目内按里程碑编号排列，便于各项目负责人核对自己负责的记录。

清单里的证据需要保存到什么程度才算可核验？

证据字段写清材料名称和存放位置即可，例如“联调测试报告（项目文档库）”。材料本身应能对应完成判定标准中的条件，评审时可按名称和位置直接调取核对。节点进行中可以先写计划证据名称，完成时替换为实际材料。仅有日期、没有可查证据的里程碑，验收时容易产生争议。

清单与各项目自己的进度计划如何避免重复维护？

清单只承载项目集层共同节点的信息项，包括共同节点本身、各项目的承接承诺和证据；单个项目的详细任务排期留在项目进度计划中。跨项目依赖的处理在依赖协同机制中跟进，清单只记录与共同节点直接相关的依赖。维护时以清单中的编号和日期为对齐依据，项目内部排期变化只要不影响承接承诺，就不必同步到清单。

清单落地到协作工具后，还需要保留文档版本吗？

建议保留。工具中的工作项和状态适合日常跟踪，文档版本适合评审留痕和收尾归档。每次项目集评审后保存一个带日期的版本，收尾时归档最终版本及全部变更记录。ONES 的项目计划支持创建工作分解结构并设置任务前后置依赖，里程碑可标记重要时间点、事件或决策点，项目计划和里程碑基线可用于对比计划与执行的偏差，并通过版本对比追溯变更，可作为清单落地的承载方式，具体字段配置以实际产品为准。