任务看板示例的价值在于把“谁在做、卡在哪、下一步是什么”变成一眼可读的卡片和列。下面用一张演示看板完整走一遍：先定执行问题，再配列与卡片字段，最后用筛选控制范围。示例中的项目、人员、日期均为演示情景，用于说明填写方法，不代表真实客户案例。
要点总览（TL;DR）
- 一张可用的任务看板示例包含四部分：列划分与流转规则、卡片正面与详情字段、视图筛选与排序、一组演示数据分布。
- 列即状态，移动卡片等于更新状态；阻塞独立成列便于站会看见停滞任务，解除后回到原列。
- 卡片正面只放标题、负责人、优先级、截止日期四个字段，描述与验收标准放入详情，保证列内扫视效率。
- 迁移到其他团队时按“先列执行问题—再定列—再定卡片字段—最后设筛选”的顺序调整，试运行一周后删减空列和未用字段。
- 示例聚焦工作项呈现，不涉及在制品限制等 Kanban 机制与效能度量，演示数据不能当作真实项目基线。
示例目标：这张任务看板要回答什么
假设有一个跨角色交付小组，成员包括需求、设计、开发、测试四类角色，共同推进一个为期六周的内部系统改版。小组每周一开一次站会，平时各自推进任务。这个情景下，看板承担的任务是把分散在多人手中的工作项集中呈现，让站会讨论和日常协作有共同的参照。
这张看板需要回答三个执行问题：第一，谁在做——每张卡片能直接看到当前负责人；第二，卡在哪——通过列位置和阻塞标记识别停滞的工作项；第三，下一步是什么——通过优先级和截止日期判断接下来该推进什么。三个问题对应三类信息，也决定了后面列和字段的设置取舍。
需要先说明假设条件，避免读者误读示例数据：
- 小组规模为8人左右，任务粒度控制在半天到三天可完成的工作项；
- 工作项类型统一为“任务”，暂不区分需求、缺陷等类型；
- 看板按周更新，站会时集中检视，平时由负责人自行移动卡片；
- 示例中的项目名称、人员姓名、日期均为虚构，仅用于演示填写方式。
明确这些条件后，看板的列数、字段数量和筛选规则才有讨论基础。团队规模更大或任务粒度更细时，同样的思路需要调整参数，这一点在第四节展开。
完整示例：一张已填好的任务看板
下面给出这张看板的完整配置，包括列划分、卡片字段、筛选排序和一组演示数据的分布。读者可以对照自己的项目直接替换内容。
列划分与流转规则
看板设五列，每列对应一个工作项状态，并约定进入和退出条件：
| 列名 | 对应状态 | 进入条件 | 退出条件 |
|---|---|---|---|
| 待启动 | 未开始 | 工作项已创建并分配负责人 | 负责人开始处理，移入进行中 |
| 进行中 | 处理中 | 负责人已投入实际工作 | 产出物提交，移入待评审 |
| 待评审 | 待验收 | 产出物完成并提交评审 | 评审通过移入已完成；退回则回到进行中 |
| 阻塞 | 处理中（标记阻塞） | 出现外部依赖或问题导致无法推进 | 阻塞解除后回到原列 |
| 已完成 | 已完成 | 评审通过或确认无需评审 | 本周内保留，周会后归档 |
卡片正面与详情字段
卡片正面只放四个字段，保证一屏内可读：任务标题、负责人、优先级、截止日期。卡片详情补充描述、验收标准、关联文档、阻塞原因四项，点开卡片查看。优先级取值限定为高、中、低三档；截止日期精确到日；阻塞原因仅在卡片进入阻塞列时必填。
视图筛选与排序
看板视图设置两个筛选条件：所属项目等于“内部系统改版”，状态不等于“已归档”。排序规则为优先级从高到低，同优先级按截止日期从近到远。这样站会时高优先级、临近截止的任务自然排在列的上方。
演示数据分布
假设当前有12个工作项，分布如下：待启动3项（其中2项高优先级）、进行中4项（1项高优先级）、待评审2项、阻塞1项（高优先级，阻塞原因为等待外部接口文档）、已完成2项。站会上按列从左到右检视，阻塞列的高优先级任务优先讨论，待评审列确认评审人是否到位，待启动列确认本周能否启动。
这张看板的配置可以在工作项视图中落地：ONES 的工作项视图支持按状态分列呈现任务，并通过字段与筛选条件控制卡片显示内容。具体配置方式以实际产品界面为准，示例重点在于说明字段与列的搭配思路。
逐项解释：每个字段和列为什么这样设
示例中的每个选择都对应一个执行问题，理解依据比照抄配置更重要。下表逐项说明设置理由和取值口径：
| 配置项 | 设置方式 | 理由与取值口径 |
|---|---|---|
| 状态列 | 五列对应五个工作项状态 | 列即状态，移动卡片等于更新状态，避免列与状态两套口径并存导致信息不一致 |
| 阻塞列 | 独立成列而非标签 | 阻塞需要被看见和讨论，独立列让停滞任务在站会上无法被忽略；解除后回到原列，保留原状态 |
| 负责人 | 单一负责人 | 每项任务只有一个当前负责人，协作人放在详情中，避免“人人有责等于无人负责” |
| 优先级 | 高、中、低三档 | 三档足够区分处理顺序，档位过多会导致判断标准模糊；高优先级需在站会上说明理由 |
| 截止日期 | 精确到日 | 用于排序和识别临近任务；不设具体时刻，避免制造虚假精确 |
| 筛选条件 | 项目加状态两个条件 | 控制看板只显示当前项目未归档的工作项，范围过宽会稀释看板的执行焦点 |
| 排序规则 | 优先级优先，截止日期其次 | 与站会讨论顺序一致，列内自上而下即处理顺序 |
卡片信息量的取舍值得单独说明。正面四个字段是站会扫视所需的最小集合，描述和验收标准属于执行细节，放在详情中按需查看。如果正面塞入描述摘要，卡片高度不一，列内扫视效率下降。反过来，如果正面只有标题，站会时无法判断优先级和时限，讨论会退化为逐张点开。四个字段是这张看板的平衡点，团队可以按自己的讨论习惯增减，但每次增减都应回答“站会上是否会用到这个信息”。
筛选条件的作用容易被低估。同一批工作项如果全部显示在一张看板上，已完成和已归档的任务会占据列空间，进行中的任务被挤到下方。用项目和状态两个条件收窄范围后，看板只呈现当前需要决策的工作项，这也是看板能承担执行可视化任务的前提。
可迁移规律：换一个团队怎么改这张看板
把示例迁移到其他团队时，调整顺序比调整内容更重要。建议按以下步骤进行：
- 先列出团队站会要回答的执行问题，通常不超过四个；
- 按问题确定列：每个列对应一个需要被看见的停滞点或交接点，问题里没有的环节不设列；
- 确定卡片正面字段，每个字段对应一个站会判断动作，用不到的字段移入详情；
- 设置筛选条件，把看板范围限定在当前周期、当前项目内；
- 用一周的真实任务试运行，站会后记录哪些列长期为空、哪些字段从未被查看，据此删减。
迁移检查点包括：列数是否超过团队站会能在十分钟内走完的数量；是否存在两个列的实际含义重叠；卡片正面字段是否都能在站会上被使用；筛选条件是否把已完成任务排除在外。任何一项不满足，先调整再扩大使用范围。
看板之外，列表视图适合按截止日期批量排查和排序，日历视图适合查看任务在时间轴上的分布与冲突。三种视图共享同一批工作项数据，看板负责执行推进，列表负责批量核对，日历负责时间安排。团队不必只选一种，按场景切换即可。
维护规则宜简单可执行：每周站会后清理已完成列，把上周完成的任务归档；每月检查一次列设置，连续四周为空的列考虑合并；负责人变更时当天更新，不留无主卡片。规则越少越容易坚持，重点是固定节奏而非规则数量。
适用边界：示例不覆盖哪些情况
这张示例看板聚焦工作项的呈现与流转，有几类情况不在覆盖范围内，读者需要区分。
示例不涉及在制品限制等 Kanban 机制。列上没有设置数量上限，也不讨论拉动式流转和流动效率。如果团队希望用看板控制并行任务数量，需要在示例基础上另行设计限制规则，这属于另一套方法范畴。
示例不涉及组织效能度量与统计分析。看板回答的是“当前谁在做什么、卡在哪”，不回答周期时间分布、吞吐量趋势或团队效能对比。需要这类分析时，应基于工作项历史数据另行设计度量口径，示例中的列和字段不构成度量基础。
示例中的演示数据不能当作真实项目基线。12个工作项的分布、阻塞比例、完成节奏都是为说明填写方法而设定的，不代表任何真实团队的工作状态，也不应被引用为参考数值。读者迁移时应使用自己团队的实际数据重新填写。
此外，示例假设任务粒度均匀、角色边界清晰。任务粒度差异很大或存在大量跨团队依赖的项目，需要先拆分工作项或增加依赖标识字段，再套用本示例的列结构。
常见问题
看板列数多少合适，站会走不完怎么办？
列数由团队站会要回答的执行问题决定，通常控制在站会十分钟内能走完的数量。如果列数偏多，先检查是否存在含义重叠的两列，合并后再看连续几周为空的列，空列可以暂时移除。列多本身不是问题，问题在于每列是否对应一个需要被看见的交接点或停滞点。
卡片正面字段能不能加描述摘要？
可以加，但要先回答“站会上是否会用到这个信息”。描述摘要会让卡片高度不一致，列内扫视效率下降；如果团队站会确实需要快速了解任务内容，可以保留一行短摘要并限制字数。更常见的做法是把描述、验收标准放在卡片详情中，站会时按需点开。
阻塞列和给任务打阻塞标签有什么区别？
独立成列让阻塞任务在站会上无法被忽略，列位置本身就是讨论顺序的一部分；标签需要额外筛选或扫视才能发现。使用阻塞列时，卡片进入该列需填写阻塞原因，解除后回到原列并保留原状态，这样既看见停滞，也不丢失任务原本的进展信息。
看板和列表、日历视图需要重复维护数据吗？
不需要。三种视图共享同一批工作项数据，看板负责执行推进，列表适合按截止日期批量核对和排序，日历适合查看任务在时间轴上的分布与冲突。团队按场景切换视图即可，字段和状态只需维护一份。
小团队任务少，还需要设五列吗？
任务少时可以精简。保留“进行中”和“已完成”两列即可起步，出现评审交接或外部依赖时再增加待评审、阻塞列。列随执行问题增长而增加，比一开始照搬完整结构更容易坚持，也避免空列稀释看板的执行焦点。
