工作流状态标签：团队可以共享的 7 个清晰状态

为什么不清晰的状态会拖慢工作

模糊的工作流状态标签会制造出看似繁忙但无意义的混乱。人们把条目往前移动，但没人确切知道发生了什么变化。一个标记为 “In Progress”（进行中）的任务，可能意味着“我刚开始考虑它”、“我被卡住了”，或“我已完成并等待复核”，这取决于最后接触它的人。

这种不匹配会导致三个可预见的问题：返工、错过交接以及噪音通知。如果状态没有说明下一位应该做什么，工作就会来回弹回。如果交接隐藏在模糊的标签里，就会一直放着，直到有人注意到。如果每个人只是为了“显示有在做”而更新状态，你的动态就会变成一片模糊，真正的变更很容易被忽略。

另一个常见症状是相同的标签在不同界面上被不同使用。一位队友用 “Ready” 表示“准备好评审”，另一位用它表示“准备开始”。查看看板的经理无法判断团队是在等待、在执行还是已完成。

目标不是描述每个边缘情况，而是用更少的状态把正常路径变得明显。当状态在所有地方都一致时，你会得到更快的交接和更少的“这到底完成了吗？”这样的提问。

如果你的团队不知道从哪里开始，目标是选 5–7 个状态来覆盖大多数工作：一个用于新条目，一个用于进行中的工作，一个用于等待或被阻塞，一个用于评审或批准，一个用于完成。只有在基础稳定且每个人都使用相同含义时，再添加细节。

状态标签应该（和不应该）表达的含义

状态标签是关于接下来会发生什么的共同承诺。当有人改变状态时，所有人都应能在不追问的情况下预测下一步。

好的工作流状态标签描述的是工作的当前现实，而不是某人的主观看法。如果标签真实，团队就能判断条目是在移动、等待还是被阻塞，以及下一位应该是谁。

状态并不等同于优先级、负责人、类别或进度备注。这些字段可能很重要，但把它们混进状态会让状态变得不可靠。

把“状态”（state）与“阶段”（stage）区分也很有帮助。状态是真实的当前情况（例如，“Blocked: waiting for customer reply”），阶段是条目在流程中的位置（例如，“review”）。可以混合使用，但当一个状态试图同时描述两者时，通常会变得模糊不清。

一个有用的状态应触发以下三者之一：

• 下一位负责人（谁来接手）
• 下一步动作（接下来要做什么）
• 等待条件（在等什么）

快速现实检查：有人在小列表视图中读到标签还能知道下一步该做什么吗？如果答案是“视情况而定”，该标签可能在隐藏一个应该在别处决定的决策（例如优先级规则或分配）。

应该使用多少个状态以及为什么 5–7 个合适

状态系统的目的是让工作一目了然。状态太多，人们就不再信任看到的内容；太少又会丢失管理交接所需的细节。

对大多数团队来说，5–7 个状态是最佳区间。它能在单屏展示，适用于看板或简单列表视图，并提供足够的信息来回答日常问题：什么被阻塞、什么在进行中、什么在等待评审。

保持集合精简还能减少“状态搜索”（猜测 12 个选项中哪个最接近）、让报表更简单，并迫使你把优先级、负责人和类型作为独立字段保留。

名称可以不同，这没问题。一支队伍可能用 “In Progress”，另一支可能用 “Doing”。但不能变化的是含义。如果 “In Review” 有时表示“等待 QA”，有时表示“等待客户”，你的看板就会变成噪音。

为了保持含义一致，建立一个唯一的事实来源：一份简短的团队文档，说明每个状态、它的含义以及何时进入和离开该状态的规则。保持短小，让人两分钟内能读完。然后在所有显示工作的地方使用同一套状态。

一个可以直接开始使用的简单 7 状态集

如果你想要长期保持清晰的工作流状态标签，从一个能回答三个问题的小集合开始：当前谁负责，接下来会发生什么，什么算“完成”。

这里有一套对大多数团队都适用且不过于细化的 7 个状态：

关键规则：不要单独使用 “Waiting”。如果某项被卡住，标记为 Blocked 并在备注中写明依赖（例如 “Blocked: customer reply” 或 “Blocked: access granted”）。

每个状态的定义（含进入与退出规则）

清晰的工作流状态在每个状态都能回答一个简单问题：现在真实的情况是什么？

New

真实情况：条目已被记录，但尚无人评估。

不真实的情况：优先级、范围或负责人未达成一致。

进入：提交请求。

退出：有人阅读并移动到 Triaged。

示例：“一位支持人员提交了带一张截图的 bug 报告。”

Triaged

真实情况：团队已足够了解请求以便分类并确认其有效性。

不真实的情况：尚未准备好开始工作。

进入：有人补充基本上下文（摘要、影响、受影响区域）。

退出：要么准备好执行（Ready），要么被有意驳回（在流程外处理，而非作为一个状态）。

示例：“PM 标记为真实 bug 并备注重现步骤。”

Ready

真实情况：可以在不缺信息的情况下开始工作。

不真实的情况：工作尚未开始。

进入：验收标准明确，依赖到位。

退出：某人开始工作并做出第一个实质性更改（In Progress）。

示例：“表单字段与校验规则已达成一致。”

In Progress

真实情况：正在进行主动工作。

不真实的情况：它并非在队列中等待。

进入：有人接手并开始工作。

退出：达到可检查的完成度（In Review）或触及依赖被标为 Blocked。

示例：“开发者实现了新的状态下拉并保存了逻辑。”

In Review

真实情况：正在进行检查（同行评审、QA 或利益相关者批准）。

不真实的情况：还在继续新增功能。

进入：执行者提交以供验证。

退出：被批准并符合团队的完成定义（Done），或带反馈退回（In Progress）。

示例：“QA 在 Web 和移动端均确认通过。”

Blocked

真实情况：由于具体且已命名的依赖，工作无法继续。

不真实的情况：条目只是优先级较低。

进入：指派人在无法独自解决的依赖上受阻。

退出：依赖被移除并恢复工作（通常为 In Progress）。

示例：“Blocked: 等待获得生产日志访问权限。”

Done

真实情况：满足约定的验收标准并已发布或准备发布。

不真实的情况：仍需评审、测试或后续跟进。

进入：评审通过且发布步骤完成（根据你团队的定义）。

退出：无；重新打开时需有明确的新理由并开始新一轮流程。

示例：“修复已上线且 bug 无法复现。”

分步操作：在 60 分钟内创建你的状态系统

你可以在一次集中会议中修复混乱的状态。目标不是完美模型，而是一套能反映实际工作流且大家能复述的共享标签与规则。

一个 60 分钟的工作会议（并产出一个结果）

邀请每个接触该工作的角色中的一名代表（请求者、执行者、审查者、批准者）。共享屏幕并打开当前看板或列表。

首先，绘制真实的工作流（不是理想流程）。选一个典型条目并追踪实际发生的每一步，包括等待时间。把步骤写成动词（“起草”、“评审”、“批准”）。如果某步只是偶尔发生，将其标注为分支。

接着，删除重复项并重命名不清晰的标签。合并意义相同的标签（“In Progress” 与 “Doing”）。把模糊的标签（“Pending”）改成可以执行的说法（“Blocked: customer reply”）。如果你无法用一句话解释一个标签，它还不够成熟。

然后为每个状态添加进入与退出规则。写清进入时必须满足什么、离开时必须满足什么。保持简短。例如：“In Review 在工作提交时进入，待反馈处理并审查通过时离开。”

之后，为每个交接点指定负责人。每个状态都应有默认负责人（用角色就可以）。这样能防止条目无人处理。例如，“In Review 的负责人是审查者，而不是执行者”。

最后，在 10 条近期条目上测试并调整。从过去几周中选 10 条已完成或进行中的条目，并在每个时间点为其分配状态。如果你们经常争论，说明标签重叠；如果无法放置一个条目，说明缺少状态或将两个概念混为一谈。

会后，把定义发布到一个地方，并确保所有人看到的标签都是一致的。

在 Web 与移动端保持状态一致性

如果一个状态在网页上和移动端上含义略有不同，人们会停止信任它。他们会在聊天中提问、重复检查详情，或在注释里创建自己的“真实状态”。工作流状态的目的应是共享事实，而不是装饰。

把状态视为一个共享字段，并设置唯一事实来源。相同的标签应在列表、详情页、通知、导出和推送消息等所有地方以相同拼写、大小写和含义出现。

小屏幕上的实用规则

移动屏幕会惩罚冗长名称和弱视觉设计。一个在桌面表格看起来没问题的状态，可能在手机上变成被截断的、难以理解的徽章。

• 名称保持简短（尽量 1–2 个词）。
• 使用一致的颜色，但不要只依赖颜色传达信息。
• 以最长标签为设计基准，避免截断导致不可读。
• 在各平台保持顺序一致。
• 避免 “几乎相同” 的标签，如 “In Progress” 与 “Working”；选一个。

位置也很重要。在详情页把状态放在标题附近，让人在阅读完整描述前先看到状态。在列表视图中始终把它放在同一位置。

无障碍的基本做法对每个人都有帮助。颜色只是提示，不是信息本身。始终显示文本标签，可以考虑添加简单图标（例如 Done 的勾），以便使用屏幕阅读器或色觉有差异的人也能快速获取含义。

导致状态漂移的常见错误

当状态不再表示“工作在哪里”，而开始表示“人们对工作的感受”时，状态就会漂移。那时你的看板看起来很忙，但没人真正信任它。

一个常见原因是过多标签来匹配每个小步骤。如果一个任务在一小时内可能移动三次，人们会停止更新，或者选一个“差不多”的状态。少而精的状态在每次变更都代表真正的准备或责任变化时效果最好。

另一个漂移点是把不同维度混在一个字段里。优先级和紧急程度很重要，但它们属于独立字段，而不该放在状态里。如果 “Urgent” 是一个状态，它就会与 “In Review” 争夺位置，报表的含义就会丢失。

警惕这些模式：

• 多个“差不多完成”的标签却没有明确差别
• 一次性个人标签（“等 Sam”）
• “In Progress” 变成了停车场
• 没有书面的进入/退出规则
• 新界面显示不同的状态名称或顺序

为防止漂移，指定一个人负责状态集合并尽量少改动。改动时，写明改了什么、为什么改以及替换了什么。

示例：一个请求从开始到完成

用户向支持写道：“在移动端，订单历史页面即使有订单也显示空状态。”支持记录一个将转为产品修复并最终发布的条目。

New：支持收集截图、设备信息以及什么才算“正确”。

Triaged：产品负责人确认这是个真实的 bug，确定所属（移动端而非后端），并说明影响程度。

Ready：重现步骤确认无误，验收标准明确。

In Progress：工程师复现问题，发现 API 返回了数据但页面过滤错了，开始修复。

Blocked：工程师发现 UI 依赖某个旧账号缺失的字段，需要后端变更。条目标为 Blocked 并写明原因：“Blocked: backend needs legacy field mapping.”

In Review：依赖解决后，QA 在 iOS 与 Android 上检查并验证在确实没有订单时仍显示空状态。

Done：修复被批准并已发布（或排入下个发布窗口，如果你的团队这样定义为完成）。支持确认上线并回复用户。

注意防止混乱的要点：“Blocked” 有明确理由和下一步，且职责不来回转移。任何人打开条目都能看懂谁在负责。

保持团队一致性的快速清单

如果你的看板感觉混乱，通常 10 分钟就能找到原因。

10 分钟看板扫描

快速查看看板并寻找这些信号：

• 每个状态都能回答：“现在真实情况是什么？”
• 每个状态有默认负责人（角色即可）和明确的下一步动作
• 没有两个状态可以同时描述同一条目
• 条目不是被无限停放（如果能停好几天，增加一个退出规则）
• 相同类型的工作应走相同的核心步骤，除非有书面例外

如果人们对卡片属于哪个状态存在争议，说明该状态与另一个状态重叠或定义不够清楚。

Web + 移动一致性检查

在手机上打开相同工作流，确认标签在窄空间内仍然有效：

• 标签在列表视图中短且可读（不截断）
• 文本在没有颜色时也能传达含义
• 状态变更由一个负责人批准（团队负责人或运维），而不是个人随意决定
• 每次变更都带有简短备注，防止定义漂移

下一步：维护、衡量并持续改进

状态系统在你把它当作规则手册来维护时才会持续有效：稳定，但需定期复查。目标不是不断改动，而是始终如一地使用。

设定轻量的节奏，例如每月一次 30 分钟的复盘，邀请每个接触看板的角色选一人参加。带上 5–10 条近期条目，寻找可以修正的例外情况。

几个值得跟踪的简单信号：

• 在 Blocked 状态的时间（以及最常见的原因）
• 在两个状态间来回弹的条目
• 超过正常周期时间仍然无人触碰的条目

当你感觉不对时，别急着添加新状态。只有当新的状态确实不同、会改变人们的下一步动作并且经常发生时，才该新增状态。大多数情况下，更简单的修复是：收紧定义、补充进入规则或明确负责人。

如果你在为内部工具构建工作流，把状态当作共享数据而不是界面专用文本。例如在 AppMaster (appmaster.io) 中，你可以在 Data Designer 里一次性定义状态字段，并在 Web 与原生移动应用中复用，从而减少“手机上意义不同”的漂移问题。