状态怎么做？研发团队落地方案：任务属性从0到1

2023 年我接手过一个挺典型的烂摊子：一家做工业 SaaS 的公司，研发团队 180 人，项目管理平台里躺着 11 个工作流状态。从「需求池」到「已关闭」，中间塞了「待评审」「评审中」「待排期」「开发中」「联调中」「待提测」「测试中」「待上线」「已上线」。听起来很专业，对吧？问题是他们的周会上，产品经理说「这个需求在开发中」，开发说「我这边还没排上，它在待排期」，而系统里这张卡片显示的是「联调中」。三个人说的是同一张卡，三个答案。

更扎心的是数据：我拉了他们前 90 天的状态变更日志，发现 63% 的卡片在「开发中」这个状态里停留超过 5 天没有任何变更记录，而「联调中」和「待提测」两个状态加起来的平均停留时间只有 4.2 小时，也就是说，这两个精心设计的状态，几乎从没被真正使用过，只是给报表增加了两行颜色。

这就是我想聊「状态」这件事的原因。绝大多数团队做状态设计时，脑子里想的是「怎么把流程画得更完整」，但状态真正的用户不是流程，是每天早上站会里那十几个人。状态不是流程的说明书，而是团队的共识接口。这篇文章我会把状态和任务属性从 0 到 1 的落地过程完整拆一遍，包括我踩过的坑、见过的六个高频误区、四层设计法，以及一个把 11 个状态压到 5 个状态的真实改造案例。

一、先把结论摆出来：状态设计的五条硬规则

在展开细节之前，我先把这几年反复验证过的结论放在这里。如果你只想要一份可执行的判断依据，这五条基本够用；如果你想知道为什么是这五条而不是别的，后面的章节会逐层拆开。

规则一：状态描述「东西在哪」，不描述「谁在忙」。「开发中」是一个合法的状态，「张三正在写」不是。前者是物料的物理位置，后者是人力的占用情况。一旦你把人的忙闲塞进状态，状态就变成了考勤工具，团队会本能地开始美化它。

规则二：状态数量上限由团队纪律水平决定，不由流程复杂度决定。很多团队以为流程复杂就该状态多，恰恰相反。我观察到的规律是：能稳定维护 9 个以上状态的团队，必须具备专职的流程 owner 和自动化的状态流转规则，否则三周内必然退化，大家开始凭感觉点，历史数据变成噪音。

规则三：每个状态必须有唯一的「退出条件」和「退出责任人」。没有退出条件的状态是黑洞。我见过最夸张的一个团队，「测试中」的退出条件是「测试完成了」，这等于没写。正确的写法是「所有 P0/P1 缺陷已关闭，且验收人点击通过」。

规则四：先定 5 个状态，跑满两周再动。状态设计最大的敌人是会议室里的完美主义。纸上推演出来的状态机，几乎没有一个能原样落地。先上一个最小可用版本，用真实流转日志去修正，比开三次评审会有效得多。

规则五：状态和看板列必须解耦。状态是工作项的数据属性，看板列是人的视图。一个状态可以映射到多列，一列也可以聚合多个状态。把它们 1:1 绑死，等于把数据库表结构绑死在某个人的 Excel 上。

二、为什么 100 人以上的团队一定会撞上「状态失控」

30 人的团队几乎不需要状态设计。大家坐在一个开放区，抬头喊一嗓子就知道进度。这时候哪怕状态只有「待办 / 做 / 完」三个，协作也不会出问题，因为真正的信息通道是人，不是系统。

问题出在组织跨过某个规模阈值的那一刻。当团队从「彼此认识」变成「彼此知道角色」的时候，口头同步的带宽就撑不住了。你开始需要一套不依赖记忆和人际关系的共享状态。而这个时候，团队往往已经积累了一堆历史遗留状态，改造成本和抗拒心理都已经起来了。

1. 从 30 人到 150 人：状态口径一致率的衰减曲线

我把过去几年收集的样本按团队规模做了分层，统计了一个指标叫「状态口径一致率」，做法很简单，随机抽 20 张在制品卡片，让负责人和项目经理分别独立判断「这张卡真实处于什么阶段」，两边判断一致才算通过。

结果是一条很陡的衰减曲线。30 人以下能到 90% 以上，100 人左右掉到 74%，200 人掉到 61%，超过 400 人的团队基本在 40% 上下徘徊。这条曲线的含义很直接：你看到的看板，和真实发生的研发，是两个东西。

2. 站会为什么会变成「状态朗读会」

很多团队的站会最后会退化成逐卡念状态，本质原因是状态本身失去了信息量。当一张卡片从「待办」到「完成」中间只有两个状态时，状态变更就等于「有人动了一下」；而当状态有 11 个时，状态变更又太频繁，念起来没完。

我统计过不同规模团队站会时间的构成，结论是：状态数量在 5，7 个区间时，站会里讨论「阻塞和依赖」的时间占比最高，接近 45%；状态超过 12 个之后，这个占比会跌到 20% 以下，剩下的时间全花在确认「这张卡到底在哪个状态」上。站会不是变长了，是变质了。

3. 状态失控的三种典型症状

判断一个团队的状态设计是否失效，不用看流程文档，看三个现象就够了。

症状一：同一个人在站会上说出的状态和系统里不一致。这说明系统状态已经不是可信数据源，只是填报义务。一旦出现这种情况，所有基于状态的度量，周期时间、吞吐量、瓶颈分析，全部作废。

症状二：出现「僵尸状态」。也就是某些状态的卡片数量长期接近于零，但仍然留在工作流里。我见过一个团队保留了「待 UED 确认」这个状态，半年里只有 3 张卡片流经过。这种状态存在的唯一作用是让流程文档显得完整。

症状三：状态变更需要「特权」。比如只有项目经理能把卡片从「测试中」拖到「已完成」，普通成员拖不动。这看起来是权限设计，实际上是流程设计失败的信号，如果一个状态流转需要靠人来审批，说明它的退出条件没有被定义清楚。

三、我见过的六个高频误区

下面这六条，是我在复盘会上重复讲得最多的。它们有个共同特征：看起来都很有道理，甚至在某个阶段确实有效，但在团队规模扩大后就会变成负债。

1. 误区一：把状态做成审批流

最典型的表现是状态名里带「待」字：待评审、待排期、待确认、待验收。这类状态的本质不是「工作在哪」，而是「等某个人点头」。

审批流和研发流的区别在于：审批流关心的是合规，研发流关心的是价值流动。把审批节点做成状态，最直接的后果是「待」状态堆积，而且没人觉得这是问题，因为在大家心里，「等评审」不算拖延，是在走流程。我在一个团队里见过「待排期」的平均停留时间是 9.4 天，比「开发中」还长，但从来没有人把它列为瓶颈。

正确的做法是把审批动作变成字段（比如「评审结论」），把审批结果变成流转条件，而不是让审批本身占用一个状态位。

2. 误区二：用状态承载「阻塞」

「已阻塞」是一个很诱人的状态，因为它一眼就能看出问题。但它会破坏状态机的正交性：一张卡片可以既是「开发中」又是「已阻塞」，你只能二选一，等于丢失了一个维度。

我在 PingCode 上做配置时的做法是：状态只表达生命周期位置，「是否阻塞」用独立的标记字段或标签表达。这样你可以统计出「处于开发中且被阻塞的卡片有 14 张，平均阻塞时长 3.2 天」，而不是只看到一个笼统的阻塞状态。后者根本无法告诉你瓶颈发生在哪个环节。

3. 误区三：状态名用动词或形容词

「开发中」「测试中」没问题，但「优化中」「处理中」「跟进中」就是灾难。「处理中」到底是在写代码、在等接口、还是在跟客户对齐需求？这三种情况对应的下一步动作完全不同，但在报表里它们是一回事。

判断一个状态名是否合格，我有个简单测试：把状态名念给一个刚入职一周的新人听，他能不能立刻判断出「什么东西已经发生了，什么东西还没发生」。「联调中」通过这个测试，因为它隐含了「双方代码已提交、正在验证接口」；「跟进中」不通过，因为它什么都没说。

4. 误区四：状态与看板列 1:1 死绑

这是工具层面的误区，但影响很大。很多团队在配置项目管理平台时，直接把看板的列等同于工作流状态，一列一个状态。

问题在于，看板列是为「人」服务的视图，状态是为「数据」服务的属性。同一个状态在不同团队、不同迭代阶段可能需要不同的展示方式。比如「开发中」这一列，在迭代中期可能是活跃列，在迭代末期可能被拆成「开发中-前端」「开发中-后端」两列。如果列即状态，你每次调整视图都要改工作流，改工作流就要动历史数据。

5. 误区五：状态只增不减

状态机的演化几乎总是单向膨胀的。每次出现问题，大家的直觉是「再加一个状态就能区分了」：出现了联调扯皮，加个「联调中」；出现了提测不清晰，加个「待提测」；出现了线上验证问题，加个「待线上验证」。

极少有团队会主动删状态。但状态设计的第一步应该是减法，不是加法。我的建议是给状态机设一个硬性上限（比如 7 个），新增一个必须删掉一个，强制做取舍。这条规则本身不完美，但它能逼着团队想清楚：「这个新状态到底解决了什么上一版解决不了的问题？」

6. 误区六：状态改了，历史数据没对齐

最后一个误区最隐蔽，也最贵。团队把 11 个状态简化成 5 个，配置改完上线了，但两万条历史卡片的状态字段还是老值。结果就是报表里同时出现「联调中」和「验证中」两套语义，任何跨周期的趋势分析都做不了。

正确的做法是：状态合并必须同时定义映射规则，并且映射规则要可审计。比如「联调中 + 待提测 → 验证中」，这个映射关系要写在变更记录里，而不是靠某个人的记忆。下面是我们当时用的一份状态映射配置示例：

status_mapping:
from: legacy_workflow_v3

to: workflow_v4

rules:

old: "需求池"

new: "待办"

old: "待评审"

new: "待办"

old: "评审中"

new: "待办"

old: "待排期"

new: "待办"

old: "开发中"

new: "进行中"

old: "联调中"

new: "验证中"

old: "待提测"

new: "验证中"

old: "测试中"

new: "验证中"

old: "待上线"

new: "待发布"

old: "已上线"

new: "已完成"

old: "已关闭"

new: "已完成"

audit: true # 保留原状态值到 legacy_status 字段，便于回溯

effective_date: "2023-11-01T00:00:00+08:00"

注意 audit: true 这一行。我坚持把所有状态改造都保留原始值到独立字段，因为半年后一定会有人问「改造前的周期时间是多少」，如果没有原始值，这个问题就永远回答不了。

四、专业判断逻辑：状态从 0 到 1 的四层设计法

说完误区，讲方法。我把状态设计拆成四层，每一层解决的问题不同，顺序不能颠倒。跳过第一层直接做第三层，是做状态设计最常见的失败方式。

1. 第一层：先确定生命周期的「锚点」，再谈中间态

所谓锚点，是一个工作项从被创建到被彻底关闭，必然经过的几个不可绕过的位置。对绝大多数研发团队来说，锚点只有四个：还没有人打算做、有人打算做但没开始、正在做、做完并验证了。

这四件事对应的状态就是「待办」「已排期（可选）」「进行中」「已完成」。锚点的特征是它们无法被合并，你不可能说「这张卡片既没开始又在进行中」。

先定锚点有个巨大的好处：它逼着你把所有候选状态都拿去和这四个锚点比对，问一句「它是不是可以归到某个锚点里」。我见过太多团队一上来就讨论「要不要加联调状态」，但从来没人问过「联调到底属于做完了还是没做完」。

2. 第二层：区分正向流转与退回流转

状态机里最容易被忽略的是「退回」。正向流转是「待办 → 进行中 → 验证中 → 已完成」，退回是「验证中 → 进行中」「已完成 → 验证中」。

很多团队在设计状态时只画正向路径，结果上线后发现卡片在往回拖的时候没有合适的落点，只能拖回「进行中」，于是所有返工都被记录成「进行中」，瓶颈分析彻底失效。

我的建议是：退回流转必须显式定义，并且要求填写退回原因。在 PingCode 这类支持工作流自定义的平台上，可以把「退回原因」设成流转必填字段，这样你就能统计出「因为需求理解偏差退回占 41%，因为环境问题退回占 22%」，这才是真正能推动改进的数据。

3. 第三层：把「不在流程里」的状态显式化

这一层是我认为最有价值的差异点。绝大多数团队的状态机只描述「在流程里」的卡片，但真实项目里，大量卡片是「不在流程里」的：被搁置的、被否决的、被合并到其他需求的、需求方撤回的。

如果这些卡片没有专属的终止状态，它们就会永远挂在「待办」列里，让你的待办池越滚越大，最后没人知道那 400 张待办卡里到底有多少是活的。

我的方案是设两个终止态：「已完成」和「已取消」。已完成表示交付并验收，已取消表示明确不再做。两者都需要填写原因。这个设计还有一个额外好处：当你发现「已取消」的数量超过「已完成」的 30% 时，说明需求进入系统前的筛选机制出了问题，这是非常有价值的输入信号。

4. 第四层：定义状态迁移的权限与自动化

最后一层才是大家最爱讨论的权限和自动化。我把这一层放最后，是因为在没有前三层的前提下做自动化，等于把错误的流程自动化，只会错得更快。

这一层要回答三个问题：谁能改状态、什么时候自动改、改了之后触发什么。我整理过一份常用的自动化规则清单，按价值排序：

1. 代码提交信息中关联工作项编号，自动把状态从「进行中」推进到「验证中」，价值最高，因为它把状态变更和真实工作绑定，无法造假。
2. 工作项被加入某次发布计划时，自动流转到「待发布」，减少人工维护成本。
3. 验收人点击通过后，自动流转到「已完成」并记录完成时间，确保完成时间是可信的。
4. 卡片在「验证中」停留超过 5 个工作日时，自动通知 QA 负责人，把等待变成可见的告警。
5. 子任务全部完成时，父任务状态自动推进，减少父子状态不一致。

注意第一条。如果把状态变更和代码提交挂钩，你就得到了一个无法伪造的进度信号。这是我认为判断一个团队状态数据可信度的最快方法：看它有没有和代码仓库打通。

五、任务属性从 0 到 1：哪些字段必须建，哪些是负担

状态解决的是「东西在哪」，任务属性解决的是「这是个什么东西」。两者是状态机的一体两面：只有状态没有属性，你无法做分群分析；只有属性没有状态，你无法看流动。

但属性的问题比状态更严重，因为它看起来「零成本」，加一个字段而已。结果就是很多团队的工作项表单长得像一份申请表，填完要三分钟，成员自然开始填假数据。

1. 必建字段清单

下面这六个字段，我建议任何研发团队从第一天就建起来，不要犹豫。

• 工作项类型：需求、任务、缺陷、子任务。类型决定了后面所有字段的可见性和工作流的适用性，是最基础的分类维度。
• 负责人：单一负责人，不是多人。多人负责等于无人负责，这是最贵的组织学常识。
• 优先级：建议只用四级，P0 阻塞、P1 本期必须、P2 应该做、P3 有空再说。超过四级，判断成本会超过收益。
• 所属迭代或版本：这是把工作项和交付节奏对齐的关键字段。没有它，你无法回答「这个迭代能不能按时交付」。
• 验收人：这是我认为最被低估的字段。负责人负责做，验收人负责判，这两个角色分开，能消灭大量「做完了但没人认」的扯皮。
• 创建来源：客户、内部、监控告警、还是技术债。这个字段成本极低，但半年后你能算出「需求里有多少是自产的」，价值极高。

2. 选建字段：按团队成熟度决定

下面这些字段有价值，但前提是团队已经能稳定填写前面六个。如果你的团队现在连负责人字段都经常空着，加这些只会增加噪音。

3. 慎建字段：我建议直接砍掉的类型

有三类字段，我看到就建议删掉。

第一类是「进度百分比」。它和状态高度重复，而且几乎必然是拍脑袋填的。一张卡片填了 70%，这个 70% 是代码写完了 70%，还是需求覆盖了 70%？没有人能回答一致。它的唯一作用是让甘特图看起来更漂亮。

第二类是「预计完成时间」加「实际完成时间」加「承诺完成时间」三件套。当你不止一个时间字段时，团队会开始维护「哪个时间给老板看、哪个时间给自己看」两套账。只保留一个截止日期，且允许它被修改并记录修改原因，比三个时间字段诚实得多。

第三类是自由文本的「备注」以外的大段描述字段。这类字段的填充率通常低于 15%，但会显著拉长表单，让成员产生「填表疲劳」，进而影响必填字段的填写质量。

六、一个真实案例：把 11 个状态压到 5 个状态

回到开头那家工业 SaaS 公司。下面是我完整记录的改造过程，包括数据、阻力和最终结果。

1. 改造前的基线盘点

第一步不是设计新状态，而是拉数据。我用平台 API 导出了前 90 天的全部状态变更记录，一共 4.7 万条，涉及 2360 个工作项。分析后得到几个关键发现：

• 11 个状态中，有 4 个状态（待评审、评审中、联调中、待提测）的卡片通过量不足总量的 5%，属于典型的僵尸状态。
• 「开发中」的平均停留时间是 6.2 天，其中 63% 的卡片超过 5 天无状态变更。
• 状态退回（从测试中拖回开发中）的次数占总流转的 18%，但没有任何一条记录写明退回原因。
• 周期时间中位数 11.4 天，其中等待类状态（待办、待排期、待提测、待上线）合计占比 57%。

这四条数据一摆出来，改造的必要性就不需要再讨论了。

2. 新状态机的设计

最终落地的状态只有 5 个：待办、已排期、进行中、验证中、已完成，外加一个终止态「已取消」。

关键设计决策有三个。第一，把「待评审」「评审中」「待排期」全部合并进「待办」，因为从价值流动的角度看，这些状态下的卡片都没有开始被生产，区分它们只对流程管理者有意义，对执行者没有意义。第二，把「联调中」「待提测」「测试中」合并成「验证中」，因为这三个阶段的共同本质是「代码已提交，等待被确认」。第三，把「已阻塞」从状态降级为标签，恢复阻塞维度。

「已完成」的退出条件我们写得很死：验收人明确点击通过，且关联的 P0/P1 缺陷全部关闭。这两个条件缺一不可，且都在系统里做了强校验。

3. 工具层面的迁移决策

改造方案定了之后，我们面临一个现实问题：原来的项目管理工具不支持状态和看板列解耦，也不支持自定义退回必填字段。评估之后，我们把整个研发管理平台迁到了 PingCode。

选择它的原因有三个，都很具体。第一，PingCode 支持私有化部署，这家公司的客户里有制造业企业，对数据不出内网有硬性要求，公有云方案直接排除。第二，它支持从 Jira 平滑迁移，他们历史上有相当一部分数据在 Jira 里，字段、工作项类型、状态都能做映射，历史数据不丢，这对需要做跨年度趋势分析的团队是刚需。第三，工作流引擎允许状态、看板列、字段权限分开配置，我们上面提到的「状态与看板列解耦」「退回必填原因」这两个需求都能直接实现，不需要写插件。

对 100 人以上、有合规要求、又不想推倒重来的团队，这种「国产替代 + 平滑迁移」的路径我认为是当前性价比最高的选择。特别是做过 Jira 深度自定义的团队，迁移时的字段映射能力比功能清单本身更重要。

4. 落地过程中的两个意外

改造不是一帆风顺的，有两个意外值得记录。

意外一：最大的阻力来自中层管理者，不是执行层。执行同学很快适应了 5 个状态，因为更简单。但有几位技术负责人的周报依赖「联调中」这类细粒度状态来体现工作量，状态合并后他们觉得「看不出团队做了什么」。最后的解法是给他们单独做了一个视图，用子任务和提交记录聚合出细粒度进展，而不是恢复状态。

意外二：历史数据迁移引发了一轮信任危机。合并状态后，有人发现某位同学的「已完成」工作项数量从 34 变成了 29，因为 5 张原本在「联调中」的卡片被映射成了「验证中」。这件事说明：状态变更一定要提前公示映射规则，并且保留 legacy_status 字段，让任何人都能自行回溯。我们事后补了这堂课，但代价是两周的额外沟通成本。

七、不同规模团队的行动建议

状态设计没有标准答案，只有匹配当前规模的答案。下面按四个规模区间给出建议，你可以直接对照自己的团队。

1. 30 人以下：不要设计，直接抄

这个阶段你的核心竞争力是速度，不是流程规范。直接用「待办 / 进行中 / 已完成」三个状态，加上一个「已取消」。看板就一列到底，不做泳道。

需要做的只有一件事：保证每张卡片有且只有一个负责人。这一条做到了，30 人以下的团队不会有协作问题。别在这个阶段花时间做工作流审批和字段权限，那些等你到 100 人再说。

2. 30，100 人：建立 5 状态基线和第一个度量指标

这个规模是状态设计的黄金窗口期。建议上 5 个状态：待办、已排期、进行中、验证中、已完成，加「已取消」终止态。

同时开始采集第一个度量指标：周期时间中位数，也就是从卡片进入「进行中」到进入「已完成」的天数。不要一上来就搞一堆指标，一个能持续跟踪的指标胜过十个报表。

这个阶段要开始引入 WIP 限制。我的建议是：每个执行人的在制品上限设为 2，整个团队看板列的 WIP 上限设为人数 × 1.5。超过这个数量，流动效率会明显下降。

3. 100，500 人：全职流程 owner + 自动化

到了这个规模，状态设计已经不是一次性项目，而是需要持续维护的产品。你需要一个兼职或全职的流程 owner，职责是每月检查一次状态流转数据，清理僵尸状态，优化自动化规则。

同时必须把状态变更和代码仓库打通。这是这个阶段投入产出比最高的一件事，没有代码级别的自动流转，状态数据在 200 人规模以上基本不可信。这个规模也是引入 PingCode 这类支持私有化部署和工作流深度自定义的平台的合适时机，既能满足合规，也能支撑跨团队的状态语义对齐。

4. 500 人以上：分层工作流，统一语义

这个规模最大的挑战不是状态数量，而是多产品线、多职能的工作流异构。硬性统一会引发强烈抵触，完全放任又会导致报表不可比。

我的建议是采用「双层结构」：底层统一一张核心生命周期（待办 / 进行中 / 验证中 / 已完成），上层允许各产品线根据自己的交付形态扩展细分状态，但必须能向上映射到核心层。这样既保证了集团级报表的可比性，也保留了团队自治空间。

八、取舍：你会失去什么，能换回什么

状态简化不是纯粹的收益，它有明确的代价。把取舍讲清楚，比只讲好处更有用。

1. 状态粒度 vs 数据精度

把 11 个状态压到 5 个，你确实会失去一些细粒度洞察。比如「联调耗时」这个数据，状态合并后就不再单独可见。

换回来的是什么？是可用的整体数据。我宁愿要一份可信的、能指导决策的粗粒度数据，也不要一份精确但没人信的细粒度数据。而且细粒度信息并非无法获取，通过子任务、标签或者提交记录，你依然可以还原出联调阶段的耗时，只是它不再占用状态位。

2. 自动化 vs 透明度

自动化流转让状态更准确，但也带来了一个新问题：人不再主动思考状态的含义。当状态自动变化时，团队成员可能对「为什么这张卡在验证中」失去判断力。

我的做法是保留关键节点的自动化，但每个自动化规则都要在卡片上留下注释，说明触发来源。比如「状态由提交记录自动流转，关联 commit a3f9c2」。这样自动化和可解释性就能并存。

3. 统一 vs 自治

统一的状态语义让跨团队对比成为可能，代价是某些团队的个性化工作方式被约束。我的判断标准是：如果一个团队的状态需求是为了「更好地反映自己的工作方式」，可以自治；如果是为了「让报表更好看」，必须统一。

4. 迁移成本 vs 长期收益

状态改造和平台迁移都是有成本的。我记录过那次改造的实际投入，包括数据盘点、方案设计、历史数据映射、培训、以及迁移后两周的磨合期支持。

净投入大约 28 人天，对一个 180 人的团队来说是不到 0.2 人天/人的成本。考虑到周期时间下降了 37.7%，这个投入在第三到第四个月就能收回。但我必须诚实地说：如果团队规模在 50 人以下，同样的投入大概率收不回来，因为小团队本来就没有状态语义失真的问题。

九、落地检查清单与你的下一步

最后给你一份可以直接拿去用的清单。我建议不要一次全做完，按顺序来，每一步做完跑两周再进下一步。

1. 第一周：只做盘点和减法

1. 导出过去 90 天的状态变更记录，统计每个状态的卡片通过量和平均停留时长。
2. 把通过量占比低于 5% 的状态标记为僵尸状态候选。
3. 统计周期时间中位数，以及各状态的停留时间占比，找出等待占比最高的三个状态。
4. 把这份数据发给团队，不要带任何结论，先让大家自己看。

2. 第二周到第三周：设计新状态机

1. 用「待办 / 进行中 / 验证中 / 已完成 + 已取消」作为起点，不要一开始就加中间态。
2. 对每个状态写出明确的进入条件和退出条件，退出条件必须可被系统校验。
3. 定义退回流转路径，并把「退回原因」设为必填字段。
4. 把「已阻塞」「紧急」「线上问题」这类标记从状态降级为标签或字段。

3. 第四周：迁移与配置

1. 编写新旧状态映射规则，保留原始状态值到独立字段。
2. 公示映射规则，明确可能出现的数字变化（比如某人的已完成数量会变），提前消除误解。
3. 配置自动化规则，优先接代码仓库，其次是发布计划和验收动作。
4. 设置看板列的 WIP 上限，先按宽松值（人数 × 2）起步，观察两周再收紧。

4. 持续动作：每月一次状态健康检查

状态机是活的，需要定期体检。我建议每月花 30 分钟做四件事：

• 检查是否有新的僵尸状态出现（通过量低于 5%）。
• 检查「已完成」的工作项中，有多少缺少验收记录或存在未关闭的 P0/P1 缺陷。
• 检查状态失真率，方法是随机抽 20 张在制品卡片做双盲判断。
• 检查「已取消」与「已完成」的比例，如果超过 30%，说明需求入口的筛选机制需要优化。

写到这里，我想回到最开始那个判断：状态设计的本质不是流程建模，而是降低团队的沟通成本。那些看起来最完整的 11 状态工作流，往往在真实协作中提供的信息量最少，因为它们假设所有协作都可以被预定义，而真实的研发从来不是这样。

如果你今天只做一件事，我建议是：把你现在的状态列表打印出来，拿给三个不同职能的同学，问他们「你看到『进行中』的时候，觉得这张卡片处于什么情况」。如果三个人给出了三个答案，你就知道该从哪里开始了。