缺陷修复看板列设置的关键，是让每一列对应缺陷流转中一个可判断的状态，并写清进入、离开该列的条件。本文提供可直接复制的空白列定义表与卡片字段表，配套字段填写口径、必填与选填划分、一条缺陷走完五列的完整示例，以及后续增删列和维护的检查方法。
要点总览（TL;DR）
- 缺陷修复看板列设置的核心是让每一列对应一个可判断的状态，并写清进入、离开该列的条件；可直接复制文中的列定义表与卡片字段表起步。
- 推荐以“待确认—已确认—修复中—待验证—已关闭”五列起步，每列至少配置列名、对应状态、进入条件、离开条件、负责人角色、必填字段和停留上限。
- 必填与选填的划分标准是：缺少该字段是否会导致某一列无法做出进入或离开判断；缺陷量小的团队可先省略协作角色与超限处理的书面规定。
- 文中用一条缺陷走完五列的演示示例验证模板可用性，填写自己的模板时可抽查一两列，确认字段与规则对得上。
- 列设置需随团队节奏维护：新增或合并列、列名与状态同步修改、按固定周期或积压触发回顾，并明确责任人。
缺陷修复看板列设置空白模板（可直接复制）
先拿到成品表格，再理解字段。以下两张表可直接复制到文档或表格工具中填写。列定义表用于规定看板上有哪些列、每列怎么进怎么出；卡片字段表用于规定一张缺陷卡片上必须呈现哪些信息。两张表配合使用，缺一列定义则流转无依据，缺卡片字段则列内信息不完整。
表一：列定义表（空白模板）
| 序号 | 列名 | 对应状态 | 进入条件 | 离开条件 | 负责人角色 | 协作角色 | 必填字段 | 停留上限 | 超限处理 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 待确认 | ||||||||
| 2 | 已确认 | ||||||||
| 3 | 修复中 | ||||||||
| 4 | 待验证 | ||||||||
| 5 | 已关闭 | ||||||||
| 6 | （按需增列） |
表二：卡片字段表（空白模板）
| 字段名称 | 字段类型 | 是否必填 | 填写人 | 取值说明 | 出现在哪些列 |
|---|---|---|---|---|---|
| 缺陷标题 | 单行文本 | ||||
| 缺陷编号 | 编号/自动生成 | ||||
| 严重程度 | 单选 | ||||
| 优先级 | 单选 | ||||
| 发现版本/环境 | 文本或单选 | ||||
| 复现步骤 | 多行文本 | ||||
| 缺陷负责人 | 人员 | ||||
| 验证人 | 人员 | ||||
| 关联需求/用例 | 关联项 | ||||
| 修复说明 | 多行文本 | ||||
| 进入当前列日期 | 日期 | ||||
| （按需增字段） |
看板级规则空白区
以下规则作用于整个看板，不针对单列，填写时逐条确认：
- 看板名称与适用范围：____（如某产品线、某迭代周期）
- 缺陷来源渠道：____（测试提交、线上反馈、内部巡检等）
- 列顺序调整权限归属：____（角色或人员）
- 卡片在看板上的排序规则：____（如按优先级、按进入时间）
- 跨列移动的权限要求：____（谁可以把卡片从一列拖到另一列）
- 看板回顾周期与召集人：____
每个列字段的含义与填写口径
模板中的每一栏都对应一个判断动作。填写口径统一后，不同的人看到同一张卡片能做出相同的判断。下表与表一、表二字段一一对应。
| 字段 | 该填什么 | 判断依据 |
|---|---|---|
| 列名 | 简短动词或状态词，如“修复中” | 列名应让团队成员一眼判断卡片是否属于该列，避免“处理中”这类无法判断完成度的词 |
| 对应状态 | 该列在缺陷状态字段中的取值 | 列与状态保持一一对应，避免同一状态分散在多列，或一列混装多个状态 |
| 进入条件 | 卡片可以进入该列的前提事实 | 写成可核验的事实，如“已复现且指定负责人”，而非“开始处理”这类主观描述 |
| 离开条件 | 卡片可以离开该列的前提事实 | 与进入下一列的条件衔接，确保每次移动都有依据 |
| 负责人角色 | 对该列停留时间负责的角色 | 每列只设一个主责角色，避免无人推进或多人推诿 |
| 协作角色 | 在该列需要配合的角色 | 如“待验证”列的协作角色为开发，用于解答验证中的疑问 |
| 必填字段 | 卡片进入该列时必须已填写完整的字段 | 按该列判断所需信息确定，如“待验证”列必须有修复说明和验证人 |
| 停留上限 | 卡片在该列允许停留的最长时间 | 按团队实际节奏设定，如“修复中”2个工作日，需与团队确认后写入 |
| 超限处理 | 超过停留上限后的动作 | 写明由谁在什么场合处理，如“由负责人在每日站会说明原因并给出新预计时间” |
| 看板级规则 | 作用于整个看板的约定 | 包括权限、排序、回顾节奏，避免每列重复规定 |
填写时有一个常见误区：把进入条件写成动作描述，如“开发开始修”。动作无法核验，卡片是否该移动就变成个人判断。改为事实描述，如“已定位原因并指定修复人”，判断就有了共同依据。离开条件同理，应描述“什么事实成立后可以走”，而非“谁同意后可以走”。
当团队使用 ONES Project 管理缺陷时，缺陷可作为工作项进入项目或迭代，看板用于呈现当前进度，缺陷状态与属性可自定义。列设置模板中的“对应状态”一栏，正是把看板列与工作项状态对齐的环节；具体列级自定义与状态映射的配置方式，建议在选型或配置时向厂商确认，再落到模板中。
哪些字段必填、哪些按团队情况选填
必填与选填的划分标准只有一条：缺少该字段，是否会导致某一列无法做出进入或离开判断。会导致判断中断的字段必填，仅用于辅助沟通的字段选填。模板过重会让人绕过填写，过轻则列流转失去依据。
| 字段 | 建议 | 理由或适用条件 |
|---|---|---|
| 列名 | 必填 | 没有列名看板无法成立 |
| 对应状态 | 必填 | 列与状态脱节会导致同一缺陷在两处显示不同进度 |
| 进入条件 | 必填 | 缺少则卡片移动全凭个人判断 |
| 离开条件 | 必填 | 与进入条件配对，缺一不可 |
| 负责人角色 | 必填 | 每列需要明确谁对停留时间负责 |
| 必填字段 | 必填 | 规定卡片进入该列时的信息完整度 |
| 停留上限 | 必填 | 没有上限，列内积压无法被发现 |
| 协作角色 | 选填 | 协作关系简单的团队可省略；跨职能配合多的团队建议填写 |
| 超限处理 | 选填 | 团队已有固定站会机制时可省略，否则建议写明 |
| 缺陷编号 | 必填 | 用于跨文档、跨会议引用同一缺陷 |
| 缺陷标题 | 必填 | 卡片识别的基本信息 |
| 严重程度、优先级 | 必填 | 决定修复顺序，缺失会导致排序失据 |
| 复现步骤 | 必填 | “待确认”列判断能否复现的核心依据 |
| 缺陷负责人 | 必填 | “修复中”列的责任人 |
| 验证人 | 必填 | “待验证”列的判断主体 |
| 修复说明 | 必填 | 验证人据此判断验证范围 |
| 发现版本/环境 | 选填 | 多环境并行发布的团队建议填写；单一环境团队可省略 |
| 关联需求/用例 | 选填 | 需要追溯缺陷来源时填写 |
| 进入当前列日期 | 选填 | 需要统计停留时长时填写；仅靠人工观察的团队可省略 |
按团队情况调整时，可参考两个维度。缺陷量较小的团队（例如每周新增缺陷在个位数），可先保留七项必填列字段和核心卡片字段，省略协作角色与超限处理的书面规定，靠日常沟通补位。缺陷量较大、多人并行修复的团队，建议把协作角色、超限处理和进入当前列日期一并启用，否则列内积压和交接空档难以定位。团队规模扩大或缺陷来源渠道增多时，优先补充的是“发现版本/环境”和“关联需求/用例”，而不是增加列数。
填写示例：一条缺陷走完五列
以下为演示情景，用于说明模板如何填满，数值与角色名称可按实际替换。假设一条缺陷为“订单列表页在弱网下重复提交”，严重程度为高，优先级为高。
| 列 | 进入条件判断 | 该列填写的关键字段 | 离开条件判断 | 停留情况 |
|---|---|---|---|---|
| 待确认 | 测试提交缺陷，附复现步骤与环境信息 | 标题、编号、严重程度、优先级、复现步骤、发现版本 | 测试负责人复现成功，指定缺陷负责人，严重程度确认 | 停留1个工作日，未超限 |
| 已确认 | 复现成功且已指定负责人 | 缺陷负责人、关联需求、确认后的优先级 | 负责人给出修复方案与预计完成时间，进入排期 | 停留半个工作日，未超限 |
| 修复中 | 已排期且负责人开始修改代码 | 修复说明（初稿）、进入当前列日期 | 代码提交并通过自测，修复说明补充完整，指定验证人 | 停留2个工作日，达到上限，负责人在站会说明进度 |
| 待验证 | 修复完成且验证人已指定 | 验证人、修复说明、验证环境 | 验证人按复现步骤回归通过，或验证不通过退回修复中 | 停留1个工作日，未超限 |
| 已关闭 | 验证通过并记录验证结论 | 验证结论、关闭日期 | 无需离开；后续若复现则新建缺陷并关联原编号 | — |
示例中“修复中”列达到停留上限，处理动作是负责人在站会说明进度并给出新的预计时间，卡片继续留在该列，而不是自动跳到下一列。若验证不通过，“待验证”列的离开条件不成立，卡片退回“修复中”，此时需在修复说明中补充未通过的原因，避免同一问题反复往返而信息丢失。
这条示例同时验证了模板的字段一致性：列定义表中“待验证”列的必填字段为修复说明和验证人，示例中该列确实填写了这两项；列定义表中“修复中”列的停留上限为2个工作日，示例中停留情况与之一致。填写自己的模板时，可用同样方式抽查一两列，确认字段与规则对得上。
模板的调整与维护方法
列设置不是一次定稿。团队节奏、缺陷来源和验证方式变化后，模板需要同步调整，否则会出现列名与实际状态脱节、卡片长期停在某一列无人处理的情况。
新增或合并列的判断依据
- 新增列：某一状态下的卡片长期需要区分两类不同处理动作，且两类动作的负责人或判断依据不同。例如线上缺陷与测试缺陷的确认流程差异明显，可增设“线上确认”列。
- 合并列：两列的进入条件与离开条件高度重合，或卡片在两列之间频繁往返且无实质信息变化。合并后需确认原两列的必填字段已并入保留列。
- 不新增列的情形：仅为了区分优先级或严重程度时，优先用卡片字段和排序规则表达，避免列数膨胀。
列名与状态字段同步修改的检查点
- 列名修改后，对应状态字段的取值是否同步更新，历史卡片是否仍能正确归类。
- 看板级规则中引用了旧列名的约定（如权限、排序、回顾范围）是否一并修订。
- 卡片字段表中“出现在哪些列”一栏是否随列调整更新。
- 团队文档、站会模板、缺陷提交表单中出现的旧列名是否同步替换。
定期回顾的触发条件与责任人
| 触发条件 | 回顾内容 | 建议责任人 |
|---|---|---|
| 固定周期（如每季度一次） | 逐列核对进入、离开条件是否仍可判断，停留上限是否仍符合实际节奏 | 缺陷管理负责人 |
| 某列连续出现超限积压 | 检查该列负责人角色与必填字段是否合理，必要时拆分或调整上限 | 该列负责人牵头 |
| 团队规模或缺陷来源渠道变化 | 复核必填与选填划分，补充或精简卡片字段 | 项目负责人 |
| 缺陷状态定义调整 | 同步列名与对应状态，检查历史卡片归类 | 缺陷管理负责人与工具管理员 |
维护动作落到工具中时，ONES Project 支持自定义需求状态与多种属性，并提供看板呈现项目进度，缺陷可提交至对应项目或迭代中跟踪修复情况。把模板中的列名、状态和必填字段落到系统配置时，建议先小范围试用一个迭代，确认列级自定义与状态映射的实际配置方式后再全量推广；相关配置细节以厂商实际说明为准。
常见问题
团队缺陷量很少，五列结构可以精简吗？
可以。缺陷量较小的团队可先保留“待确认—修复中—待验证—已关闭”四列，把“已确认”并入“待确认”的离开条件中，即复现成功并指定负责人后直接进入“修复中”。精简时需确认原列的必填字段已并入保留列，例如“已确认”列的缺陷负责人字段应成为“修复中”列的必填项，避免信息在合并中丢失。
缺陷在“待验证”列验证不通过，应该退回哪一列？
退回“修复中”列。此时“待验证”列的离开条件不成立，卡片按原路退回，并在修复说明中补充未通过的原因和验证环境，避免同一问题反复往返而信息丢失。若验证不通过的原因是复现条件本身有误，也可退回“待确认”重新判断，具体走哪条路径应在列定义表的离开条件中提前写明。
列名改了，历史卡片会受影响吗？
取决于列名与状态字段的对应关系。修改列名时，应同步检查对应状态字段的取值是否更新、历史卡片是否仍能正确归类，以及看板级规则中引用旧列名的约定（如权限、排序、回顾范围）是否一并修订。团队文档、站会模板和缺陷提交表单中出现的旧列名也应同步替换，减少沟通中的歧义。
停留上限到了但缺陷确实修不完，怎么处理？
停留上限的作用是让积压被看见，不要求卡片到点自动跳列。常见做法是卡片继续留在原列，由该列负责人在站会说明进度并给出新的预计时间，同时记录超限原因。若同一列连续多个周期出现超限，应回到模板层面检查该列的负责人角色、必填字段和上限数值是否合理，必要时拆分列或调整上限。
用工具管理缺陷时，模板里的列和状态怎么落地？
落地时把列定义表中的“列名”与“对应状态”对齐到工具的工作项状态配置，把卡片字段表中的必填项配置为对应字段。以 ONES Project 为例，缺陷可提交至对应项目或迭代中跟踪修复情况，项目支持自定义需求状态与多种属性，并提供看板呈现进度。列级自定义与状态映射的具体配置方式，建议先小范围试用一个迭代，确认实际效果后再全量推广，配置细节以厂商实际说明为准。
