累积流图上的水平断层，指某条状态曲线在一段时间内几乎水平延伸，说明该状态的在制品数量停止增长，流入与流出大致相等，工作项在这里排队。断层只回答“卡在哪里”，具体原因要结合断层所在状态、前后曲线斜率以及队列与等待时间证据判断。本文给出形态识别、原因假设与验证证据、处置步骤和恢复验证方法。
要点总览（TL;DR）
- 水平断层指某条状态曲线在一段时间内近似水平延伸，该状态在制品数量基本不变，流入与流出大致相等，工作项在此排队等待下游承接。
- 断层只说明卡在哪里，具体原因要结合断层所在状态、下游状态带是否同步变宽、下游等待时间是否上升、上游是否阶梯式批量交付来判断。
- 排查按先口径、再下游、后上游的顺序推进，先核对状态定义与流转日志排除假断层，再逐类验证原因假设。
- 处置按锁定状态与时段、核对等待原因、选择处置动作、设置观察窗口与停止条件推进，调整在制品上限前先评估对交付节奏的影响。
- 恢复看断层状态在制品数量是否恢复增长、平均等待时间是否回落，并与断层发生前同一指标对比；把断层纳入流动回顾固定检查项预防复发。
水平断层在累积流图上是什么形态
累积流图的横轴是时间，纵轴是工作项累计数量，相邻两条状态曲线之间的垂直间距就是该状态的在制品数量。水平断层表现为某条状态带的上、下边界在时间轴上近似平行延伸，带子宽度基本不变。它说明这段时间内进入该状态的工作项数量与离开的数量接近，队列长度稳定，工作项在该状态处停留、等待下游承接。
识别断层时，先确认自己看的是哪条状态线。累积流图通常按“待办—分析—开发—测试—待发布—完成”等状态分层，断层出现在不同状态之间，指向的环节不同：断层出现在开发完成到测试开始之间，多指向测试承接能力；出现在评审状态，多指向评审资源或评审规则；出现在待发布状态，多指向发布窗口与外部依赖。断层位置是后续排查的第一条线索。
水平断层容易与另外两种形态混淆，需要分开识别：
| 形态 | 图形特征 | 在制品含义 | 常见指向 |
|---|---|---|---|
| 水平断层 | 某状态带上下边界近似平行，宽度基本不变 | 该状态在制品数量稳定，流入约等于流出 | 该状态或其下游存在承接卡点，工作项在此排队 |
| 状态带变宽 | 上下边界间距持续扩大 | 该状态在制品持续累积，流入快于流出 | 下游消化能力不足，或上游持续批量输入 |
| 状态带变窄 | 上下边界间距持续缩小 | 该状态队列在消化，流出快于流入 | 下游恢复承接，或上游供给减少 |
| 整体上移 | 最上方累计完成曲线持续上升 | 累计完成量增长 | 交付在推进，需结合各状态带宽度看流动是否健康 |
读图有一个前提：各状态定义一致，工作项按进入和离开每个状态的时间记录。如果状态口径中途调整、流转记录缺失或补录，曲线形态会失真，可能出现看似断层、实际是记录断档的情况。判断断层前，先确认这段时间的状态定义和记录方式没有变化。
水平断层对应的阻塞原因假设与排除证据
看到断层后，可以列出几类原因假设，但每类都要找到对应证据才能成立。图形只提供线索，结论要靠流转日志、等待时长和交接记录来验证。下面按假设、证据、排查顺序展开。
假设一：下游环节容量不足
这是最常见的方向。该状态的工作项能进来，却出不去，队列停在原地。验证证据有两条：一是看下游状态带是否同步变宽，如果下游在制品持续累积，说明瓶颈可能在下游而非当前状态；二是看下游队列的等待时间是否上升，工作项进入下游后到开始处理之间的间隔拉长，支持容量不足的判断。两条证据同时出现，假设的可信度较高。
假设二：上游批量交付
上游按批次集中交付，会让下游状态在短时间内接收大量工作项，随后一段时间流入暂停，曲线呈现阶梯式跳变后走平。验证时看上游状态带是否呈阶梯式上升、交付批次是否集中在少数时间点。如果断层前有明显的批量涌入，断层可能是批量节奏造成的排队，而非下游能力绝对不足。
假设三：评审、测试或外部依赖排队
评审资源有限、测试环境排队、外部团队交接等待，都会让工作项在某个状态停留。验证证据是该状态的等待时长分布和交接记录：拉出这段时间内停留最久的工作项，看它们的等待发生在哪个环节、等待对象是谁。等待时长集中在少数工作项还是普遍拉长，指向的原因不同——前者可能是个别工作项卡在特殊依赖上，后者更可能是资源或规则问题。
假设四：状态定义或记录口径问题造成的假断层
状态合并、拆分或流转记录补录，会让曲线出现不真实的平段。验证方法是把工作项流转日志与图形对照，看这段时间内是否真的没有工作项离开该状态。如果日志显示有流转但图形未反映，问题在记录口径，不在流程阻塞。
排查顺序
建议按“先口径、再下游、后上游”的顺序推进：
- 先核对状态定义与流转日志，排除假断层。这一步成本低，能避免在错误方向上投入分析。
- 再看下游承接：下游状态带是否变宽、下游等待时间是否上升，判断瓶颈是否在下游。
- 最后看上游供给：上游是否阶梯式批量交付，判断断层是否由输入节奏造成。
- 三类都排除后，回到断层所在状态本身，检查该状态的资源、规则与外部依赖。
这个顺序的价值在于：口径问题会污染后面所有判断，先排除它；下游与上游的证据互相印证，能缩小原因范围。每一步都应有书面记录，写明看了哪些数据、得出什么判断，避免把假设直接当成结论去改流程。
确认阻塞后的处置步骤
原因确认后，处置要按步骤推进，每一步有明确动作、责任角色和停止点。以下步骤适用于大多数断层场景，具体动作按原因类型选择。
第一步：锁定断层所在状态与时间段
由负责流动分析的角色（如团队负责人或敏捷教练）拉出断层时段内该状态停留最久的工作项清单，记录每项的进入时间、离开时间、停留时长和当前状态。这份清单是后续核对的事实基础，也是处置后对比的基线。
第二步：与相关角色核对实际等待原因
带着清单与开发、测试、评审或外部依赖方逐一核对，确认每项工作项的实际等待原因，形成书面记录。核对的目的不是追责，而是把图形上的平段还原成具体的等待事件。记录应包含等待对象、等待时长和当时可用的承接资源。
第三步：按原因类型选择处置动作
不同原因对应不同动作：
- 下游容量不足：补充评审或测试承接能力，或临时调整人员分工，优先消化积压队列。
- 上游批量交付：拆分批量，把集中交付改为小批多次，降低下游瞬时压力。
- 评审或外部依赖排队：明确评审时限与升级路径，或与外部团队约定交接节奏。
- 在制品整体偏高：限制在制品上限，先停止新工作项进入，让队列消化。
调整在制品上限或流程规则前，先确认对交付节奏的影响范围：哪些工作项会因此延后、延后多久、是否影响对外承诺。影响范围超出可接受程度时，改用局部调整，例如只对某一状态设上限，而非全流程收紧。
第四步：设置观察窗口与停止条件
每项处置动作都要配一个观察窗口，例如两周或两个迭代，并明确停止或回退条件：如果断层状态的在制品数量开始恢复增长、等待时间回落，动作继续；如果等待时间没有改善或下游出现新的积压，回退该动作并重新核对原因。观察窗口内不叠加多项规则调整，避免无法判断哪项动作起了作用。
如何验证恢复并预防断层复发
处置是否有效，要看可观察的指标，而不是感觉队列变短了。验证围绕两个指标展开：断层状态的在制品数量是否恢复增长，说明工作项重新流动；该状态的平均等待时间是否回落，说明排队在缓解。两个指标一起看，避免只看到制品变化而忽略等待质量。
对比基线用断层发生前的同一指标，而不是处置后的即时值。观察周期建议覆盖至少一个完整交付周期，让批量交付、评审节奏等因素都能体现在数据里。如果指标在观察周期内稳定改善，处置可以转为常规做法；如果反复波动，回到原因假设重新核对。
复发预防靠固定检查机制：把累积流图形态纳入流动回顾的固定检查项，每次回顾看各状态带宽度变化和是否出现新的平段，发现断层苗头时提前排查，而不是等队列明显积压再处理。断层时段的工作项清单与处置记录要留存，后续出现类似形态时可以直接对照，缩短诊断时间。
这些诊断动作依赖可靠的状态流转记录：工作项何时进入、何时离开每个状态，停留了多久。ONES 的工作项状态流转记录可以支撑这类数据回溯，团队在核对断层时段、拉取停留最久的工作项时，能从系统中找到对应的流转时间和状态变化，把图形上的平段还原成具体的等待事件。记录口径一致、流转及时，累积流图的形态才可信，后续的原因验证和恢复对比才有依据。
常见问题
水平断层持续多久才值得作为流程阻塞来排查？
没有统一的时间阈值，判断依据是断层是否与交付节奏或等待时间的变化同时出现。如果断层跨越了一个完整的交付周期，且该状态的平均等待时间相比之前明显拉长，就值得按阻塞排查。断层时间很短、随后状态带恢复变宽或变窄，更可能是批量交付或集中评审带来的正常波动，先记录观察即可。
断层出现在多个状态上，应该先处理哪一个？
先看最靠近下游的断层，也就是离完成状态最近的那条。下游卡住会向上游传导，上游状态带随之变宽或走平，如果先处理上游，可能只是缓解表象。确认下游断层的原因并处置后，再观察上游断层是否随之缓解；如果上游断层仍然存在，再单独排查上游自身的资源或规则问题。
状态定义中途调整过，之前的累积流图还能用来对比吗？
状态口径变化前后的曲线不能直接对比，断层位置和宽度都会失真。可行的做法是以调整时间为界分段看：调整后的数据用于当前诊断，调整前的数据只作为历史参考，不用于计算等待时间的变化幅度。如果确实需要跨口径对比，先把工作项流转日志按新口径重新归类，再生成对照视图，并在记录中注明口径调整的时间点。
限制在制品上限后，断层没有消失反而出现了新的断层，怎么处理？
先确认新断层出现的位置。如果新断层出现在被限制状态的上游，说明限制把排队推到了上游，需要检查上游是否具备消化能力，或把限制范围缩小到单个状态。如果新断层出现在下游，说明下游承接能力本身不足，限制在制品只是把问题暴露出来。无论哪种情况，都先回退本次规则调整，回到原因核对环节，避免在多个规则叠加的情况下判断失效。
团队规模较小、状态划分简单时，还需要专门做断层分析吗？
状态少、流转快的小团队，累积流图上的断层往往持续时间短，分析成本可能高于收益。这类团队可以把重点放在等待时间上：定期看工作项在各状态的停留时长，发现某一状态普遍拉长时再回到累积流图确认形态。状态划分较细、跨团队交接较多的场景，断层更容易持续，固定检查累积流图形态的收益更明显。
