看板如何做好自定义状态？研发团队最佳实践与操作步骤

研发看板最常见的失效，不是状态太少，而是状态名称看起来很完整，团队却不知道什么时候该改、改完由谁接手。我的判断是：自定义状态不是给任务贴更多标签，而是把工作交接、责任归属和下一步动作明确下来。若一个状态不能改变任何人的判断或行动，它大概率不该单独存在。

一、先讲结论：状态要服务于流转，而不是装饰看板

1. 先问每个状态能不能触发行动

设计状态时，我通常先问团队一个具体问题：“任务进入这个状态后，谁需要做什么？”如果回答只是“表示任务到了某个阶段”，但没人知道接下来要检查什么、由谁负责、满足什么条件才能离开，那么这个状态可能只是换了一个名字，并没有帮助协作。

例如，“待评审”如果意味着开发已提交变更、评审人需要在约定时间内检查，并且评审通过或提出修改后才能离开，它就是有用的流程状态。反过来，如果团队成员随手把卡片拖进“待评审”，却没有评审责任人，也没有完成条件，它只会让看板多一个停放任务的地方。

2. 状态数量不是流程成熟度

增加状态会带来实际成本：成员要理解更多规则，管理员要维护更多流转路径，统计口径也更难保持一致。状态并非越少越好，也不是越细越专业。合适的粒度取决于一个问题：团队是否需要依据这个阶段，采取与其他阶段不同的动作。

比如，“开发中”和“代码已提交”可能需要区分，因为前者由开发负责推进，后者需要评审人接手；但“开发中（上午）”和“开发中（下午）”通常不会形成不同的协作动作，不值得成为两个状态。

3. 设计结果至少要回答五个问题

• 含义：任务处于这个状态时，实际工作已经完成到哪一步？
• 进入条件：满足什么可观察条件，卡片才能进入该状态？
• 退出条件：需要完成什么检查或交付，任务才能离开？
• 责任人：当前由谁推动，下一步交接给谁？
• 异常处理：阻塞、返工、取消等情况怎样记录，不让主流程失真？

如果这五项里有两三项说不清，先别急着进工具里新增状态。把定义写明白，通常比多配置几个颜色更能解决问题。

二、背景与真实场景：为什么任务都在“进行中”，团队仍然看不清进度

1. 看板卡住时，先区分“工作在做”和“流程在等”

研发团队常遇到一种表面矛盾：每个人都在更新任务，周会上也能报出进展，但负责人打开看板，仍然不知道哪些工作正在编写代码、哪些等评审、哪些卡在测试环境、哪些只是等待外部确认。问题往往不是没人更新，而是一个“进行中”承载了太多不同的现实。

在流程诊断中，我会把“进行中”拆成两个问题来观察：团队是否需要识别任务当前的工作阶段？任务停下来时，是否需要分辨它是在等待别人，还是仍由当前负责人主动处理？如果答案都是肯定的，原有状态可能隐藏了重要交接信息。

但不要仅凭一张看板的截图就判断流程有问题。要再看卡片更新时间、责任人变更、评论内容和实际交付记录。看板状态只能说明成员如何记录工作，不一定完全等于工作真实发生的过程。

2. 用一个示例说明状态含义如何被混淆

以下是一个用于讨论的示例流程，不代表某个真实客户，也不是所有研发团队都应照搬。团队原本只有“待处理、进行中、已完成”三个状态。大家把“代码还没提交”“已经提交等待评审”“评审通过等待测试”都放在“进行中”。管理者看到的是一个大队列，却无法判断队列里分别需要开发、评审还是测试采取行动。

如果直接把“进行中”拆成十个小状态，也未必更好。更稳妥的做法是先找出工作交接点：开发完成后是否需要评审？评审后是否要独立验证？验证完成后由谁确认交付？只有会改变责任人或决策动作的节点，才优先考虑成为状态。

3. 分析状态问题，要同时看卡片和团队约定

同一个状态名称，在不同团队可能指向不同事实。“待验收”可能表示开发自测已完成，也可能表示测试已通过、业务方尚未确认。名字相同不代表含义相同，真正需要统一的是触发条件、责任人和退出标准。

因此，我不会把某套状态名称称为行业标准。更有价值的交付物，是一份团队能共同使用的状态词典：每个状态一行，写清定义、进入条件、离开条件、责任角色和例外处理方式。工具配置只是把这份约定落实到界面里。

三、常见误区：看板越配越细，协作却没有变快

1. 把所有管理信息都做成状态

优先级、缺陷类型、发布版本、责任团队、风险原因都很重要，但它们不一定是工作阶段。把这些信息全部塞进状态名称，会出现“高优先级开发中”“移动端开发中”“外部阻塞开发中”等组合，状态数迅速膨胀，统计也变得难以比较。

我的判断原则是：描述“工作走到哪一步”的信息，优先考虑状态；描述“这项工作是什么、有什么属性”的信息，优先考虑标签或字段；描述“为什么暂时不能继续”的信息，考虑阻塞原因字段或明确的异常标记。具体工具支持哪些字段和视图能力，要按当前产品版本核对。

2. 用状态掩盖责任不清

新增“等待某某”不一定等于责任明确。如果团队把卡片拖到“等待产品确认”，却没指定确认人、没有提出问题的记录，也没有跟进时点，任务仍然可能长期停留。状态名称看起来解释了原因，实际上只把管理问题换了一个标签。

更有效的处理方式，是在进入等待状态时补齐三项信息：等待谁、需要对方给出什么、何时复查。如果工具不能强制填写，也可以先通过团队约定或自动化提醒降低遗漏。

3. 把异常路径塞进主流程

返工、阻塞、取消、延期都是真实情况，但不意味着每种情况都要变成主看板的一列。若“阻塞”只是短暂等待，可能用标记和原因字段更清楚；若阻塞会触发升级、责任转移和时限管理，它可能值得被单独管理；取消则常常需要保留结果记录，不一定要沿着正常交付流程继续流转。

判断的重点不是异常发生得多不多，而是团队是否要对它采取独立动作，以及是否需要单独分析其影响。若不同处理方式会带来不同责任和管理规则，再考虑独立状态或流程分支。

4. 状态可以随意跳转，导致数据无法解释

如果卡片可以从“待处理”直接跳到“已完成”，而团队又没有规定何时允许跳过评审或验证，事后就很难分辨任务是走完流程，还是只是被快速关闭。反过来，把每一次跳转都锁得过严，也可能让紧急修复或小型维护受制于工具流程。

我建议先定义“必须遵守的门槛”和“允许例外的路径”。比如常规功能任务需经过验证，紧急修复可走简化流程，但应记录例外原因。工具权限应服务于真实治理要求，而不是为了看起来严谨而把所有路径都设成不可调整。

5. 只看状态数量，不看长期停留和回流

状态多不代表流程细，状态少也不代表管理差。更有诊断价值的观察包括：任务在哪个阶段停留较久、哪些状态经常被跳过、任务是否反复回到前一阶段、不同成员对同一状态是否有一致解释。指标能帮助发现问题，但不能单独证明原因。

四、专业判断逻辑：怎样决定要不要新增、合并或保留状态

1. 从工作事实开始，而不是从工具菜单开始

我会先收集一段时间内的任务样本，重点看卡片的状态变更记录、更新时间、责任人变化和交付结果。观察窗口可按团队节奏选择，例如覆盖一个完整迭代或一个发布周期；这只是方便取样的方法，不是必须遵循的行业标准。

挑选样本时，不要只看顺利完成的任务。至少要纳入按期完成、长期停留、返工、阻塞和取消等不同情形，否则新流程只适用于“理想任务”，遇到真实例外时很快失效。

2. 用“决策差异”判断两个阶段是否应拆开

将两个疑似状态并排比较：任务进入阶段A和阶段B时，负责人是否不同？接下来要执行的动作是否不同？离开阶段所需的证据是否不同？团队是否需要分别查看它们的数量或停留时间？如果这些答案大多是否定的，通常应考虑合并，或把差异改成字段。

反过来，如果“开发中”和“待评审”由不同角色负责，且交接动作不同，拆开就可能有实际价值。这种拆分不是为了追求流程颗粒度，而是让看板能回答“现在卡在哪个责任环节”。

3. 用状态词典把定义写成可执行规则

状态词典不必写成厚重流程制度。每个状态一行，控制在团队能快速查询的范围内即可。名称尽量表达任务当前处境，定义则说明触发条件和责任要求，避免用含糊词语让成员各自解释。

4. 先试运行，再确定正式流程

状态方案在白板或表格里看起来合理，不代表实际使用一定顺畅。试运行要观察三个现象：成员是否知道何时更新状态、任务是否能自然流转、异常任务是否有地方记录。若大家频繁绕过状态、把卡片拖回任意位置，说明流程定义或工具限制需要调整。

试运行也要明确边界：哪些团队参与，何时开始，谁收集问题，何时复盘。不要一边试用一边不断改名，却没有记录变更原因，否则成员会分不清是规则变了，还是自己记错了。

五、具体操作步骤：从草案到工具配置，再到团队验证

1. 第一步：记录现状，不要先删旧状态

先导出或抽查任务记录，统计现有状态的使用情况，并抽样核对卡片真实内容。使用次数少不必然意味着状态没用：它可能代表低频但关键的交付节点；使用次数多也不代表定义合理，可能只是大家把它当成默认选项。

我会将问题先分为三类：状态含义重叠、状态缺少触发条件、重要等待阶段不可见。这样比简单统计“哪列卡片最多”更容易找到配置改动的原因。

2. 第二步：画出状态流转草图

在配置之前，用表格或流程图表达主流程和例外路径。先确认正常任务从进入队列到交付如何经过关键阶段，再讨论紧急任务、返工、阻塞和取消如何处理。不要在第一轮就把所有罕见例外塞进主流程。

可以用下面的文本格式作为讨论草案，再依据工具的实际配置能力调整：

待处理
→ 开发中

→ 待评审

→ 待验证

→ 已完成

→ 评审退回：回到开发中

→ 阻塞：记录阻塞原因、责任人和复查时间

→ 已取消：记录取消原因并保留结果

这段草图不是通用流程模板。团队如果没有独立评审环节，可以合并对应阶段；如果验证由开发自测完成，也需要在状态定义中写清可追溯的完成条件。

3. 第三步：审查每个状态的必要性

逐个检查：它能否帮助成员采取不同动作？是否能通过字段或标签表达？是否会让任务状态变得难以维护？是否有明确的责任人和退出条件？若一个状态只是为了让报表更细，却没有稳定的记录方式，先不要上线。

合并状态时，注意历史数据的解释。过去的“进行中”可能混合多个阶段，合并或重命名后，不应假设旧任务记录自动具备新的语义。需要报表对比时，应记录迁移日期和历史口径，避免把定义变化误读为流程表现变化。

4. 第四步：在工具中配置并检查权限

进入所用项目管理工具的工作流或项目设置区域，按实际产品界面配置状态名称、顺序和允许的流转路径。不同产品、版本和部署方式的菜单名称可能不同，发布操作说明前应以当前版本官方文档或测试环境为准，不能把某一版界面写成所有用户都能看到的固定路径。

配置完成后，至少检查四件事：成员是否能看到新状态；卡片能否按预期流转；权限是否会阻断正常工作；通知和自动化是否会重复触发。若团队管理敏感研发数据，还要把访问范围、审计要求和部署方式纳入实施评估。

5. 第五步：选择小范围试运行

优先挑选流程相对稳定、成员愿意参与复盘的项目试用。试运行期间保留反馈入口，记录“无法流转”“不知道该选哪个状态”“同一状态多人解释不一”等具体情况。不要只问“大家觉得怎么样”，而要让成员提供发生问题的任务链接或实际情形。

试运行后，分别看流程可用性和记录质量。若任务能走通，但成员总忘记更新状态，可能需要调整操作习惯或自动化提醒；若成员按规则更新却仍看不出责任交接，可能是状态定义不完整；若出现大量例外跳转，则要判断是规则过度约束，还是主流程遗漏了常见路径。

6. 第六步：发布状态词典和变更规则

正式上线时，发布一页简明的状态说明，告诉团队新旧规则的差异、生效时间、异常处理方式和反馈渠道。另需明确谁可以修改工作流、修改前要通知哪些角色、历史数据如何处理、何时复审。没有变更治理，状态体系很容易随着项目临时需求不断分叉。

对于 100 人以上的组织，跨团队复用尤其需要谨慎。统一的状态名称有利于汇总，但各团队的实际交接可能不同。更可行的方式通常是统一核心阶段的语义，同时允许经过治理的团队级扩展，而不是强迫所有项目使用完全相同的流程。

六、案例与数据观察：一条示例流程如何暴露交接问题

1. 示例背景：问题不在“开发中”太宽，而在下一位责任人不可见

下面用一个明确标注为情景模拟的研发团队案例说明判断方法。假设一个 12 人团队维护内部业务系统，任务从开发到交付需要评审和验证。原看板包含“待处理、进行中、已完成”，团队成员反馈“进行中”任务很多，但难以判断哪些需要继续开发、哪些在等评审、哪些在等验证。

这时不应直接把所有阶段拆细。先抽查 40 张任务卡，逐项核对状态记录与实际活动。假设其中发现 14 张正在开发、10 张等待评审、8 张等待验证、5 张因外部依赖暂停、3 张已取消但仍留在进行中。这个分布是用于演示的样本推演，不能当作行业平均值。

观察结果说明，团队需要区分的不只是工作阶段，还包括两类异常：外部依赖等待需要复查和升级，已取消任务则需要从正常交付队列中退出并留下原因。若把“阻塞”简单等同于一个新状态，仍需定义谁跟进、何时复查、解除后回到哪一步。

2. 调整后要看过程信号，而非只看完成数量

完成数量会受任务大小、需求变更和迭代节奏影响，不能单独用来证明状态调整有效。更有解释力的观察包括：待评审队列中的任务是否能识别评审责任人；等待验证的任务是否有清晰交接；阻塞任务是否具备原因和复查日期；返工是否能追溯回流原因。

例如，配置上线后，“待评审”卡片数量增加，不一定意味着评审变慢，也可能只是过去被隐藏在“进行中”的任务现在被显性记录。要结合停留时长、任务量和团队处理节奏解释变化。状态改善首先提高的是可观察性，不应直接把可见性提升包装成效率提升。

3. 一份适合复盘的观察表

七、不同情况下的行动建议与取舍

1. 小团队：优先约定规则，谨慎增加配置复杂度

团队人数较少、协作链路短时，成员通常可以直接沟通。此时先统一已有状态的含义、责任人和更新时点，可能比新建多个状态更有效。如果只有少数任务需要区分，可先用标签或轻量约定试验，等确认该差异会反复影响决策，再升级为正式状态。

小团队的取舍重点是维护成本。若新增状态需要所有人学习，却只在极少数任务上出现，实际收益可能不足以覆盖沟通成本。但如果某个交接点频繁遗漏，增加一个状态反而可能显著降低口头追问。

2. 多团队组织：统一语义，允许必要的局部流程

大型组织通常需要跨团队统计，也要容纳不同项目的研发方式。完全统一每一个状态，可能导致某些团队不得不制造虚假步骤；完全放任团队各自命名，则会让汇总报表失去可比性。

我的建议是分两层治理：第一层统一少数核心语义，例如工作尚未开始、正在处理、等待交接、已完成；第二层允许团队在不改变核心统计含义的前提下增加本地阶段。若组织要求跨项目比较，必须把状态映射规则写清楚，不能只按名称相似就合并口径。

3. 强合规或审计场景：流程可追溯性优先于少点几下

涉及审批、质量门禁或审计要求时，状态变化可能关联责任记录和验收证据。此时要优先确认谁有权限流转、关键节点是否需要附件或审批记录、例外路径能否追溯。流程可以比普通团队更严格，但仍需留出授权例外机制，避免紧急处理时团队在系统之外另建一套不可追溯流程。

这一场景下，状态设计要与组织制度和实际工具能力一起评估。不要只依赖颜色、名称或成员记忆来承担控制责任，也不要在未确认权限模型前承诺某平台能够实现特定审批效果。

4. 迁移到新工具：先做状态映射，再搬任务历史

如果团队正在迁移项目管理平台，旧状态与新状态往往不是一一对应。迁移前应把旧状态逐项映射到新语义，标出无法准确映射的历史记录，并决定保留旧值、归入通用阶段，还是通过附加字段保留原始信息。不要为了让迁移表看起来整齐，把含义不同的状态强行合并。

以 PingCode 为例，若组织正在评估研发协作工具，可把工作流配置、跨项目管理、权限治理、私有化部署要求和历史数据迁移放在同一轮验证中。它主要面向中大型企业及 100 人以上组织，并支持私有化部署和 Jira 平滑迁移；具体迁移范围、字段映射、工作流兼容性及当前版本能力，仍应结合官方资料和实际测试环境逐项确认。评估国产替代时，不能只看功能清单，还要验证团队现有流程能否迁移、报表口径是否保持、管理员是否能够持续维护。

5. 资源紧张时：先改一条关键路径，不追求一次重构全部流程

如果没有足够时间全面梳理，可以先选一条返工多、等待明显或责任交接频繁的路径试点。写清状态定义，配置最少必要流转，观察一个完整工作周期，再决定是否扩展到其他项目。局部试点能降低改动风险，也能让团队用实际问题检验设计假设。

但局部试点要避免“试点成功、无法复制”。结束时应记录哪些规则是通用的，哪些依赖项目角色或工具权限；若后续推广，先做映射和培训，再扩大范围。

八、上线前检查与持续复盘：让状态体系不过期

1. 上线前检查清单

• 每个状态是否有一句可理解的定义，而非只提供名称？
• 进入和退出条件是否能通过实际工作记录判断？
• 当前责任人与下一步接手方是否明确？
• 是否把优先级、类型、版本等属性误做成流程状态？
• 阻塞、返工、取消等常见例外是否有明确记录方式？
• 状态跳转权限是否满足团队治理要求，又不会阻断必要工作？
• 历史数据、报表口径和跨项目汇总是否已考虑？
• 是否明确配置负责人、变更通知方式和复盘时间？

2. 复盘时区分三类问题

定义问题：成员对同一状态解释不同，说明状态词典不够明确，或者培训只讲了名称、没讲触发条件。此时先修定义，不要马上增加新状态。

流程问题：任务经常停在交接点，责任人不明确或等待没有复查机制。此时应检查交接规则、责任分配和提醒机制，状态本身可能无需增加。

工具问题：规则明确、成员也理解，但实际界面无法表达所需路径，或者权限设置阻碍正常工作。此时才需要评估配置调整、自动化能力或工具适配，并在当前版本中验证。

3. 复盘关注变化，不用单一指标下结论

团队可以定期检查状态解释一致性、状态长期停留情况、退回与跳转记录、阻塞信息完整度，以及任务交接是否有明确责任人。指标适合发现需要讨论的信号，不适合直接给个人排名或简单判断团队好坏。

如果某状态长期无人使用，先确认它是否本来就只服务于低频关键环节；如果成员总是跳过它，再判断是规则不现实、工具不顺手，还是培训不足。数据提出问题，工作现场的核对才能解释问题。

4. 结尾：真正好的状态，是让下一步更容易发生

我看一套看板状态设计得好不好，不先数列数，也不先看颜色，而是挑一张正在流转的任务卡，问三件事：现在它为什么在这里？谁负责下一步？什么条件满足后它才能离开？如果团队能给出一致、具体的答案，状态设计就开始发挥作用。

下一步不必从重做整套工作流开始。先抽查一批近期任务，找出一个最影响交接的模糊状态；写清进入条件、当前责任和退出标准；再在小范围试运行并记录例外。看板的价值不在于把流程画得更复杂，而在于让工作进展、等待原因和下一步行动都能被团队看见。