软硬件协同开发时，硬件按阶段推进、周期长，软件按迭代滚动、节奏快，直接排成一张甘特图往往两边都不好用。统一项目计划要统一在共同里程碑、交付物和接口层面，让两条线保留各自节拍，再用依赖关系连接。本文按这一思路说明编制步骤、角色分工和完成检查，偏差跟踪与具体任务排期不在本文展开。
要点总览（TL;DR）
- 统一计划统一在共同里程碑、交付物和接口层面，软硬件两条线保留各自的阶段粒度与滚动周期。
- 先定共同里程碑与交付物框架，再分别编制硬件阶段计划和软件迭代计划，用接口交付物与跨线依赖把两条线连接起来。
- 计划基线、滚动更新规则和变更触发条件要在编制阶段一并确定，避免执行时反复重排。
- 项目负责人统筹框架与基线，硬件、软件负责人各管本线计划，接口/系统负责人确认跨线交付物与依赖。
- 编制完成后按里程碑对应、节奏保留、依赖完整、基线明确、分工到人五项逐条核对，再进入执行。
统一计划先定什么：共同里程碑与交付物框架
统一计划的第一步是确定两条研发线共用的骨架。这个骨架由三部分组成：共同里程碑、交付物清单、里程碑与交付物的对应关系。统一发生在这三部分上，软硬件各自的阶段划分和任务排期仍由各线负责。
共同里程碑应选那些两条线都必须对齐的关键节点，常见的有：系统方案冻结、关键器件或平台选型确认、集成验证、样机试制完成、版本发布或客户交付。里程碑数量不宜过多，以能覆盖跨线交接点为原则。每个里程碑要写明责任线和验收口径，避免出现“完成了但没人确认”的情况。
交付物清单按硬件、软件、接口三类划分。硬件类包括原理图、结构件、样机、测试报告等；软件类包括版本包、接口文档、测试用例与报告等；接口类包括软硬件通信协议、硬件抽象层定义、联调环境说明等。接口类交付物是两条线的连接点，需要单独列出并指定提供方和接收方。
| 里程碑 | 责任线 | 主要交付物 | 验收口径 |
|---|---|---|---|
| 系统方案冻结 | 系统/接口负责人 | 系统方案文档、软硬件接口定义初稿 | 方案评审通过，接口定义双方确认 |
| 硬件样机就绪 | 硬件线 | 样机、硬件测试报告、烧录与调试说明 | 样机通过功能自测，可交付软件联调 |
| 集成验证通过 | 项目负责人 | 联调记录、问题清单、集成测试报告 | 关键用例通过，遗留问题有处理结论 |
| 版本发布 | 项目负责人 | 发布版本包、发布说明、已知问题清单 | 发布评审通过，交付物归档完整 |
这张表是后续所有计划活动的参照。里程碑变更需要走变更规则，交付物增减要同步更新对应关系，保证框架始终和实际计划一致。
软硬件节奏差异怎么落到计划结构上
硬件研发通常按概念、方案、详细设计、样机、小批量等阶段推进，单个阶段可能持续数周到数月，返工成本高，计划偏向一次性锁定加阶段评审。软件研发通常按两周或四周迭代滚动，需求可以在迭代边界调整，计划偏向持续细化。统一框架要容纳这两种粒度，而不是把软件拉成月级阶段、把硬件拆成周级迭代。
具体做法是：在共同里程碑之下，硬件线使用阶段计划，每个阶段列出进入条件、主要活动和退出评审；软件线使用迭代计划，每个迭代关联到最近的共同里程碑，说明本迭代为哪个里程碑提供什么交付物。两条线的滚动周期可以不同，硬件按月或按阶段滚动，软件按迭代滚动，但都要向同一个里程碑汇报进展。
两条线的连接依靠接口交付物和依赖关系。例如软件某个迭代需要硬件提供调试板，就在该迭代中标注对硬件交付物的前置依赖；硬件样机评审需要软件提供基础固件，就在硬件阶段计划中标注对软件版本的前置依赖。依赖要写到具体交付物和日期，不停留在“软硬件配合”这类描述上。
必须对齐的节点包括：接口定义冻结、联调开始、集成验证、版本发布。这些节点上两条线要共同确认交付物状态。可以各自滚动的部分包括：硬件内部的设计评审安排、软件内部的迭代内容调整。区分标准是是否影响另一条线的输入，影响则对齐，不影响则各自管理。
编制步骤：从框架到可执行计划
以下五步按顺序执行，每步给出输入、动作、输出和完成标志。前一步的输出是后一步的输入，跳步容易导致框架和计划脱节。
步骤一：确定共同里程碑与交付物
输入是产品目标、系统方案初稿和两条线的初步范围。动作是召集软硬件负责人和系统负责人，列出跨线关键节点，为每个节点定义交付物、责任线和验收口径。输出是共同里程碑与交付物框架表。完成标志是所有里程碑都有明确责任人和验收口径，接口类交付物已单独列出。
步骤二：分别编制软硬件工作分解与阶段计划
输入是框架表和各线范围说明。动作是硬件线按阶段分解工作，软件线按迭代分解工作，各自标注与共同里程碑的对应关系。输出是硬件阶段计划和软件迭代计划。完成标志是每条线的工作都能追溯到至少一个共同里程碑，没有孤立任务。
步骤三：标注接口交付物与跨线依赖
输入是两条线的分解结果和接口清单。动作是逐项确认接口交付物的提供方、接收方、交付时间和验收方式，在计划中建立前后置依赖。输出是带依赖标注的统一计划。完成标志是所有跨线依赖都有明确的交付物和日期，双方负责人确认。
步骤四：设定计划基线与滚动更新规则
输入是确认后的统一计划。动作是确定基线范围，明确哪些内容纳入基线、哪些允许滚动细化，规定滚动更新的周期和审批方式。输出是计划基线和更新规则说明。完成标志是基线版本已归档，两条线都清楚自己的滚动权限。
步骤五：明确变更与重排的触发条件
输入是基线和更新规则。动作是列出需要走变更的触发条件，例如里程碑日期调整、接口定义变更、关键交付物范围变化，并规定变更的提出、评估和确认流程。输出是变更规则清单。完成标志是触发条件和处理流程已写入计划文档，相关角色知悉。
在工具承载上，可以用 ONES 的项目计划创建工作分解结构，按交付物或项目阶段分解计划和工作；为任务设置前后置依赖，用里程碑标记集成验证、样机、发布等关键节点；设置计划和里程碑基线，便于后续对比计划与执行。项目经理还可以在项目计划中关联迭代和研发任务，让软件迭代与硬件阶段挂在同一项目下查看。
角色分工与各阶段交付物
统一计划由项目负责人统筹，但编制不能由一方包办。硬件负责人和软件负责人分别对本线计划的合理性负责，接口或系统负责人对跨线交付物和依赖的准确性负责。各角色在四个关键动作中分工如下。
| 角色 | 里程碑确认 | 分解与计划编制 | 依赖标注 | 基线确认 | 主要交付物 |
|---|---|---|---|---|---|
| 项目负责人 | 组织确认，拍板里程碑和验收口径 | 审核两条线计划与框架的一致性 | 协调争议依赖，确认跨线承诺 | 批准基线，发布变更规则 | 统一计划文档、基线记录、变更规则 |
| 硬件负责人 | 确认硬件相关里程碑和交付物 | 编制硬件阶段计划和工作分解 | 提出对软件交付物的依赖需求 | 确认本线基线内容 | 硬件阶段计划、硬件交付物清单 |
| 软件负责人 | 确认软件相关里程碑和交付物 | 编制软件迭代计划和版本安排 | 提出对硬件交付物的依赖需求 | 确认本线基线内容 | 软件迭代计划、版本交付清单 |
| 接口/系统负责人 | 提供接口相关里程碑建议 | 定义接口交付物和验收方式 | 审核跨线依赖的完整性和合理性 | 确认接口交付物纳入基线 | 接口交付物清单、依赖关系说明 |
计划文档由项目负责人维护主版本，两条线的分计划由各自负责人维护并同步到主计划。评审参与方至少包括项目负责人、两条线负责人和接口负责人；涉及验收口径的里程碑，应邀请测试或质量角色参加。评审结论要记录在计划文档中，作为基线确认的依据。
示例：一款软硬件协同产品的统一计划骨架
以下为演示情景，用于说明计划骨架的组织方式，不代表任何真实项目。假设某团队开发一款带嵌入式软件的智能终端，硬件线周期约六个月，软件线按三周迭代推进，两条线并行开发。
共同里程碑设为四个：系统方案冻结、硬件样机就绪、集成验证通过、版本发布。硬件线在系统方案冻结后进入详细设计阶段，约三个月后完成样机；软件线在方案冻结后开始迭代开发，前几个迭代先基于开发板推进，样机就绪后转入真机联调。
| 共同里程碑 | 硬件线对应阶段 | 软件线对应迭代 | 接口交付物与依赖 |
|---|---|---|---|
| 系统方案冻结 | 方案设计完成 | 迭代一启动 | 接口定义初稿，双方确认后冻结 |
| 硬件样机就绪 | 样机试制完成 | 迭代四至五 | 硬件提供样机和调试说明；软件提供基础固件用于样机自测 |
| 集成验证通过 | 样机问题修复 | 迭代六至七 | 软件依赖样机稳定版本；硬件依赖软件联调问题清单 |
| 版本发布 | 小批量准备 | 发布迭代 | 发布版本包与硬件配置清单对应 |
依赖标注写到具体交付物：软件迭代四标注“前置依赖：硬件样机及调试说明，计划日期为样机评审后三个工作日”；硬件样机自测标注“前置依赖：软件基础固件版本，计划日期为迭代三结束”。滚动更新上，软件迭代内容按迭代边界细化，硬件阶段计划按月更新进展；里程碑日期变更和接口定义变更走变更规则，由项目负责人组织评估后更新基线。
计划编制完成检查
计划编制完成后，用以下清单逐项核对。全部满足再进入执行阶段，未满足的项要回到对应步骤补齐。
- 每个共同里程碑都有对应的交付物清单，交付物都有责任线和验收口径，没有只有日期没有交付内容的里程碑。
- 硬件阶段计划和软件迭代计划都保留各自粒度，没有为了形式统一把软件拆成月级阶段或把硬件拆成周级迭代。
- 接口类交付物单独列出，提供方、接收方、交付时间和验收方式齐全。
- 所有跨线依赖都写到具体交付物和日期，双方负责人已确认。
- 计划基线已确定并归档，滚动更新的范围和周期有书面规则。
- 变更触发条件明确，变更提出、评估、确认的流程和责任人已写入计划文档。
- 项目负责人、硬件负责人、软件负责人、接口负责人的职责和交付物已落实到人，评审参与方已确认。
这份清单同时可以作为计划评审的检查表。评审通过后，计划进入执行，后续的进度偏差跟踪和具体任务排期按相应管理流程处理。
常见问题
软硬件两条线的里程碑数量怎么控制？
以覆盖跨线交接点为原则，通常保留系统方案冻结、样机就绪、集成验证、版本发布这类节点即可。里程碑过多会让两条线频繁对齐，反而拖慢各自节奏；过少则跨线交接点缺少共同确认。每个里程碑都要写明责任线和验收口径，只有日期没有交付内容的节点应合并或删除。
硬件阶段计划已经锁定，软件迭代还能调整内容吗？
可以，前提是调整不影响对硬件的接口交付承诺。软件迭代内容在迭代边界内细化属于滚动范围，由软件负责人管理；一旦涉及接口交付物的时间、范围或验收方式变化，就进入变更流程，由项目负责人组织评估并更新基线。判断标准是这次调整是否改变另一条线的输入。
接口交付物由谁定义、谁确认？
接口或系统负责人负责定义接口交付物的内容和验收方式，提供方与接收方负责人共同确认。确认内容包括交付时间、版本对应关系和验收标准。确认结果写入统一计划并纳入基线，后续接口定义变更按变更规则处理。
计划编制完成后，偏差跟踪放在哪里做？
偏差跟踪与纠偏属于项目进度管理范围，具体任务的排期与依赖排布属于任务排期与依赖管理范围。本文的编制检查清单只用于判断计划是否具备进入执行的条件，评审通过后按相应管理流程跟踪进展。
没有专门的项目管理工具，能编制统一计划吗？
可以先用表格承载共同里程碑与交付物框架、两条线的阶段计划和依赖标注，关键是框架、依赖和基线规则写清楚。项目规模变大、跨线依赖增多后，再考虑用工具承载工作分解、前后置依赖、里程碑和基线，减少手工同步的成本。
