状态怎么做？研发团队效率提升：任务属性从0到1

我给一家 180 人的研发组织做流程诊断时，第一个要的不是需求文档，而是他们的状态列表。他们给了我 14 个：待评审、评审中、待排期、已排期、开发中、开发完成、提测中、测试中、测试通过、待发布、灰度中、已发布、已验收、已关闭。我随后问了三个问题：这 14 个状态里，哪几个意味着"有人正在等另一个人"？哪几个状态在过去 90 天里中位停留时间超过 24 小时？有几个人能准确说出"开发完成"和"提测中"的边界？

后两个问题当场没人答得上来。会后我拉了数据：14 个状态里有 4 个，在最近 90 天没有任何一个工作项停留超过 4 小时；还有 3 个状态的平均停留时间不到 30 分钟，它们不是流程节点，只是操作日志。而真正卡人的"开发中"，平均停留 6.8 天，里面没有任何一个字段能说明它到底在等什么。

这就是我这几年反复见到的一件事：研发团队在"状态"上花掉的配置时间可能只有两个小时，但状态设计的好坏，几乎决定了一整条协作链路的摩擦系数。这篇文章讲的是，一个研发团队的任务属性，尤其是状态，应该怎么从 0 到 1 做起来，以及做到什么程度就该停手。

一、核心结论：状态是研发协作里最便宜也最贵的抽象

先把结论摆在最前面，后面所有内容都是围绕这几条展开的。

1. 状态不是进度条，是责任交接点

绝大部分团队把状态当"进度条"用：百分比往前推一格，看起来更直观。这是错的。进度条是给人看的心理安慰，状态是给人用的协作契约。

一个状态只要存在，就必须能回答一个问题：此刻谁在等谁，以及等多久算异常。回答不了这个问题的状态，不是状态，是标签。

"待排期"是一个合格的状态，因为它明确指出：需求方在等排期人。而"已排期"通常不合格，它只说明某个动作发生过了，不说明现在谁在等谁。如果"已排期"之后没有任何人在等待，这个状态就应该被合并或删除。

2. 判断一个状态该不该存在，问四个问题

1. 归属问题：这个状态下的工作项，当前责任人是谁？是角色，不是人名。
2. 等待问题：它进入这个状态是在等谁的动作？如果没有等待对象，它是终态或伪状态。
3. 时限问题：停留超过多少小时算异常？说不出来的，说明它没有管理价值。
4. 退出问题：离开这个状态的触发条件，是人工点击还是系统事件？

四个问题有一问答不上来，这个状态就是负债。它带来的不是管理精度，而是误用概率、培训成本和统计噪声。

3. 我给中大型团队的经验值：主状态 5±2 个

这里说的是"主状态"，也就是一条主线上的生命周期状态，不包括被驳回、已取消这类分支终态。5±2 的依据不是理论，是我在几十个团队里观察到的误用率拐点：状态数在 3 到 6 之间时，成员的状态选择正确率通常能维持在 90% 以上；超过 7 个之后开始明显下滑；到 10 个以上，误用率经常超过 25%。

二、背景与真实场景：状态是怎么一步步失控的

没有团队会在第一天就设计出 14 个状态。状态失控几乎总是"合理的小决定"累积出来的。我把它归纳成三条最典型的路径。

1. 场景一：从小队到部门的"状态继承"

团队 3 个人的时候，状态是 3 个：待办、进行中、完成。协作靠喊，谁在等谁根本不需要写下来，因为大家就坐在一张桌子前。

团队到 15 人，出现了专职测试。于是"进行中"被拆成"开发中"和"测试中"，合理。团队到 40 人，出现了发布窗口，于是多了"待发布"，也合理。团队到 80 人，出现灰度发布，多了"灰度中"，还是合理。团队到 180 人，每个新加入的角色都想在状态上留下痕迹，于是又多了 6 个。

问题在于：每一次拆分在当时都是对的，但从来没有人回头做减法。状态只增不减，三年后就是 14 个。

2. 场景二：一次审计带来 4 个新状态

我见过一家做金融行业的团队，因为一次外部合规审计，要求能证明"每个需求都经过了安全评审"。团队的第一反应是加一个状态"待安全评审"。

但"是否经过安全评审"是一个布尔属性（是/否，加上评审人和评审时间），不是一个生命周期阶段。它应该是一个字段，而不是一个状态。用状态承载属性信息，是状态爆炸最常见的单一原因。

3. 场景三：工具能力倒逼流程

还有一类更隐蔽：团队用了某个项目管理工具，发现它支持"状态自动流转"，比如代码合并请求合并后自动把工作项推进到"待测试"。这是一个很好的能力，但它会诱导团队为每一个自动化动作都定义一个状态。

自动化应该服务于流程，而不是定义流程。如果一个状态存在的唯一理由是"某个 webhook 需要一个目标值"，那它更适合做成一个属性字段或者一条自动化日志。

三、拆解五个最常见的误区

下面五条是我在复盘会上重复讲过最多的，每一条后面都跟着一个我亲历的反例。

1. 误区一：状态越多，管理越精细

精细的前提是信息真实。状态数量超过人的短期记忆容量（大约是 7 个左右）之后，成员的真实行为不是"更精细地填写"，而是挑一个差不多就点过去。

我统计过一个 11 状态团队的 90 天数据：状态的分布极度不均，两个"中间态"承载了 68% 的停留时间，剩下的 9 个状态加起来不到 12%。也就是说，团队花了 11 个状态的认知成本，实际只用到 2 个。

2. 误区二：把"阶段"当"状态"

阶段是宏观划分：需求阶段、开发阶段、测试阶段、发布阶段。状态是微观交接：谁在等谁。两者不是一回事。

"测试阶段"里可能包含"待提测""测试中""待修复验证"三个状态；也可能只有一个"测试中"。把阶段直接写成状态，会导致状态粒度粗到无法反映真实等待。

3. 误区三：用状态承载所有分类信息

这是最普遍的。阻塞原因、优先级、环境、来源渠道、是否紧急、是否需要安全评审，这些全是属性，不是状态。

如果一个团队发现自己需要"开发中-阻塞""测试中-阻塞"这样的复合状态，那说明它在用一个维度（状态）承载两个维度（阶段 + 阻塞）的信息。正确做法是拆成两个字段：状态 = 测试中，阻塞标志 = 是，阻塞原因 = 等待第三方接口。

4. 误区四：状态对所有工作项类型通用

需求、任务、缺陷、技术债、线上事故，它们的生命周期是不一样的。用一套状态套所有类型，结果是每个类型都别扭。

缺陷需要"待复现""已复现""待回归"；需求需要"待评审""待验收"。强行统一，团队就会自创"胶水状态"，比如"开发中（其实是缺陷）"。

5. 误区五：改了配置就等于改了流程

工具里删掉一个状态只需要 30 秒，但流程上真正生效需要三件事：明确新状态的归属角色、更新所有自动化规则和看板视图、以及让存量数据迁移到位。少做任何一件，旧状态就会以"口头习惯"的形式复活。

四、专业判断逻辑：任务属性的四层模型

我通常会把"状态怎么做"这个问题拆成四层，从下往上建。跳过任何一层，后面都会返工。

1. 第一层：生命周期状态（Status）

只保留一条主线，5±2 个。命名规则我推荐用"等待导向"而不是"动作导向"。

比如同样是测试环节，"测试中"是动作导向，"待验证"是等待导向。前者描述谁在干活，后者描述谁在等谁。等待导向的命名天然自带时限概念，谁等太久，一眼能看出来。

下面是我给一个 200 人规模团队落地时用的状态定义示意（YAML 结构，可直接映射到多数项目管理工具的配置里）：

# 状态定义示意（工作项类型：需求）
states:

id: backlog

name: 待评估

owner_role: 产品经理

waiting_for: 优先级与验收标准确认

sla_hours: 72

exit_trigger: 人工（评审通过）

id: ready

name: 待认领

owner_role: 开发负责人

waiting_for: 排期与认领

sla_hours: 48

exit_trigger: 人工（指派到人）

id: in_progress

name: 开发中

owner_role: 开发工程师

waiting_for: 无（价值创造区间）

sla_hours: null # 不用 SLA，用 WIP 上限控制

exit_trigger: 系统事件（分支合并）

id: verifying

name: 验证中

owner_role: 测试工程师

waiting_for: 可验证版本

sla_hours: 24

exit_trigger: 人工（验证通过）

id: done

name: 已完成

owner_role: –

waiting_for: –

sla_hours: null

exit_trigger: 终态

注意最后一个状态叫"已完成"而不是"已发布"。发布与否是一个属性（发布版本号 + 发布时间），它不应该占用生命周期状态位。这个决定直接让状态数从 6 降到了 5。

2. 第二层：流转规则（Transition）

谁可以从哪个状态推到哪个状态，这是权限问题也是流程问题。我的建议是默认收紧、例外放开：主路径只允许角色推进，跨状态跳转必须走"驳回"或"取消"这类显式动作。

关键是要区分两种反向流转：驳回（验证不通过，退回上一环节）和回滚（已完成后发现问题，重新打开）。这两者的统计意义完全不同，混在一起就会污染返工率指标。

3. 第三层：属性字段（Attributes）

所有"分类信息"都放在这一层。我通常会给一套最小字段集：

• 阻塞标志 + 阻塞原因：替代"阻塞态"。
• 优先级：P0-P3，不要用"高/中/低"之外的表达。
• 工作项类型：需求/任务/缺陷/技术债，决定用哪套状态。
• 发现阶段：缺陷专用，用于区分"提测前发现"和"线上发现"。
• 环境：开发/预发/生产，用于灰度类流程。
• 验收人：明确"谁签字"，这是终态的契约。

字段的原则是能被自动化填的，绝不要求人工填。比如"发现阶段"可以从创建来源推断，"验收时间"可以从状态变更时间取。

4. 第四层：视图与度量（Views & Metrics）

前面三层建完，如果不做视图和度量，等于白建。我固定要看的四个指标：

其中流动效率是我认为最被低估的一个。它直接告诉团队：你的时间有多少花在干活，有多少花在等待。我见过的最好团队做到 42%，最差的只有 6%。

5. 状态颗粒度的判定公式

最后一个实操问题：什么时候该拆状态，什么时候不该拆？我用一个简单的判据，

如果某个状态的中位停留时间超过整个周期时间的 15%，且其中超过一半的时间在做同一件事的等待，就值得拆；否则不拆。

举例：周期时间 8 天，其中"开发中"占 4 天（50%），但这 4 天里既有写代码也有等接口联调，各占一半，那"等接口联调"就值得拆出来，或者至少用阻塞字段标记出来。

五、真实案例：一次 200 人规模的研发状态重构

下面这个案例我全程参与，从诊断到落地大约 10 周。团队是一家 200 人规模的 B 端 SaaS 公司，三条产品线，研发、测试、运维合计 130 人。

1. 基线：重构前 90 天的数据

重构前，他们的需求工作项有 14 个状态，缺陷有 9 个状态，两套状态之间没有任何对应关系。核心基线如下：

• 需求周期时间中位数：11.2 天
• 流动效率：18%
• 状态选择正确率（抽样 200 条，人工复核）：64%
• 周会用于状态对齐的时间：约 45 分钟/团队/周
• 超过 72 小时无人处理的工作项占比：23%
• 90 天内停留少于 4 小时的状态数：4 个

这里最刺痛管理层的不是周期时间，而是第 5 条：将近四分之一的工作项，在某个状态下悄无声息地躺了三天以上，而没有任何机制提醒任何人。

2. 动作：14 天里做了什么

我们没有一步到位改成 5 个状态，而是分三步走，避免一次性破坏团队习惯。

1. 第 1-3 天：导出全部历史状态变更记录，计算每个状态的停留时间分布和进入/离开频率，产出"状态价值清单"。
2. 第 4-6 天：把 4 个"僵尸状态"合并，把"待发布""灰度中"降级为字段（发布版本号 + 发布阶段），把"待安全评审"改为布尔字段。
3. 第 7-10 天：为剩余状态逐个补齐"归属角色 + 等待对象 + 时限 + 退出触发"，并在工具里配置自动化规则。
4. 第 11-14 天：做存量数据迁移和看板重建，同时跑一次全员 30 分钟的培训，只讲边界案例。

3. 结果：重构后 90 天的指标变化

有一点必须说清楚：周期时间下降的 34%，不是靠团队加班换来的，而是靠"让等待可见"换来的。超过 72 小时无人处理的占比从 23% 降到 7%，本质上就是把原来没人注意的停滞变成了有人负责的告警。

4. 迁移过程中的三个坑

这个案例里我们踩了三个坑，值得单独说。

第一个坑是存量数据。把"灰度中"降级为字段后，历史上处于该状态的工作项需要重新映射。我们一开始想全自动映射，结果发现有 60 多条工作项的实际语义和状态名不符。最后的做法是：先按规则自动映射 90%，剩下 10% 用清单人工确认，宁可多花两天。

第二个坑是视图断层。看板重建后，有两个团队发现自己的日常视图不见了，因为他们的视图是基于已删除的状态过滤的。这类问题必须在切换前做一次"视图依赖扫描"。

第三个坑是口头习惯的复活。切换后两周，有人在群里说"这个需求先放提测中"，实际上"提测中"已经不存在了。我们的对策是在工具里给旧状态名设置了 30 天的自动提示，输入旧名时弹出新状态的对应关系。

5. 工具侧的两个额外考量

这个团队最终选择在 PingCode 上落地新的状态模型。PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们的组织形态是匹配的，三条产品线、130 名研发、需要按工作项类型配置不同状态集。

有两个能力在这个案例里直接起了作用。第一个是按工作项类型独立配置状态和流转规则，需求用一套 5 状态，缺陷用另一套，两套之间不需要互相妥协。第二个是字段级的历史留痕，这让"阻塞标志"这类属性字段的变更可以被回溯，我们才能算出"阻塞导致的额外停留时间"。

另外两点对他们的长期规划有影响：支持私有化部署，满足他们客户侧的合规要求；支持从 Jira 平滑迁移，包括工作项字段、状态映射和历史记录，这让"国产替代"这条路不需要以丢掉历史数据为代价。对于正在做工具替换的中大型团队来说，这两点往往比功能清单上的差异更关键。

6. 半年后的回看

半年后我又回访了一次。5 个状态还在，但新增了 2 个属性字段和 6 条自动化规则。这是一个健康的信号：状态数稳定、属性和自动化持续增长，说明团队在往"用字段表达复杂度"的方向走，而不是往"用状态表达复杂度"的方向走。

不过也有反复。他们的一个新建团队在第 4 个月自己加了"待联调"状态。我们复盘时发现，根本原因是"联调等待"确实频繁（占开发中停留的 41%），但更好的解法是把它作为阻塞原因的一个枚举值，而不是新状态。这次我们没有直接删掉，而是先跑了 30 天数据，用数据说服团队。

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

状态方案没有标准答案，但每一种规模都有明显更优的起手式。以下是我在实践里给出的默认建议，你可以直接对照自己的团队。

1. 10 人以下团队：1 到 4 个状态，别做流程

这个阶段最大的浪费是"提前建设流程"。3 个状态（待办 / 进行中 / 完成）足够用，甚至可以只有 2 个。

不要做流转权限，不要做 SLA，不要做 WIP 上限。这个阶段真正该做的是让工作项本身写清楚，标题、验收标准、负责人。状态在这里的作用只是让墙上那块看板能看。

2. 10 到 50 人团队：4 到 6 个状态，开始分类型

出现专职测试之后，把"进行中"拆成"开发中 / 验证中"是值得的。这是第一个真正有意义的拆分点。

同时开始给需求、缺陷分成两套状态。缺陷至少要有"待复现"，因为大量缺陷的时间其实花在复现而不是修复上。

这个阶段应该开始观测周期时间和流动效率，但不要设考核，只看趋势。

3. 50 到 200 人团队：5 到 7 个状态，重点在属性和视图

这是状态最容易失控的区间，也是收益最大的区间。核心动作有三个：

1. 把发布、灰度、合规评审这类"阶段性信息"全部降级为字段。
2. 给每个状态明确归属角色和时限，把超时告警跑起来。
3. 按团队或产品线做视图，而不是按状态做视图。

这个阶段我强烈建议做一次完整的"状态审计"，把每个状态的停留数据拉出来。绝大多数团队第一次看到这份数据时的反应都是"还有这个状态？"

4. 200 人以上 / 多产品线：主状态全局统一，属性团队自治

到了这个规模，最怕的是每个产品线一套状态，跨团队协作时无法汇总。我的建议是：主生命周期状态由平台层统一（5-7 个），属性字段和视图由各团队自治。

这样既能保证全局报表口径一致，又不会让某个团队因为自己的特殊流程去改全局配置。跨团队协作时，大家只需对齐"处于哪个主状态"，细节差异用字段表达。

5. 从 Jira 迁移的团队：先把状态映射做扎实

迁移场景的特殊性在于，你不能只设计新状态，还要处理历史数据。我的建议顺序是：

1. 先导出 Jira 中的状态使用统计（每个状态的停留时间和流入流出次数）。
2. 用这份统计做减法，而不是照搬迁移。你大概率会发现至少 3 个状态可以直接砍掉。
3. 建立"旧状态 → 新状态"的映射表，并对无法一对一映射的部分准备人工确认清单。
4. 迁移后保留 30 天的旧状态名检索能力，减少团队切换成本。

PingCode 在这类场景里提供的是平滑迁移能力，包括字段映射和历史记录保留，这让"先做减法再迁移"成为可行路径，你不必因为"迁移麻烦"而被迫保留旧结构。

七、四组必须做的取舍

状态设计本质上是一系列取舍。下面四组是我认为最需要提前想清楚的。

1. 状态数量 vs 认知成本

每增加一个状态，收益是"多一个可观测的环节"，成本是"全员多一个需要判断的分类"。这个成本不是一次性的，是每天每次操作都要付。

我的取舍原则是：只有当这个状态的停留时间能被主动优化时，才值得为它付出认知成本。如果一个状态你打算建了却不去看它的数据，那就别建。

2. 自动化 vs 灵活性

自动化让流程更可靠，但也让例外更难处理。状态自动流转的规则越多，人工纠偏的路径就越绕。

我的做法是自动化只覆盖高频主路径，例外路径保留人工。比如"分支合并 → 自动进入验证中"是安全的；"验证不通过自动退回开发中"就不一定，因为它可能掩盖了"应该直接关闭"的情况。

3. 全局统一 vs 团队自治

全局统一的好处是报表可汇总，坏处是团队会觉得"这不是我的流程"。团队自治的好处是贴合实际，坏处是半年后没人能说清全公司有多少种状态。

折中方案是前面提过的"主状态统一、属性自治"。这个折中不是妥协，它有明确的技术基础：主状态回答的是"在哪个环节"，这在不同团队之间是可比的；属性回答的是"为什么卡住"，这本来就是团队特有的。

4. 一次性重构 vs 渐进演进

一次性重构速度快，但风险集中，尤其容易在存量数据上出问题。渐进演进风险低，但拖得久，团队容易疲劳。

我的经验值是：如果当前状态数超过 12 个，做一次性重构；如果在 7-12 个之间，做渐进演进。超过 12 个时，状态之间的关系已经乱到无法局部调整，必须重画。

八、从 0 到 1 的 14 天落地清单

如果你现在就要动手，下面这份清单可以直接拿去用。它是我在多个团队验证过的版本，按天排。

1. 第 1-3 天：测量，不要设计

• 导出过去 90 天全部状态变更记录。
• 计算每个状态的进入次数、离开次数、中位停留时间、P90 停留时间。
• 产出"僵尸状态清单"：进入次数 < 总工作项数 5%，或中位停留 < 2 小时的状态。
• 抽样 200 条，人工复核状态选择正确率。

2. 第 4-7 天：设计新模型

• 确定主状态数量（参考上一节的区间）。
• 为每个状态写清"归属角色 / 等待对象 / 时限 / 退出触发"。
• 把所有分类信息从状态迁移到属性字段。
• 区分驳回与回滚两条反向路径。

3. 第 8-10 天：配置与自动化

• 在工具里配置状态集、流转权限、字段。
• 配置超时告警：某状态停留超过 SLA 时通知责任人。
• 配置高频主路径的自动流转。
• 做一次"视图依赖扫描"，找出会被状态变更影响的看板和报表。

4. 第 11-12 天：数据迁移

• 建立"旧状态 → 新状态"映射表。
• 自动映射并输出无法映射的清单，人工确认。
• 保留 30 天的旧状态名检索提示。

5. 第 13-14 天：培训与首次度量

• 30 分钟全员培训，只讲边界案例，不讲理论。
• 发布第一版流动效率、周期时间、WIP 超限看板。
• 约定 30 天后做一次复盘，只看数据，不追责任。

结语：状态做得好不好，看的是它有没有让等待变得不可忍受

回到开头那 14 个状态。这个团队后来只保留了 5 个，但真正改变的不是数字，而是团队第一次能说出"我们在等什么"。

我有一个可能有点反常识的判断：状态设计的成功标志，不是流程跑得更顺，而是问题暴露得更早、更吵。重构完成后，这个团队的群消息变多了，不是闲聊，而是超时告警。"这个需求在待认领躺了两天了，谁接？"这句话以前不会出现，因为根本没人知道它躺了两天。

另一个常被忽略的点是：状态是少数几个"配置成本极低、长期收益极高"的杠杆。改一个状态名只要 30 秒，但它影响着未来两年每一天、每个人的每一次操作。这种杠杆在研发管理里并不多，所以值得你专门花两周认真做一次。

如果你准备动手，我的建议是按这个顺序走：先拉 90 天数据，再砍状态，再补属性，最后配自动化。顺序反了，你就会掉进"配置很漂亮、数据没人填"的坑里。

如果你们的团队已经在 100 人以上、状态数超过 10 个、并且正在考虑工具替换，那么把状态重构和工具迁移合并成一次动作，通常比分开做更划算，这也是我在最近几个项目里越来越倾向的做法。前提是，迁移方案必须支持字段级映射和历史记录保留，否则你会在迁移过程中把刚建立起来的度量体系再丢一次。