瀑布门禁已经触发，迭代产出却还没就绪；迭代评审通过了，门禁材料又被退回——软硬件混合项目里的这类等待和返工，往往被笼统归为“流程对不上”。要判断根因，可以先把问题拆成三层：同步点设置、交付边界、评审输入输出。取最近2–3次等待返工事件，核对门禁触发时点、迭代评审时点、双方要求的输入清单和评审结论，看错位发生在哪一层，再决定处置方向。
要点总览（TL;DR）
- 先按等待发生的环节归类症状：门禁先到产出未到、评审先过门禁退回，是两类不同方向的错位。
- 建立三类原因假设——同步点设置、交付边界、评审输入输出，用判别特征区分，不把原因直接当结论。
- 取证按固定顺序：先画时间轴看是否周期性错位，再对照双方交付物口径，最后查评审材料与结论闭环。
- 判别规则可简化为：固定周期重复等待优先查同步点；评审后反复补件、结论被推翻优先查输入输出。
- 处置对应已确认根因，门禁规则改动先小范围试点、保留备份并设停止点，用处置前后同口径数据验证效果。
等待返工出现在哪些环节：症状与范围界定
“对不上”本身不是可诊断的对象，需要先落到具体环节。软硬件混合项目中，硬件侧按阶段推进、软件侧按迭代交付，两套节奏在同一项目里并行，错位通常出现在门禁与迭代评审的交接处。常见的可观察症状有两类方向。
第一类是门禁先到、产出未到。门禁按计划日期触发，要求提交设计文档、测试报告或样机验证记录，但对应迭代尚未完成评审，交付物还停留在草稿或待确认状态，门禁只能挂起等待。第二类是评审先过、门禁退回。迭代评审已经给出通过结论，门禁审核却认为材料粒度不够、完成定义不符，要求补充或重做，形成返工。
判断是否构成需要诊断的问题，可以看三个信号：
- 排队时长：门禁触发到材料受理之间的等待天数，是否在多次事件中重复出现；
- 返工轮次：同一交付物因门禁退回而补充、修改的次数；
- 结论推翻：迭代评审已通过的结论，在门禁环节被否定或要求重新评审的次数。
诊断范围限定在单个项目内，对象是门禁与迭代评审之间的同步点、交付边界和评审输入输出。组织级流程制度是否合理、敏捷框架本身如何选型，属于另一层问题，本文不展开。范围收窄的好处是，取证对象明确，处置动作也能在项目内落地。
先分清三类原因假设：同步点、交付边界、评审输入输出
症状收集完成后，不要直接跳到“流程有问题”的结论，先建立三类原因假设，再用证据逐一排除。三类假设的判别特征如下表。
| 原因假设 | 核心错位 | 典型症状 | 反例（不支持该假设） |
|---|---|---|---|
| 同步点设置问题 | 门禁时点与迭代节奏、触发条件或评审对象错位 | 等待按固定周期重复出现，如每次迭代末门禁必然空等；门禁触发条件与迭代完成事件无关联 | 等待偶发，且集中在材料质量差的个别交付物上 |
| 交付边界问题 | 门禁要求的交付物与迭代产出物在粒度、完成定义上不一致 | 评审认为已完成，门禁认为未完成；同一交付物两套验收口径 | 双方对完成定义一致，问题只出在时间先后 |
| 评审输入输出问题 | 输入材料不齐或口径不一，输出结论含糊、返工项未闭环 | 评审后反复补件；结论被门禁推翻；返工要求口头传达、无人跟踪 | 材料齐全、结论明确，等待仅由排期造成 |
同步点问题的特征是“时间上的系统性错位”。例如门禁固定在每月末触发，而迭代周期是两周，月末门禁必然落在某个迭代中途，产出天然不完整。这类等待有规律、可预测，调整时点或触发条件就能缓解。
交付边界问题的特征是“同一件事两套标准”。迭代评审按“功能可用、缺陷在阈值内”判定完成，门禁却要求“文档归档、测试报告签署完毕”，两者都合理，但没有事先对齐，评审通过的成果在门禁处被判定为未完成。
评审输入输出问题的特征在评审本身。进入评审的材料缺少关键项，评审只能带条件通过；或者结论写成“基本可行，细节后续确认”，返工要求没有登记责任人和期限，到门禁时才发现未闭环。这类问题的等待往往表现为评审后的反复补件，而非固定周期。
三类假设可能同时存在，但通常有一层是主因。判别时先找“最稳定的重复模式”，再验证其他层是否只是伴随现象。
用证据排除：如何验证根因落在哪一层
验证按固定顺序进行：先看时间轴，再看交付物口径，最后看评审材料与结论闭环。顺序的意义在于，时间错位会放大后两层的症状，先排除同步点问题，能避免把时间问题误判为质量问题。
第一步，取门禁触发记录与迭代评审记录，把两类事件画在同一条时间轴上。核对三个点：门禁触发日、迭代评审日、交付物实际就绪日。如果门禁触发日稳定早于交付物就绪日，且间隔与迭代周期相关，同步点假设成立的可能性高。如果门禁触发日与就绪日无固定关系，等待随交付物质量波动，则转向下一层。
第二步，对照门禁输入清单与迭代评审的完成定义。逐项列出双方对同一交付物的要求，标注粒度差异和完成标准差异。典型证据是：评审记录写“功能验收通过”，门禁清单要求“测试报告已签署”，而签署流程在评审时尚未启动。这类差异属于交付边界问题。
第三步，检查评审输入与输出。输入侧看材料清单是否齐备、版本是否一致；输出侧看结论是否有明确通过/不通过判定、返工项是否登记了责任人与期限、后续是否有人核对闭环。若返工项在门禁前无人跟踪，或结论表述含糊导致门禁审核无法引用，则归入评审输入输出问题。
取证清单可按下表整理，每项标注“已确认”或“待验证”，未取得记录的项目不写成结论。
| 取证对象 | 核对内容 | 支持的假设 |
|---|---|---|
| 门禁触发记录 | 触发日期、触发条件、挂起原因 | 同步点 |
| 迭代评审记录 | 评审日期、参与角色、结论类型 | 同步点、输入输出 |
| 双方输入清单 | 交付物名称、粒度、完成定义 | 交付边界 |
| 评审结论与返工单 | 结论明确性、返工项责任人、闭环状态 | 输入输出 |
判别规则可以简化为两条：等待按固定周期重复出现，优先查同步点；评审后反复补件、结论被推翻，优先查输入输出。交付边界问题常表现为两者之间——评审和门禁各自都按规则执行，规则本身没有对齐。
这些记录需要有稳定的承载位置。在 ONES 中，项目计划可按阶段和交付物分解任务并设置前后置依赖，里程碑可标记门禁这类决策点；计划与里程碑基线支持对比计划与执行偏差，便于回看门禁触发时点的实际状态。迭代与研发任务可在项目计划中关联，评审材料可通过 ONES Wiki 文档关联任务，使输入清单与结论有对应的工作项可查。需要说明的是，门禁触发条件与评审时点的专门配置能力，现有资料未明确说明，选型时应向厂商核验。
按根因处置：调整同步点、对齐交付边界、规范评审输入输出
处置动作对应已确认的根因，未确认的层不提前改动，避免一次调整多个变量后无法判断效果。
同步点处置。先明确哪些门禁必须等迭代评审结论，哪些可以并行。对必须等待的门禁，把触发条件从固定日期改为“迭代评审结论发布”这一事件；对可以并行的门禁，把材料要求拆成“评审前可提交部分”和“评审后补充部分”，减少空等。调整后保留原规则备份，记录改动前后的触发时点对比。
交付边界处置。组织门禁审核方与迭代评审方共同修订完成定义，形成一份双方共用的交付物清单，明确每项交付物的粒度、验收标准和责任人。清单落到具体工作项上，评审通过即代表对应工作项达到约定状态，门禁按同一份清单核对，不再另设口径。
评审输入输出处置。固定评审输入清单，材料不齐不进入评审；统一结论模板，结论必须包含通过判定、遗留项、责任人和期限；返工项登记为独立工作项并跟踪到关闭，门禁审核时可直接引用评审结论和闭环状态。
涉及门禁规则改动时，风险边界需要提前交代：先在单个项目或单条产品线上试点一个迭代周期，保留原规则备份，设定停止点——若试点期内等待时长未下降或返工轮次上升，回退到原规则再分析。门禁规则往往与合规、质量要求相关，改动前应确认没有外部约束禁止调整触发条件。
验证恢复与防止复发
处置是否有效，用处置前后的同口径数据对比，而不是凭感受判断。建议跟踪三个指标：门禁触发到材料受理的平均等待时长、同一交付物的平均返工轮次、迭代评审结论在门禁环节被推翻的次数。取处置前最近2–3次事件作为基线，处置后观察至少两个完整迭代周期，软硬件混合项目中硬件阶段较长时，观察窗口应覆盖一次门禁完整触发。
验证时注意区分改善来源。如果同期还调整了人员或范围，指标变化不能全部归因于本次处置，需在复盘中说明。指标未改善时，回到取证表检查是否有第二层根因未被处理。
防止复发靠把结论写成可检查的约定，而不是停留在会议纪要里：
- 同步点约定：列出门禁清单，逐项标注触发条件（日期或事件）和是否依赖迭代评审结论；
- 交付边界约定：维护双方共用的交付物与完成定义清单，变更时同步修订；
- 评审输入输出约定：输入清单和结论模板作为评审准入条件，返工项闭环状态纳入门禁核对项；
- 例行复盘：每个迭代或每个门禁周期结束后，核对一次等待时长与返工轮次，发现连续两次异常即启动重新诊断。
这三类约定可以放在项目文档中与工作项关联，使约定本身可追溯、可核对。约定是否被执行，比约定写得多细更影响复发概率，复盘时优先检查执行记录而非文档完整性。
常见问题
等待时长在处置后没有明显下降，应该先怀疑哪一层？
先回到取证表，检查是否存在第二层根因未被处理。同步点问题被调整后，如果交付边界仍未对齐，门禁仍会因完成定义不一致而退回材料，等待时长不会明显改善。另一种常见情况是观察窗口不足：软硬件混合项目中硬件阶段较长，处置后只观察了一个迭代，可能还没覆盖一次完整的门禁触发。建议先确认观察窗口是否覆盖完整门禁周期，再逐层核对取证记录。
门禁触发条件从固定日期改为依赖迭代评审结论，会不会影响合规或质量要求？
有可能。部分门禁与外部合规、质量签署或客户交付节点绑定，触发条件不能随意调整。改动前应先确认该门禁是否存在外部约束，例如合同约定的评审节点或行业要求的阶段签署。若存在约束，可考虑保留门禁时点、把材料要求拆分为评审前可提交部分与评审后补充部分，减少空等而不改变门禁本身。调整方案确定后先小范围试点并保留原规则备份。
评审结论已经明确通过，门禁仍然退回，这种情况算交付边界问题还是输入输出问题？
看退回理由指向什么。如果门禁认为交付物粒度不够或完成定义不符，而评审按另一套标准判定通过，属于交付边界问题——双方各自按规则执行，规则本身没有对齐。如果门禁退回是因为评审结论缺少可引用的依据，例如结论未写明验收范围、遗留项未登记，则属于评审输入输出问题。区分方法是核对门禁退回意见与评审结论的具体表述，看差异出在标准口径还是结论完整性。
项目里同时存在同步点错位和评审输入不齐，应该先改哪一个？
先处理时间轴上的错位。时间错位会放大后两层的症状：门禁在迭代中途触发，材料天然不完整，此时去补评审输入清单，效果会被时间问题掩盖。建议先调整同步点，观察一个完整周期，再处理交付边界和评审输入输出。如果两类问题相互独立、改动互不影响，也可以并行推进，但需分别记录改动前后的数据，避免无法判断哪项调整起了作用。
复发预防的约定写在文档里就够了吗？
约定是否被执行，比写得多细更影响复发概率。建议把同步点清单、交付物与完成定义清单、评审输入清单和结论模板与具体工作项关联，使约定可追溯、可核对。复盘时优先检查执行记录，例如返工项是否登记了责任人与期限、门禁核对时是否引用了评审结论，而不是只看文档是否完整。连续两次出现等待时长或返工轮次异常，即启动重新诊断。
