状态怎么做？研发团队入门指南：任务属性从0到1

我把一个 120 人的研发组织从“一个状态字段撑起整个流程”改到“状态、阶段、阻塞三件套各司其职”，前后花了 11 周。改造前，他们的看板上“进行中”这一列长期堆着 340 多张卡片，项目经理每天靠肉眼找哪些卡住了；改造后第一个完整迭代，“进行中”的卡片稳定在 90 张以内，单个任务平均流转次数从 5.8 次降到 3.2 次。这篇文章不讲状态机的教科书定义，只讲状态这个任务属性怎么从 0 到 1 设计出来、哪些坑我亲自踩过，以及在不同团队规模下你该做哪些不一样的取舍。

一、核心结论：状态不是流程的装饰品，而是任务的“位置坐标”

先把结论摆在最前面。如果我只能给研发团队留三句话关于状态的设计建议，就是下面这三句，剩下的所有内容都是这三句话的展开和证明。

第一，状态是离散枚举，它只回答一个问题：这个任务现在停在谁那里、在等什么。它不回答“做完多少”，也不回答“健不健康”，更不回答“谁在做”。把这四个问题塞进一个字段，是绝大多数团队状态失控的起点。

第二，一个状态存在的唯一理由，是有人会因为任务进入这个状态而改变自己的动作。如果没有任何角色会因为这个状态而采取不同行为，它就是僵尸状态。僵尸状态不会自己消失，它会持续制造看板噪音和口径争议。

第三，状态数量超过 8 个之后，协作成本的增速会明显快于管理精度的提升。这不是审美偏好，是我在多个团队样本上量出来的拐点。状态数从 4 涨到 14 的过程中，单个任务的平均跨角色等待时间不是线性上升，而是在 8 个状态附近开始加速。

1. 状态是坐标，不是评分

我常打一个比方：状态像快递物流里的“已揽收、运输中、派送中、已签收”。你不会在物流详情里看到一个叫“完成度 63%”的状态，因为那不是一个位置，那是一个估计值。研发任务的状态同理，它描述的是任务当前所处的位置，而不是它的完成质量或完成比例。

一旦你把状态和进度混在一起，就会出现“开发中 80%”这种表述，而 80% 这个数字没有任何可验证的判定标准，每个人心里的 80% 都不一样。三轮迭代之后，这个数字就会彻底失去参考价值。

2. 状态的归属是“位置”，不是“人”

很多团队的状态是“张三处理中”“李四处理中”，这是把人名写进了状态。正确做法是“待处理”“进行中”“待验收”，把人的信息交给负责人字段。原因很简单：负责人会变，状态不应该跟着变；而状态会因为负责人变化而变化，说明这个状态本质上是在描述人而不是描述任务。

我见过一个团队因为成员离职，导致 47 个任务的状态字段失效，看板直接瘫了一半。这不是人员管理问题，这是字段设计问题。

3. 状态是 WIP 限制的载体

状态最被低估的价值，是它可以承载在制品限制（WIP Limit）。当“进行中”被限制为每人不超过 2 张卡片时，状态就从“记录工具”变成了“约束工具”，它会强迫团队先完成再开始。

但如果你的状态有 12 个，你就不可能给每个状态设 WIP 限制，因为没人记得住 12 个数字。状态越少，WIP 限制才越可能真正被执行。这是状态数量必须克制的另一个硬理由。

二、为什么研发团队的状态一定会失控：三个结构性原因

我复盘过十几个团队的状态设计，发现失控几乎从来不是因为某个人偷懒，而是三个结构性原因在同时作用。理解这三个原因，比记住任何一套“最佳状态列表”都重要。

1. 状态被当成万能字段，承担了四种职责

健康的任务字段分工是这样的：状态回答“在谁那里”，负责人回答“谁在做”，进度或工时回答“做了多少”，标签回答“是什么类别”。但在很多团队里，这四件事全被压缩进了状态字段。

于是状态列表里出现了“开发中”“开发中（有风险）”“开发中（等待第三方）”“开发中（待联调）”。这不是状态设计，这是用一个字段硬扛四种信息维度，最终结果是每种维度都表达不清。

2. 不同角色对“到底在哪一步”的感知天然不同

开发同学关心的是“代码写完没有、能不能提测”；测试同学关心的是“这个版本是不是稳定、敢不敢回归”；产品同学关心的是“能不能给业务方交付”。三种感知都真实，但如果全都塞进一个状态字段，就会互相打架。

我的判断是：状态应该以“交接点”为分界，而不是以“工作内容”为分界。开发内部写代码、写单测、自己联调，对下游没有交接意义，可以合并成一个“进行中”；而“从开发手里交到测试手里”是一个真实的交接点，值得一个独立状态。

3. 工具迁移会原样搬运历史包袱

这是我见得最多的一种失控。团队从旧工具迁到新工具时，为了“不影响大家习惯”，把旧系统里的 17 个状态一比一搬了过来。三个月后没人说得清“待验证”和“待测试”有什么区别，但两个状态都还在被使用。

工具迁移是状态重构最好的窗口期，因为此时所有人的心理预期本来就在变化。错过这个窗口，下一次重构可能要等到两年后。关于这一点，我在第六节会给出一个具体的迁移映射表和它的代价。

三、先把概念拆干净：状态、阶段、进度、阻塞、标签的边界

很多人以为状态设计难在“选哪些状态”，其实难在“哪些东西不该做成状态”。下面这张表是我在实际咨询里反复使用的判定框架，你可以直接拿去对照自己团队的状态列表。

1. 阻塞为什么绝对不能做成状态

这是我最想强调的一个判断。阻塞是一种“叠加态”，它可以和任何进行中的状态共存，一个任务可以在“进行中”被阻塞，也可以在“验证中”被阻塞，甚至可以在“待处理”阶段就发现前置依赖缺失而被阻塞。

如果你把阻塞做成状态，你就被迫为每一个进行中的状态配一个对应的阻塞版本：进行中、进行中已阻塞、验证中、验证中已阻塞、待处理、待处理已阻塞……状态数量直接翻倍，而且每新增一个状态，你都要再补一个阻塞版本。

正确做法是：阻塞用布尔标记承载，配一个“阻塞原因”枚举字段和一个“进入阻塞时间”的时间戳。这样你既能筛出所有当前被阻塞的任务，又能统计阻塞总时长和阻塞原因分布，而且完全不影响主状态机。

2. 用“是否改变他人动作”做一次筛选

我给状态列表做减法的唯一标准是：假设任务进入状态 X，团队里是否存在至少一个角色，会因为这个变化而做出不同的动作？如果答案是“没有，只是看起来更清楚了”，那这个状态就可以删掉。

四、常见误区：我在真实团队里见到的七种状态设计翻车

下面这七种误区，我几乎在每个没有专门设计过状态的团队里都能找到至少三种。它们不是理论问题，每一种我都见过它造成的具体返工。

1. 误区一：状态数量越多越“精细”

新接手流程的人常有一种错觉，认为把流程切得越细，管理就越精细。实际结果往往相反：状态越多，每个状态的停留时间越短、数据越稀疏，统计出来的平均值越没有意义。

一个状态平均只待 3 小时，你去统计它的平均停留时长，得到的数字基本就是噪音。这种“精细”消耗了维护成本，却没有产出任何可用的洞察。

2. 误区二：把角色塞进状态

“待产品确认”“待开发处理”“待测试验证”这类状态看起来很直观，但它把角色和位置绑定死了。一旦流程调整，比如测试前置介入，这组状态就全部失效。

更严重的是，它会让人下意识认为“任务在某个状态就是某个角色的事”，从而削弱共同责任人意识。我建议把角色信息放进负责人字段和看板的泳道维度，而不是状态命名里。

3. 误区三：用“正在做什么”命名状态

“编码中”“调试中”“写文档中”这类命名的问题是：它描述的是动作，而动作是不可验证的。你怎么判断一个人是在“编码中”还是在“调试中”？这个问题本身就没有答案，因为没有判定标准。

我推荐的命名法是完成式命名：状态描述“已经完成了什么”，而不是“正在做什么”。“需求已确认”“开发已完成”“验证已通过”，每一个都有明确的判定条件，谁也糊弄不过去。

4. 误区四：状态没有退出条件

这是造成看板堆积的第一杀手。如果一个状态没有明确定义“满足什么条件才允许离开”，那它就会变成一个心理上的舒适区，卡片进去容易出来难。

我要求每个状态都必须配一条可判定的退出条件，写在状态说明里，直接挂在看板列的提示上。比如“验证中”的退出条件是“核心用例全部通过且无 P0/P1 缺陷”，而不是“测试觉得差不多了”。

5. 误区五：状态可以被任意跳转

有些团队允许任务从任何状态跳转到任何状态，理由是“灵活”。结果就是数据失真：一个从“进行中”直接跳到“已完成”的任务，在报表里和走完全流程的任务没有任何区别。

我的做法是定义一张迁移矩阵，只允许白名单内的迁移，其他迁移需要填写理由并被记录。不是为了管控人，而是为了让数据可信。

6. 误区六：取消和完成混用

“已完成”和“已取消”是两个完全不同的事实，但很多团队只有一个终态。这会导致两个严重后果：迭代交付率虚高，以及需求价值分析失真。

取消必须独立成一个终态，并且要带一个取消原因枚举：需求变更、重复、技术不可行、优先级下调、其他。这五个原因的数据价值极高，是复盘需求质量的直接依据。

7. 误区七：一套状态集打天下

缺陷和需求本质上是两类对象，它们的自然生命周期完全不同。缺陷不需要“需求评审”阶段，需求一般也不会有“复现”阶段。强行共用一套状态，要么给其中一类加上无意义的状态，要么让另一类缺少关键节点。

正确做法是在工具里为不同工作项类型绑定不同的工作流。这也是为什么我坚持状态必须和“工作项类型”绑定，而不是全局唯一。

五、专业判断逻辑：从动作清单反推状态的四步法

大部分人的做法是先画流程图，再往图上摆状态框。我强烈建议反过来：先收集动作，再从动作聚类出状态。原因是流程图上没人会画“等第三方接口联调”这种节点，但它恰恰是最需要被看见的等待。

1. 第一步：收集动作，而不是画流程

找产品、开发、测试、运维各 2-3 人，每人独立列出一份清单：过去一个迭代里，你为了让一个任务往前走，实际做了哪些动作？不要限制颗粒度，越琐碎越好。

我做过的一次收集，5 个人列出了 87 个动作，其中包括“在群里问接口人什么时候能给 mock”“确认灰度环境是否释放”“手动把需求文档链接补到卡片上”这类从不出现在流程图里的动作。这些才是真实流程的骨架。

2. 第二步：聚类动作，得到候选状态

把 87 个动作按“发生在谁身上、卡在哪个环节”聚类，通常能收敛到 15-20 个候选状态。这一步不要急着删，先做加法，把所有可能的候选人摆出来。

聚类时有个技巧：凡是描述“任务被移交给另一个人或另一个角色”的动作，都标记为交接点。交接点是状态的天然分界线，非交接点的动作可以直接合并进上一个状态。

3. 第三步：为每个状态写退出条件

这一步淘汰率最高。我的经验是，19 个候选状态里，大约有 8 个写不出明确可判定的退出条件，它们会被合并或删除。

判定标准很简单：把退出条件拿给两个不同的团队成员看，他们看完对同一张卡片该不该离开这个状态，能不能得出相同结论。如果不能，这个条件就不合格。

4. 第四步：定义迁移矩阵与权限

最后才定义谁可以触发哪个迁移。这一步我建议用一份可读的配置文件管理，而不是散落在工具的后台设置里。下面是我在实际项目中用的迁移矩阵描述方式，把它放在代码仓库里做版本管理，比在工具后台点鼠标可靠得多。

workflow: requirement
states:

id: backlog

name: 待处理

exit_condition: 负责人已指派 且 验收标准已填写

id: in_progress

name: 进行中

wip_limit: 2

exit_condition: 代码已合并主干 且 自测用例通过

id: verifying

name: 验证中

exit_condition: 核心用例全部通过 且 无 P0/P1 缺陷

id: done

name: 已完成

exit_condition: 已上线 且 验收人确认

id: canceled

name: 已取消

exit_condition: 已填写取消原因

transitions:

from: backlog

to: in_progress

allowed_roles: [developer, tech_lead]

from: in_progress

to: verifying

allowed_roles: [developer]

required_fields: [merge_request_url]

from: verifying

to: done

allowed_roles: [qa, product_owner]

required_fields: [acceptance_record]

from: verifying

to: in_progress

allowed_roles: [qa, developer]

require_reason: true

from: "*"

to: canceled

allowed_roles: [product_owner, project_manager]

required_fields: [cancel_reason]

flags:

id: blocked

type: boolean

extra_fields: [block_reason, blocked_since]

note: 阻塞是叠加标记，不参与状态机

注意最后一段：阻塞被显式定义为一个标记，而不是状态。这条规则一旦写进配置并被评审通过，后面就很难再被随意破坏了。

5. 工具落地：以 PingCode 为例

流程设计完之后，需要一个能承载“工作项类型 × 工作流 × 状态 × 迁移权限”这套结构的工具。我们最终选择落地在 PingCode 上，主要原因是它把工作流配置、状态迁移权限和自定义字段的约束关系做在了同一层，不需要靠插件拼。

PingCode 主要服务中大型企业及 100 人以上组织，这恰好是状态设计问题最集中的区间，人多了，角色多了，跨产品线协作多了，状态口径冲突就会指数级放大。另外它支持私有化部署，对有数据合规要求的团队是硬性加分项；同时支持 Jira 平滑迁移，这一点在下一节的映射表里体现得很直接。

六、案例与数据观察：120 人研发团队的状态从 0 到 1

前面讲的是方法，这一节讲一个我完整参与的项目。背景是一家做企业服务的公司，研发约 120 人，分 4 个小组，两个产品线，原来用的是 Jira，正在评估国产替代方案，最终落地在 PingCode。

1. 改造前的基线数据

改造前他们全局共用一个状态集，一共 14 个状态，需求、缺陷、技术任务共用同一套工作流。看板“进行中”这一列是整个组织的垃圾桶，任何不知道该往哪放的任务都会被拖进这一列。

我抽取了他们改造前两个迭代的数据作为基线：看板“进行中”峰值 340 张卡片，单任务平均流转 5.8 次，其中约 21% 是回退流转；每月因为“这个状态到底代表什么意思”产生的争议工单约 21 件；迭代准时交付率 61%。

2. 我们做的四件事

1. 把 14 个状态压缩到 6 个主状态，按前文四步法重新推导。
2. 把“阻塞”从状态降级为标记，并强制填写阻塞原因与阻塞起始时间。
3. 为需求、缺陷、技术任务分别绑定三套工作流，不再共用。
4. 在“进行中”状态上设置每人 WIP 上限为 2，超出时工具侧直接拦截。

3. 改造后的数据变化

改造后第一个完整迭代，看板“进行中”峰值降到 88 张，下降约 74%；单任务平均流转次数从 5.8 降到 3.2，回退流转占比从 21% 降到 7%；状态口径争议工单从每月 21 件降到 4 件；迭代准时交付率从 61% 提升到 82%。

还有一个没在预期内但我觉得最有价值的指标：阻塞任务的平均识别耗时从 1.8 天降到 0.4 天。原因是阻塞变成标记后，可以直接按“阻塞时长倒排”列出被卡最久的卡片，站会上不再靠人肉扫描看板颜色。

4. 迁移过程中状态映射的真实代价

迁移是这次项目里最容易被低估的工作量。很多人以为迁移是导数据，其实状态映射才是难点。我们最终用的映射策略是这样的：

整条迁移链路我们归集了约 110 人时的投入，其中“阻塞状态转标记并回填时间”和“取消原因归类”合计占了约 40%。如果你的团队也准备从旧工具迁移，这两项预算一定要提前留出来，否则最容易在迁移末期赶工，留下一批脏数据。

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

状态设计没有唯一正确答案，只有和团队规模、协作模式匹配的答案。下面按四种典型情况给出可直接执行的建议。

1. 10 人以下：状态不超过 4 个，不要设 WIP 限制

这个阶段沟通成本几乎为零，所有人都在一个群里，谁在做什么一目了然。状态的唯一作用是让外部知道这张卡有没有人管。建议只用：待处理、进行中、已完成、已取消。

不要在这个阶段搞复杂工作流，因为人少意味着角色重叠，任何按角色切分的状态都会立刻失效。这个阶段更值得投入的是把验收标准写清楚，而不是把状态分细。

2. 10-50 人：状态 5-6 个，开始区分工作项类型

这个区间开始出现专职测试或专职产品，交接点变得真实。建议把需求、缺陷分开工作流，并且在“进行中”之外增加一个“验证中”，因为它对应一个真实的人员交接。

WIP 限制可以从这里开始尝试，但如果团队还在快速试错，建议先设为软提醒而不是硬拦截，避免压制探索性工作。

3. 50-200 人：状态 6-7 个，必须建立迁移矩阵与权限

这是状态设计收益最明显的区间。人数超过 50 之后，跨组协作开始出现，状态口径不一致的成本会以工单形式显性化。我在这个规模的项目里，一定会推动三件事：迁移矩阵白名单、阻塞标记化、状态与工作项类型绑定。

另外建议把状态定义写进一份可以版本管理的文档，并且每次流程调整都走一次变更评审。这个阶段最大的风险不是设计得不好，而是改得太随意。

4. 200 人以上或多产品线：主状态收敛，子状态下放

这个规模不要追求全局唯一的状态集，那只会导致无休止的争论。可行的做法是收敛一层主状态用于集团级报表，允许各产品线在主状态之下定义子状态，用于本团队看板。

主状态控制在 6-7 个，子状态由各产品线自管，但必须能无损映射回主状态。PingCode 在这类场景下的价值就体现出来了，它支持为不同工作项类型配置独立工作流，同时保留跨项目的统一报表口径，这正好对应“主状态收敛、子状态下放”的组织需求。

八、取舍：什么时候该简单，什么时候必须复杂

状态设计的本质是一道成本收益题。每增加一个状态，你都获得了一点额外的可见度，同时支付了培训、记忆、维护和口径对齐的成本。关键是判断这笔交易划不划算。

1. 三种必须把状态做复杂的场景

第一，存在外部合规或审计要求。比如金融、医疗类产品，某些节点必须有独立的可审计状态和操作记录。这时状态是合规证据的一部分，不能为了简洁而合并。

第二，跨组织交付且存在真实合同节点。如果交付物需要甲方按节点确认，那“待甲方确认”就必须是一个独立状态，否则你无法证明自己在等对方。

第三，状态直接驱动自动化动作。如果进入某个状态会触发构建、部署或通知，那这个状态就有独立的机器可读语义，值得独立存在。

2. 四种必须把状态做简单的场景

第一，团队处于快速探索期。需求本身还在变化，此时定义精细状态，等于给一个还没定型的东西套上模具。

第二，团队人数低于 10 人。沟通成本极低时，状态的边际价值几乎为零。

第三，状态没有配套的退出条件。写不出可判定退出条件的状态，不要加，加了也是噪音。

第四，状态只服务于报表好看。如果某个状态没有任何角色会因此改变动作，只是为了让某个图表多一根柱子，果断砍掉。

3. 一张取舍对照表

我自己的经验法则是：如果加一个状态，你说不出“谁会因为它改变动作”和“它的退出条件是什么”，那就先不加。等真的痛了再加，比一开始就加错要便宜得多。状态设计是一个减法做不完的领域，宁少勿多。

九、总结与下一步

回到最开始那个 120 人团队的案例。这个项目真正起作用的不是那 6 个状态本身，而是三条设计原则：状态只回答“在谁那里”、一个状态的存废由“是否有人因此改变动作”决定、阻塞是叠加标记而不是顺序状态。

如果你只记住一句话，我希望是这句：状态是任务的位置坐标，不是任务的工作描述。位置会变、坐标要准、坐标数量要少。任何试图用状态承载进度、角色、健康度的做法，最后都会变成看板上那列永远清不空的“进行中”。

至于下一步，我建议你按这个顺序做三件事。第一，把当前团队所有状态列出来，逐个问“谁会因为它改变动作”，砍掉得票为零的。第二，给剩下的每个状态写一条可判定的退出条件，写不出来的继续砍。第三，把“阻塞”从状态降级为标记，并加上阻塞时长统计，这一条改动最小，见效最快。

三件事做完，你大概只需要两个下午。但它带来的看板清晰度提升，往往比上一次流程重构加起来还多。等你真正把状态收敛到 6 个左右，再回头看当初那 14 个状态的列表，你会发现大部分状态当初被加进来，只是因为那一刻有人觉得“这样看起来更清楚”。而“看起来更清楚”，从来不是状态存在的理由。