软硬件协同项目计划模板需要同时管住两条线：一条是硬件、软件、结构、测试之间的接口交付，另一条是双方必须共同确认的评审节点。建议用四张表搭起骨架——里程碑与交付物表、接口依赖台账、联合评审节点表、变更与问题跟踪表。接口依赖按“编号—名称—双方责任人—交付形态—提供时间—就绪时间—验证方式—状态”记录，联合评审按“节点—触发条件—参与角色—评审输入—通过标准—结论与待办”记录。下文先给可直接复制的空白表，再说明字段口径、必填取舍、完整填写示例与维护方法；ONES可用于承载计划分解、任务依赖与评审记录，文中在相应位置简要说明。
要点总览（TL;DR）
- 模板由四张表组成：里程碑与交付物表、接口依赖台账、联合评审节点表、变更与问题跟踪表，通过编号互相引用。
- 接口依赖台账按“接口编号—接口名称—双方责任人—交付形态—提供方交付时间—接收方就绪时间—验证方式—状态”记录，双方责任人和两个时间点属于必填。
- 联合评审节点表按“评审节点—触发条件—参与角色—评审输入—通过标准—结论与待办”记录，触发条件与通过标准缺失会让评审难以追溯。
- 小型项目可减少里程碑数量、合并评审场次，但每个接口的唯一编号、双方责任人与交付/就绪时间，每个评审的触发条件与通过标准应保留。
- 模板需绑定更新时点：接口台账每周例会后更新，评审结论当日回写，变更关闭时同步接口状态，模板本身保留版本记录。
可复制空白模板：四张表组成计划骨架
四张表各有分工：里程碑与交付物表回答“什么时候交出什么”，接口依赖台账回答“谁在什么时候把什么交给谁”，联合评审节点表回答“哪些时点必须双方共同确认”，变更与问题跟踪表回答“计划变化和遗留问题如何闭环”。四张表通过编号互相引用，避免同一件事在多处重复描述。
表1 里程碑与交付物表
| 里程碑编号 | 里程碑名称 | 计划日期 | 交付物 | 交付物形态 | 负责人 | 验收方 | 关联接口编号 | 关联评审编号 | 状态 |
|---|---|---|---|---|---|---|---|---|---|
| M-01 | |||||||||
| M-02 |
表2 接口依赖台账
| 接口编号 | 接口名称 | 硬件责任人 | 软件责任人 | 交付形态 | 提供方交付时间 | 接收方就绪时间 | 验证方式 | 关联里程碑 | 状态 |
|---|---|---|---|---|---|---|---|---|---|
| IF-01 | |||||||||
| IF-02 |
表3 联合评审节点表
| 评审编号 | 评审节点 | 触发条件 | 参与角色 | 评审输入 | 通过标准 | 结论与待办 | 关联接口编号 | 计划日期 |
|---|---|---|---|---|---|---|---|---|
| RV-01 | ||||||||
| RV-02 |
表4 变更与问题跟踪表
| 编号 | 类型（变更/问题） | 描述 | 提出人 | 影响接口/评审 | 处理责任人 | 计划关闭时间 | 状态 | 关闭依据 |
|---|---|---|---|---|---|---|---|---|
| CR-01 | ||||||||
| ISS-01 |
引用关系保持单向清晰：接口台账的“关联里程碑”指向表1的里程碑编号，评审表的“关联接口编号”指向表2的接口编号，变更与问题表通过“影响接口/评审”回指前两张表。这样从任一接口出发，可以查到它支撑哪个里程碑、在哪个评审节点被确认、有哪些未关闭的变更或问题。
字段说明：每个字段记录什么、由谁维护
字段口径统一，模板才能被不同团队一致使用。以下按表说明含义与维护角色，维护角色可按团队实际岗位替换，但同一字段应固定由一方主责。
接口依赖台账字段
- 接口编号：全项目唯一，建议按“IF-两位序号”编排，一经分配不再复用。
- 接口名称：用双方都能识别的业务或技术名称，避免只写“数据交互”这类笼统表述。
- 硬件责任人、软件责任人：各填一名主责人，负责本侧交付与确认，不填团队名。
- 交付形态：写明对方实际收到的东西，如接口文档、通信协议、样机、固件版本、测试数据。
- 提供方交付时间、接收方就绪时间：前者是交付方承诺完成的时间，后者是接收方具备联调条件的时间，两者之间留出集成缓冲。
- 验证方式：写清如何确认接口可用，如联调测试、信号测量、协议一致性检查。
- 状态：建议用“未开始、进行中、已交付待验证、已验证、阻塞”五档。
联合评审节点字段
- 评审节点：用阶段动作命名，如“接口定义评审”“样机联调准入评审”“小批量转产评审”。
- 触发条件：写可判断的条件，如“接口文档双方签署完成”“样机通过自测”。
- 参与角色：列明硬件、软件、测试、质量等必须到场的角色，而非具体人名。
- 评审输入：列出会前必须齐备的材料，与接口台账、里程碑交付物对应。
- 通过标准：写可判定的结论条件，避免“基本满足”这类模糊表述。
- 结论与待办：评审后填写通过、有条件通过或不通过，并列出待办与责任人。
里程碑与交付物、变更与问题字段
里程碑表重点在“交付物形态”和“验收方”，前者说明交付物是文档、样机还是版本，后者明确谁有权确认完成。变更与问题表重点在“影响接口/评审”和“关闭依据”，前者保证变更能追溯到具体接口或评审节点，后者要求关闭时写明验证结果或评审结论，避免口头关闭。
维护角色建议：接口台账由项目计划负责人汇总、双方责任人各自更新本侧字段；评审表由质量或项目管理人员维护，结论由评审主持人确认后回写；里程碑表由项目经理维护；变更与问题表由提出人和处理责任人共同更新，项目经理定期核对状态。
必填与选填：哪些字段缺失会导致计划不可执行
必填字段的判断标准是：缺失后无法判断“谁、在什么时间、交付什么、由谁确认”。满足这条的字段应设为必填，其余可按项目复杂度裁剪。
| 表格 | 必填字段 | 选填字段 | 缺失必填字段的风险 |
|---|---|---|---|
| 接口依赖台账 | 接口编号、接口名称、硬件责任人、软件责任人、交付形态、提供方交付时间、接收方就绪时间、验证方式、状态 | 关联里程碑、备注、接口版本号 | 无法确定交付责任与联调时点，接口延期只能在联调阶段暴露 |
| 联合评审节点表 | 评审编号、评审节点、触发条件、参与角色、评审输入、通过标准 | 计划日期、关联接口编号、会议纪要链接 | 评审变成临时召集，缺少输入和判定标准，结论难以追溯 |
| 里程碑与交付物表 | 里程碑编号、里程碑名称、计划日期、交付物、负责人、验收方 | 交付物形态、关联接口编号、关联评审编号 | 无法判断阶段完成与否，交付物无人验收 |
| 变更与问题跟踪表 | 编号、类型、描述、处理责任人、状态 | 影响接口/评审、计划关闭时间、关闭依据 | 变更和问题散落各处，接口状态与实际不一致 |
裁剪原则：小型项目可减少里程碑数量、合并评审节点，但接口台账的双方责任人与两个时间点、评审表的触发条件与通过标准应保留。裁剪后需保留的最小集合是——每个接口有唯一编号、双方责任人和交付/就绪时间；每个联合评审有触发条件、参与角色和通过标准；每个里程碑有交付物和验收方。只要这组信息完整，计划就具备基本可执行性。
填写示例：一条接口依赖与一个联合评审节点
以下为演示情景，接口编号、时间与角色均需按实际项目替换。
接口依赖填写示例
| 字段 | 填写内容 |
|---|---|
| 接口编号 | IF-03 |
| 接口名称 | 主控板与上位机通信协议 |
| 硬件责任人 | 硬件工程师A |
| 软件责任人 | 嵌入式工程师B |
| 交付形态 | 通信协议文档V1.0及寄存器说明 |
| 提供方交付时间 | 第6周周五 |
| 接收方就绪时间 | 第7周周三 |
| 验证方式 | 协议一致性检查加联调测试用例通过 |
| 关联里程碑 | M-02 样机联调启动 |
| 状态 | 进行中 |
联合评审节点填写示例
| 字段 | 填写内容 |
|---|---|
| 评审编号 | RV-02 |
| 评审节点 | 接口定义评审 |
| 触发条件 | IF-03协议文档提交且双方责任人确认可评审 |
| 参与角色 | 硬件负责人、软件负责人、测试负责人、项目经理 |
| 评审输入 | 通信协议文档V1.0、寄存器说明、接口台账IF-03记录 |
| 通过标准 | 双方对协议字段、时序和异常处理无未决分歧，测试方确认可据此编写用例 |
| 结论与待办 | 有条件通过：补充掉电重连时序说明，由硬件工程师A在第7周周二前完成 |
| 关联接口编号 | IF-03 |
| 计划日期 | 第6周周四 |
两表的引用关系体现在：评审RV-02的触发条件直接引用接口IF-03的交付状态，评审输入包含接口台账记录，评审结论产生的待办又会影响IF-03能否按时进入“已验证”状态。该接口同时关联里程碑M-02，说明接口验证结果决定样机联调能否按期启动。
填写后的检查要点：接口编号与评审表中的引用编号一致；提供方交付时间早于接收方就绪时间；评审计划日期落在接口交付之后、里程碑之前；结论中的待办有责任人和完成时间；状态与评审结论不矛盾。
调整与维护方法：按项目规模裁剪并持续更新
模板的价值在于持续维护，而非一次性填完。建议把更新动作绑定到固定时点，让台账状态与项目实际同步。
按项目规模裁剪
接口数量少、双方在同一地点协作的项目，可保留四张表但精简行数，评审节点合并为接口定义评审和联调准入评审两个。跨团队、跨地点或涉及多家供应商的项目，应增加接口版本号、供应商名称等字段，并把评审节点细化到样机、小批量等阶段。裁剪时优先减少选填字段和评审场次，不删减必填字段。
更新时点与回写方式
- 接口台账：每周计划例会后更新状态；接口交付或变更时当日更新；联调开始前核对两个时间点是否仍成立。
- 联合评审节点表：评审前确认触发条件和输入齐备；评审后由主持人确认结论，项目管理人员当日回写结论与待办。
- 变更与问题跟踪：变更提出时登记并标注影响的接口或评审编号；关闭时填写关闭依据，并同步更新接口台账状态。
- 里程碑表：里程碑达成或计划日期调整时更新，并检查关联接口和评审是否随之调整。
在工具承载上，ONES可用「项目计划」按交付物或阶段分解工作并设置任务前后置依赖，用里程碑标记关键决策点，并支持设置计划与里程碑基线、对比计划与执行偏差；接口台账和评审记录可作为项目文档沉淀，ONES Wiki支持页面组关联项目、页面模板与版本记录，便于模板复用和结论追溯。具体字段配置需团队按实际流程定义。
版本管理建议
模板本身应有版本号，字段增删或口径调整时记录变更说明和生效日期；每个项目使用模板时复制一份项目实例，保留模板原版不动。项目结束后复盘一次，把反复出问题的字段或评审节点补充进模板下一版，形成可复用的组织资产。
常见问题
接口的提供方交付时间和接收方就绪时间应该怎么定？
提供方交付时间是交付方承诺完成交付的时间，接收方就绪时间是接收方具备联调或使用条件的时间。两者之间应留出集成缓冲，用于文档消化、环境准备和初步验证。填写时先由双方责任人各自给出本侧时间，再由项目计划负责人核对先后顺序；联调开始前需重新确认这两个时间是否仍然成立，接口发生变更时当日更新。
联合评审节点应该设多少个，小型项目能否合并？
评审节点数量取决于接口数量和阶段划分，没有统一标准。常见做法是至少保留接口定义评审和联调准入评审两个节点，前者确认双方对协议和交付形态的理解一致，后者确认接口具备联调条件。小型项目可以合并评审场次，但每个保留的评审仍需写清触发条件、参与角色和通过标准，否则评审容易变成临时召集，结论难以追溯。
接口依赖台账和联合评审节点表之间如何联动？
两张表通过接口编号关联。评审表的“关联接口编号”指向接口台账中的记录，评审的触发条件通常引用接口的交付状态，评审输入包含接口台账记录，评审结论产生的待办又会影响接口能否进入“已验证”状态。维护时建议评审主持人确认结论后，由项目管理人员当日回写评审表，并同步检查接口台账状态是否与结论一致。
模板裁剪后，最少要保留哪些信息才算可执行？
裁剪后需保留的最小集合是：每个接口有唯一编号、双方责任人和提供方交付时间、接收方就绪时间；每个联合评审有触发条件、参与角色和通过标准；每个里程碑有交付物和验收方。满足这组信息，团队就能判断谁在什么时间交付什么、由谁确认。选填字段如接口版本号、会议纪要链接、计划关闭时间可按项目复杂度取舍。
模板在项目进行中如何持续维护，避免台账与实际脱节？
把更新动作绑定到固定时点：接口台账在每周计划例会后更新状态，接口交付或变更时当日更新；评审表在评审前确认输入齐备，评审后当日回写结论与待办；变更与问题关闭时填写关闭依据并同步接口状态；里程碑达成或日期调整时检查关联接口和评审是否随之调整。模板本身保留版本号和变更说明，每个项目复制一份实例使用，原版模板不动。
