研发任务看板的列设置，需要把“工作流阶段”和“卡片上展示的字段”分开处理：列对应任务从进入到完成所经过的状态，卡片字段对应不同角色在扫视看板时需要看到的信息。本文提供研发任务、缺陷修复、运营任务三套可直接复制的空白列设置表，并说明每个字段的填写口径、必填与选填规则、完整填写示例，以及模板上线后的调整与维护方法。
要点总览（TL;DR）
- 看板列设置分两层：列对应工作流阶段，卡片字段对应角色扫视时需要的信息，先定列再定字段。
- 研发任务、缺陷修复、运营任务三套空白表结构一致，均含列名、列含义、进入条件、退出条件、卡片字段五栏，可直接复制填写。
- 必填项以“缺了就无法判断能否移动或找不到责任人”为标准：列名与进出条件必填，卡片字段中标题、负责人通用必填，各场景再补一个判断节奏的字段。
- 进入与退出条件写成可核验的事实，并与相邻列的进出条件对应，看板移动才有共同依据。
- 模板上线后按迭代结束和季度初检查：列是否仍匹配流程、卡片字段是否仍被使用，变更需评审并同步通知。
三套可复制的空白列设置模板
三张表的结构一致，都包含列名、列含义、进入条件、退出条件、卡片字段五栏。复制到文档或工具中后，按团队实际流程逐行填写；每张表末尾保留两行空白行，用于新增列或拆分列。列的顺序即看板上从左到右的顺序。
研发任务看板空白列设置表
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待梳理 | 已提出但尚未明确范围和验收口径的任务 | 任务被提出并登记 | 范围、验收标准、负责人已确认 | 标题、提出人、优先级 |
| 待开发 | 已确认、尚未开始编码的任务 | 需求评审通过并完成排期 | 开发人员开始编码 | 标题、负责人、计划完成时间、关联需求 |
| 开发中 | 正在编码或联调的任务 | 开发人员领取任务并开始工作 | 代码提交并通过自测 | 标题、负责人、计划完成时间、阻塞标记 |
| 待评审 | 代码已提交、等待评审或测试验证 | 自测通过并提交评审 | 评审通过或测试验证通过 | 标题、负责人、评审人、提交时间 |
| 已完成 | 通过验证、可交付的任务 | 评审与验证均通过 | 任务关闭或进入发布批次 | 标题、负责人、完成时间 |
缺陷修复看板空白列设置表
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待确认 | 已提交、尚未判定是否为缺陷 | 缺陷被提交并登记 | 确认可复现并定级 | 标题、提交人、严重程度、影响版本 |
| 待修复 | 已确认、尚未开始修复 | 缺陷定级并指派负责人 | 负责人开始定位问题 | 标题、负责人、严重程度、计划修复时间 |
| 修复中 | 正在定位或修改代码 | 负责人开始处理 | 修复完成并提交验证 | 标题、负责人、严重程度、阻塞标记 |
| 待验证 | 修复已提交、等待回归验证 | 修复代码合入待验证环境 | 验证通过或验证不通过退回 | 标题、负责人、验证人、修复版本 |
| 已关闭 | 验证通过、缺陷结束 | 回归验证通过 | 缺陷关闭 | 标题、负责人、关闭时间 |
运营任务看板空白列设置表
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待策划 | 已提出、方案尚未成形的运营任务 | 任务被提出并登记 | 方案与排期确认 | 标题、提出人、目标渠道、期望上线时间 |
| 待执行 | 方案已定、尚未开始执行 | 方案评审通过并明确负责人 | 负责人开始执行 | 标题、负责人、上线时间、关联活动 |
| 执行中 | 正在制作内容、配置或投放 | 负责人领取任务并开始执行 | 执行完成并提交检查 | 标题、负责人、上线时间、阻塞标记 |
| 待复核 | 执行完成、等待数据或质量复核 | 执行结果提交复核 | 复核通过或退回修改 | 标题、负责人、复核人、提交时间 |
| 已完成 | 复核通过、任务结束 | 复核通过 | 任务归档 | 标题、负责人、完成时间 |
列与卡片字段的填写说明
模板中每一栏承担不同职责：列定义任务处在流程的哪个位置，进入与退出条件定义任务何时可以移动，卡片字段定义卡片上显示哪些信息。填写时先定列，再定条件，最后按角色关注点挑选卡片字段，顺序颠倒容易把看板做成字段清单。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 列名 | 看板上一个阶段的简短名称 | 用两到四个字概括阶段，全表用词风格统一，避免“开发中”“正在开发”混用 |
| 列含义 | 该阶段覆盖的工作范围 | 一句话说明这一列里放什么任务，用于新成员理解和评审时对齐 |
| 进入条件 | 任务可以移入该列的前提 | 写成可核验的事实，如“评审通过”“代码已提交”，避免“差不多完成”这类主观描述 |
| 退出条件 | 任务可以离开该列的前提 | 与下一列的进入条件对应，保证移动有依据；退出条件通常就是下一列进入条件的另一种表述 |
| 卡片字段 | 卡片正面展示的信息项 | 按该列主要读者的关注点选取，控制在三到五项；详情类信息放在卡片内页而非正面 |
| 状态与列的关系 | 工作项状态在看板上的呈现方式 | 列通常映射一个或多个状态；若工具中列与状态绑定，新增列前先确认状态是否已存在，避免列与状态两套口径并行 |
| 场景差异 | 不同看板对同一字段的不同要求 | 研发任务看“计划完成时间”，缺陷看“严重程度”和“影响版本”，运营任务看“上线时间”和“目标渠道”，按场景替换而非全部保留 |
进入与退出条件的写法直接影响看板可信度。建议用“动作完成＋可观察结果”的结构，例如“代码提交并通过自测”，而不是“开发完成”。条件写成事实后，站会上的移动动作就有共同依据，也便于后续统计各列停留时间。
哪些字段必填、哪些可以选填
必填项的作用是保证看板可读、可流转；选填项的作用是补充特定角色的信息需求。判断标准是：缺少该字段会导致任务无法判断能否移动，或无法找到责任人，就设为必填；只影响阅读便利的，设为选填。
| 层级 | 必填 | 选填 |
|---|---|---|
| 列设置 | 列名、进入条件、退出条件 | 列含义（团队规模小、流程共识强时可省略，但建议保留） |
| 卡片字段（通用） | 标题、负责人 | 优先级、标签、关联需求 |
| 研发任务看板 | 标题、负责人、计划完成时间 | 提出人、评审人、关联需求、阻塞标记 |
| 缺陷修复看板 | 标题、负责人、严重程度 | 提交人、影响版本、修复版本、验证人 |
| 运营任务看板 | 标题、负责人、上线时间 | 提出人、目标渠道、关联活动、复核人 |
不同场景的必填差异来自流转判断依据的不同：研发任务靠排期判断是否延期，缺陷靠严重程度判断处理顺序，运营任务靠上线时间判断节奏。选填字段的取舍原则是“有人看才留”：连续两个迭代无人使用的字段应移入卡片详情；只有个别角色关注的字段，可通过筛选视图而非卡片正面呈现。
三套模板的完整填写示例
以下示例按S1的表结构填写，字段与S2说明、S3必填规则一一对应，可直接作为团队首次配置的参照。
研发任务看板填写示例
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待梳理 | 已提出、范围待明确的任务 | 任务登记到需求池 | 验收标准与负责人确认 | 标题、提出人、优先级 |
| 待开发 | 已排期、未开始编码 | 需求评审通过并进入迭代 | 开发人员领取任务 | 标题、负责人、计划完成时间 |
| 开发中 | 编码与联调进行中 | 开发人员领取并开始编码 | 代码提交并通过自测 | 标题、负责人、计划完成时间、阻塞标记 |
| 待评审 | 等待代码评审与测试验证 | 自测通过并提交评审 | 评审与验证通过 | 标题、负责人、评审人 |
| 已完成 | 验证通过、可交付 | 评审与验证通过 | 任务关闭 | 标题、负责人、完成时间 |
缺陷修复看板填写示例
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待确认 | 已提交、待判定 | 缺陷登记并附复现步骤 | 确认可复现并完成定级 | 标题、提交人、严重程度、影响版本 |
| 待修复 | 已定级、未开始修复 | 定级完成并指派负责人 | 负责人开始定位 | 标题、负责人、严重程度 |
| 修复中 | 定位与修改进行中 | 负责人开始处理 | 修复提交到待验证环境 | 标题、负责人、严重程度、阻塞标记 |
| 待验证 | 等待回归验证 | 修复代码合入待验证环境 | 回归验证通过 | 标题、负责人、验证人、修复版本 |
| 已关闭 | 验证通过、缺陷结束 | 回归验证通过 | 缺陷关闭 | 标题、负责人、关闭时间 |
运营任务看板填写示例
| 列名 | 列含义 | 进入条件 | 退出条件 | 卡片字段 |
|---|---|---|---|---|
| 待策划 | 方案未成形的运营任务 | 任务登记并明确目标 | 方案与排期确认 | 标题、提出人、目标渠道 |
| 待执行 | 方案已定、未开始执行 | 方案评审通过并指派负责人 | 负责人开始执行 | 标题、负责人、上线时间 |
| 执行中 | 内容制作或投放进行中 | 负责人领取并开始执行 | 执行完成并提交复核 | 标题、负责人、上线时间、阻塞标记 |
| 待复核 | 等待数据或质量复核 | 执行结果提交复核 | 复核通过 | 标题、负责人、复核人 |
| 已完成 | 复核通过、任务结束 | 复核通过 | 任务归档 | 标题、负责人、完成时间 |
模板的调整与维护方法
模板上线后需要按固定节奏检查，否则列会越加越多、卡片字段会越堆越满。调整的依据来自实际使用中的卡点，而不是流程文档的设想。
新增或合并列的判断依据
- 某一列长期积压且内部任务处理方式明显不同，例如“开发中”同时容纳编码和联调，可拆为两列。
- 相邻两列的进入与退出条件几乎相同、任务停留时间很短，可合并为一列。
- 新增列前先确认对应工作项状态是否已存在，避免列与状态形成两套口径。
卡片字段的定期清理
- 每个季度统计一次卡片字段的使用情况，连续两个迭代无人查看的字段移入卡片详情。
- 新增字段时同步说明使用角色和使用场景，避免为个别需求增加全员可见字段。
列设置变更的评审与通知
- 涉及列增删或进入退出条件变化的调整，由看板维护人发起，相关角色确认后生效。
- 变更生效当天在看板说明或团队频道同步，注明生效时间和影响范围。
维护责任人与检查时点
- 指定一名看板维护人，负责列设置、字段规则和变更记录。
- 检查时点建议放在每个迭代结束时和季度初，分别核对列是否仍匹配流程、字段是否仍被使用。
在协作工具中落地时，列设置对应看板的列配置，卡片字段对应卡片正面展示的属性。以ONES为例，看板列可与工作项状态对应配置，卡片上展示哪些属性可按视图调整，字段变更后团队成员在同一看板中看到一致的信息。维护人可据此把上述检查动作落到具体配置上：先核对状态与列的对应关系，再调整卡片展示字段，最后同步变更通知。
常见问题
团队刚开始用看板，三套模板应该先上哪一套？
从当前任务量最大、流转最频繁的那类工作开始。研发任务看板覆盖从梳理到交付的主线，适合作为第一套；如果线上问题积压明显，先上缺陷修复看板，让定级和验证环节先清晰起来；运营任务看板适合内容或活动节奏固定的团队。一次只启用一套，运行两三个迭代后再引入第二套，避免同时维护多套列设置而无人跟进。
列名可以直接用工具里的工作项状态名吗？
可以，前提是列与状态保持一一对应或明确的映射关系。若工具中列绑定状态，新增列前先确认对应状态是否已存在；列名与状态名不一致时，在列含义中写清对应关系，避免成员在看板和状态字段之间看到两套口径。状态数量多于列时，允许多个状态映射到同一列，但要在列含义里注明包含哪些状态。
卡片字段已经很多了，怎么判断哪些该移到详情里？
按使用角色和查看频率判断。连续两个迭代无人主动查看的字段，移入卡片详情；只有个别角色关注的字段，用筛选视图呈现，不放在卡片正面。卡片正面控制在三到五项，保留能帮助判断“这张卡是否需要我处理”的信息，例如负责人、计划时间、阻塞标记，其余信息在点开卡片后查看。
列设置调整后，历史任务的数据会受影响吗？
取决于调整方式。合并列通常只是呈现方式变化，任务本身的状态记录不变；拆分列或修改进入退出条件，会让按列统计的停留时间出现口径断点。建议在变更记录中注明生效时间，跨变更周期的停留时间统计分段解读。涉及状态本身的增删时，先确认历史任务的状态归属，再执行调整。
看板维护人需要具备什么权限，日常要做哪些事？
维护人需要能修改看板列配置和卡片展示字段的权限，通常由项目管理员或团队指定的流程负责人担任。日常动作包括：核对状态与列的对应关系、处理列增删的评审、每季度清理卡片字段、在变更生效当天同步通知。维护人不必承担所有字段的填写，但要对列设置的变更记录负责，保证成员看到的是同一版看板。
