硬件阶段门禁已经通过，软件迭代却还没达到可交付状态，项目就会卡在两个节奏之间：硬件按阶段推进，软件按迭代推进，关键路径上出现一段无人推进的等待。本文给出三步调整方法——重排门禁条件、重切软件迭代范围、重设交付边界，并说明每步的输入、负责人和完成标志。调整后的门禁条件、迭代任务与交付边界需要在同一处跟踪状态和交接，ONES 的项目计划、迭代与文档能力可以承接这部分管理动作。
要点总览（TL;DR）
- 先沿关键路径定位等待位置：门禁条件等待、迭代出口等待、交付边界等待，三类成因不同，处理方式也不同。
- 硬件门禁结论保留，软件侧改为带条件放行：每条条件写明放行最低条件、关闭证据、负责人和回退条件。
- 软件迭代用可交付状态清单重定义出口，把阻塞关键路径的工作拆成可独立验证的短任务，并把联调准备、测试环境、接口对齐、文档等并行工作提前启动。
- 交付边界书面重设，明确包含项、排除项和完成状态定义，四个角色的职责与交接物固定时点，变更记录与边界说明同版本管理。
- 调整后用检查清单逐项核对，并跟踪关键路径等待任务数与天数、条件关闭周期、交接一次通过率，每周复查一次。
先判断等待发生在关键路径的哪一段
调整计划之前，先把“等”拆开。硬件门禁通过而软件未就绪时，等待通常落在三个位置，成因和影响范围不同，处理方式也不同。定位错了，后面的门禁重排和迭代重切就会做在非关键路径上，投入了人力却缩短不了总工期。
| 等待位置 | 典型表现 | 成因 | 影响范围 |
|---|---|---|---|
| 门禁条件等待 | 硬件结论已出，但下一阶段启动要求软件整体就绪，整段放行被推迟 | 门禁按一次性放行设计，软件侧没有条件化条目 | 后续所有阶段整体后移 |
| 迭代出口等待 | 迭代临近结束，仍有任务未达可交付状态，迭代无法关闭 | 出口标准模糊，任务颗粒度大，验证依赖整批完成 | 联调、测试、验收依次顺延 |
| 交付边界等待 | 各方对“本次交付包含什么”理解不一致，交接反复确认 | 交付范围未书面确认，角色职责不清 | 跨团队交接停滞，返工增加 |
定位方法是沿关键路径逐段核对依赖关系：从当前时点出发，找出后续必须串行执行的任务，检查每个任务的前置条件由谁提供、何时提供。若某个前置条件的提供方是软件团队且尚未完成，这段就是等待点。再判断该等待属于上表哪一类：门禁规则导致的整段阻塞、迭代出口不清晰导致的收尾拖延，还是边界不清导致的交接停滞。
定位前需要收集三类输入：一是硬件门禁结论，包括通过的范围、遗留项和适用条件；二是软件迭代待办完成情况，逐项标注已完成、进行中、未开始及各自的可交付状态；三是依赖清单，列明每个后续任务的前置任务、提供方和期望时间。三类输入齐备后，把等待点标注在关键路径上，形成一张等待位置定位表，作为后续调整的依据。
重排阶段门禁：把一次性放行改为带条件放行
硬件门禁的结论应当保留，不需要因为软件未就绪而推翻或重审。需要调整的是门禁的放行方式：从“全部条件满足才整体放行”改为“硬件结论照常生效，软件侧按条件条目分批放行”。这样后续阶段可以带着明确的软件遗留条件启动，把整段等待拆成若干可管理的短等待。
重排时先明确硬件门禁结论的覆盖范围。例如硬件设计评审通过，覆盖结构、接口定义和物料选型，但不覆盖软件对接口的实际适配、联调结果和整机功能验证。把“不覆盖范围”写清楚，可以防止后续把硬件结论误当作整机可交付的依据。
然后为软件侧设置条件化放行条目，每条包含四项内容：可带条件进入下一阶段的工作、放行需满足的最低条件、条件关闭的证据、负责人。可参考以下结构：
| 条件条目 | 放行最低条件 | 关闭证据 | 负责人 |
|---|---|---|---|
| 接口联调启动 | 接口协议文档冻结，双方接口桩可用 | 联调环境跑通首轮用例记录 | 软件接口负责人 |
| 系统测试启动 | 核心功能路径可执行，缺陷收敛到约定阈值 | 测试准入评审记录 | 测试负责人 |
| 文档交付启动 | 交付边界说明与接口说明完成初稿 | 文档评审通过记录 | 项目文档负责人 |
条件放行的审批角色建议由项目经理牵头，软件负责人和测试负责人共同确认，硬件负责人对涉及硬件接口的条件条目提供意见。每个条件条目必须有唯一负责人和可核验的关闭证据，证据形式可以是评审记录、测试报告或联调日志，避免用“基本完成”这类无法核对的描述关闭条件。
门禁重排后，后续阶段的启动不再依赖软件整体就绪，但会引入新的管理要求：条件条目要在计划中可见，关闭进度要定期核对。同时设定回退条件，例如联调连续两轮未通过、或关键缺陷数量超过约定阈值时，暂停依赖该条件的后续工作，回到条件条目重新评估。回退条件与放行条件成对出现，防止带条件放行变成无条件放行。
重切软件迭代范围与出口标准
门禁带条件放行之后，软件迭代本身仍需要调整，否则未就绪的工作会继续堆积在迭代末尾。核心做法是用可交付状态清单重新定义迭代出口，再把阻塞关键路径的工作拆成更短周期、可独立验证的任务。
可交付状态清单把迭代内的每一项工作分为两类：必须完成项和可延后项。必须完成项是关闭当前条件条目、解除关键路径等待所必需的工作，例如接口适配、联调所需的环境配置；可延后项是不影响条件关闭的功能完善、体验优化和非关键缺陷修复。分类标准写进迭代出口定义，评审时逐项对照，避免出口判断依赖个人经验。
拆分任务时遵循两条规则：单个任务能在数个工作日内独立验证；任务的完成状态可以由负责人之外的角色核对。例如把“完成设备接入模块”拆为“接口协议对齐”“接入代码提交并通过单元验证”“与硬件样机完成首轮联调”三个任务，每个任务有独立完成标志，前一个完成即可启动后一个，不必等整个模块收尾。
同时识别可以提前启动的并行工作，把它们排入当前迭代或紧随其后的短周期：联调准备包括环境搭建、样机预约和测试数据准备；测试环境包括硬件在环环境的配置与校准；接口对齐包括协议版本确认和异常场景约定；文档包括接口说明、交付边界说明和测试记录的初稿。这些工作不依赖软件功能全部完成，提前启动可以把等待时间转化为准备时间。
迭代范围调整后，排期需要同步更新：重画关键路径，把拆分后的任务和并行工作按依赖关系排入计划，标注每个条件条目的关闭时点；沟通节奏上，建议在每日同步中只核对阻塞关键路径的任务和条件条目关闭进度，每周做一次范围与出口标准复核，范围变更需经项目经理和软件负责人确认后生效。
重设交付边界与角色分工
门禁和迭代调整之后，交付边界必须同步重设，否则各方仍按旧范围理解交付内容，交接处会继续产生等待。边界重设的产物是一份书面交付边界说明，明确本次交付包含什么、不包含什么、以什么状态交付。
交付边界说明至少写清三项：本次交付的功能与硬件范围；每项交付物的完成状态定义，例如“接口联调通过”指首轮用例全部执行且无阻塞级缺陷；明确排除的内容及后续安排，例如整机长时间稳定性验证放到下一阶段。排除项要写明计划时点，避免被理解为取消。
| 角色 | 新计划下的职责 | 主要交付物 | 交接时点 |
|---|---|---|---|
| 硬件负责人 | 维护硬件门禁结论的覆盖范围，提供样机与接口支持 | 门禁结论说明、样机可用状态确认 | 联调启动前 |
| 软件负责人 | 拆分迭代任务，关闭软件侧条件条目 | 拆分任务清单、条件关闭证据 | 每个条件条目关闭时 |
| 测试负责人 | 确认测试准入条件，执行联调与系统测试 | 测试准入评审记录、测试报告 | 测试启动前及每轮测试结束 |
| 项目经理 | 维护关键路径与条件条目状态，组织边界确认 | 调整后计划、交付边界说明、变更记录 | 每周复核及边界变更时 |
跨角色交接要约定固定时点和交接物：硬件向软件交接样机时，附样机状态与已知问题清单；软件向测试交接版本时，附变更说明与自测结果；测试向项目组反馈结果时，附缺陷分级与阻塞项清单。交接物不齐备时，接收方可以拒收，这一规则要写进边界说明。
边界变更需要记录和确认：任何范围增减、状态定义调整、交接时点变化，都记入变更记录，注明提出人、影响分析和确认人，经项目经理与相关角色确认后更新边界说明版本。变更记录与边界说明放在同一处，保证各方看到的是同一版本。
这些条件条目、拆分任务和边界文档需要在同一处保持状态同步。在 ONES 中，可以用项目计划分解任务并设置前后置依赖，用里程碑标记门禁与条件关闭节点，将迭代和研发任务关联到项目计划中跟踪进度；交付边界说明、接口文档等可放在 ONES Wiki 中并与相关工作项关联，使文档版本与任务状态对应。
一个混合项目的调整示例
以下为演示情景，用于说明三步调整如何落地，实际项目需按自身依赖关系调整。
某设备研发项目，硬件阶段门禁评审通过，覆盖结构设计与接口定义。原计划要求软件完成全部功能并通过系统测试后才启动整机联调。当前软件迭代剩余两周，接口适配完成约六成，测试环境尚未搭建，项目组判断整机联调将推迟约三周。
定位阶段，沿关键路径核对发现三处等待：门禁条件等待，整机联调被绑定在软件整体就绪之后；迭代出口等待，接口适配任务颗粒度大，完成状态无法逐项核对；交付边界等待，硬件与软件对“接口就绪”的理解不一致，一方指协议文档完成，另一方指代码可运行。
门禁重排阶段，保留硬件门禁结论，新增两条软件侧条件放行条目：接口联调在协议文档冻结且接口桩可用时放行，系统测试在核心功能路径可执行且阻塞级缺陷清零时放行。每条指定负责人和关闭证据，并约定联调连续两轮失败即回退重评。
迭代重切阶段，把接口适配拆为协议对齐、代码提交并通过单元验证、首轮联调三个短任务；把测试环境搭建、样机预约、接口异常场景文档列为并行工作，提前到当前迭代执行；迭代出口改为以条件条目关闭为准，非关键功能完善列为可延后项。
边界重设阶段，书面明确本次交付包含接口联调通过与核心功能测试通过，不包含长时间稳定性验证，后者列入下一阶段；统一“接口就绪”的定义为代码可运行且首轮联调用例通过；四个角色的职责与交接物按上节表格确认并记录版本。
| 对比项 | 调整前 | 调整后 |
|---|---|---|
| 整机联调启动条件 | 软件全部功能完成并通过系统测试 | 协议冻结且接口桩可用即启动 |
| 关键路径等待时长 | 约三周 | 约一周，其余时间转为并行准备 |
| 迭代出口判断 | 迭代内任务全部完成 | 条件条目关闭，可延后项另行安排 |
| 交接争议 | “接口就绪”理解不一致，反复确认 | 定义写入边界说明，按交接物验收 |
示例的假设是硬件样机可按期提供、接口协议无重大变更。若样机延迟或协议变更，条件条目的放行时点需重新评估，回退条件可能被触发，此时应按门禁重排中的回退规则处理，而非直接顺延整个计划。
调整后的完成检查
调整是否生效，用一份检查清单逐项核对。每项给出通过标准，全部通过才认为关键路径等待已被有效压缩。
| 检查项 | 通过标准 |
|---|---|
| 门禁条件条目完整 | 每条有条件内容、唯一负责人、可核验的关闭证据和回退条件 |
| 迭代出口可验证 | 必须完成项与可延后项已分类，每项有明确的完成状态定义，可由负责人之外的角色核对 |
| 并行工作已排入计划 | 联调准备、测试环境、接口对齐、文档等并行工作有任务、负责人和时点，并已进入当前或下一短周期 |
| 交付边界已确认 | 边界说明含包含项、排除项和状态定义，经相关角色确认并记录版本 |
| 角色交接有约定 | 各角色交接时点与交接物明确，交接物不齐备时可拒收的规则已写入 |
观察调整是否真正减少等待，可跟踪三个指标：关键路径上处于等待状态的任务数量及其累计天数；条件条目从放行到关闭的平均周期；跨角色交接一次通过的比例。建议在调整生效后每周复查一次，连续两周关键路径等待天数下降，可认为调整方向有效；若等待未下降，回到等待位置定位表重新核对，重点检查是否有未识别的依赖或条件条目设置过严。
复查时同步核对回退条件是否被触发、边界说明是否有未记录的变更。调整后的计划、条件状态和边界文档保持同一版本，是后续复查能够成立的前提。
常见问题
硬件门禁结论已经通过，软件侧带条件放行会不会削弱门禁的把关作用？
关键在于把放行条件和回退条件成对设置。硬件门禁结论保留原有覆盖范围，软件侧每条条件条目都写明放行最低条件、可核验的关闭证据和唯一负责人；同时约定回退触发条件，例如联调连续两轮未通过或关键缺陷超过约定阈值时，暂停依赖该条件的后续工作并重新评估。这样放行是有边界的，条件未关闭的部分始终可见，门禁把关作用体现在条件关闭的核对上，而非整段阻塞。
软件迭代未达可交付状态时，哪些工作适合提前并行启动？
判断标准是这项工作是否依赖软件功能全部完成。联调准备（环境搭建、样机预约、测试数据准备）、测试环境配置与校准、接口协议版本与异常场景对齐、接口说明和交付边界说明初稿，通常都可以提前启动。把它们排入当前迭代或紧随其后的短周期，需要为每项指定负责人和时点，否则并行工作会停留在口头安排上。
迭代出口标准调整后，如何避免范围反复变化？
把必须完成项和可延后项的分类标准写进迭代出口定义，评审时逐项对照，出口判断不依赖个人经验。范围变更需经项目经理和软件负责人确认后生效，并记入变更记录。每日同步只核对阻塞关键路径的任务和条件条目关闭进度，每周做一次范围与出口标准复核，减少临时插入带来的反复。
调整后多久能判断关键路径等待确实减少了？
建议调整生效后每周复查一次，连续两周关键路径等待天数下降，可认为方向有效。跟踪三个指标：关键路径上处于等待状态的任务数量及累计天数、条件条目从放行到关闭的平均周期、跨角色交接一次通过的比例。若等待未下降，回到等待位置定位表重新核对，重点检查是否有未识别的依赖，或条件条目设置过严导致放行迟迟无法触发。
硬件样机延迟或接口协议变更时，已调整的计划怎么处理？
按门禁重排中约定的回退规则处理，而非直接顺延整个计划。样机延迟会影响联调启动时点，协议变更会影响接口对齐任务的完成定义，两者都需要重新评估相关条件条目的放行时点，并核对是否触发回退条件。边界说明中排除项的计划时点也要同步更新，避免各方按旧版本理解交付内容。
