软硬件协同项目的计划难点，往往在于硬件、固件、结构、测试几条线并行推进，里程碑和交付物却各记各的。这份模板以“阶段—里程碑—交付物—接口依赖—联合评审”为主线，把六个阶段的里程碑、每个节点应交付什么、软硬件双方约定什么、何时联合评审放在同一张表里，可直接复制填写，也可按产品复杂度裁剪。
要点总览（TL;DR）
- 模板以“阶段—里程碑—交付物—接口依赖—联合评审”为主线，包含阶段里程碑计划表、接口依赖登记表、联合评审节点表三张可复制空白表。
- 里程碑按概念与需求、方案与架构、详细设计、样机与联调、验证与试产、量产发布六个阶段设置，每个里程碑绑定可验收的交付物，同一里程碑多个交付物拆行填写。
- 里程碑名称、计划日期、责任人、验收标准，以及交付物名称、版本、验收方式，接口提供方、接收方、内容、约定时间均为必填，缺失会导致计划无法跟踪和验收。
- 联合评审固定为需求评审、架构与接口评审、设计冻结评审、联调准入评审、转产评审五个关口，评审结论与遗留问题需回填并写明关闭条件。
- 维护规则是变更走审批、版本留记录、接口变更双方同步、评审结论闭环，建议每周对齐接口状态、每月复核整体计划。
可复制空白模板：软硬件协同项目计划表
模板由三张表组成：主计划表承载阶段、里程碑与交付物；接口依赖登记表单独记录软硬件双方的输入输出；联合评审节点表固定关键评审关口。三张表通过“里程碑编号”关联，填写时先定主计划，再补接口与评审。
表一：阶段里程碑计划表
| 里程碑编号 | 阶段 | 里程碑名称 | 验收标准 | 计划日期 | 责任人 | 交付物名称 | 交付物类型 | 版本 | 存放位置 | 验收方式 | 关联评审编号 | 风险备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| M01 | 概念与需求 | R01 | ||||||||||
| M02 | 方案与架构 | R02 | ||||||||||
| M03 | 详细设计 | R03 | ||||||||||
| M04 | 样机与联调 | R04 | ||||||||||
| M05 | 验证与试产 | R05 | ||||||||||
| M06 | 量产发布 |
填写粒度：一行对应一个里程碑；同一里程碑下有多个交付物时，拆成多行，里程碑编号重复填写，交付物名称逐行区分。阶段列可按项目裁剪，编号保持连续便于引用。
表二：接口依赖登记表
| 依赖编号 | 关联里程碑 | 接口内容 | 提供方 | 接收方 | 约定时间 | 交付形式 | 状态 | 变更记录 |
|---|---|---|---|---|---|---|---|---|
| I01 | M03 | |||||||
| I02 | M04 |
接口内容写清具体对象，例如“主板安装孔位与结构件装配尺寸”“通信协议帧格式”“固件升级接口时序”。提供方与接收方填角色或姓名，约定时间精确到日期，状态可用“待提供／已提供／已确认／已变更”。
表三：联合评审节点表
| 评审编号 | 评审类型 | 关联里程碑 | 参与角色 | 准入条件 | 计划日期 | 结论 | 遗留问题与关闭条件 |
|---|---|---|---|---|---|---|---|
| R01 | 需求评审 | M01 | |||||
| R02 | 架构与接口评审 | M02 | |||||
| R03 | 设计冻结评审 | M03 | |||||
| R04 | 联调准入评审 | M04 | |||||
| R05 | 转产评审 | M05 |
五个评审节点是软硬件协同的固定关口：需求评审确认双方对功能与指标的理解一致；架构与接口评审锁定软硬件分工与接口定义；设计冻结评审后原理图、结构图、固件架构进入受控状态；联调准入评审确认样机、固件、测试环境齐备；转产评审确认试产问题关闭、量产条件具备。
字段说明：每一列记录什么、由谁维护
字段口径统一，模板才能在多人协作中保持可比。下表逐列说明含义、填写口径与维护角色，维护角色按常见分工给出，团队可按实际岗位调整。
| 字段 | 含义 | 填写口径 | 维护角色 |
|---|---|---|---|
| 阶段 | 里程碑所属的项目阶段 | 从概念与需求、方案与架构、详细设计、样机与联调、验证与试产、量产发布中选取；裁剪时保留阶段名称，不合并语义不同的阶段 | 项目经理 |
| 里程碑名称 | 该阶段的关键时间点或决策点 | 用“动词＋对象”描述可判定的状态，如“需求基线确认”“设计冻结” | 项目经理 |
| 验收标准 | 判定里程碑达成的条件 | 写成可核验的条件，如“需求文档通过评审且无未关闭的高优先级问题” | 项目经理与各线负责人共同确认 |
| 计划日期 | 里程碑预计达成日期 | 填具体日期；跨月长周期里程碑可加注目标周 | 项目经理 |
| 责任人 | 对该里程碑结果负责的人 | 填单一责任人，避免填团队名 | 项目经理指定 |
| 交付物名称 | 该里程碑应产出的具体成果 | 一名一物，如“接口控制文档”“固件V0.9版本”“联调记录” | 交付物所属线负责人 |
| 交付物类型 | 交付物的类别 | 可用文档、图纸、代码与固件、测试报告、记录等分类 | 交付物所属线负责人 |
| 版本 | 交付物的当前版本标识 | 与存放位置中的实际文件版本一致 | 交付物所属线负责人 |
| 存放位置 | 交付物的归档位置 | 填目录路径或文档库位置，保证他人可检索 | 交付物所属线负责人 |
| 验收方式 | 确认交付物合格的手段 | 可用评审、测试通过、样机验证、签核等 | 接收方与责任人约定 |
| 接口内容 | 软硬件双方需要交换的具体对象 | 写到可核对的粒度，避免只写“硬件资料” | 提供方填写，接收方确认 |
| 提供方／接收方 | 接口输出的责任方与使用方 | 填角色或姓名，双方均需可见 | 项目经理登记，双方确认 |
| 约定时间 | 接口交付的时间承诺 | 填日期，与关联里程碑的计划日期保持逻辑先后 | 提供方承诺，项目经理跟踪 |
| 变更记录 | 接口内容或时间的调整痕迹 | 记录变更日期、变更内容、确认人 | 项目经理 |
| 评审类型 | 联合评审的类别 | 按五类固定评审填写，新增评审另起编号 | 项目经理 |
| 参与角色 | 必须到场的评审角色 | 列出硬件、固件、结构、测试、质量、采购等必要角色 | 项目经理 |
| 准入条件 | 允许召开评审的前置条件 | 写成可检查的清单，如“接口控制文档已发布且双方确认” | 评审组织者 |
| 结论 | 评审的最终判定 | 通过、有条件通过、不通过三选一，附日期 | 评审组织者 |
必填与选填：哪些字段缺失会导致计划不可用
必填字段决定计划能否被跟踪和验收。缺失里程碑名称、计划日期、责任人、验收标准中的任何一项，该行就无法判断“谁在什么时候达成什么”，计划失去执行意义；交付物缺名称、版本或验收方式，交付就无法核对；接口依赖缺提供方、接收方、接口内容或约定时间，双方就无法对齐，联调阶段容易出现等待和返工。
| 字段 | 必填／选填 | 缺失后果 |
|---|---|---|
| 里程碑名称 | 必填 | 无法识别节点，后续引用和评审关联失效 |
| 计划日期 | 必填 | 无法排定节奏，也无法判断延期 |
| 责任人 | 必填 | 无人对结果负责，问题无人推动 |
| 验收标准 | 必填 | 达成与否靠口头判断，评审缺乏依据 |
| 交付物名称 | 必填 | 里程碑没有可检查的产出 |
| 交付物版本 | 必填 | 无法区分新旧文件，易误用过期版本 |
| 验收方式 | 必填 | 交付物是否合格无判定手段 |
| 接口提供方、接收方 | 必填 | 接口无人认领，责任边界不清 |
| 接口内容 | 必填 | 双方对交换对象理解不一致 |
| 约定时间 | 必填 | 接口交付无时间约束，联调排期失真 |
| 交付物类型 | 选填 | 影响检索与统计，不影响执行 |
| 存放位置 | 选填（建议填写） | 查找成本上升，交付物仍可交付 |
| 风险备注 | 选填 | 风险信息缺失，可在例会上补充 |
| 参考文档链接 | 选填 | 背景资料缺省，不影响主计划 |
| 供应商信息 | 选填 | 涉及外购件或外协时建议填写 |
填写示例：一个软硬件协同项目的完整计划片段
以下为演示情景：一款带固件的智能硬件产品，硬件团队负责主板与结构，固件团队负责嵌入式软件，测试团队负责整机验证。示例只展示片段，实际项目按表一逐行展开。
里程碑与交付物示例
| 里程碑编号 | 阶段 | 里程碑名称 | 验收标准 | 计划日期 | 责任人 | 交付物名称 | 类型 | 版本 | 验收方式 |
|---|---|---|---|---|---|---|---|---|---|
| M01 | 概念与需求 | 需求基线确认 | 产品需求与软硬件分工说明通过评审，无未关闭的高优先级问题 | 第4周周五 | 产品负责人 | 产品需求规格说明书 | 文档 | V1.0 | 需求评审通过 |
| M02 | 方案与架构 | 架构与接口定义完成 | 软硬件接口控制文档双方签字确认 | 第8周周五 | 系统架构师 | 接口控制文档 | 文档 | V1.0 | 架构与接口评审通过 |
| M03 | 详细设计 | 设计冻结 | 原理图、结构图、固件架构设计完成并受控 | 第14周周五 | 硬件负责人 | 主板原理图 | 图纸 | V1.2 | 设计冻结评审通过 |
| M03 | 详细设计 | 设计冻结 | 同上 | 第14周周五 | 固件负责人 | 固件架构设计说明 | 文档 | V1.0 | 设计冻结评审通过 |
| M04 | 样机与联调 | 联调完成 | 样机与固件完成主要功能联调，联调记录无阻塞问题 | 第20周周五 | 测试负责人 | 联调记录 | 记录 | V1.0 | 联调准入评审后验证 |
接口依赖示例
| 依赖编号 | 关联里程碑 | 接口内容 | 提供方 | 接收方 | 约定时间 | 状态 |
|---|---|---|---|---|---|---|
| I01 | M03 | 结构件与主板装配尺寸、安装孔位 | 结构工程师 | 硬件工程师 | 第12周周三 | 已确认 |
| I02 | M04 | 固件与主板的通信协议帧格式及升级接口时序 | 固件工程师 | 硬件工程师 | 第16周周三 | 待提供 |
联合评审节点示例
| 评审编号 | 评审类型 | 关联里程碑 | 参与角色 | 准入条件 | 结论 |
|---|---|---|---|---|---|
| R03 | 设计冻结评审 | M03 | 硬件、固件、结构、测试、质量 | 原理图、结构图、固件架构说明已发布；接口控制文档V1.0已确认 | 有条件通过，遗留两项结构公差问题，关闭后冻结生效 |
示例中同一里程碑M03出现两行，分别对应硬件与固件的交付物，这是“一交付物一行”的填写方式；接口I01的时间早于M03，保证设计冻结前尺寸已对齐。
调整与维护方法：模板随项目阶段如何更新
计划表一旦冻结就长期不改，会迅速与实际脱节；频繁改动又不留痕，则无法追溯。维护规则的核心是：变更走审批、版本有记录、接口变更双方同步、评审结论闭环、定期复核。
- 里程碑变更：调整计划日期或验收标准时，由责任人提出，项目经理审批；在表中保留原值并新增变更记录行，注明变更日期、原因与批准人。涉及关键节点的变更同步告知评审参与角色。
- 交付物版本升级：交付物更新后同步修改版本号与存放位置，旧版本保留归档；验收方式若随之调整，在验收方式列注明新口径。
- 接口依赖变更：接口内容或约定时间调整时，提供方在变更记录列登记，接收方确认；影响联调节奏的，同步更新关联里程碑的计划日期。
- 评审结论回填：评审结束后三个工作日内填写结论与遗留问题；遗留问题逐条写明关闭条件与责任人，全部关闭后评审节点标记为关闭。
- 定期复核：建议每周例会对齐接口状态与临近里程碑，每月复核一次整体计划与评审关闭情况；样机与联调阶段可加密到每周两次。
变更记录建议至少包含四个字段：变更日期、变更对象（里程碑编号或依赖编号）、变更前后内容、确认人。这样在复盘时能还原每一次调整的来龙去脉。
当计划表从个人表格转为团队共用时，可以把里程碑和交付物作为工作项管理，用前后置依赖表达接口与任务的先后关系，用里程碑标记关键决策点，并通过基线对比查看计划与执行的变化。ONES 的项目计划支持按目标、交付物或项目阶段分解工作，为任务设置前后置依赖并用里程碑标记重要时间点，也支持设置计划和里程碑基线以对比偏差、追溯变更细节；在深圳农商行的案例中，团队依托瀑布项目模版对关键里程碑和交付物进行规范化管理。这些能力承载的是计划表的协作与留痕，模板本身的字段口径仍按本文三张表执行。
常见问题
项目规模较小，六个阶段和五个评审节点可以裁剪吗？
可以裁剪，但裁剪的是阶段数量和评审频次，字段口径建议保留。阶段列可按产品复杂度合并，例如把“验证与试产”与“量产发布”合并为一个阶段，里程碑编号保持连续便于引用。评审节点方面，需求评审、设计冻结评审、转产评审通常是不可省略的关口；架构与接口评审、联调准入评审在接口少、软硬件团队同地协作的项目中可以合并召开，但合并后仍需在评审表中记录参与角色与结论。裁剪时注意不要合并语义不同的阶段，否则里程碑的验收标准会变得模糊。
接口依赖登记表和主计划表是什么关系，需要重复填写吗？
两张表通过“关联里程碑”字段关联，不需要重复填写同一信息。主计划表记录里程碑层面的验收标准与交付物；接口依赖登记表记录软硬件双方交换的具体对象、提供方、接收方与约定时间。一条接口依赖通常挂在它最直接影响的那个里程碑下，例如结构件与主板装配尺寸挂在设计冻结里程碑。接口内容变更时，在接口表的变更记录列登记，若影响里程碑计划日期，再同步更新主计划表对应行。这样接口的细粒度信息集中在一处，主计划表保持可读。
交付物版本升级后，旧版本还需要保留吗？
建议保留。交付物版本升级时，同步修改版本号与存放位置，旧版本归档而不是覆盖，原因有两个：一是评审和验收需要还原当时依据的版本，二是复盘时能追溯设计演进过程。如果交付物已通过评审并进入受控状态，版本升级应作为一次变更处理，在变更记录中写明升级原因与确认人。验收方式若随版本调整，在验收方式列注明新口径，避免后续核对时口径不一致。
评审结论为“有条件通过”时，里程碑算达成吗？
取决于遗留问题的性质与关闭条件。模板中“有条件通过”应逐条写明遗留问题、责任人与关闭条件；若遗留问题不影响下一阶段启动，里程碑可标记为达成并附带跟踪项；若遗留问题涉及接口定义或安全指标等关键项，建议在关闭后再判定里程碑达成，或明确下一阶段可并行开展的范围。无论哪种处理，评审结论与关闭条件都要回填到评审表，全部关闭后将评审节点标记为关闭，避免“有条件通过”长期悬空。
计划表从个人表格转为团队共用时，有哪些衔接难点？
主要难点在权限、留痕和口径统一三处。权限上，需要明确谁能修改里程碑日期、谁能确认接口状态，避免多人同时改动造成版本混乱。留痕上，变更记录字段要真正填写，而不是只改数值不留痕迹。口径上，交付物命名、版本标识、验收方式需要团队统一约定，否则统计和检索会失真。若使用协作工具承载，可以把里程碑和交付物作为工作项管理，用前后置依赖表达接口与任务的先后关系，用里程碑标记关键决策点，并通过基线对比查看计划与执行的变化。ONES 的项目计划支持按目标、交付物或项目阶段分解工作，为任务设置前后置依赖并用里程碑标记重要时间点，也支持设置计划和里程碑基线以对比偏差、追溯变更细节；在深圳农商行的案例中，团队依托瀑布项目模版对关键里程碑和交付物进行规范化管理。工具承载的是协作与留痕，字段口径仍按本文三张表执行。
