任务看板出现空列和阻塞，往往同时涉及列定义和实际流转：列分得太细、阶段已经合并，会让某些列长期没人进入；缺少阻塞标记、退出条件模糊，则会让卡片停在同一列里看不出原因。调整时先记录每列的在制数量和停留时长，再判断该合并列、补充阻塞标记，还是重写列的进入与退出条件。ONES 可用于承载工作项状态与看板视图的对应关系，具体列设置方式以团队实际配置为准。
要点总览（TL;DR）
- 先记录每列的在制数量、平均停留时长和空列出现频率，用一段完整交付周期的数据区分“偶发空闲”和“阶段已不存在”。
- 空列多来自列粒度细于实际流转或阶段已合并；阻塞多来自缺少阻塞标记、阻塞与等待混在同一列，两类现象要分开诊断。
- 调整按优先级推进：合并长期空列或降为子状态、为阻塞设置独立标记或泳道、重写每列进入与退出条件、统一列名与工作项状态。
- 调列适合已有稳定流转记录且团队对列含义有共识的情况；阻塞源于外部依赖未解决时，先做标记和记录，暂缓合并与重写。
- 用调整前后的空列比例、阻塞标记率、阻塞停留时长和卡片回流次数做对照，观察周期覆盖一个完整交付周期，无记录时只作观察假设。
先看清当前列设置与调整目标
调整列结构前需要一段观察期，用现有数据回答“哪一列空、空多久、为什么空”。没有基线就直接改列，容易把原本正常的阶段合并掉，也无法判断调整是否有效。观察期不必很长，覆盖一个完整的任务交付周期即可，例如两周或一个迭代。
观察时逐列记录四项信息：列名、当前在制数量、卡片平均停留时长、该列出现空列的频率。在制数量反映列是否被使用，停留时长反映卡片是否卡住，空列频率则帮助区分偶发空闲和长期闲置。记录方式可以用表格手工统计，也可以从看板的流转记录中导出，关键是口径统一，比如停留时长按工作日还是自然日计算，要在开始时就定下来。
空列需要进一步区分两种情况：一种是这一列确实有任务会进入，只是观察期内恰好没有；另一种是它所代表的阶段在实际流程中已经不存在，任务从上一列直接跳到下一列。前者属于正常波动，后者才是列定义需要调整的信号。判断依据可以看历史流转记录中该列是否长期没有进入记录，以及团队成员是否说不清这一列该放什么。
调整目标要写成可观察的结果，避免“让看板更清晰”这类无法验证的表述。可用的目标包括：把长期空列数量降到某一范围、让每张阻塞卡片在列上有明确标记、缩短卡片在某一列的平均停留时长、让每列的进入条件能被成员用一句话说清。目标确定后，后续的合并、标记和条件重写都围绕它展开。
一份可用的现状观察清单如下：
| 列名 | 在制数量 | 平均停留时长 | 空列出现频率 | 初步判断 |
|---|---|---|---|---|
| 待处理 | 较多 | 短 | 几乎不空 | 保留 |
| 方案设计中 | 0–1 | — | 经常空 | 核查是否与需求分析重复 |
| 开发中 | 较多 | 较长 | 几乎不空 | 保留，关注停留时长 |
| 联调等待 | 若干 | 很长 | 不空但停滞 | 疑似阻塞，需加标记 |
| 已验收 | — | — | — | 终点列，不参与空列判断 |
表中数值为演示情景，实际填写时以团队自己的记录为准。终点列和入口列通常不纳入空列统计，因为它们承担的是收口和缓冲作用。
空列和阻塞分别暴露了什么问题
空列和阻塞看起来是两种现象，成因却常常同源：列的含义没有被定义清楚。空列多来自列粒度细于实际流转、阶段被合并、入口条件不清；阻塞多来自缺少阻塞标记、阻塞与普通等待混在同一列、退出条件模糊。把这两类现象分开诊断，才能避免用同一种动作去处理不同的问题。
| 现象 | 常见成因 | 判断依据 | 容易走的误区 |
|---|---|---|---|
| 某列长期为空 | 列粒度细于实际流转，任务直接跳过该阶段 | 历史记录中该列长期无进入 | 认为列越多管理越细 |
| 某列偶尔为空 | 阶段真实存在但任务量少 | 观察期内有少量进入记录 | 急于合并，丢失阶段信息 |
| 两列内容高度重叠 | 阶段已被合并，列名未同步 | 成员说不清两列区别 | 靠改名掩盖定义问题 |
| 卡片长期停在某列 | 缺少阻塞标记，阻塞与等待混在一起 | 卡片无标记但停留时长异常 | 把阻塞当成个人效率问题 |
| 卡片反复回流 | 退出条件模糊，未达标就流转 | 同一卡片多次回到前一列 | 增加更多列来拦截 |
空列本身不一定是问题。任务量小的团队，某些阶段天然低频，列空着是正常状态。真正需要处理的是长期无进入记录、且成员无法说明其用途的列。判断时可以问两个问题：这一列最近一个月有没有卡片进入？如果没有，团队能否说出什么情况下卡片应该进入这一列？两个问题都答不上来，这一列才进入合并候选。
阻塞的处理误区更值得注意。把阻塞卡片留在原列不动，看板上只表现为“这一列停留时间长”，无法区分是在正常推进还是在等外部依赖。久而久之，团队会对长停留习以为常，阻塞被淹没在日常等待里。另一种误区是把阻塞归因为某个人动作慢，而实际原因可能是接口未就绪、评审未安排或环境不可用。列结构能解决的是让阻塞可见，不能替代对阻塞原因的排查。
还有一种误区是靠不断加列来解决所有问题：发现联调经常卡住就加一列“联调中”，发现测试排队就加一列“待测试”。列越加越多，每列的在制数量越来越少，空列随之增加，看板反而更难读。列的数量应当与团队实际能区分的阶段相匹配，超出这个范围的细分适合放到子状态或标签里。
优先调整动作：合并、标记与列含义重写
调整按优先级推进，先做改动小、收益直接的动作，再处理需要团队重新达成共识的部分。建议顺序是：合并长期空列、为阻塞设置独立标记或泳道、重写每列的进入与退出条件、统一列名与工作项状态的对应关系。
第一步，合并长期空列或改为子状态。对观察期内长期无进入、且成员说不清用途的列，直接合并到相邻阶段。如果该阶段仍有区分价值，但发生频率低，可以把它降为子状态或标签，保留信息而不占用一列。合并后要同步更新列名，避免出现“开发中（含设计）”这类含糊表述。合并的动作会改变历史数据的统计口径，调整前的停留时长按旧列统计，调整后按新列统计，对照时需要在同一口径下比较，或明确标注口径变化。
第二步，为阻塞设置独立标记或泳道。阻塞卡片需要在不离开原列位置的前提下被识别出来。常见做法有两种：一种是在卡片上加阻塞标记，并记录阻塞原因和解除条件；另一种是在看板上增加一条阻塞泳道，卡片进入阻塞时移入泳道，解除后回到原列。前者改动小，适合阻塞事件不多的团队；后者让阻塞整体可见，适合阻塞频繁、需要集中跟进的场景。两种做法都要求阻塞有明确的解除条件，否则标记会长期挂着，失去提示作用。
第三步，重写每列的进入条件与退出条件。进入条件回答“卡片满足什么才能放进这一列”，退出条件回答“满足什么才能离开”。条件要具体到可核对，例如“代码已提交并通过自测”比“开发完成”更可判断。退出条件同时也是阻塞的识别依据：卡片长时间不满足退出条件，就应当检查是否被阻塞。每列的条件写完后，团队需要一起过一遍，确认理解一致。
第四步，统一列名与工作项状态的对应关系。看板列是工作项状态的一种视图呈现，列名与状态名不一致时，成员在更新状态和拖动卡片之间会产生歧义。调整时把列名、状态名和状态流转规则放在一起核对，确保一张卡片在看板上的位置能反映它真实的状态。ONES 的工作项状态与看板视图可用于承载这种对应关系，具体配置方式建议按团队使用的版本核对后再落地。
调整方案可以用一张表固化下来：
| 列名 | 处理方式 | 进入条件 | 退出条件 | 阻塞处理 |
|---|---|---|---|---|
| 待处理 | 保留 | 已确认进入本周期 | 开始分析或开发 | — |
| 方案设计中 | 合并入需求分析 | — | — | — |
| 开发中 | 保留 | 方案已确认 | 代码提交并自测通过 | 加阻塞标记，注明原因 |
| 联调等待 | 改为阻塞标记 | — | — | 进入阻塞泳道，解除后回开发中 |
| 已验收 | 保留 | 验收通过 | — | — |
表中内容为演示结构，团队应按自己的阶段划分填写。合并列和新增阻塞标记会改变成员的操作习惯，落地时最好配一次简短说明，讲清每列的新含义和阻塞标记的使用时机。
调整的适用前提与代价
调列适合在已有稳定流转记录、团队对列含义有基本共识的情况下进行。如果看板刚上线、卡片流转还不规律，此时观察到的空列可能只是样本不足，贸然合并会丢掉尚未显现的阶段。建议先积累一段可用的流转记录，再启动调整。
调整的代价主要有三项。一是历史数据口径变化：合并列之后，调整前后的停留时长和空列比例不在同一口径上，直接对比会失真，需要在对照时说明口径差异，或只比较调整后稳定运行的一段数据。二是成员需要重新适应列含义：列名改了、进出条件重写了，成员在最初一段时间可能仍按旧习惯放卡片，需要通过评审或站会及时纠正。三是阻塞标记可能被滥用：如果解除条件不明确，标记会长期挂着，反而降低看板的可信度。
有些情况应当暂缓调列。当阻塞主要来自外部依赖尚未解决，例如第三方接口未提供、跨团队评审排期未定，调整列结构只能提高阻塞的可见性，不能消除阻塞本身。此时先把阻塞标记和原因记录做起来，把问题暴露给相关方，列结构的合并与重写可以等依赖有进展后再做。同理，如果团队对阶段划分本身存在分歧，先通过几次复盘对齐阶段含义，比直接改列更有效。
暂缓调整的判断条件可以归纳为：观察期不足一个完整交付周期、团队无法就某列用途达成一致、阻塞原因集中在外部依赖且短期无解。满足其中任一条，优先做记录和沟通，把列结构调整放到下一轮。
用流转数据验证调整效果
调整是否有效，要看调整前后的对照数据，不能凭感觉判断。对照的核心指标有两个：空列比例和阻塞停留时长。空列比例按观察期内空列数占总列数的比例统计，阻塞停留时长按卡片从标记阻塞到解除阻塞的时间统计。两个指标都需要在调整前后用相同的统计口径各取一段数据。
| 观察项 | 调整前记录 | 调整后记录 | 判断方式 |
|---|---|---|---|
| 长期空列数量 | 按观察期统计 | 同口径统计 | 数量下降且无新增长期空列 |
| 阻塞卡片标记率 | 标记数/阻塞发生数 | 同口径统计 | 标记率上升，说明阻塞可见性改善 |
| 阻塞平均停留时长 | 按标记到解除统计 | 同口径统计 | 时长缩短，且解除原因有记录 |
| 卡片回流次数 | 按卡片统计 | 同口径统计 | 回流减少，说明退出条件更清晰 |
| 成员对列含义的说明一致性 | 抽查若干成员 | 同口径抽查 | 能一致说出进入与退出条件 |
观察周期建议覆盖调整后的一个完整交付周期，并在周期结束时做一次复盘。复盘时逐项核对：空列是否减少、减少的空列是否确实无用、阻塞卡片是否被及时标记和解除、有没有出现新的长停留列。如果某项指标没有改善，先检查是调整动作没落地，还是指标本身受其他因素影响，例如任务量整体下降也会让空列增多，这类相关性不能直接当作调整无效的结论。
效果数字需要有记录支撑。没有留存调整前的数据时，只能把调整后的观察结果作为假设，在下一轮继续积累对照，不宜对外表述为改善幅度。ONES 的看板视图和工作项流转记录可作为观察素材，是否提供列停留时长等统计，建议按团队实际使用的版本核对。验证的目的不是证明某次调整正确，而是让下一轮列结构调整有据可依。
常见问题
看板刚上线不久就出现空列，应该马上合并吗？
不建议马上合并。刚上线时卡片流转还不规律，观察到的空列可能只是样本不足，此时合并容易丢掉尚未显现的阶段。建议先积累一个完整交付周期的流转记录，再判断哪些列是长期无进入、且成员说不清用途的，这类列才进入合并候选。偶发为空的列可以先保留，继续观察。
阻塞卡片是留在原列加标记，还是单独设一条阻塞泳道？
两种做法都可行，选择取决于阻塞发生的频率和跟进方式。阻塞事件不多、由个人自行跟进时，在原列加阻塞标记并记录原因和解除条件，改动小、成本低。阻塞频繁、需要集中跟进时，增加一条阻塞泳道，卡片进入阻塞时移入泳道、解除后回到原列，整体可见性更好。无论哪种做法，都要有明确的解除条件，否则标记会长期挂着，失去提示作用。
合并列之后，调整前后的停留时长还能直接对比吗？
不能直接对比。合并列会改变统计口径，调整前的停留时长按旧列统计，调整后按新列统计，直接比较会失真。处理方式有两种：一是在对照时明确标注口径变化，只比较调整后稳定运行的一段数据；二是保留调整前的原始记录，按新列口径重新归并后再比较。口径说明要写进复盘记录，避免后续误读。
阻塞主要来自外部依赖，调列还有意义吗？
有意义，但作用限于提高可见性。当阻塞源于第三方接口未提供、跨团队评审排期未定等外部依赖时，调整列结构不能消除阻塞本身。此时先把阻塞标记和原因记录做起来，把问题暴露给相关方，列结构的合并与重写可以等依赖有进展后再做。如果团队对阶段划分本身还有分歧，先通过复盘对齐阶段含义，比直接改列更有效。
调整后多久能判断是否有效？
建议观察周期覆盖调整后的一个完整交付周期，并在周期结束时做一次复盘。对照指标包括长期空列数量、阻塞卡片标记率、阻塞平均停留时长和卡片回流次数，调整前后用相同口径各取一段数据。某项指标没有改善时，先检查调整动作是否落地，再排除任务量整体下降等外部因素，不把相关性直接当作调整无效的结论。
