软硬件混合项目的协同进度检查点，应设在软硬件互相等待的交付物交接处，按“接口依赖”而不是单一专业线的完成度来设。具体做法是：先识别双方互相等待的样机、固件、接口文档和测试环境，再为每个交付物写清输入、判定标准、责任人和证据，把检查点放在交接前、交接时、交接后三个位置。本文给出检查点位置对应表、定义字段、指标口径、角色分工和一个完整示例，最后附验收清单。
要点总览（TL;DR）
- 检查点应设在软硬件互相等待的交付物交接处，按交接前、交接时、交接后三段设点，与各专业线内部里程碑并行运行。
- 每个检查点写清输入、判定标准、责任人、输出与证据四类要素，判定标准要可勾选、可举证。
- 协同指标只回答依赖是否按期闭合，常用依赖按期闭合率、交接返工次数、检查点阻断时长和下游启动偏差，按周或双周取值。
- 交付方声明版本与已知问题，接收方实际验证可用性，意见不一致时由裁决人给出放行或阻断结论并记录理由。
- 体系运行一轮后复盘，调整反复出问题的交付物判定标准，合并或取消没有实际确认动作的检查点。
检查点先落在软硬件依赖交接上
软硬件混合项目的进度风险，多数出现在一方等另一方交付的环节：软件等硬件样机才能联调，硬件等固件版本才能验证功能，测试等接口文档和测试环境才能开始用例。这些等待关系跨专业线存在，任何一条专业线内部的里程碑都无法单独反映它们是否按期闭合。因此检查点的锚点是依赖交接，而不是硬件评审通过或软件版本发布这类单线节点。
识别依赖时，可以从交付物清单入手，逐项确认“谁在等谁”。常见的互相等待对象包括：硬件样机及其配置版本、固件版本、接口文档与协议说明、测试环境与工装、结构件与线缆等配套物料。每一项依赖都应能指出交付方、接收方和期望交接时间，找不到接收方的交付物通常不是协同依赖，不必单独设点。
确定依赖后，把检查点放在交接的三个位置：交接前查输入是否齐备，交接时查双方是否确认，交接后查下游是否按预期启动。三段设点能把“东西交了”和“对方能用了”区分开，避免交付方认为已完成、接收方仍在等待的错位。
| 依赖交接类型 | 交接前检查点 | 交接时检查点 | 交接后检查点 |
|---|---|---|---|
| 硬件样机交付软件联调 | 样机配置、烧录版本、可用状态确认 | 软硬件双方共同确认样机可联调 | 联调任务按计划启动，问题已登记 |
| 固件版本交付测试 | 版本号、变更说明、已知问题清单齐备 | 测试方确认版本可安装、可回退 | 测试用例开始执行，阻断问题有归属 |
| 接口文档交付软硬件双方 | 文档版本与协议版本一致 | 双方对接口定义无异议 | 按文档实现的接口进入联调验证 |
| 测试环境与工装就绪 | 环境配置、工装校准记录完整 | 测试方确认环境可用 | 测试排期启动，环境问题有人处理 |
这些检查点与各专业线内部里程碑并行运行，互不替代。硬件内部的设计评审、软件内部的版本冻结仍按各自节奏管理，协同检查点只回答跨线依赖是否按期闭合。本文讨论的范围限于单项目层面，组织级流程制度和敏捷框架本身的运作不在其中。
每个检查点要定义的四类要素
只写时间节点的检查点无法判定是否通过，容易变成走过场的会议。一个可执行的检查点至少要写清四类要素：输入、判定标准、责任人、输出与证据。四类要素齐全，检查点才能被第三方复核。
输入
写明进入检查点前必须具备的交付物及其版本。例如“样机为第 2 版配置，固件为指定构建号，接口文档为对应协议版本”。输入项要具体到可核对的对象和版本，避免写“相关资料齐全”这类无法验证的描述。
判定标准
判定标准要可观察、可举证。可以用“能完成某项操作”“某项记录已签署”“某份清单无未关闭项”来表述。判定标准与输入对应，一条输入配一条或几条判定条件，检查时逐条勾选。
责任人
每个检查点明确三类角色：交付方负责提供输入并说明状态，接收方负责确认可用性，裁决人在双方意见不一致时给出放行或阻断结论。责任人写具体岗位或姓名，不写部门。
输出与证据
检查结束后留下检查结论、遗留问题清单、放行或阻断记录。证据可以是签署记录、问题单编号、版本截图或会议纪要，关键是能在后续追溯时证明当时依据什么做出判断。
| 要素 | 填写内容 | 合格判断 |
|---|---|---|
| 输入 | 交付物名称、版本、提供方 | 可逐项核对，版本明确 |
| 判定标准 | 可观察的完成条件 | 能勾选“是/否”，有举证方式 |
| 责任人 | 交付方、接收方、裁决人 | 均为具体岗位或人员 |
| 输出与证据 | 结论、遗留问题、放行/阻断记录 | 可追溯，问题有归属和期限 |
在工具层面，检查点、交付物和遗留问题需要在同一处登记与流转，避免结论散落在邮件和聊天记录里。ONES 的项目计划支持为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；检查点可以作为里程碑或带依赖的任务登记，遗留问题随任务状态流转，便于在下一轮检查时核对是否关闭。具体字段和可用范围以实际版本为准。
协同进度的度量指标怎么选
协同指标只回答一个问题：依赖是否按期闭合。它不用于考核某一专业线的进度快慢，也不能用软件完成百分比或硬件调试进度代替。指标数量宜少，每个指标都要能对应到具体检查点并取到数据。
| 指标 | 口径 | 数据来源 | 对应检查点 |
|---|---|---|---|
| 依赖按期闭合率 | 统计周期内按计划日期完成交接确认的依赖数 ÷ 应完成依赖数 | 检查点记录中的计划日期与实际确认日期 | 交接时检查点 |
| 交接返工次数 | 同一依赖因输入不合格被退回或重新交接的次数 | 检查结论与退回记录 | 交接前、交接时检查点 |
| 检查点阻断时长 | 从判定阻断到解除阻断的工作日数 | 阻断记录与解除记录 | 交接时检查点 |
| 下游启动偏差 | 下游任务实际启动日期与计划启动日期的差值 | 项目计划中的任务日期 | 交接后检查点 |
统计周期建议与项目例会节奏一致，按周或按双周取值，周期过长会掩盖阻断问题。每个指标都要能追溯到检查点记录，取不到数据的指标应删除或补充记录方式，而不是估算填写。
使用这些指标时注意两点：依赖按期闭合率低，先看是输入不齐还是确认环节拖延，再决定调整计划还是补充资源；交接返工次数集中出现在某一类交付物上，说明该类交付物的完成标准需要细化。指标用于发现依赖链条上的薄弱环节，各专业线内部的进度管理仍由各自负责。
角色分工与交付物
检查点要有人负责、有人确认、有人裁决，否则容易变成无人跟进的例会。角色分工按检查点运行的实际动作划分，每个角色在检查点上有明确产出。
| 角色 | 主要职责 | 检查点产出 |
|---|---|---|
| 项目经理 | 维护依赖清单和检查点计划，组织检查，跟踪遗留问题关闭 | 检查点计划、检查结论汇总、升级记录 |
| 硬件负责人 | 作为交付方或接收方确认样机、工装等硬件交付物状态 | 交付物状态说明、硬件侧遗留问题 |
| 软件负责人 | 确认固件版本、接口实现状态及联调准备情况 | 版本说明、软件侧遗留问题 |
| 测试/集成角色 | 验证交付物可用性，执行联调与环境检查 | 可用性确认记录、阻断问题清单 |
交付方的确认动作是提供输入并声明版本与已知问题；接收方的确认动作是实际验证可用性并给出接受或退回结论，不能只做签收。双方意见不一致时，由裁决人依据判定标准给出放行或阻断结论，结论和理由一并记录。
遗留问题在检查点当场登记，写明问题描述、责任人和期望关闭日期。影响下游启动的问题列为阻断项，由项目经理按约定路径升级：先在本项目内协调，超出项目范围时提交到相应的决策层。升级路径和时限在检查点体系建立时一并写明，运行中不临时约定。
示例：一个样机与固件联调检查点
以下示例为演示情景，用于说明字段如何填写，不代表真实项目数据。
背景：某设备项目进入联调阶段，软件团队需要第 2 版硬件样机和指定构建号的固件才能开始联调。硬件团队等待软件确认固件在样机上的运行状态。双方约定在样机交付当日设置一个交接时检查点。
| 要素 | 填写内容 |
|---|---|
| 输入 | 第 2 版样机 2 台，配置清单已签署；固件指定构建号及变更说明；接口文档对应协议版本；联调用测试环境已就绪 |
| 判定标准 | 样机上电自检通过；固件可安装并可回退到上一版本；接口文档中的主要接口在样机上可连通；测试环境能访问样机 |
| 责任人 | 交付方：硬件负责人（样机）、软件负责人（固件）；接收方：测试/集成角色；裁决人：项目经理 |
| 输出与证据 | 检查结论（放行/阻断）、遗留问题清单、样机配置签署记录、固件版本截图 |
指标取值：该依赖计划在周三完成交接确认，实际周三确认，计入依赖按期闭合率分子；检查中未发生退回，交接返工次数为 0；下游联调任务按计划周四启动，下游启动偏差为 0 个工作日。
异常处理示例：若检查时发现固件在样机上无法回退，判定为阻断，记录阻断日期和责任人，由软件负责人在两个工作日内提供可回退版本，期间检查点阻断时长开始累计。下游联调任务顺延，项目经理同步更新计划并通知相关方。阻断解除后重新执行交接时检查，通过后放行，阻断时长计入本期指标。
检查点体系的完成检查
检查点体系建立后，用以下清单逐项核对，全部满足才具备运行条件。
- 依赖清单中的每一项都能对应到至少一个检查点，没有遗漏的交接关系。
- 每个检查点都写清了输入、判定标准、责任人和输出与证据四类要素，判定标准可勾选、可举证。
- 每个指标都有明确口径和数据来源，能在统计周期内取到值，并与具体检查点对应。
- 阻断判定规则、遗留问题登记方式和升级路径已写明，责任人和时限明确。
- 检查点计划与各专业线内部里程碑的关系已说明，双方不互相替代。
体系运行一轮后安排复盘：核对依赖按期闭合率、交接返工次数和阻断时长，找出反复出现问题的交付物类型，调整其判定标准或交接时间；对从未触发阻断、也没有实际确认动作的检查点，考虑合并或取消。复盘结论落实到下一轮的检查点定义中，形成调整记录。ONES 支持设置项目计划和里程碑基线，对比计划与执行的偏差，复盘时可以据此查看检查点计划与实际确认日期的差异，追溯变更细节。
常见问题
软硬件双方对同一个交付物是否可用判断不一致时，检查点怎么处理？
在检查点定义阶段就指定裁决人，通常由项目经理担任，并写明裁决依据是判定标准中的具体条目。出现分歧时，交付方说明版本与已知问题，接收方说明实际验证结果，裁决人逐条对照判定标准给出放行或阻断结论，结论和理由一并记录。若分歧源于判定标准本身表述模糊，应在本次检查后修订标准，而不是每次临时协商。
检查点数量多、开会频繁，如何控制运行成本？
检查点只覆盖存在跨线等待关系的交付物，找不到接收方的交付物不必单独设点。交接前和交接后的检查可以用书面确认完成，只有交接时检查需要双方同时参与。运行一轮后，对从未触发阻断、也没有实际确认动作的检查点考虑合并或取消，把精力集中在反复出现退回和阻断的依赖上。
项目计划发生变更时，检查点计划怎么同步调整？
依赖清单和检查点计划由项目经理统一维护，计划日期变更时同步更新对应检查点的期望交接时间，并通知交付方和接收方。已经发生的检查记录保留原样，不追溯修改，以便复盘时区分计划调整和执行偏差。使用 ONES 时，可以设置项目计划和里程碑基线，对比计划与执行的偏差，追溯变更细节，具体可用范围以实际版本为准。
硬件样机或固件版本延期，检查点阻断后下游任务怎么安排？
阻断发生时记录阻断日期、责任人和解除条件，下游任务按实际影响顺延或调整范围，项目经理同步更新计划并通知相关方。阻断期间检查点阻断时长开始累计，解除后重新执行交接时检查，通过后放行。若阻断超出项目内可协调的范围，按事先写明的升级路径提交到相应决策层，升级路径和时限在体系建立时确定，运行中不临时约定。
这套检查点方法适用于哪些项目，什么情况下需要调整？
方法适用于软硬件之间存在明确交付物等待关系的单项目，例如样机联调、固件验证、接口对接和测试环境准备。若项目以纯软件交付为主，跨线依赖少，检查点可相应精简；若涉及多个项目共享样机或测试环境，资源冲突的协调超出单项目范围，需要结合组织层面的排期机制处理。本文不展开组织级流程制度设计。
