任务看板的列怎么划，取决于团队希望看板回答什么问题。工作项状态列回答“这件事现在卡在谁手里、能不能往下走”，研发阶段列回答“这件事在交付链条上走到了哪一步”。多数团队以工作项状态作为列的主干，把研发阶段作为泳道、标签或筛选条件叠加；当流程本身按阶段交接、各阶段责任人和交付物差异明显时，才把研发阶段提升为列。角色职责一般作为泳道或筛选维度，不单独充当列。
要点总览（TL;DR）
- 看板列划分先看团队希望看板回答什么问题：工作项状态列回答“卡在谁手里、能不能往下走”，研发阶段列回答“在交付链条上走到哪一步”。
- 流程稳定、状态定义清晰、角色较多的团队，以工作项状态作为主列，角色用泳道或筛选视图承载。
- 阶段交接明确、各阶段交付物与评审要求不同的项目，可把研发阶段提升为列，并配套阶段门准入准出条件、控制列数。
- 标准流程与差异化工作流并存时，采用“统一主干、差异叠加”：状态为主列，阶段作标签或分组，差异用泳道和子视图表达。
- 列结构变更前做评审，试点期观察阻塞识别速度与列间回流次数，据此判断列划分是否贴合协作。
两种列划分方式的核心区别
工作项状态列与研发阶段列的本质差异，在于它们描述的是工作项的不同属性。状态描述“流转条件是否满足”，阶段描述“交付链条走到哪一环”。同一张看板上两者可以同时存在，但承担不同职责：列承载流转，阶段信息用泳道、标签或分组呈现。
判断一张看板该用哪种列，可以先问：团队每天站会时最想一眼看到什么？如果最常讨论的是“这张卡为什么三天没动、卡在谁那里”，状态列更合适；如果最常讨论的是“这个需求评审过了没有、测试环境部署了没有”，阶段列更合适。
| 比较维度 | 工作项状态列 | 研发阶段列 |
|---|---|---|
| 列回答的核心问题 | 这件事现在卡在谁手里、能不能往下走 | 这件事在交付链条上走到了哪一步 |
| 粒度与变更频率 | 粒度较细，随日常流转频繁变化 | 粒度较粗，随阶段交接变化，频率较低 |
| 责任人归属 | 状态对应明确的处理角色或处理动作 | 阶段对应阶段负责人或阶段交付物 |
| 与评审/准入准出的配合 | 通过完成定义约束流转条件 | 天然与阶段门评审、准入准出条件配合 |
| 列数膨胀风险 | 较低，状态数量通常可控 | 较高，阶段细分容易导致列数增加 |
| 跨角色可读性 | 较强，非技术角色也能理解“待处理、处理中、待验证” | 依赖团队对阶段定义的共识，跨团队可读性较弱 |
这张表说明：状态列偏向“协作视角”，阶段列偏向“交付视角”。两者并非互斥，问题在于哪一类信息值得占据列这个最显眼的位置。
按工作项状态划分列的适用条件
状态列适合流程相对稳定、状态定义清晰、团队对“什么算完成”有共识的场景。典型如迭代内的任务协作：待处理、处理中、待验证、已完成，四到六列即可覆盖大部分日常流转。列数与状态数对齐，一列只对应一个状态，避免“处理中”同时容纳开发和联调两种含义。
设计状态列时，需要把流转规则写进列的完成定义，而不只是给列起个名字：
- 每列标注进入条件与离开条件，例如“待验证”要求开发自测通过并附上验证说明。
- 状态与处理角色对应，让卡片停在某一列时，团队知道下一步该找谁。
- 控制列数，超过七八列时考虑合并低频状态，或把细分信息放到标签上。
- 为阻塞设置显式表达方式，例如阻塞标记或独立泳道，避免阻塞信息淹没在列内。
状态列的优势在跨角色协作中尤其明显：产品、开发、测试看到同一列名，能快速判断工作项处于什么处理环节、需要谁介入。代价是状态定义需要持续维护，状态语义漂移会让看板逐渐失真。
按研发阶段划分列的适用条件
阶段列适合阶段交接明确、各阶段交付物差异明显的流程。例如需求、设计、开发、测试、发布各环节由不同角色负责，每个环节有独立的产出物和评审要求，此时列本身就是交付链条的可视化，卡片从左到右移动即代表阶段推进。
阶段列要与阶段门评审、准入准出条件配合才有意义：进入“测试”列前要求开发完成自测并提交构建，进入“发布”列前要求测试报告通过。缺少这些条件，阶段列容易退化为装饰性的进度条。
把阶段做成列需要付出管理成本，主要有两类：
- 列数膨胀。阶段细分越细，列越多，看板越宽，站会扫视成本越高。常见做法是把相邻阶段合并，或把子阶段放到标签上。
- 跨阶段回流。测试发现问题退回开发、评审不通过退回设计，这类回流在阶段列上表现为卡片逆向移动，需要明确回流规则，否则看板会频繁出现“倒流”而失去稳定读图。
阶段列更适合交付周期较长、阶段间存在正式交接和评审的项目；对于节奏快、状态频繁变化的迭代任务，阶段列往往过重。
角色职责作为列还是泳道
角色职责通常不作为列。原因在于角色列与状态列语义高度重叠：一张卡片处于“开发中”，往往同时意味着它由开发角色处理，用列表达角色等于把两个维度压进一个维度，列名会变得含混。
更合适的放置方式是泳道或筛选维度：列承载流转，泳道承载角色或团队，同一列内按泳道分行，既能看出整体流转，也能看出各角色的工作量分布。按角色筛选视图则适合个人视角的日常查看，让成员只关注与自己相关的工作项。
角色临时作为列的情况较少，一般出现在角色即流程节点的场景，例如需要按“产品确认、开发实现、测试验收”严格串行交接的小团队。即便如此，也应确认这些角色节点同时具备状态含义，否则仍建议回到泳道方案。
标准流程与差异化工作流下的取舍
团队在标准流程与差异化工作流之间选择列结构时，可执行路径是“统一主干、差异叠加”：主干列采用工作项状态，保证跨团队可读和统一汇报口径；差异化部分通过泳道、标签、子视图承载，让不同工作流在不改变主干列的前提下表达自身特点。
列结构变更本身有成本：列增减会影响历史数据的归类、报表口径和成员习惯。因此变更前应做一次评审，明确变更原因、影响范围和迁移方式，避免频繁调整导致看板失去可信度。
混合方案的具体做法是：状态为主列，研发阶段作为标签或分组条件。这样既保留状态列的流转可读性，又能按阶段聚合查看交付进度。试点阶段可观察两个指标：阻塞识别速度，即站会上发现卡点所需时间；列间回流次数，即卡片逆向移动的频率。前者改善说明列结构更贴合协作，后者过高说明阶段或状态定义需要收敛。
适配场景与选择建议
综合前文，可按流程稳定性、交接密度和角色数量三个条件给出选择建议：
| 团队情况 | 建议列结构 | 补充说明 |
|---|---|---|
| 流程稳定、状态定义清晰、角色较多 | 以工作项状态为主列 | 角色用泳道或筛选视图承载 |
| 阶段交接明确、各阶段交付物与评审要求不同 | 以研发阶段为主列 | 配套阶段门准入准出条件，控制列数 |
| 标准流程与差异化工作流并存 | 状态为主列，阶段作标签或分组 | 统一主干，差异用泳道和子视图表达 |
| 小团队、角色即流程节点 | 可临时用角色列 | 确认角色节点同时具备状态含义 |
列结构确定后，需要明确维护责任与复盘节奏：指定一名看板维护人负责列定义与流转规则，按迭代或季度复盘列的使用情况，重点看阻塞识别是否变慢、回流是否增多。列结构是管理约定的载体，约定变化时列也应随之调整。
这些管理动作最终要落到工作项与文档状态上。以 ONES Project 为例，团队可以编写需求并自定义需求状态与属性，用看板等工具实时掌握进度；多种视图与全局、项目内筛选可让不同角色聚焦各自关注的数据，组件化设计支持按业务需求定义项目类型与组件，适配不同流程。状态流转的联动也可借助 ONES Automation 的预置规则模板，例如任务与需求的状态联动、父子工作项状态联动，减少手工同步。列结构怎么划是团队的管理选择，工具承担的是让状态、视图与筛选稳定承载这套约定。
常见问题
看板列已经按状态划分，研发阶段信息放在哪里比较合适？
常见做法是把阶段信息放到标签、分组条件或泳道中，列仍然承载状态流转。这样站会扫视时先看到卡片停在哪个处理环节，需要看交付进度时再按阶段聚合或筛选。如果阶段信息使用频率很高、几乎每次讨论都要看，可以评估是否把阶段提升为列，同时接受列数增加带来的扫视成本。
小团队人少、角色就是流程节点，可以直接用角色作为看板列吗？
可以临时使用，但需要确认这些角色节点同时具备状态含义，例如“产品确认、开发实现、测试验收”本身就是串行交接的处理环节。若角色节点与状态语义重叠不明显，列名会变得含混，建议回到状态列加泳道的方案。团队规模扩大或角色分工细化后，角色列通常需要重新调整。
列结构定下来之后，多久复盘一次比较合适？
可以按迭代或季度复盘，重点看两件事：站会上发现卡点是否变慢，卡片逆向移动是否增多。前者变慢说明列没有覆盖团队真正关心的流转信息，后者增多说明状态或阶段定义需要收敛。列结构是管理约定的载体，约定变化时列也应随之调整，调整前做一次评审，明确影响范围和迁移方式。
状态列和阶段列能不能在同一张看板上同时作为列使用？
技术上可以，但列会同时承载两种语义，读图成本明显上升。更清晰的分工是列承载一种主干维度，另一种用泳道、标签或分组呈现。若确实需要同时展示，建议明确哪一类信息是站会主看内容，另一类作为辅助信息放在卡片字段或筛选条件中。
用工具落地列结构时，状态、视图和筛选需要怎么配合？
以 ONES Project 为例，团队可以编写需求并自定义需求状态与属性，用看板等工具实时掌握进度；多种视图与全局、项目内筛选可让不同角色聚焦各自关注的数据，组件化设计支持按业务需求定义项目类型与组件。状态流转的联动可借助 ONES Automation 的预置规则模板，例如任务与需求的状态联动、父子工作项状态联动，减少手工同步。列结构怎么划是团队的管理选择，工具承担的是让状态、视图与筛选稳定承载这套约定。
