任务看板列设置的核心做法是：先按团队真实流转阶段确定列，再为每列写清进入条件、退出条件和责任人，接着把工作项状态与列一一映射，明确排序、容量提示和归档规则，最后用一批真实任务试跑一周。列的数量控制在5到7个，每个列都能回答“谁在等什么、下一步做什么”。下面按列划分、字段定义、状态映射、呈现配置、角色分工、完整示例和上线检查七步展开。
要点总览（TL;DR）
- 列按团队真实流转阶段或等待角色切分，数量控制在5到7个，保证一屏看清全貌。
- 每列写清进入条件、退出条件、责任人和停留上限四个字段，条件要具体到可判断。
- 工作项状态与看板列建立明确映射，状态可以比列细，但每列必须列出包含哪些状态。
- 呈现层配置排序、在制品数量提示和已完成列归档规则，权限默认全员可见、按需收紧。
- 用真实任务试跑一周，检查超时、跳列和状态不一致，三项通过再正式使用。
先定列的划分依据：按流转阶段还是按角色
列从哪里切分，决定了看板能否反映真实工作。开始设置前，先回答一个问题：团队的任务在推进过程中，主要卡在阶段推进上，还是卡在等待某个人或某个角色上。答案不同，列的划分方式也不同。
按流转阶段划分的适用情形
当任务需要经过几个明确的处理环节，且每个环节的完成标准相对稳定时，按阶段划分列更合适。例如“待处理—进行中—待验证—已完成”，每列对应一个可判断的完成状态。这种划分适合流程相对固定、交接动作清晰的团队，列名直接描述工作进展到什么程度。
按角色或等待对象划分的适用情形
当任务频繁在角色之间交接，且等待时间主要消耗在“等某个人处理”上时，按角色划分列更能暴露瓶颈。例如“待开发—待测试—待产品确认”，每列代表任务当前由谁负责或等谁处理。这种划分适合跨职能协作密集、交接环节多的团队，列名直接回答“现在在等谁”。
两种划分混用时的常见问题
同一块看板里既有阶段列又有角色列，容易出现语义重叠。例如“开发中”和“待测试”并列时，一个任务究竟算开发阶段还是等待测试角色，边界会变得模糊。混用还会导致同一任务在两列之间反复移动，看板上的位置无法稳定反映真实状态。如果确实需要同时表达阶段和角色，建议以其中一种为主划分列，另一种通过标签、负责人字段或子列表达，避免列本身承担两套语义。
列数量控制在5到7个的理由
列太少，任务堆积在同一列里，无法看出卡在哪一步；列太多，每列停留的任务变少，看板失去整体视图，成员每天移动卡片的操作成本也会上升。5到7列通常能覆盖从进入到完成的主要环节，同时保证一屏之内看清全貌。超过7列时，先检查是否有可以合并的相邻阶段，或是否有列长期没有任务停留。
完成这一步的产出是一句明确结论：本团队按流转阶段划分，还是按角色划分，列清单是哪几个。这个结论是后续字段填写和状态映射的基础。
每一列要写清的四个字段：进入条件、退出条件、责任人、停留上限
列名只是标签，真正让列可执行的是四个字段。缺任何一个，列就会退化成“大家凭感觉拖卡片”的区域。建议用一张列定义表把四个字段固定下来，作为团队共同遵守的规则。
进入条件与退出条件的写法示例
进入条件回答“任务满足什么才能放进这一列”，退出条件回答“任务满足什么才能离开这一列”。写法要具体到可判断，避免“基本完成”“差不多”这类模糊表述。例如“待验证”列：进入条件是“开发自测通过并提交验证说明”，退出条件是“验证通过并记录结果，或退回并注明问题”。条件写成动作加结果，任何人对照都能判断是否满足。
列责任人的指定方式
每列指定一名责任人，负责该列内任务的推进和规则执行。责任人可以是具体角色而非固定个人，例如“待测试”列由测试负责人担任。责任人的职责包括：检查进入条件是否满足、推动任务尽快满足退出条件、发现长期滞留时发起协调。责任人不是审批人，不需要逐张卡片签字，而是对该列的流转质量负责。
停留上限或预警阈值的设定思路
停留上限是任务在某列允许停留的最长时间，超过即触发提醒。设定时参考该类任务在该环节的常见耗时，取一个略高于正常值的数，例如“进行中”列设为3个工作日。没有历史数据时，可以先设一个初始值，试跑一周后按实际分布调整。阈值的作用是让滞留可见，而不是考核个人。
字段空白时会导致的看板失真
进入条件空白，任务会被提前放入，列内混入未就绪的工作；退出条件空白，任务完成与否靠个人判断，列无法清空；责任人空白，滞留任务无人推动；停留上限空白，长期不动的任务沉在列底无人察觉。四种空白叠加，看板上的位置就不再代表真实进展，团队会逐渐失去对看板的信任。
| 列名 | 进入条件 | 退出条件 | 责任人 | 停留上限 |
|---|---|---|---|---|
| 待处理 | 需求已确认并拆分为可执行任务 | 负责人领取并开始处理 | 需求负责人 | 5个工作日 |
| 进行中 | 已领取，明确负责人和预计完成时间 | 完成开发并自测通过 | 开发负责人 | 3个工作日 |
| 待验证 | 提交验证说明，注明改动范围 | 验证通过并记录结果，或退回注明问题 | 测试负责人 | 2个工作日 |
| 已完成 | 验证通过，结果已记录 | —（归档列） | — | — |
把工作项状态映射到列：避免状态与列重复
工作项状态和看板列是两套表达，状态描述任务处于什么阶段，列描述任务在界面上放在哪里。两者没有对应关系时，同一任务可能在状态上显示“已完成”却停在“进行中”列，看板就失去可信度。设置时需要明确映射规则。
状态与列一对一、一对多的取舍
一对一映射最清晰：每个状态对应唯一一列，卡片移动即状态变更。适合状态数量与列数量接近、流程简单的团队。一对多映射适合状态更细的场景，例如“开发中”和“联调中”两个状态都归入“进行中”列，列提供整体视图，状态保留细节。取舍标准是：看板需要多细的视图，就设多少列；状态可以比列更细，但每列必须能明确包含哪些状态。
状态多于列时的合并方式
状态多于列时，把语义相近、责任人和退出条件一致的状态合并到同一列。例如“待评审”“评审中”合并为“评审”列。合并前确认这些状态的下一步动作相同，否则合并后列内任务的处理方式会不一致。合并后在列定义中列出包含的状态，避免成员困惑。
列多于状态时的补充方式
列多于状态时，说明某些列需要独立的状态支撑。例如“待验证”列如果没有对应状态，卡片移入后状态仍显示“进行中”，会造成状态与位置不一致。此时应补充状态，或把该列合并回相邻列。补充状态时同步更新状态流转规则，确保状态变更与卡片移动同步发生。
映射调整对历史数据的影响
调整映射前，先确认历史任务的状态会如何显示。合并状态时，原状态下的历史任务需要批量迁移到新状态，否则报表和筛选会出现断层。删除列时，列内任务要先迁移到目标列，避免任务失去位置。建议在调整前导出当前状态分布，调整后核对数量是否一致，保留一次变更记录。
| 看板列 | 包含的工作项状态 | 映射方式 |
|---|---|---|
| 待处理 | 新建、已确认 | 一对多 |
| 进行中 | 开发中、联调中 | 一对多 |
| 待验证 | 待验证 | 一对一 |
| 已完成 | 已完成、已关闭 | 一对多 |
列的排序、容量提示与归档规则怎么配
规则定义完成后，进入呈现层配置。这一层决定看板在界面上是否好用，包括列的顺序、数量提示、已完成列的处理以及谁能看到什么。
列从左到右的排序原则
按任务实际流转顺序从左到右排列，最左侧是任务进入的起点，最右侧是完成。这样成员扫视看板时，视线方向与工作推进方向一致。如果团队按角色划分列，则按交接顺序排列，例如“待开发—待测试—待确认”。排序确定后保持稳定，频繁调整顺序会让成员形成的位置记忆失效。
在制品数量提示的设置方式与适用条件
在制品数量提示用于提醒某列任务过多。设置方式是为列配置一个数量上限，超过时在列头显示提示。适用条件是团队已经能稳定执行进入和退出条件，否则提示会被频繁触发而失去意义。初始上限可参考团队人数和该环节的平均并行处理能力，试跑后调整。提示的作用是引发讨论，不自动阻止任务进入。
已完成列的归档与清理规则
已完成列会持续累积卡片，影响看板加载和浏览。建议设置归档规则：任务完成后经过固定周期（例如两周）自动归档，或按迭代结束时统一清理。归档前确认任务的结果和验证记录已保存，归档后仍可通过筛选查询。已完成列默认折叠或只显示最近若干条，保持看板主体清爽。
列权限与可见范围的设置考虑
列的可见范围按团队协作需要设置。涉及敏感信息（如安全验证、客户数据确认）的列，可限制为相关角色可见或可编辑，其他成员只读。权限设置过严会增加交接成本，过松则可能让未授权成员误改状态。建议默认全员可见，仅对确有保密需要的列单独配置。
在工具中落地时，ONES 工作项管理支持按状态配置看板列、设置列内工作项的状态映射，并通过筛选和视图控制列的可见范围，列定义和状态规则可以在同一套工作项配置中维护。配置完成后，建议用少量真实任务验证卡片移动是否同步触发状态变更。
角色分工：谁定义列、谁维护列、谁评审列
列设置不是一次性的配置动作，需要明确谁发起、谁日常维护、谁在什么时点评审，否则规则会随使用逐渐松动。
列定义的发起人与审批人
列定义通常由团队负责人或敏捷教练发起，负责收集成员对流转环节的意见，形成列清单和字段草案。审批人由团队共同确认，可以是团队负责人，也可以是团队会议集体通过。审批的内容是列划分依据、列数量和四个字段是否完整，不涉及具体工具操作细节。
日常维护列规则的责任角色
每列的责任人负责日常维护：检查进入和退出条件是否被遵守、处理超时滞留、在规则与实际不符时提出调整建议。团队负责人定期汇总各列情况，判断是否需要修改列定义。维护动作记录在变更记录中，便于追溯。
列调整的评审时点与触发条件
固定评审时点可以放在每个迭代结束或每月一次，检查列是否仍反映真实流转。触发临时评审的条件包括：某列长期无任务停留、某列任务频繁超时、状态与列出现不一致、团队流程发生明显变化。评审只调整有问题的列，避免整体推倒重来。
变更记录的留存方式
每次调整记录变更日期、调整内容、原因和影响范围。记录可以放在团队文档或工作项配置说明中，与列定义表放在一起。变更记录的作用是让新成员了解规则演变，也为回退提供依据。
| 角色 | 职责 | 交付物 | 时点 |
|---|---|---|---|
| 团队负责人/敏捷教练 | 发起列定义，组织讨论 | 列清单与字段草案 | 设置初期 |
| 团队集体 | 审批列划分与字段完整性 | 审批结论 | 设置初期 |
| 列责任人 | 执行列规则，处理滞留 | 列内任务流转记录 | 日常 |
| 团队负责人 | 组织评审，汇总调整建议 | 变更记录 | 迭代结束/触发时 |
一个五人研发小组的列设置示例
以下示例为演示情景，用于说明前述步骤如何串起来，不代表特定团队的真实数据。
示例团队的列清单与字段填写
该小组负责一个内部系统的持续迭代，任务从需求确认到上线验证。按流转阶段划分，设5列：待处理、进行中、待验证、待上线、已完成。字段填写如下：
| 列名 | 进入条件 | 退出条件 | 责任人 | 停留上限 |
|---|---|---|---|---|
| 待处理 | 需求已确认，任务描述含验收要点 | 负责人领取并给出预计完成时间 | 需求负责人 | 5个工作日 |
| 进行中 | 已领取，明确负责人 | 开发完成并自测通过，提交验证说明 | 开发负责人 | 3个工作日 |
| 待验证 | 提交验证说明，注明改动范围 | 验证通过并记录结果，或退回注明问题 | 测试负责人 | 2个工作日 |
| 待上线 | 验证通过，上线清单已确认 | 上线完成并记录版本 | 发布负责人 | 2个工作日 |
| 已完成 | 上线完成，结果已记录 | —（归档列） | — | — |
状态映射结果
该小组的状态设置为：新建、已确认、开发中、联调中、待验证、待上线、已完成、已关闭。映射关系为：待处理列包含新建和已确认；进行中列包含开发中和联调中；待验证列对应待验证；待上线列对应待上线；已完成列包含已完成和已关闭。状态比列细，列提供整体视图，状态保留环节细节。
试跑一周后的调整点
试跑一周后，小组发现两个问题。第一，“进行中”列任务经常超过3个工作日，原因是联调依赖外部系统，等待时间被算进了开发时间。调整方式是把“联调中”从进行中列拆出，单独设“联调”列，停留上限设为2个工作日，让等待外部响应的任务可见。第二，“待上线”列的任务经常被跳过，直接移到已完成，原因是上线操作由发布负责人统一执行，开发人员不移动卡片。调整方式是在列定义中明确由发布负责人移动卡片，并在每日站会上核对。
示例可迁移的规律
这个示例说明三点：列的数量和划分依据要匹配团队真实的等待结构，等待外部依赖的环节值得单独成列；停留上限要按环节的实际耗时设定，不能所有列用同一个值；卡片移动的责任人要明确到角色，否则列会被绕过。其他团队可以参照这个结构，但列清单和阈值需要按自己的流转情况重新确定。
上线前的完成检查：列设置是否可用的判断标准
列设置完成后，用一份检查清单逐项核对，确认看板可以投入使用。检查分为定义完整性、映射一致性和试跑观察三部分，每项给出通过标准。
列定义完整性的检查项
- 每列都有进入条件和退出条件，且条件可判断，不含“基本完成”等模糊表述。
- 每列都有明确的责任人角色，责任人知道自己的维护职责。
- 每列都有停留上限或预警阈值，阈值有设定依据。
- 列数量在5到7个之间，或超出时有明确的合并理由。
状态映射一致性的检查项
- 每个工作项状态都能归入某一列，没有游离状态。
- 每列包含的状态在列定义中列出，成员可查。
- 卡片移动会同步触发状态变更，抽查若干任务确认一致。
- 历史任务在映射调整后数量核对一致，无任务丢失位置。
试跑观察指标与通过标准
用一批真实任务试跑一周，观察三项指标：是否有任务在某一列停留超过上限且无人处理；是否有列被整体跳过，任务直接从前面列移到后面列；状态与列是否出现不一致。通过标准是：超时任务都有处理记录，被跳过的列有明确原因或已调整，状态与列无不一致。三项都满足，看板可以正式使用。
需要回退调整的阻断条件
出现以下情况时，先回退调整再上线：超过三分之一的卡片移动后状态未同步；某列连续一周无任务停留且无合理解释；团队成员无法说清某列的进入条件；状态与列的映射存在多义，同一任务可归入两列。阻断条件的作用是防止带着明显缺陷的看板进入日常使用，避免团队形成错误的操作习惯。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 定义完整性 | 进入/退出条件、责任人、停留上限 | 四项齐全且可判断 |
| 定义完整性 | 列数量 | 5到7列，或超出有合并理由 |
| 映射一致性 | 状态归属与同步 | 无游离状态，移动同步变更 |
| 映射一致性 | 历史数据 | 调整后数量核对一致 |
| 试跑观察 | 超时、跳过、不一致 | 均有处理记录或已调整 |
| 阻断条件 | 同步失败、空列、条件不清、映射多义 | 均未出现 |
完成以上检查后，列设置即可投入使用。后续按评审时点定期检查，列规则随团队流转变化持续调整，看板才能长期保持可信。
常见问题
团队任务类型差异很大，一块看板放不下，列应该怎么处理？
按任务类型拆成多块看板，每块看板各自定义列，而不是把所有类型塞进同一组列。拆分依据可以是工作项类型（需求、缺陷、运维任务）或业务线。拆分后保持各看板列定义表独立维护，但状态体系尽量共用一套，避免同一工作项在不同看板里状态含义不一致。跨看板的汇总视图可以另建，用于整体查看，不承担流转规则。
列设置好之后，成员仍然不按规则移动卡片，怎么办？
先检查规则本身是否可执行：进入和退出条件是否具体到任何人对照都能判断，责任人是否清楚自己的维护职责。规则模糊时，成员会按自己的理解操作。规则清楚仍不执行，通常与卡片移动的责任人未明确有关，需要在列定义中写清由谁移动，并在每日站会或迭代会上核对列内任务。把看板位置与状态同步绑定，移动卡片即变更状态，也能减少随意拖动。
停留上限设多少合适，没有历史数据怎么定初始值？
参考该类任务在该环节的常见耗时，取略高于正常值的数作为初始值，例如开发环节常见2天完成，可先设3个工作日。没有历史数据时，先按团队经验估一个值，试跑一周后看实际分布：多数任务在上限内完成说明阈值合理；大量任务超时说明阈值偏紧或环节本身存在等待，需要区分是规则问题还是流程问题。不同列按各自环节设定，不用统一数值。
调整列或合并状态时，历史任务的数据怎么处理才不出问题？
调整前先导出当前各状态和列的任务数量作为基线。合并状态时，把原状态下的历史任务批量迁移到目标状态；删除列时，先把列内任务迁移到目标列。调整完成后核对数量是否与基线一致，确认没有任务失去位置。保留一次变更记录，写明调整内容、原因和影响范围，便于后续追溯和必要时回退。
在制品数量提示会不会限制团队正常工作？
数量提示的作用是让某列任务过多这件事可见，引发讨论，不自动阻止任务进入。适用条件是团队已经能稳定执行进入和退出条件；规则尚不稳定时频繁触发提示，反而会让成员忽略它。初始上限参考团队人数和该环节的平均并行处理能力，试跑后调整。提示被触发时，团队应检查是任务确实积压，还是上限设得过低。
