软硬件关联项目的共同里程碑，应围绕双方必须共同完成的交接点来设定，例如样机与固件联调、软硬件接口冻结、联合测试准入。把两个项目各自的内部节点直接叠加，往往无法形成真正的共同节点。本文按“选哪些节点、怎么设、填什么字段、谁来负责、如何检查”的顺序，给出可直接执行的设定方法，并在综合计划跟踪环节说明ONES可承载的管理动作。
要点总览（TL;DR）
- 共同里程碑应围绕软硬件之间的交接点设定：由两个及以上关联项目共同承担，以交接完成或联合交付为完成标志，而非各自内部节点的简单叠加。
- 筛选时同时满足三条条件：存在跨项目交付依赖、双方均需投入、完成状态可被共同判定；单项目节点、阶段关口和依赖事项不宜混入。
- 设定按五步执行：梳理交接关系、筛选候选节点、定义节点要素、对齐内部计划、纳入项目集综合计划并建立基线。
- 每个里程碑需写明双方交付物、统一日期口径、可判定的完成标准和验收证据，并指定唯一负责人。
- 纳入综合计划前逐项核对关联项目、负责人、完成标准与日期一致性，常见偏差包括挂名共同节点、标准模糊和单方改期。
共同里程碑的判定标准与选取范围
共同里程碑指由两个及以上关联项目共同承担、以交接完成或联合交付为完成标志的节点。它服务的是项目集层面的协同交付，判断一个节点能否升级为共同里程碑，可以看三条筛选条件是否同时成立。
- 存在跨项目交付依赖：一方的产出是另一方开展下一步工作的必要输入，例如硬件样机交付给软件团队进行烧录与联调。
- 双方均需投入：节点完成需要软硬件两个项目分别提供人员、物料、版本或环境，单方无法独立关闭。
- 完成状态可被共同判定：双方能依据同一份证据确认节点是否达成，例如联调记录、接口文档签署页、测试准入结论。
需要区分三类容易混淆的节点。单项目里程碑只对一个项目的内部交付负责，例如硬件完成结构件打样；项目集阶段关口是管理层对整体阶段的评审决策点，覆盖范围大于单个交接；依赖事项是任务之间的前后置关系，粒度更细，通常不单独作为里程碑管理。共同里程碑介于三者之间：它由依赖关系产生，以交接为完成标志，并进入项目集综合计划统一跟踪。
软硬件关联场景中，常见的候选节点类型包括：样机与固件联调启动、软硬件接口冻结、联合测试准入、批量交付准备。这些节点的共同特征是双方在同一时间窗口内必须同时就位，任何一方延期都会直接阻断对方工作。
设定共同里程碑的操作步骤
设定过程从梳理交接关系开始，到纳入项目集综合计划基线结束。每一步都应有明确输入、动作、输出和完成标志，避免只停留在口头对齐。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 梳理交接关系 | 软硬件各项目的交付物清单、版本计划 | 逐项列出软硬件之间的交付物与交接关系，标明提供方、接收方和时间窗口 | 软硬件交接清单 | 交接清单经双方项目经理确认，无遗漏项 |
| 2. 筛选候选节点 | 交接清单 | 按三条筛选条件逐项判断，明确每个候选节点双方的交付内容 | 共同里程碑候选清单 | 每个候选节点均标注两个及以上关联项目及各自交付内容 |
| 3. 定义节点要素 | 候选清单 | 为每个节点填写名称、目标日期、完成标准与验收证据 | 共同里程碑定义表 | 完成标准可由第三方依据证据独立判定 |
| 4. 对齐内部计划 | 定义表、各项目内部计划 | 核对共同日期在双方计划中是否一致，记录偏差并协商调整 | 对齐后的日期与偏差记录 | 双方计划中的同一节点日期一致或偏差已登记 |
| 5. 纳入综合计划 | 对齐后的定义表 | 登记到项目集综合计划，建立基线，明确变更规则 | 项目集综合计划中的共同里程碑基线 | 基线经项目集经理确认，变更规则已告知相关角色 |
第三步和第四步通常需要反复：完成标准一旦写细，往往会暴露双方对交付内容理解不一致的问题，此时应回到第二步调整候选节点的范围，而不是在定义表里含糊处理。第五步建立基线后，后续任何日期或完成标准的调整都应走变更记录，保留原基线用于对比。
共同里程碑的字段设计与完成标准
字段设计的目的是让每个共同里程碑可判定、可跟踪。建议至少包含以下核心字段，并在项目集综合计划中保持各项目使用同一套字段口径。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 里程碑名称 | 唯一名称，体现交接内容，避免与单项目节点重名 | 硬件样机与固件V1.2联合调试启动 |
| 关联项目 | 列出全部共同承担的项目 | 硬件样机项目、嵌入式软件项目 |
| 双方交付物 | 分别写明各方需提供的具体产出 | 硬件：可上电样机3台及调试接口说明；软件：可烧录固件V1.2及版本说明 |
| 目标日期 | 统一日期口径，注明以哪份计划为基准 | 以项目集综合计划基线日期为准 |
| 完成标准 | 写成可判定的条件，避免“基本完成”类描述 | 双方完成联调并签署联调记录，遗留问题清单中阻断级问题为0 |
| 验收证据 | 指明判定时需查看的具体材料 | 联调记录、问题清单关闭记录 |
| 负责人 | 指定唯一负责人，通常为项目集经理或双方共同指定的协调人 | 项目集经理张某 |
| 状态 | 使用统一取值，并约定升级规则 | 未开始、进行中、待验收、已完成、已延期 |
完成标准的写法直接决定节点能否被共同判定。可参考两类写法：一类以签署为准，如“软硬件接口文档经双方技术负责人签署”；一类以数量或结论为准，如“联调问题清单中阻断级问题关闭至0，一般问题不超过约定数量并附处理计划”。日期口径需要提前约定，例如统一以项目集综合计划中的基线日期为准，任一项目内部计划调整时，偏差记录在共同里程碑的变更说明中，而不是只改自己项目的计划。
状态取值应保持精简，并明确升级规则：节点进入“待验收”后超过约定天数未完成判定，或目标日期前约定周期内双方交付物仍未就位，即升级至项目集经理协调。
角色分工与交付物
共同里程碑的责任容易在软硬件两个项目之间悬空，因此需要明确谁负责设定、谁负责确认、谁负责跟踪。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目集经理 | 统筹共同里程碑清单，组织双方对齐，维护综合计划基线，处理升级事项 | 共同里程碑清单、综合计划基线、变更记录 | 设定阶段牵头，执行阶段按约定频率更新 |
| 硬件项目经理 | 提供硬件侧交付内容与日期，确认共同节点，反馈偏差 | 硬件交付物清单、日期确认意见 | 梳理交接关系与对齐计划时 |
| 软件项目经理 | 提供软件侧交付内容与日期，确认共同节点，反馈偏差 | 软件交付物清单、日期确认意见 | 梳理交接关系与对齐计划时 |
| 技术负责人 | 判定完成标准是否达成，签署验收证据 | 验收结论、签署记录 | 节点进入待验收时 |
| 变更审批与知会角色 | 审批日期或完成标准的调整，知会受影响的项目与干系人 | 变更审批记录、知会记录 | 发生变更时 |
项目集经理对共同里程碑清单负总责，但每个节点的完成判定应由技术负责人依据验收证据作出，避免由单方项目经理自行宣布完成。变更审批角色可由项目集经理与技术负责人共同承担，知会范围至少覆盖两个关联项目的项目经理。
示例：一次软硬件联调节点的共同里程碑设定
以下为演示情景，用于说明从候选节点到可跟踪里程碑的填写过程，不代表真实客户案例。
场景设定：硬件团队完成样机试制，嵌入式软件团队完成固件V1.2开发，双方需要联合调试。在交接清单中识别出的候选节点包括样机交付、固件版本交付、联调启动、联调问题关闭。按筛选条件判断，“联调启动”需要双方同时投入且以双方共同确认为完成标志，适合设为共同里程碑；“样机交付”主要由硬件项目内部完成，作为依赖事项管理即可。
| 字段 | 填写内容 |
|---|---|
| 里程碑名称 | 样机与固件V1.2联合调试启动 |
| 关联项目 | 硬件样机项目、嵌入式软件项目 |
| 双方交付物 | 硬件：可上电样机3台、调试接口说明；软件：可烧录固件V1.2、版本说明与已知问题清单 |
| 目标日期 | 以项目集综合计划基线日期为准 |
| 完成标准 | 双方在联调环境完成首轮联调，签署联调启动记录，阻断级问题为0 |
| 验收证据 | 联调启动记录、首轮问题清单 |
| 负责人 | 项目集经理 |
| 状态 | 进行中 |
对齐过程中出现日期偏差：软件项目内部计划中固件V1.2完成时间比硬件样机可上电时间晚一周。双方协商后，将共同里程碑目标日期按较晚一方设定，并在变更说明中记录偏差原因；硬件项目据此调整联调准备工作的排期。纳入综合计划后，该节点以统一状态跟踪，进入待验收时由技术负责人依据联调启动记录判定，延期则按升级规则提交项目集经理协调。
在综合计划层面，这类共同里程碑需要与各项目计划保持同一视图。ONES 项目集管理支持制定项目里程碑、甘特图，多时间跨度查看进度，并提供多项目总览与多维度进度查看；ONES 瀑布项目管理方案支持用项目计划创建工作分解结构，为任务设置前后置依赖，用里程碑标记重要时间点，并设置项目计划和里程碑基线，对比计划与执行偏差、追溯变更细节。对于需要把软硬件共同节点放进统一计划跟踪的团队，可以在同一项目集视图中登记共同里程碑并维护基线，具体跨项目共享同一里程碑对象的配置方式，建议在试用或咨询时结合当前版本确认。
完成检查与常见偏差
共同里程碑清单在纳入综合计划前应逐项核对，后续按固定节奏复查。可使用的检查项如下：
- 每个共同里程碑是否关联两个及以上项目，且各方交付内容均已写明。
- 是否指定了唯一负责人，负责人是否清楚自己的判定与协调职责。
- 完成标准是否可由第三方依据验收证据独立判定，是否仍存在模糊表述。
- 目标日期是否在双方计划中一致，偏差是否已登记并说明原因。
- 状态取值是否统一，升级规则是否已告知相关角色。
- 是否已建立基线，变更规则是否明确。
常见偏差有三类。第一类是把单项目节点挂名为共同里程碑，实际只有一方投入，纠正方式是回到筛选条件重新判断，将其降为依赖事项。第二类是完成标准写成“基本完成”“进展顺利”等模糊描述，纠正方式是补充可查看的证据和可计数的条件。第三类是日期只在一方计划中更新，导致双方计划脱节，纠正方式是要求任何日期调整都同步更新共同里程碑记录并留存变更说明。
共同里程碑清单建议在项目集计划基线建立时评审一次，此后在每个共同节点进入待验收前复查，并按月或在发生变更时更新。评审参与方至少包括项目集经理、软硬件项目经理和技术负责人。
常见问题
共同里程碑的目标日期在双方计划中不一致时，以哪一方为准？
建议在设定阶段就约定统一口径，通常以项目集综合计划中的基线日期为准，而不是默认采用某一方项目内部计划的日期。出现不一致时，先由双方项目经理核对各自交付物的实际就位时间，协商确定共同日期；协商结果记入共同里程碑的变更说明，写明偏差原因和调整依据。硬件项目或软件项目据此调整自身排期，双方计划中的同一节点日期随之保持一致。若偏差无法在项目层面解决，按升级规则提交项目集经理协调。
共同里程碑的完成由谁判定，项目经理能否自行宣布完成？
建议由技术负责人依据验收证据作出判定，项目经理负责提供交付物和过程记录，不单独宣布节点完成。这样安排的原因是共同里程碑涉及双方交付，单方判断容易忽略对方尚未就位的内容。判定时查看的证据应在设定阶段就写清楚，例如联调记录、接口文档签署页、问题清单关闭记录。节点进入待验收状态后超过约定天数仍未完成判定，或目标日期前约定周期内交付物未就位，即升级至项目集经理协调。
软硬件项目中，哪些节点容易被误设为共同里程碑？
常见的是把只有一方投入的内部节点挂名为共同节点，例如硬件完成结构件打样、软件完成某模块编码。这类节点虽然重要，但完成状态由单方判定，按筛选条件应作为单项目里程碑或依赖事项管理。另一类容易混淆的是项目集阶段关口，它覆盖整体阶段的评审决策，范围大于单个交接点。判断时回到三条条件：是否有跨项目交付依赖、双方是否均需投入、完成状态能否被共同判定，三条同时成立才适合升级为共同里程碑。
共同里程碑设定后，清单需要多久复查一次？
建议在项目集计划基线建立时完整评审一次，此后在每个共同节点进入待验收前复查该节点，并按月或在发生变更时更新整份清单。评审参与方至少包括项目集经理、软硬件项目经理和技术负责人。复查重点包括关联项目是否仍为两个及以上、完成标准是否仍可判定、日期是否在双方计划中保持一致、状态与升级规则是否已同步给相关角色。发生日期或完成标准调整时，保留原基线用于对比，变更说明随记录留存。
把共同里程碑放进统一计划跟踪时，需要关注哪些配置问题？
核心是让多个关联项目在同一视图中看到同一节点，并保持名称、日期和状态口径一致。ONES 项目集管理支持制定项目里程碑、甘特图，多时间跨度查看进度，并提供多项目总览与多维度进度查看；ONES 瀑布项目管理方案支持用项目计划创建工作分解结构，为任务设置前后置依赖，用里程碑标记重要时间点，并设置项目计划和里程碑基线，对比计划与执行偏差、追溯变更细节。跨项目共享同一里程碑对象的具体配置方式，建议在试用或咨询时结合当前版本确认。
