状态怎么做？研发团队流程优化：任务属性从0到1

去年秋天，我带着三个人进到一家做智能硬件的公司做研发流程诊断。第一天旁听站会，我就看到一个很微妙的动作：一个开发同学把任务卡从"待提测"拖回"开发中"，然后小声解释"刚才手快"。旁边的测试同学翻了个白眼，说"这周第三次了"。

会后我拉了他们系统的数据：一个任务从创建到关闭，一共配了 16 个状态，平均每个任务要经历 9.7 次状态变更，其中 1.8 次是"拖错再拖回"。更要命的是，他们一直想统计"开发实际耗时"，结果"开发中"这个状态平均停留 6.8 天，而代码提交记录显示真实编码时长只有 1.5 天。剩下那 5.3 天，是有人提前把任务拖过去"占位"。

这件事让我确认了一个判断：状态字段不是流程的装饰品，它是流程的计量单位。你把它设计错了，后面所有关于效率、瓶颈、产能的判断都会跟着错。而绝大多数研发团队在设计任务属性时，恰恰是从"状态"这个最贵、最容易被滥用的字段开始犯错的。这篇文章我把过去几年在十几个团队里做状态收敛的完整方法、踩过的坑、以及从 0 到 1 建属性体系的路径，一次讲清楚。

一、核心结论：状态是责任交接的契约，不是流程的素描

如果只让我留一句话，那就是：状态的数量应该等于责任发生转移的次数，而不是流程步骤的数量。这两件事听起来像，实际上差了十万八千里。

很多团队设计状态的方式是"画流程"：先想任务要经过哪些环节，每个环节给一个状态。于是就有了"待澄清、已澄清、待排期、已排期、待自测、自测中、待提测、测试中、测试不通过、待验收、已完成、已关闭"这一长串。看起来很专业，实际上是把"步骤"和"责任"混为一谈了。

正确的做法是反过来：先问"这个任务现在在谁手上、在等谁"，责任换手一次，才配一个新状态。按这个标准去砍，上面那 12 个状态里能活下来的通常不超过 6 个。

我把这个判断拆成四条可以直接检验的硬结论：

1. 单一等待者原则。任何一个状态，都必须能回答"现在在等谁"，而且只能有一个答案。如果一个状态里既有开发在改，又有测试在等，这个状态就是坏的。
2. 度量绑定原则。每个状态至少要服务于一个你真实要看的指标。如果你从来没统计过"自测中"的停留时长，这个状态就是纯成本。
3. 三秒判定原则。团队成员看到一张卡，应该在 3 秒内决定它该放哪里。超过 3 秒，说明状态定义有重叠。
4. 可迁移约束原则。状态之间不是任意跳转的，必须有一张明确的迁移矩阵。没有迁移矩阵的状态机，等于没有状态机。

我在 11 个研发团队（规模从 8 人到 400 人）做过状态审计，把状态数量和几项流程成本放在一起看，规律非常明显。需要说明的是，下面这组数据是我在访谈、系统日志抽查和月度抽检中汇总出来的示意性样本，不是某个权威机构的统计，但方向和量级在不同团队之间高度一致。

二、背景与真实场景：一个 120 人团队的状态字段是怎么失控的

回到开头那家智能硬件公司。他们的研发中心 120 人，分 4 条产品线，用的是自研的一套轻量任务系统，后来迁移到了标准化平台。我先说清楚他们当时的状态字段长什么样，因为这套配置在国内中大型团队里非常有代表性。

1. 初始配置：16 个状态，4 套工作流

他们的任务类型分了四种：需求、开发任务、缺陷、技术改进。每种类型挂了一套独立工作流，状态集合有交集但不完全一致。开发任务这条线最复杂，16 个状态如下：

• 未开始阶段：新建、待澄清、已澄清、待排期、已排期
• 进行中阶段：开发中、待自测、自测中、待提测、测试中、测试不通过、待验收
• 已完成阶段：已完成、已关闭
• 其他：已挂起、已拒绝

看板上为了好看，硬生生把这 16 个状态压成了 5 列：待办、进行中、测试中、待验收、完成。于是每一列里都塞了三到四个状态，卡片在列内还要再拖一次才能改状态。这就是问题的第一层：状态和看板列不是一对一关系时，团队每天都在做两遍判断。

2. 失控的三个具体症状

症状一：占位式拖拽。因为"开发中"是唯一能体现"我在干活"的状态，开发同学会在任务还没真正开始时先拖进去，防止它在站会看板上显得"没人管"。结果"开发中"这个状态的停留时长完全失真，从 1.5 天膨胀到 6.8 天。

症状二：接力棒掉在地上。从"测试中"到"待验收"这一步，按流程应该由测试同学判定，但系统里任何有权限的人都能拖。开发同学提测后顺手拖到"测试中"，测试同学根本不知道有新任务进来，任务在那里躺了平均 3.1 天。

症状三：新人三周学不会。我让他们做了个小测试，让入职第 3 周的新同学看 10 张卡，说出每张卡下一步该谁做什么。10 张里答对 4 张。他们的技术 Leader 当时的原话是："我以为状态这事不用教。"

3. 收敛之后发生了什么

我们花了 6 周时间，把 16 个状态收敛到 6 个核心状态加 2 个终态，看板列与状态严格一对一。收敛后第 8 周我回访，拿到了这组数据（同一系统、同一统计口径、前后各取 8 周）：

三、常见误区：我在七个团队里反复看到的五种错误

1. 把状态当成进度条

这是最普遍也最根深蒂固的错误。团队潜意识里希望任务卡上的状态能告诉所有人"现在完成了百分之多少"，于是不断加状态：25%、50%、75%……

问题是，进度是一个主观估计，状态是一个客观事实，两者不能混在一个字段里。你一旦让状态承担进度表达，开发者就会为了"显得在推进"而拖动状态，状态数据立刻失真。正确的做法是进度用单独的数值字段或子任务完成度表达，状态只负责表达"交给谁了"。

2. 状态越多显得越专业

我见过一个团队，把"自测中"和"待自测"拆成两个状态，理由是"更精细"。半年后统计，两个状态的月度使用次数分别是 3 次和 2 次。这两个僵尸状态每周让 30 个人多看两个选项，一年下来就是几千次无意义的认知负担。

判断一个状态是不是僵尸状态，有个很实用的指标：如果一个状态在最近 90 天内的进入次数占总任务数不到 2%，它就该被合并或删除。

3. 状态没有进入和退出条件

"待评审"这个状态，进入条件是什么？是"开发自测通过"还是"代码合并到主干"？退出条件是什么？是"至少一位评审人点了通过"还是"评审意见已全部回复"？

大部分团队答不上来。没有进入/退出条件的状态，就像没有验收标准的验收，最后必然靠个人理解。我要求所有状态必须配一段不超过 30 字的 DoD（完成定义），写清楚"进入时要满足什么、离开时要满足什么"。

4. 状态和看板列强绑定，或者完全不绑定

这两个极端都有问题。强绑定意味着流程一改，看板要重画，团队要重新学；完全不绑定意味着看板上看到的列和系统里的状态对不上，统计口径立刻分裂。

我的判断是：看板列应该恰好是状态的一个子集视图，而不是另一套分类法。允许若干"非看板状态"（比如已挂起、已拒绝）存在于系统里但不显示在看板上，但绝不能允许一个看板列里塞多个状态。

5. 让状态同时承担流转、审批和归档三个职责

有些团队用状态来实现审批流：进入"待审批"就意味着要走一个审批单，审批通过才能到"已审批"。这在任务规模小时还行，一旦任务量大、审批人多，状态机就会变成审批引擎，而且是表达能力很差的审批引擎。

状态负责"东西在谁手上"，审批负责"这件事被谁同意了"，归档负责"它最终去了哪里"，这三件事应该由三个不同的机制承担。把它们压进一个字段，改起来就是牵一发而动全身。

四、专业判断逻辑：状态设计的四步法与三条硬规则

1. 第一步：画责任交接链，而不是流程图

拿一张白纸，不画方框，而是画箭头。每个箭头代表一次"东西从我手上交到你手上"。一个需求从提出到上线，通常只有这么几次真实的交接：

提出人 → 产品经理（澄清）→ 技术负责人（排期）→ 开发者（实现）→ 评审人（评审）→ 测试（验证）→ 产品经理（验收）→ 关闭。

数一下箭头：8 次。但注意，其中"提出人 → 产品经理"和"产品经理 → 技术负责人"这两次，通常发生在需求管理域，不属于研发任务的状态范畴。真正需要状态表达的是中间那 5 到 6 次。这就是 6 个状态的理论来源。

2. 第二步：抽交接点，得到候选状态

把每个交接点的"接收方"提取出来，就是候选状态的命名基础。这里我给一个非常具体的命名公式：

状态名 = 等待对象 + 待发生的动作。比如"待产品验收""待测试验证""待技术评审"。这种命名的好处是，任何人看名字就知道下一步该谁动手，不需要查文档。

对比一下两种命名方式对新人上手的影响，我们在两个规模接近的团队里做过对照观察（示意数据）：

3. 第三步：为每个状态写清楚三件事

每个状态必须配齐三项内容，缺一不可：进入条件、退出条件、当前等待谁。我用下面这段配置来说明一个可落地的状态机长什么样。这段配置是通用的状态机定义格式，可以对应到任何主流项目管理平台的工作流设置里：

# 研发任务状态机定义（可直接映射到工具的工作流配置）
states:

key: todo

name: 待处理

category: 未开始

waiting_for: 产品经理/技术负责人

entry: 任务已创建，但尚未指定执行人

exit: 已指定执行人且纳入当前迭代

sla_days: 5

key: in_progress

name: 开发中

category: 进行中

waiting_for: 开发者

entry: 执行人已确认，且已开始实际编码

exit: 代码已合并且有可验证的自测记录

sla_days: 3

key: in_review

name: 待技术评审

category: 进行中

waiting_for: 评审人

entry: 代码合并记录已存在

exit: 评审意见全部关闭

sla_days: 1

key: in_test

name: 待测试验证

category: 进行中

waiting_for: 测试工程师

entry: 提测说明与测试环境已就绪

exit: 用例执行完毕且无阻断级缺陷

sla_days: 2

key: in_acceptance

name: 待产品验收

category: 进行中

waiting_for: 产品经理

entry: 测试已签署通过

exit: 验收结论已记录

sla_days: 2

key: done

name: 已完成

category: 已完成

waiting_for: 无

entry: 验收通过

exit: 不可退出（如需返工，新建关联任务）

sla_days: 0

key: canceled

name: 已取消

category: 已完成

waiting_for: 无

entry: 明确不再执行

exit: 不可退出

sla_days: 0

注意里面的 category 字段。这是很多团队忽略的关键点：状态的展示名可以随团队习惯变化，但状态类别必须统一为三到四类（未开始/进行中/已完成/已取消）。所有跨团队的报表、燃尽图、吞吐量统计，都应该基于类别而不是基于状态名。否则你换个状态名，历史报表就断了。

4. 第四步：写迁移矩阵，约束谁能跳到哪

这一步的产出是一张表，明确每个状态的合法下一跳。我通常建议写成矩阵形式，交给平台做校验。下面是我给一个 60 人团队设计的版本：

这张表有个看起来很别扭的地方："已完成"不可回退。很多团队第一反应是反对，觉得产品验收后发现问题怎么办。我的判断是，返工应该新建一个关联任务，而不是把老任务从坟里挖出来。因为一旦允许回退，"已完成"这个状态的统计意义就消失了，你的交付吞吐量永远算不准。

5. 三条硬规则的违反代价

上面四条规则可以再压缩成三条，方便贴在团队规范里：单一等待者、度量绑定、可迁移约束。我们统计过违反它们的代价（示意数据）：

五、案例与数据：14 个状态收敛到 6 个的 90 天记录

这一节我讲一个更完整的案例。客户是一家年营收 30 亿规模的制造企业，研发中心 380 人，横跨嵌入式、云平台、移动端三条线。他们从一套国际主流研发管理工具迁移到 PingCode，正好赶上做状态重构。

需要先说明背景：这家公司属于典型的中大型组织，对私有化部署有硬性要求（数据不出内网），同时历史项目数据必须完整迁移，不能断报表。PingCode 在这类场景里是比较对症的选择，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在国产替代的选型里是很常见的一个落点。

1. 起点：14 个状态、3 套工作流

迁移前的状态集合是这样的：开放、待分析、分析完成、待排期、已排期、开发中、开发完成、待评审、评审中、待测试、测试中、待验收、已关闭、已拒绝。三条产品线各自微调过名称，最后落到系统里是 3 套工作流方案。

他们最初的迁移方案是 1:1 映射，14 个状态原样搬过去。我建议先别搬，先做收敛。原因很简单：把 14 个状态搬到新平台，等于把 8 年的流程债一起搬过去，而且新平台的报表能力会让你第一次看清这些债有多贵。

2. 收敛路径：每个旧状态的去向

我们用了两周做状态审计，方法是导出最近 12 个月的完整状态变更日志，统计每个状态的进入次数、平均停留时长、被回退次数。结果发现 14 个状态里有 5 个是僵尸状态，有 3 个互为近似。

具体判据我列一下，这套判据后来我复用到了其他项目：

• 合并近似状态：两个状态的进入次数接近、停留时长都小于 0.5 天、且经常在同一批任务里连续出现。典型的例子是"开发完成"和"待评审"，中间那一步没人真的等。
• 删除僵尸状态：90 天进入次数占比低于 2%。这个案子里"评审中"只有 1.3%，因为评审要么秒过要么直接打回，没人会让它停在"评审中"。
• 归一终态："已关闭"和"已拒绝"在报表里从来都是合并统计的，那就干脆合并成"已取消"，用取消原因字段区分。

3. 迁移的技术细节：三件容易被低估的事

（1）状态映射必须做双向校验，不能只做正向

正向映射好做，旧状态到新状态。难的是反向：如果迁移后发现问题要回滚，新状态能不能拆回去？我们的做法是保留原始状态值到一个不可见的自定义字段里，作为审计留痕。这一点在金融、军工、制造这类客户那里是刚需，他们需要能回答"这条记录在 2023 年 4 月 12 日到底是什么状态"。

（2）历史数据的周期时间要重算，不能直接沿用

因为状态合并了，历史周期时间的构成会变。我们做了一版重算，把合并掉的状态时长归并到目标状态里，这样新旧数据的趋势线才是可比的。如果不重算，迁移后你会看到周期时间突然跳变，然后团队会误以为是新平台的问题。

（3）工作流方案先收敛再分化

他们的三条产品线原本各有一套工作流。我们在迁移时先把三套统一成一套，观察 4 周，再根据真实差异分化。结果是最终只分化出两套：硬件线因为涉及打样，多了一个"待硬件验证"状态；软件两条线共用一套。

4. 迁移后 12 周的数据

我把迁移后 12 周的两个核心指标拉出来看，趋势是这样的（数据来自客户内部系统，已做脱敏，量级保留）：

5. 一个反直觉的发现

这个项目里最让我意外的，不是周期时间下降，而是状态收敛之后，"等待"第一次变成了可管理的对象。

以前他们统计任务耗时，只能算"开发中"多久，因为其他状态太碎，归并起来太麻烦。收敛成 6 个状态之后，三个等待型状态（待技术评审、待测试验证、待产品验收）的停留时长可以自动汇总成一条"总等待时长"曲线。上线第 8 周他们发现，这条等待时长占总周期时间的 41%，而开发时长只占 34%。

换句话说，团队过去两年一直在优化占 34% 的那部分，从来没碰过占 41% 的那部分。这就是状态设计对业务判断的反向塑造作用：你怎么切分状态，决定了你能看到什么样的瓶颈。

我还把六个状态的平均停留时长和任务数放一起看过，找瓶颈非常直观：

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

状态设计没有唯一正确答案，但有清晰的适用边界。我按团队规模和业务复杂度给四档建议，这套划分是我在十几个项目里反复修正过的经验值，不是教科书标准。

1. 5 到 15 人：五个状态，别犹豫

这个规模下，团队所有人都在一个群里，沟通成本几乎为零。状态的作用只有一个：让外部（老板、客户、其他部门）看到进展。推荐配置：待处理、进行中、待验证、已完成、已取消。

这个规模最容易犯的错是照着大厂模板抄一套十几个状态的流程。我的建议是明确拒绝，等团队超过 20 人再说。你们真正需要的是把任务写清楚，而不是把状态配复杂。

2. 20 到 50 人：六个状态，加描述性属性

开始出现职责分离了，测试和开发不再是一个人。这时候把"待验证"拆成"待技术评审"和"待测试验证"，是合理的。同时引入两个描述性字段：任务类型（需求/缺陷/技术改进）和模块归属。注意这两个字段是给筛选和统计用的，不参与流转。

3. 50 到 200 人：六到八个状态，按项目类型分工作流

这个区间是状态最容易被搞复杂的阶段。我的建议是核心状态集合保持全局统一，只在必要处按项目类型分化工作流。比如硬件项目多一个"待硬件验证"，数据类项目多一个"待数据校验"。分化的判断标准是：这个状态是否对应一个独立的责任人角色，且 90 天进入次数占比超过 5%。

4. 200 人以上：状态收敛，类别统一

这个规模最稀缺的不是精细度，是可比性。你需要在不同产品线之间横向比较周期时间、吞吐量、等待时长，这就要求所有工作流的状态类别必须统一成四类。展示名可以各叫各的，报表口径必须一致。

这也正是我在前面提到的那个 380 人客户项目里坚持的第一原则：先统一类别，再讨论状态名。

七、不同情况下的取舍

做状态设计，本质上是做五组取舍。我把每一组的判断逻辑和我的倾向都写出来，你可以对照自己团队的情况决定站哪一边。

1. 精细度 vs 数据准确性

状态越细，理论上能看到的越多；但状态越细，人为误判的概率越高，数据反而越不准。这是个倒 U 型曲线，拐点大约在 6 到 8 个状态之间。

我的倾向是宁可粗一点，保证准。因为在准确的基础上你可以往下钻（比如用自定义字段标记子阶段），但在不准的基础上你什么都做不了。

2. 全局统一 vs 团队自治

统一的好处是报表可比、人员流动成本低；自治的好处是贴合各自业务、团队接受度高。我的判断是分两层处理：状态类别强制统一，状态展示名允许自治，工作流在中大型组织里适度分化。

3. 强制流转 vs 自由拖拽

强制流转（只有特定角色能拖动）能保证数据质量，但会增加摩擦。我们在这家 380 人客户那里的做法是分级：核心路径上的关键交接（进入待评审、进入待测试、进入已完成）强制校验权限和必填字段；非关键路径（回到待处理、挂起）自由操作。

结果是状态错误率降到 4%，同时没有出现团队抱怨流程繁琐的情况。这个平衡点我认为是普适的。

4. 历史数据保留 vs 迁移成本

把所有历史状态原样搬过去，成本最低但会带来报表口径分裂；做状态归一化重算，成本高但历史数据可用。我的经验值是：如果历史数据要用于跨年趋势分析或合规审计，就必须重算；如果只是留存备查，可以保留原始字段但不重算。

5. 自动化规则 vs 可维护性

状态流转上可以挂很多自动化：进入"待测试"自动指派给测试负责人，停留超 2 天自动升级提醒。这些规则很有用，但每加一条就多一个维护点。我的建议是把自动化规则数量控制在状态数量的 1.5 倍以内，超过这个比例，规则之间的相互触发会让你排查问题的时间超过它节省的时间。

这五组取舍我用雷达图做了个整体对比，横轴是三种典型取向：极简派、标准派、精细派。

6. 一张取舍决策表

八、落地清单与下一步

讲完方法、案例和取舍，最后给一套可以直接照着做的落地路径。我把它压缩成 30 天四周计划，每一周都有明确的产出物，避免变成"讨论了很久但什么都没改"。

1. 第 1 周：做状态审计

导出最近 90 到 180 天的完整状态变更日志，统计三件事：每个状态的进入次数占比、平均停留时长、被回退次数。这一步的产出是一张 Excel，标出所有占比低于 2% 的僵尸状态和停留时长低于 0.5 天的近似状态。

如果你们的平台支持，尽量用原生报表或 API 导出，手工统计容易漏掉回退记录。这里给一个通用的统计口径示例，方便你对照确认数据是否算对：

-- 状态停留时长与进入次数统计（通用口径）
SELECT

to_state                     AS 状态名,

COUNT(*)                     AS 进入次数,

COUNT(*) * 100.0 / SUM(COUNT(*)) OVER () AS 占比百分比,

AVG(duration_hours) / 24.0   AS 平均停留天数,

SUM(CASE WHEN is_rollback = 1 THEN 1 ELSE 0 END) AS 回退次数

FROM task_status_transition

WHERE changed_at >= DATEADD(day, -180, CURRENT_DATE)

GROUP BY to_state

ORDER BY 进入次数 DESC;

-- 判读规则

-- 占比  候选删除

-- 平均停留  候选合并

-- 回退次数 / 进入次数 > 30% -> 该状态定义或准入条件有问题

2. 第 2 周：设计新状态机

用四步法产出三份文档：责任交接链、状态定义表（含进入/退出条件/等待者/SLA）、迁移矩阵。产出物必须让一个没参与讨论的人能看懂，这是检验质量的最好方式。

这一步有个容易被跳过的动作：把新状态机画成一张图，贴到团队群里让大家挑刺。我见过太多方案在会议室里全票通过，上线三天就被推翻，原因就是没人真正在脑子里跑过一遍日常场景。

3. 第 3 周：单团队试点

选一个 10 到 20 人的团队先跑，跑满一个完整迭代。重点观察三个信号：新人是否还在问"这卡放哪"、看板上是否出现长时间无人推进的卡片、站会讨论状态的时间是否下降。

试点期间不要改规则。我知道这很难，但频繁调整会让试点数据失去参考价值。

4. 第 4 周：全量推广与基线记录

推广的同时做一件很重要的事：记录基线数据。把推广当天的周期时间、等待时长、状态错误率完整记录一次，作为三个月后复盘对比的锚点。没有基线的优化，最后只能靠感觉说"好像快了"。

5. 三个立刻可以做的动作

1. 今晚就查一遍僵尸状态。任何一个 90 天进入次数占比低于 2% 的状态，列出来，下周一讨论是否删除。
2. 给每个状态补一句话的进入条件和退出条件。不用写得漂亮，用大白话写清楚就行，写完贴到团队知识库里。
3. 检查状态名里有没有"进行中"这种模糊词。如果有，改成"等待谁做什么"的格式。这一个动作的成本是半小时，收益是新人上手时间从三周变成两天。

6. 最后总结一下我的核心观点

状态字段是研发流程里最被低估、也最容易被滥用的一个属性。它看起来只是任务卡上的一个下拉框，实际上承担着三件事：定义责任边界、支撑效率度量、约束流程流转。这三件事只要有一件没做好，团队就会陷入"流程看起来很完整，但没人说得清哪里慢"的状态。

我的独特判断可以归结为一句反常识的话：状态不是用来描述流程的，是用来描述等待的。你砍掉的状态越多，被看见的等待就越多；被看见的等待越多，你能优化的空间就越大。那些看起来"流程很细"的团队，往往是因为他们的等待从来没有被真正测量过。

下一步不用等，从今天开始做两件事：第一，把你们系统里所有状态列出来，挨个问"这个状态在等谁"；第二，把答不上来的那些状态标红，它们就是你这次优化的起点。90 天后你再回头看，会发现周期时间的变化，往往不是来自大家更努力了，而是来自那些原本藏在状态缝隙里的等待，终于被摆到了台面上。