看板如何做好自定义状态？研发团队入门指南与操作步骤

研发看板里多加一个“待联调”状态，可能让交接更清楚，也可能只是让任务多停一站。自定义状态真正要解决的，不是看板列太少，而是团队无法一致回答三个问题：任务现在处于什么阶段、谁负责推动、满足什么条件才能进入下一阶段。先把这三件事说清楚，再配置工具；否则状态越细，统计越乱，维护成本也越高。

一、先给结论：状态设计要从工作流出发

1. 状态不是装饰，而是团队共同遵守的流程定义

我通常把一个看板状态看成一项协作约定：它说明任务当前所处阶段，并让团队能判断下一步由谁采取什么行动。一个状态如果没有明确的进入条件、退出条件和责任角色，就很难稳定使用，最后往往退化成“大家凭感觉拖卡片”。

因此，自定义状态不是在工具里新增几列这么简单。它会改变任务流转方式，也可能影响看板视图、过滤条件、自动化规则和团队报表。配置界面只是落地位置，工作流定义才是设计本身。

2. 先判断是否需要“状态”，再决定是否新增

任务需要表达的信息不止一种。阶段用状态表达；优先级、模块、风险类别通常更适合用字段或标签；“因为外部依赖而暂停”可能适合用阻塞标记和原因字段。把所有信息都塞进状态，容易把主流程做得臃肿。

3. 默认从最小可行流程开始

对多数研发团队来说，先把主流程中真正有交接意义的阶段表达出来，比一开始细分每一种活动更重要。可以从“待处理，进行中，待验证，已完成”这类骨架开始，再根据真实卡点决定是否拆分。

这里没有适用于所有团队的“标准状态数”。判断重点是：每个状态是否能帮助成员做出下一步行动，是否能让负责人识别任务停滞原因。如果新增状态只让流程图更像真实世界，却没有改善交接或决策，它就未必值得保留。

二、为什么团队会觉得状态不够用

1. 真实交接被藏在一个宽泛状态里

常见场景是，开发人员提交代码后，任务仍显示“进行中”；评审人员还没开始处理，测试人员也无法判断它是否已进入待测队列。一个宽泛状态实际上包住了多个角色、多个等待点，导致看板无法说明任务为什么没动。

这时可以考虑把“开发中”和“待评审”分开，但前提是团队确实需要单独管理评审队列，并且有人负责推动评审。若评审只是开发者工作中的一个短暂动作，或评审任务已经在其他视图中清晰跟踪，新增状态未必有必要。

2. 团队口头流程和系统流程不一致

有人说“已经提测”，看板上却仍是“进行中”；有人说“等产品确认”，系统里没有任何等待标记。这种差异会让管理者误以为团队缺少执行力，实际上可能是流程信息没有进入系统。

我会先问：“这个说法是否对应一个稳定的交接点？它是否改变任务的负责人、准入条件或后续动作？”如果答案是肯定的，状态或明确的流程字段可能有价值；如果只是补充背景，评论、标签或等待原因字段可能更合适。

3. 问题可能不是状态太少，而是状态没人维护

任务挂在“待评审”一周，并不必然说明缺少“评审中”“待反馈”“修改中”等更多列。根因可能是评审没有负责人、通知没有送达，或任务离开开发阶段时没有明确的完成标准。新增状态会把问题细分，却不一定让问题消失。

在改状态前，可以抽查一段时间内停留较久的任务，逐条记录停滞原因。若大多数任务是因为角色交接不清，先补责任规则；若多数任务确实等待同一种审批或验证，再评估是否拆出对应阶段。

4. 可视化看板不等于所有流程信息都必须成为列

看板列适合呈现团队需要持续关注的流动阶段。它不适合承载每个临时事件、所有异常原因和每一种任务属性。列过多时，成员需要频繁横向寻找卡片，管理者也更难一眼判断主流程瓶颈。

下图是一个情景模拟，用于解释为何状态增加会提高维护负担，并非行业统计。假设团队任务总量不变，流程从四个状态扩展到八个状态，而每增加一列都带来定义、培训和报表映射工作，团队获得的细节不一定抵得过额外成本。

三、设计自定义状态时最容易踩的误区

1. 把每个动作都建成状态

例如把“写代码”“本地自测”“提交代码”“等同事看一眼”“修改意见”全部建成独立列。若每个动作都需要单独流转，团队会花很多时间移动卡片；对于只持续几分钟、不会形成等待队列的动作，状态化通常得不偿失。

拆分前我会检查三个条件：该阶段是否有独立责任人，是否经常出现可观测的等待，是否需要单独统计或管理。三个条件都不成立时，优先用任务说明、检查清单或自动化记录，而不是新增一列。

2. 用含糊名称替代流程定义

“处理中”“有问题”“马上完成”都可能被不同成员理解成不同意思。一个人把“处理中”理解为已开始编码，另一个人却把它理解成需求正在确认，卡片虽然有状态，信息仍然不可用。

较好的名称通常描述可验证的阶段或交接，例如“待评审”“待测试”“待发布”。名称还不够，团队需要补充说明：进入这个状态时，任务必须满足什么条件；离开时，下一阶段需要哪些信息或产物。

3. 把等待、阻塞和阶段混为一谈

“待测试”是一个可以持续存在的工作阶段；“被外部依赖阻塞”更像是任务当前的异常情况。一个任务可能处于待测试，同时又因为测试环境不可用而被阻塞。如果工具支持同时记录状态和阻塞标记，通常比新建“待测试但环境阻塞”更容易维护。

但如果某类等待本身就是团队需要集中管理的工作队列，例如所有待审批任务都需要固定角色每天处理，那么把它作为独立阶段可能合理。关键不是概念上的唯一答案，而是它是否改变了任务的负责人、推进方式或统计口径。

4. 只改列名，不改规则和统计

新状态上线后，团队可能忘记同步过滤器、通知规则、模板和报表。结果是看板上出现了新列，月报仍把这些任务归入旧阶段，自动化通知也没有触发。这个问题不一定马上暴露，却会慢慢破坏团队对数据的信任。

因此，状态调整应当被视为一次小型流程变更。变更清单至少要覆盖状态定义、转换条件、权限、自动化、视图、报表口径、历史任务处理和团队说明。

5. 认为状态越多，过程透明度越高

状态很多，确实能让任务当前阶段看起来更细，但透明度不等于列数。真正有用的透明度，是成员能看懂任务为什么停留、谁来推进、怎样才算完成；若新增状态没有增加这些信息，细分只是在制造更复杂的界面。

尤其要小心“为了管理而管理”：如果负责人无法说明新状态会触发什么决策、减少什么不确定性，建议先用两周观察问题，再决定是否纳入正式流程。

四、如何判断一个候选状态值得保留

1. 用四个问题做状态准入检查

我会把候选状态放到四个问题下逐一检验。它们不是软件功能清单，而是判断一个阶段是否具备管理意义的筛选框架。

• 它描述的是阶段吗？如果描述的是优先级、风险原因或任务类别，先考虑字段或标记。
• 它有明确的进入条件吗？成员是否能判断任务何时应进入，而不是靠个人感觉？
• 它有明确的退出条件和责任人吗？任务由谁推动，满足什么条件后才能离开？
• 团队会根据它采取不同动作吗？若不同状态不会改变提醒、排期、资源安排或决策，新增价值可能有限。

四项中若有两项无法回答，我通常不会马上将其设为正式状态。可以先通过一个自定义字段、标签或临时观察表收集数据，等团队确认这是稳定模式后再调整主流程。

2. 把状态定义写成“进入，负责，退出”

为了减少含糊，我建议为每个状态写一条简短定义，至少包含三个部分：进入条件、主要责任角色、退出条件。团队不需要写长篇制度，但需要让新成员和跨团队协作者看得懂。

3. 明确状态、负责人和阻塞原因之间的关系

一个状态最好能回答“现在在哪个阶段”，负责人回答“谁负责推动”，阻塞原因回答“为什么不能继续”。三种信息各有作用，不要为了省字段而让状态承担所有解释任务。

如果团队发现同一个阶段经常出现多种等待原因，通常可以保留阶段状态，再增加结构化的等待原因。这样既能统计流程阶段，也能区分外部依赖、环境不可用、需求待澄清等问题。

4. 用观察数据代替印象判断

设计时不一定要一开始就有完整数据，但至少可以记录任务进入各状态的次数、停留时长、退回比例和未分配负责人比例。若某个状态总是没有任务、无人采取行动，可能是命名或流程设计有问题；若任务集中停留在某阶段，则需要进一步查清是容量不足、准入不全，还是责任交接失效。

在数据量较小时，不要急于把平均值当成结论。少数超长任务会拉高平均停留时间，可以同时看中位数和高分位数，并抽查具体任务。数字告诉我们哪里异常，任务记录帮助我们解释为什么异常。

五、从流程草图到工具配置的操作步骤

1. 盘点现有状态和真实任务路径

先把当前看板中的状态列出来，再抽样查看实际任务是如何流转的。不要只问负责人“流程应该怎样”，还要观察最近完成的任务和长期未完成任务：它们是否经过相同路径，是否经常跳过某一列，是否在线下发生了系统没有记录的交接。

建议至少记录状态名称、近段时间的任务数量、停留较久的任务、实际负责人以及团队口头使用的替代说法。盘点的目标不是追求复杂的数据分析，而是找到名义流程和实际工作之间的差异。

2. 先画流程，再挑出需要可视化的阶段

把任务从进入队列到交付的关键阶段画出来，在每个阶段旁边标记负责角色和交接条件。接着区分“核心工作阶段”和“补充信息”：优先级、模块、风险原因通常不需要单独变成主流程状态。

例如，团队可能把代码评审拆成“待评审，评审中，待修改，复审中”。如果这些环节都有不同责任人、经常形成队列，并且团队需要分别观察等待时间，拆分有依据；如果它们只是同一位开发者短时间内完成的连续动作，保留一个“评审中”或“待评审”可能更简单。

3. 选出最小可行状态集合

先满足当前最重要的管理目标，不要一次性把未来可能出现的流程都预建出来。把争议最大的候选状态单独列出来，问团队：“没有这一列时，我们具体会误判什么或漏掉什么？”如果无法给出具体后果，可以暂缓增加。

有些团队适合用“进行中”覆盖多个内部动作，并通过负责人、子任务或检查清单来管理细节；有些团队跨部门交接频繁，需要把待评审、待测试或待发布独立呈现。流程规模和协作边界不同，状态集合也应不同。

4. 在工具中配置名称、顺序和流转规则

完成定义后，再进入所用工具设置。具体菜单位置和功能名称会随产品版本、权限配置和部署方式变化，因此不要直接照搬其他团队的截图。配置时重点核对以下项目：

1. 状态名称是否与团队统一使用的流程术语一致。
2. 显示顺序是否符合主要工作流，而不是按照添加时间排列。
3. 工具是否支持限制状态转换；如果支持，规则是否与实际交接相符。
4. 哪些角色可以移动任务，哪些状态变更需要补充说明或指定负责人。
5. 阻塞、取消、退回和重新打开分别如何记录。

5. 同步检查视图、自动化和统计口径

新增状态后，检查所有依赖状态名称的地方。常见遗漏包括个人保存的过滤器、团队仪表板、通知规则、自动分配、任务模板和周期统计。若某个规则只识别旧状态，新任务可能不再触发预期动作。

历史任务也要有处理原则：旧状态中的任务是否批量映射到新状态，是否由负责人逐条判断，还是保持历史不动、只对新任务使用新流程。批量迁移虽然省时，但如果映射关系不准确，可能让历史统计失真。

6. 先小范围试运行，再决定是否推广

试运行时应选一个流程边界清楚、成员愿意反馈的团队或项目。试点不是为了证明新设计正确，而是为了尽早发现误用、额外录入、看板拥堵和报表断层。团队最好指定一位流程维护人，收集问题并决定哪些需要立即修正，哪些可以等复盘。

试运行期间，可以用固定节奏检查：新状态是否被一致使用，任务是否能顺利进入下一阶段，状态变更是否带来额外沟通，团队能否解释停滞原因。不要只看“大家有没有把卡片拖到新列”，还要观察新列是否改变了协作行为。

下表中的数值是试点观察的示意基准，用于展示检查维度，不是普遍适用的绩效目标。实际阈值应结合团队规模、任务类型和历史数据确定。

六、贯穿案例：一个研发团队如何调整状态

1. 场景设定：任务都在“进行中”，但交接看不出来

以下案例是情景模拟，用于说明决策过程，不代表某个真实客户的数据。假设一个跨职能研发小组使用“待处理，进行中，已完成”三种状态。成员反馈任务经常卡在开发结束后，评审和测试的等待都被看成“进行中”。

团队一开始提出新增“开发中、待评审、评审中、待测试、测试中、待发布、发布中”等多个状态。盘点后发现，真正造成误判的是两个稳定交接点：代码等待评审，以及版本等待测试；“评审中”和“发布中”没有形成独立队列，也没有明确的责任交接。

2. 设计选择：保留主流程，拆出两个可管理的等待点

团队最终试行“待处理，开发中，待评审，待测试，待发布，已完成”。同时用负责人字段表示当前推动者，用阻塞标记和原因字段记录外部依赖。测试失败不直接新建“测试失败”状态，而是退回开发阶段并记录问题关联。

3. 用两周试点数据判断是否继续

假设团队试点前后各抽取四周的任务记录，发现“待评审”阶段的停留情况比过去更容易定位；但任务在“待测试”中停留较久，进一步查看后发现主要原因是测试环境准备时间，而不是测试人员处理速度。这个结果说明，新状态的价值不只是让列更清楚，还能帮助团队区分队列问题和依赖问题。

下面的数字是为了演示分析方式而设置的模拟数据，不能当作真实提效结论。实际复盘时，应保持样本范围、任务类型和统计口径一致；如果样本差异很大，应先分层比较，不宜直接用单一平均值下结论。

4. 复盘时不要把相关变化直接说成因果

如果状态上线后等待时间下降，不能仅凭前后对比就认定“新增状态带来提效”。同期可能还有人员变化、任务难度变化、发布节奏调整或外部依赖改善。稳妥的做法是记录变更日期和同期措施，比较相近任务类型，并抽查任务流转记录。

如果试点没有明显改善，也不一定说明状态设计完全失败。新流程可能提升了可解释性，却没有增加处理能力；或者团队尚未形成稳定的状态使用习惯。是否保留，应同时看流程透明度、额外维护投入和团队实际行动变化。

七、不同团队规模与流程条件下的行动建议

1. 小团队：先减少歧义，不追求完整流程图

成员少、沟通直接、任务类型相对稳定的团队，常常不需要很多状态。可以先使用少量主流程状态，再用负责人、标签或任务说明补充信息。重点是让所有成员对“完成”“待评审”“阻塞”的含义一致。

小团队若过早设置复杂权限和自动化，维护成本可能超过管理收益。先用简单规则运行一段时间，等交接模式稳定后，再把重复动作自动化。

2. 中大型组织：优先治理跨团队边界和口径

团队规模扩大后，状态设计的难点往往从“列够不够”变成“不同团队是否用同一个词表达同一件事”。一个部门的“已完成”可能是开发完成，另一个部门的“已完成”可能是正式上线。若共享流程需要协作，应先定义共同节点，再允许各团队在局部环节保留差异。

对于百人以上组织，建议把状态字典、负责人、审批或转换规则纳入统一维护，并指定流程变更的评审角色。若采用项目管理平台集中管理流程，可以将状态定义、迁移计划和历史数据处理一起纳入治理；平台是否适合，则要结合权限模型、部署要求、报表能力和团队迁移成本评估。

3. 受合规或内网要求约束的团队：把部署和审计放进设计阶段

如果研发流程涉及受控网络、数据驻留或严格审计，状态变更记录、角色权限和数据迁移都可能是上线条件，而不是后期优化项。应提前确认平台的部署形态、日志保留方式、权限粒度和升级维护责任，避免先配置流程、后发现运行环境不符合要求。

例如在评估 PingCode 等项目管理平台时，可以重点核对其当前版本支持的部署方式、组织规模适配、状态配置能力，以及从现有系统迁移任务和流程数据的方案。即便平台提供 Jira 平滑迁移能力，也应先通过小批量试迁移核对字段映射、附件、历史状态、评论、权限和报表口径；“支持迁移”不等于每个组织都无需清洗或验证。

4. 处于工具替换期的团队：先冻结流程，再做映射

迁移期间同时重构状态，容易让团队分不清问题来自工具还是流程。若没有强制调整需求，建议先把现有状态和字段映射到新工具，完成一轮稳定运行后再优化；如果旧流程本身已经造成严重误解，则要把“状态改造”和“数据迁移”拆成可追踪的两项工作。

迁移前应确认旧状态是否一对一映射。若旧系统的“处理中”同时包含开发、评审和测试，而新系统需要区分这些阶段，不能只靠自动映射解决；需要决定历史任务如何保留原值、新任务如何使用新流程，以及报表是否从某个日期开始采用新口径。

5. 按问题类型决定下一步，而不是套用同一套状态

• 任务频繁卡在交接处：先明确负责人和交接条件，再判断是否需要独立状态。
• 任务停滞原因很多：保留阶段状态，补充阻塞原因或依赖类型，避免创建大量组合状态。
• 不同团队对状态理解不同：先统一定义和示例，再调整名称或转换权限。
• 报表统计失真：先核对状态映射、历史数据和计算口径，不要靠改列名解决。
• 状态太多、卡片难找：合并没有独立决策价值的阶段，并检查哪些信息可以改用字段表达。

八、如何取舍、复盘并长期维护

1. 在信息精度与维护成本之间做取舍

状态越细，理论上越容易定位任务所在环节；但每一列都会带来定义、权限、通知、视图和报表的维护工作。团队应比较新增状态带来的决策收益与全生命周期成本，而不是只看设置时多点几下鼠标的成本。

以下数值是情景模拟，用于说明不同设计的取舍，不是平台实测结果。实际成本取决于团队人数、流程数量、自动化规模和治理要求。

2. 建立状态新增、合并和删除的变更规则

状态一旦关联任务历史、自动化和统计口径，就不适合随意改名或删除。团队可以指定流程维护人，所有变更至少说明：解决的问题、影响的角色、旧数据处理方式、报表影响和试点范围。

删除状态前，先检查其中是否仍有未完成任务；合并状态前，确认两者是否有不同的责任人或退出条件；修改名称时，核对过滤器和自动化是否按内部状态标识运行，还是直接依赖显示名称。不同工具实现不同，不能假设改名一定安全。

3. 复盘时同时看过程指标和成本指标

如果只看任务周期，容易忽略数据录入负担；如果只看成员是否满意，又可能忽略队列中的长期停滞。复盘可以从三类指标入手：流程结果，例如交付周期和返工情况；过程信号，例如状态停留分布和交接完整率；维护成本，例如每月规则核对、人工纠错和培训所需时间。

指标不需要越多越好。选择三到五个与当前问题直接相关的指标，定义统一统计窗口和计算方式，比建立几十个没人看的图表更有效。若某项指标上线后没人据此采取行动，可以考虑移除或改为定期抽查。

4. 一份可以直接使用的配置前检查清单

• 每个候选状态是否表示稳定的工作阶段，而非临时动作或分类标签？
• 每个状态是否写清进入条件、退出条件和主要责任角色？
• 新增状态是否会触发不同的协作动作、资源安排或管理决策？
• 等待、阻塞、退回、取消和重新打开分别如何处理？
• 状态变化会不会影响过滤器、自动化、通知、模板和历史报表？
• 旧任务如何映射，新旧统计从哪个时间点区分？
• 是否指定维护人、试点范围和复盘日期？
• 试点结束后，团队将依据哪些证据决定保留、合并或回退？

自定义状态做得好，不是把每一个工作动作都展示出来，而是让关键交接可见、责任归属明确、异常原因可解释。下一步可以从一个最常卡住的流程节点开始：抽查最近一批任务，找出它们停留的真实原因；只有当问题确实来自阶段不可见，并且新状态能改变团队行动时，再把它加入正式看板。