硬件阶段门禁已经通过，软件迭代却还差一截，这类混合项目最容易出现的失误，是把两条进度线绑在一起等。重排的核心是拆开判断：已通过的硬件门禁固化为基线，软件侧设置明确的可交付判定点，再按交付物重新划定冻结与发布边界，用并行和缓冲替代整体等待。下文给出诊断、排期、边界、分工、示例和检查六个环节的具体做法。
要点总览（TL;DR）
- 先做错位诊断：确认硬件门禁通过是内部里程碑还是对外承诺，把软件缺口归为范围、质量或集成缺口，标出关键路径上的等待点。
- 阶段计划重排为“硬件基线冻结+软件滚动排期”：已通过门禁转为基线，软件侧设就绪判定点，两者之间插入缓冲与并行窗口。
- 交付边界按交付物拆分：能独立验证的先行冻结，软硬件强耦合的等就绪判定点通过后合并发布，对外承诺与内部计划分开记录。
- 就绪判定和边界变更都要落到明确的人与记录上，重排后的计划标注版本号和生效时点，确保相关角色看到同一版本。
- 用五项检查核对重排效果：基线受控、判定点有责任人、边界逐项对应、等待点被缓冲或并行替代、结果已同步。
先判断错位性质：哪些等待在关键路径上
重排之前要先回答一个问题：当前的等待究竟卡在哪里。硬件门禁通过和软件未就绪是两件性质不同的事，混在一起讨论，容易把“硬件已确认”误读为“项目整体已推进”，也容易把软件缺口一律当成延期处理。诊断的目标是产出一张错位诊断表，让后续排期有依据。
第一步：确认硬件门禁通过的性质
向硬件负责人和门禁评审方确认两件事：这次通过是内部里程碑事实，还是已经构成对外交付承诺。前者意味着该节点可以作为后续工作的稳定起点；后者意味着节点背后附带客户或合同义务，重排时需要同步处理对外沟通。两种情况下硬件基线都应冻结，差别在于对外口径的处理方式。
第二步：给软件缺口归类
软件未就绪通常落在三类缺口上，处理方式不同：
- 范围缺口：计划内的功能尚未完成开发。这类缺口影响交付物完整性，需要判断能否拆分交付。
- 质量缺口：功能已具备，但测试、缺陷收敛或性能指标未达标。这类缺口影响能否发布，通常需要一段稳定的收敛期。
- 集成缺口：软件与硬件的联调、接口验证尚未完成。这类缺口往往同时牵动两侧，是混合项目中最需要提前暴露的部分。
归类时以迭代评审记录、缺陷清单和联调记录为输入，由软件负责人给出结论，项目经理记录。一个迭代可能同时存在多类缺口，按影响交付的那一类为主归类即可。
第三步：标出关键路径等待点
把当前计划中的任务按前后置关系排开，找出“后续任务必须等软件完成才能开始”的位置，这些就是关键路径上的等待点。与之相对的是可并行点：不依赖软件就绪即可推进的硬件验证、文档编写、产线准备、认证送检等。诊断表可按以下结构填写：
| 门禁/节点 | 状态 | 软件缺口类型 | 是否在关键路径 | 可并行空间 |
|---|---|---|---|---|
| 硬件阶段门禁 | 已通过，待确认是否对外承诺 | — | 否，已转为基线 | 可作为后续任务起点 |
| 软件迭代 N | 未就绪 | 质量缺口（缺陷收敛） | 是，阻塞联调 | 联调环境准备可并行 |
| 软件迭代 N+1 | 未就绪 | 范围缺口 | 视交付物拆分而定 | 文档、认证材料可并行 |
| 整机联调 | 未开始 | 集成缺口 | 是 | 硬件侧预验证可先行 |
这张表完成后，重排的幅度就有了判断依据：关键路径上的等待点越多、缺口越偏集成，越需要插入缓冲和分批交付；等待点少且集中在非关键路径，则调整软件滚动排期即可。
重排阶段计划：固化硬件基线，软件侧设就绪判定点
诊断清楚后进入排期。重排的原则是让硬件侧稳定、软件侧滚动，两者在明确的判定点上汇合，而不是让整条计划跟着最慢的迭代走。
硬件门禁转为基线冻结
把已通过的硬件门禁及其对应的交付物、评审记录固化为基线，作为后续计划的参照点。基线冻结的含义是：该节点的结论不再回退，后续如需变更，走例外流程单独审批，并在计划中记录变更原因和影响范围。这样做的好处是后续排期不必反复确认硬件状态，软件侧的调整也不会牵动已确认的节点。
软件迭代改为以就绪判定点为节点的滚动排期
为软件侧设置一个或多个“就绪判定点”，每个判定点对应一组明确的完成条件，例如：计划范围内功能全部完成、缺陷密度降到约定阈值、与硬件的接口联调通过。判定点之间的迭代按滚动方式排期，每轮评审后更新下一轮的范围和时间，不一次性锁死全部迭代日期。判定点的完成条件应在设置时写清楚，避免到期时对“是否就绪”产生争议。
插入缓冲与并行窗口
在硬件节点与软件就绪判定点之间安排两类时间：一是缓冲，用于吸收软件收敛的不确定性，长度参考历史迭代的偏差幅度；二是并行窗口，把不依赖软件就绪的工作前移，例如硬件复测、认证材料准备、产线工装调试、用户文档编写。并行窗口的价值在于让等待期产生实际产出，而不是让整条关键路径空转。
发布重排后的计划版本
重排完成后形成新的阶段计划表，至少包含：基线节点及其冻结状态、软件就绪判定点及完成条件、缓冲窗口的位置与长度、每项的责任人。计划需要标注版本号和生效时点，旧版本归档保留，便于后续对比偏差。在工具层面，这类计划可以用 ONES 项目计划承载：按交付物或阶段分解工作项，为任务设置前后置依赖，用里程碑标记门禁和就绪判定点，并设置计划与里程碑基线，便于对比计划与执行偏差、追溯变更细节。
| 计划要素 | 内容示例 | 责任人 |
|---|---|---|
| 硬件基线节点 | 阶段门禁通过日，交付物清单冻结 | 硬件负责人 |
| 软件就绪判定点 1 | 缺陷收敛达标 + 接口联调通过 | 软件负责人 |
| 缓冲窗口 | 判定点前预留的收敛时间 | 项目经理 |
| 并行窗口 | 认证材料、产线准备等前移任务 | 各任务负责人 |
重划交付边界：分批冻结与合并发布的分界
阶段计划解决时间问题，交付边界解决范围问题。硬件已过门禁而软件未就绪时，最忌讳的是把所有交付物捆成一个整体等软件，导致本可先行确认的成果也被拖住。
按交付物拆分冻结与发布
逐项列出项目交付物，判断每一项属于哪一类：
- 可先行冻结项：以硬件为主、软件依赖弱的交付物，例如硬件设计文件、结构件、已通过门禁的样机状态、认证送检材料。这类交付物按硬件节点冻结，冻结后进入受控状态。
- 需合并发布项：软硬件耦合紧密、必须整体验证后才能对外交付的内容，例如整机功能版本、联调后的系统包、面向客户的最终发布物。这类交付物等软件就绪判定点通过后统一发布。
拆分时以“能否独立验证”为判断标准：能独立验证且结论稳定的，可以先行冻结；验证依赖软件行为的，归入合并发布。
边界变更的审批与记录
交付边界一旦划定，变更需要走明确路径：由提出方说明变更原因和影响范围，项目经理组织评审，涉及对外承诺的由项目负责人批准，变更结论记入交付边界清单并保留版本。记录的作用不只是留痕，更是在后续争议中提供判断依据。
对外承诺与内部计划分开处理
对外承诺的交付日期和范围通常不能随内部排期同步调整。处理方式是：内部计划按重排后的节奏执行，对外口径以已承诺内容为准，两者之间的差异用缓冲和分批交付消化；确实无法消化的部分，提前启动对外沟通，说明分批交付的安排，而不是等到原定日期再解释延期。
| 交付物 | 冻结时点 | 依赖软件项 | 发布方式 | 审批人 |
|---|---|---|---|---|
| 硬件设计文件与样机状态 | 门禁通过日 | 无 | 先行冻结 | 硬件负责人 |
| 认证送检材料 | 门禁通过后并行窗口内 | 弱依赖 | 先行冻结 | 项目经理 |
| 整机功能版本 | 软件就绪判定点通过后 | 强依赖 | 合并发布 | 项目负责人 |
角色分工与交接：谁判定就绪、谁批准边界变更
重排能否落地，取决于每个判断有没有明确的人负责、有没有留下记录。混合项目里最容易出现的空档，是“就绪”由谁说了算、边界变更由谁拍板这两件事没有事先约定。
职责划分
| 角色 | 判定/批准事项 | 输入 | 输出记录 |
|---|---|---|---|
| 硬件负责人 | 确认门禁通过性质，维护硬件基线 | 门禁评审结论、交付物清单 | 基线冻结记录 |
| 软件负责人 | 提交就绪判定申请，说明缺口收敛情况 | 迭代评审记录、缺陷清单、联调记录 | 就绪判定申请单 |
| 项目经理 | 组织就绪判定，维护阶段计划与缓冲 | 诊断表、计划版本、判定申请 | 判定结论、计划新版本 |
| 门禁评审方 | 确认门禁结论的有效性与变更影响 | 变更申请、影响分析 | 例外审批记录 |
| 项目负责人 | 批准涉及对外承诺的边界变更 | 边界变更评审意见 | 批准记录与对外口径 |
就绪判定的输入与记录
就绪判定不是一次口头确认，而是一次有输入、有结论、有记录的评审。输入包括判定点预设的完成条件、当前迭代的实际完成情况、缺陷与联调数据；判定人由项目经理组织，软件负责人提交，硬件负责人对涉及联调的部分给出意见；结论写入判定记录，明确“通过”“有条件通过”或“未通过”，未通过时写明差距和下一轮判定时间。
边界变更的提出、评审与批准路径
变更路径保持简短：提出方提交变更说明，项目经理评估对计划和交付物的影响，涉及对外承诺的提交项目负责人批准，其余由项目经理批准即可。所有变更结论同步到交付边界清单和阶段计划，确保相关角色看到的是同一版本。在记录承载上，ONES Wiki 支持文档关联任务，并可在文档中插入工作项列表，适合把就绪判定记录、边界变更说明与对应的计划任务放在一起，减少文档与任务脱节。
示例：一次门禁已过、软件差两个迭代的重排
以下为演示情景，用于说明重排过程，数值为示意。
初始状态
某混合项目计划在第 10 周通过硬件阶段门禁，第 14 周完成整机发布。实际第 10 周门禁通过，但软件侧第 3、第 4 两个迭代均未达标：第 3 迭代存在缺陷收敛不足，第 4 迭代的接口联调尚未开始。原计划要求整机发布等全部软件完成后进行，按当时进度预计整体推迟约 4 周。
诊断结论
硬件门禁属于内部里程碑，未构成对外交付承诺，可转为基线。软件缺口以质量缺口和集成缺口为主，其中接口联调位于关键路径，阻塞整机验证；认证材料准备、产线工装调试不依赖软件，属于可并行空间。
重排方案
- 硬件门禁及样机状态冻结为基线，后续变更走例外审批。
- 软件侧设置一个就绪判定点，完成条件为缺陷收敛达标且接口联调通过，判定时间定在第 13 周。
- 在第 10 周至第 13 周之间安排并行窗口：认证材料准备、产线工装调试前移；同时在判定点前预留 1 周缓冲。
- 交付边界拆分：硬件设计文件、样机状态、认证送检材料按门禁节点先行冻结；整机功能版本等判定点通过后合并发布。
等待时间对比
重排前，整机发布需等两个迭代全部完成，关键路径上的等待约为 4 周，期间认证与产线准备无法启动。重排后，关键路径等待被压缩为判定点前的收敛期加 1 周缓冲，认证与产线准备在并行窗口内完成，整机发布不再整体等待全部软件范围，而是以判定点通过为起点。演示情景中的压缩幅度取决于缺口实际收敛速度，不能直接套用到其他项目。
完成检查：重排是否真正减少了关键路径等待
重排完成后，用以下清单逐项核对。每项都应能指向具体记录，而不是停留在口头确认。
| 检查项 | 通过标准 |
|---|---|
| 硬件基线是否冻结且变更受控 | 基线节点有冻结记录，后续变更均有例外审批记录 |
| 软件就绪判定点是否明确且有责任人 | 每个判定点有完成条件、判定人和判定时间，判定记录可查 |
| 交付边界是否逐项对应到交付物与时点 | 交付边界清单覆盖全部交付物，每项有冻结时点、发布方式和审批人 |
| 关键路径等待是否被缓冲或并行替代 | 诊断表中的每个关键路径等待点，都能对应到缓冲窗口或并行任务 |
| 重排结果是否已同步到相关角色与记录 | 阶段计划有新版本号和生效时点，相关角色确认收到同一版本 |
五项全部满足，说明重排完成了从诊断到落地的闭环；若有任一项缺失，优先补齐对应记录再推进后续迭代，避免重排结论在执行中走样。需要说明的是，这套方法解决的是单个混合项目的阶段与边界重排，组织级的流程制度设计不在本文范围内。
常见问题
硬件门禁通过后，软件还要两个迭代才能就绪，整机发布是否必须等全部软件完成？
不一定。先看整机发布所依赖的软件范围：如果发布物必须包含全部计划功能，确实要等软件就绪；如果部分交付物能独立验证，可以按交付物拆分，硬件设计文件、样机状态、认证送检材料按门禁节点先行冻结，整机功能版本等就绪判定点通过后合并发布。判断标准是“能否独立验证”，能独立验证且结论稳定的先行冻结，验证依赖软件行为的归入合并发布。
软件就绪判定点由谁判定，判定不通过时怎么处理？
就绪判定由项目经理组织，软件负责人提交申请并说明缺口收敛情况，涉及联调的部分由硬件负责人给出意见。判定结论写入记录，明确“通过”“有条件通过”或“未通过”。未通过时写明差距和下一轮判定时间，同时评估对关键路径的影响：差距在收敛期内可消化则维持原判定点，超出缓冲则启动计划调整，必要时同步对外沟通。
对外承诺的交付日期不能改，内部计划又需要重排，两者怎么衔接？
内部计划按重排后的节奏执行，对外口径以已承诺内容为准，两者之间的差异用缓冲和分批交付消化。具体做法是提前识别哪些交付物可以先行交付、哪些必须合并发布，把分批安排作为对外沟通的内容，在原定日期前说明交付节奏，而不是等到原定日期再解释延期。涉及对外承诺的边界变更，由项目负责人批准并记录对外口径。
重排后如何确认关键路径等待真的减少了，而不是把等待挪到了别处？
回到诊断表逐项核对：每个关键路径等待点都应能对应到一个缓冲窗口或并行任务，且并行任务有明确的负责人和完成时点。同时检查缓冲长度是否参考了历史迭代的偏差幅度，判定点的完成条件是否可验证。如果某个等待点只是换了名称、没有对应的并行产出或缓冲安排，说明重排没有真正生效，需要回到阶段计划调整。
这类重排需要工具支持吗，用文档和表格能否完成？
方法本身不依赖特定工具，文档加表格可以完成诊断、计划和边界清单。当项目涉及多轮迭代、依赖关系复杂、需要对比计划与执行偏差时，工具承载会更省力。例如 ONES 项目计划支持按交付物或阶段分解工作项、设置前后置依赖、用里程碑标记门禁和就绪判定点，并设置计划与里程碑基线对比偏差；ONES Wiki 支持文档关联任务并插入工作项列表，便于把判定记录与计划任务放在一起。
