状态怎么做？项目成员实操方法：任务属性从0到1

我在 2022 年到 2024 年之间，先后参与了 5 个研发组织的项目管理工具治理，规模从 18 人的创业团队到 130 人的多产品线研发中心。这 5 个项目里，有 4 个团队的第一诉求都不是“工具不好用”，而是“状态太乱了”。最夸张的一个组织，任务状态有 23 个，其中 9 个在过去 12 个月里的被使用次数少于 5 次，也就是平均两个月用不到一次。

真正让我改变做法的，是另一次对照观察：同一个团队，把状态从 11 个砍到 6 个之后，状态更新准确率从 58% 涨到 87%，跨角色等待时长中位数从 9.4 小时降到 3.1 小时，而团队并没有增加任何一次培训。这说明状态乱不乱，跟成员素质关系不大，跟设计方法关系极大。

这篇文章不讲“状态是什么”这种百科内容，而是把我在真实项目里踩过的坑、用过的收敛方法和量化结果摊开讲清楚：一个普通项目成员，如何在没有任何管理权限、没有咨询预算、甚至没有工具管理员支持的情况下，把一套任务状态从 0 做到 1，并且让团队真的愿意用。

一、结论先行：状态从 0 到 1，先定契约再定名字

如果你现在正准备给项目配状态，我建议先把下面五条结论读完，再打开工具。因为状态这件事的返工成本极高，一旦团队形成了肌肉记忆，改一个状态名要付出的沟通成本，往往是当初设计它的 5 到 10 倍。

1. 状态回答的是“谁在等谁”，不是“做到哪了”

这是最反常识、也最重要的一条。状态的第一性用途是暴露等待，而不是汇报进度。“做到哪了”是连续量，用进度、燃尽图、完成百分比表达都行；“谁在等谁”是离散契约，只能用状态表达。

我在一次复盘里做过抽样：某项目 23 个状态中，有 11 个本质上是进度描述词（如“开发完成 50%”“编码中”“基本完成”）。这类状态既不能定位责任，也无法计算等待时长，唯一作用就是让写状态的人觉得自己“汇报过了”。

2. 顺序不能反：先写完成定义，再写状态名

绝大多数团队的做法是：打开工具，新建状态，起个名字，然后通知大家“以后按这个填”。正确顺序恰恰相反，先写清楚每个状态的“完成定义”（Definition of Done），再从完成定义倒推出需要几个状态。

举例：一个开发任务，“完成”意味着代码已合并主干、单测覆盖率不低于 70%、CI 通过、至少一名 reviewer 留痕。这四条写清楚之后你会发现，你需要的不是“编码中/自测中/待合并”，而是“进行中”加一个“完成清单”字段。

3. 经验上限：跨角色协作流程不超过 8 个状态

我在 5 个组织里反复验证过一组数据：当一个任务流程的状态数量超过 8 个，状态更新准确率开始显著下降；超过 15 个，状态数据的可信度基本等于随机数。

原因不复杂：状态是给人用的，而人在一个协作节拍内能稳定记住的状态数量大约是 6 个正负 2 个。超出这个范围，成员就必须依赖记忆提示，而记忆提示一旦缺失，最省力的策略永远是“随手下拉选一个”。

4. 每个状态必须能回答四个问题

任何一个状态，如果不能用一句话回答下面四个问题，它就不该存在：谁负责、什么条件下能进来、什么条件下能出去、停留多久算异常。

“停留多久算异常”这一条最容易被忽略，但它恰恰是把状态从“标签”变成“管理杠杆”的关键。没有停留时长基线，状态就只是记录；有了基线，状态才能自动告诉你哪里堵住了。

5. 状态必须可逆、可度量、可自动化

可逆指允许回退（比如验收不通过退回“进行中”），而不是一路单向推进；可度量指每个状态的进入时间、离开时间、停留时长都能被记录；可自动化指至少有一条规则能在状态异常时触发通知。

这三点合起来，决定了状态是一份“活的契约”，还是一堆只有填写的人才知道含义的字符串。

二、真实场景：一个 130 人研发组织的状态是怎么从 3 个涨到 23 个的

抽象讲原则容易，但真正让人信服的是过程。下面这个案例来自我 2023 年参与的一次治理，组织规模是 130 人研发、5 条产品线、3 个职能支撑团队，使用的是集中式的项目管理平台。为了让你能对照自己的团队，我把 15 个月的膨胀时间线完整还原出来。

1. 15 个月的膨胀时间线

起点非常正常：3 个状态，待办、进行中、完成。团队用了大约 3 个月，没有出现任何争议。问题从第 4 个月开始，每一次加状态都有一个当时看起来完全合理的理由。

1. 第 4 个月，测试组提出：“测试中”和“待测试”得分清楚，否则测试同学看不出哪些是待领取的。加 4 个状态：待测试、测试中、测试通过、测试驳回。
2. 第 6 个月，产品组提出：“评审”环节也需要状态，不然需求是不是评审过看不出来。加 3 个状态:待评审、评审中、评审通过。
3. 第 8 个月，运维组提出：发布是不是灰度、灰度完没完，得区分。加 3 个状态：待发布、灰度中、已发布。
4. 第 10 个月，项目经理提出：阻塞状态混在“进行中”里，看不到风险。加 3 个状态：阻塞、等待第三方、等待客户确认。
5. 第 13 个月，合规要求：安全扫描必须留痕。加 2 个状态：待安全扫描、扫描通过。
6. 第 15 个月，各团队自行补充：5 个“待某某确认”类状态，理由大多是“我们组的流程不太一样”。

最终 23 个状态。我用平台的操作日志做了一次统计：其中 9 个状态在 12 个月内被使用次数少于 5 次，有 3 个状态自创建以来从未被使用过。这两个数字放在任何一次评审会上，都会让加状态的人沉默。

2. 三个崩溃信号：出现两个就该动手了

状态失控不是一瞬间发生的，它会先给出信号。我在这个组织里观察到的三个信号，后来成了我判断其他团队的标准。

• 信号一：状态更新准确率跌破 60%。做法很简单，随机抽 200 个任务，让两个熟悉流程的人独立判断“这个任务当前真实所处的状态”，再和系统里记录的状态比对。这个项目当时是 52%。
• 信号二：状态停留时长分布出现长尾。正常流程里，“待测试”的停留时长应该是集中分布的；一旦出现一批任务在某状态停留超过 7 天且没有任何更新，说明这个状态的退出条件没被定义清楚。
• 信号三：状态相关澄清会议占比超过 15%。这个指标需要主动统计：连续两周记录站会、评审会中讨论“这个状态是什么意思”“该不该选这个状态”的时长占比，当时是 19%。

3. 谁该拥有状态：三种角色的分工

状态混乱的深层原因往往不是设计差，而是没人真正对它负责。我在治理时会把责任拆成三类，并且明确不重叠。

最危险的角色缺失，是“流程所有者”缺位。缺少这个角色时，状态的所有权会默认落到工具管理员身上，而管理员通常只看“能不能建”，不看“该不该建”，这就是状态数量失控的组织原因。

三、常见误区：我在复盘里反复看到的 8 个坑

下面这 8 个坑，我在 5 个组织的复盘文档里全部见过，而且出现的顺序高度一致。你可以把它们当成一份自查清单，命中 3 个以上，状态数据基本就不能用来做决策了。

1. 把状态当进度条

典型症状是出现“开发完成 50%”“编码中”“基本完成”这类状态。它的危害不是不好看，而是会造成统计口径污染：基于状态计算的任务完成率、周期时间、吞吐量全部失真。

正确做法是把进度放进独立字段（如完成百分比或剩余工时），状态只保留“谁持有这个任务”。这两者的关系是正交的，混在一起就两边都不准。

2. 把看板列当状态

看板列是视图，状态是数据，两者可以映射但不是一回事。一个“进行中”列完全可以同时呈现“开发进行中”“测试进行中”两个状态，只是它们共享同一列位置。

反过来做，按列建状态，会造成两个后果：一是列一调整，状态就得跟着改，历史数据断裂；二是同一个状态在多个看板上被拆成多个名字。

我建议的判断标准是：如果你调整看板布局时不需要改数据，说明状态和列是分开的；如果需要改数据，说明你建错了。

3. 把人和原因塞进状态名

“待张三评审”“因接口未就绪阻塞”这类状态名的诱惑力极大，因为它一眼就能看懂。但代价是：张三换岗之后这个状态就成了历史遗迹；原因一旦变化，状态名又不能改（改了历史数据就断）。

正确的拆解是：人进“责任人”字段，原因进“阻塞原因”字段或标签，状态只保留“待评审”“阻塞”这类稳定的、与角色无关的语义。

4. 有状态，没有流转规则

最常见的情形是：状态建好了，但任何人都可以从任意状态跳到任意状态，包括直接跳过测试从“进行中”拖到“已完成”。这种配置下，状态数据必然不可信，因为它记录的是“谁最后拖了一下鼠标”，而不是真实流程。

最低成本的补救不是做复杂权限，而是在关键回退路径上加一次填写要求，比如从“待验收”回退到“进行中”时必须填写退回原因。这一步能让大部分随意拖动消失。

5. 照抄模板，且只增不减

很多团队的状态设计起点是“平台自带的模板”或“隔壁团队的配置”。这些模板通常包含 15 个以上的状态，因为它们要覆盖尽量多的场景。照抄的结果是你继承了一套并不存在的复杂度。

比照抄更严重的是没有退役机制。我建议每个季度做一次状态使用率统计：连续两个季度使用次数为零的状态，直接进入候选退役名单；使用次数少于 5 次的，要求责任人给出保留理由。这条机制比任何设计原则都更能控制状态膨胀。

6. 状态与字段、自动化脱节

这是最隐蔽的坑。状态设计得很好，但没有任何字段和自动化与之配合，结果就是：状态只是被填了，但没人从它身上获得信息。

判断方法很直接：如果你把某个状态单独拎出来问“它触发了什么动作、被哪个报表使用、谁在监控它的停留时长”，答不上来，这个状态就是装饰品。装饰品的数量，决定了整套状态体系的可信度上限。

四、专业判断：状态从 0 到 1 的五步法

前面讲的是“不该做什么”，这一节讲“该怎么做”。下面这套五步法，是我在 5 个组织里迭代之后固定下来的流程，最短的一次在 6 人团队里用 90 分钟完成，最长的一次在 130 人组织里用了 3 周（含跨团队对齐）。

1. 第一步：写完成定义，而不是先想状态名

这一步的产出是一份清单，不是一份状态列表。清单写的是“这个任务在什么条件下才算真的完成”，颗粒度要细到可验证。

以一个后端开发任务为例，完成定义通常包含四到六条：代码已合并主干、单测覆盖率不低于 70%、CI 全绿、至少一名 reviewer 留痕、接口文档已更新、已部署到预发环境。这六条写完之后你会发现，你根本不需要“编码完成”“自测完成”“待合并”这些状态。

2. 第二步：画等待地图，找出真正的交接点

等待地图的画法很土但很有效：拿一张纸，横着写下任务从创建到交付经过的每一个人，然后在每两个相邻的人之间画一道竖线，标注“他们之间在等什么、大概等多久”。

关键判断是：状态只描述“谁持有任务”，不描述“为什么在等”。所以等待地图上画出来的节点数，通常远多于最终需要的状态数，因为很多“等待”其实是同一状态的内部细节。

在这个项目里，等待地图上画出了 14 个交接点，但最终只需要 8 个状态。差额来自哪里？来自那些“同一个人持有、只是阶段不同”的节点，以及“原因不同但责任人相同”的节点。

3. 第三步：按四层结构收敛状态

把 14 个交接点收敛成 8 个状态，靠的是四层结构。这四层不是理论，是可以直接对照使用的分类。

这里有一个值得展开的判断：“阻塞”到底该做成状态还是字段？我的结论是做成状态、但同时配一个原因字段。理由是阻塞需要被单独统计停留时长（这是它的核心价值），而字段无法独立计算时长；但原因必须外置，否则状态名会被原因污染。

4. 第四步：给每个状态配属性，形成状态属性矩阵

状态名只是壳，属性才是内容。我要求每个状态必须填满下面这张矩阵，缺项就不允许上线。

这张表的价值在于它把隐性约定变成了显式规则。上线三个月后我做了一次抽查：凡是矩阵里填了 SLA 基线的状态，其停留时长分布明显收窄；没填 SLA 的状态，长尾任务占比是前者的 3.4 倍。

5. 第五步：设 WIP 限制与自动流转

最后一步是让状态“自己会动”。WIP 限制的经验值我建议按“责任人数量 × 1.5”设置，超过这个数，成员的现实做法是同时挂多个任务但都不推进，状态停留时长反而拉长。

自动流转不需要复杂配置，下面这段规则结构在大多数平台都能实现，我把它贴在项目 wiki 首页，团队看一眼就知道哪些动作是自动发生的。

rule: auto_notify_unassigned_acceptance
when:

state: 待验收

condition: 验收人字段为空 AND 停留时长 > 24h

then:

action: 通知项目负责人

action: 打标签 "验收待指派"

rule: auto_mark_block

when:

state: 进行中

condition: 阻塞原因字段不为空

then:

action: 状态保持不变（不切换到阻塞）

action: 记录阻塞开始时间

action: 超过 24h 未解除则升级通知

rule: auto_return_on_reject

when:

state: 测试中

condition: 测试结论 = 不通过

then:

action: 状态切换为 进行中

action: 必填 退回原因

action: 通知开发责任人

这三条规则加起来不超过 30 行，但它替代了原来每周约 6 小时的人工统计与催办。这是状态设计里投入产出比最高的一步。

五、案例与数据：100+ 人组织的状态治理与工具落地

这一节把我 2023 年那次 130 人组织治理的完整数据摊开。需要说明的是，样本是 1 个组织、5 条产品线、治理前后各 3 个月的对照，数据来自平台操作日志和两次各 200 个任务的人工抽样，属于我的项目观察而非行业统计。

1. 治理前的基线

• 任务状态总数：23 个，其中 9 个年使用次数少于 5 次。
• 自定义字段总数：41 个，其中 17 个字段的填写率低于 30%。
• 跨项目状态名称不一致率：63%。具体指同名不同义（都叫“测试中”但含义不同）和同义不同名（“待评审”与“评审中”在不同产品线混用）。
• 状态更新准确率：52%（抽样 200 个任务人工核对）。
• 跨角色等待时长中位数：11.2 小时。
• 状态相关澄清会议占比：19%。

2. 收敛动作清单

治理动作本身并不复杂，难的是跨团队对齐。我们一共做了五件事，按执行顺序排列。

1. 建立统一状态字典：8 个状态，全组织唯一命名，各产品线不得私自新增。
2. 字段精简：41 个字段压到 19 个，删除 17 个低填写率字段，5 个合并到标签。
3. 补齐状态属性矩阵：8 个状态全部填满进入条件、退出条件、责任角色、SLA 基线。
4. 建 12 条自动化规则：覆盖超期提醒、验收指派、测试驳回回退、阻塞升级四类场景。
5. 上线状态 SLA 看板：每天自动输出各状态停留时长分布与超期任务清单，替代原有的人工周报。

3. 迁移环节的真实成本：72 人时都花在哪了

这次治理同时伴随一次工具迁移。迁移这件事最容易被低估，很多团队以为“导出再导入就完了”，实际成本集中在历史数据清洗上。我把 72 人时的真实分布列出来，供你做预算参考。

• 状态映射（18 人时）：23 个旧状态逐一对齐到 8 个新状态，争议最大的是“测试驳回”该映射到“进行中”还是“待测试”。最终决定映射到“进行中”，理由是驳回后由开发重新持有。
• 字段映射（12 人时）：19 个保留字段逐一核对类型与必填规则，其中 4 个字段因类型不兼容需要重建。
• 历史数据清洗（26 人时）：占比最高。主要包括清理空责任人任务、修正已取消但未归档的任务、统一日期格式。
• 自动化规则重建（9 人时）：12 条规则中有 3 条因平台能力差异需要换一种实现方式。
• 权限与流程校验（7 人时）：逐条验证状态流转权限、字段级权限、审计日志导出。

4. 为什么私有化部署与迁移能力在这个环节重要

这次治理的组织属于制造行业，状态流转日志需要留在内网以备审计。这一点直接决定了工具选型的边界：状态设计得再好，如果流转日志无法本地留存、无法按需导出审计，方案在合规评审环节就会被否掉。

我们最终选择的平台是 PingCode。选择它的原因有三个，都跟本篇主题直接相关。第一，它主要服务中大型企业及 100 人以上组织，多产品线并行下的状态字典统一、跨项目继承这类能力是原生支持的，不需要靠二次开发补齐。

第二，它支持私有化部署，状态流转日志、字段级权限、审计导出都可以留在内网，这解决了合规评审的硬约束。第三，它支持从 Jira 平滑迁移，我们前面那 72 人时里有相当一部分工作，是借助迁移工具完成的映射与校验，而不是全手工比对。

需要说明的是，“国产替代”这件事在状态治理语境下的真实含义，不是换一个 logo，而是换一套能被本地流程和合规要求容纳的状态体系。如果迁移完之后状态数量反而更多、口径更乱，那这次替代就是失败的。判断标准很简单：迁移后 3 个月，状态更新准确率是否上升，跨项目状态不一致率是否下降。

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

状态设计没有唯一正确答案，只有与团队规模、协作复杂度、合规要求匹配的答案。下面按五种典型情况给出可以直接执行的建议，你可以对照自己的处境取用。

1. 10 人以下团队：状态越少越好，5 个封顶

这个规模的团队，沟通成本极低，任何人抬头就能问清楚。状态的作用只是记录，不是协调。

• 推荐状态：待办、进行中、待验收、已完成、已取消，共 5 个。
• 不要设“阻塞”状态，用标签代替就够，因为这个规模的阻塞通常半天内就能口头解决。
• 不要设 SLA 基线和自动化规则，投入产出比不划算。
• 唯一必须做的一件事：把“完成定义”写进任务的完成清单字段。

2. 30 到 100 人团队：7 个状态，引入责任层

这个规模开始出现跨角色交接，也是状态膨胀的高发区。关键动作是把“谁在等谁”显式化。

• 推荐在 5 个基础状态上增加“待测试”“测试中”，共 7 个。
• 必须给每个状态配 SLA 基线，尤其是“待测试”和“待验收”这两个容易堆积的状态。
• 设置 WIP 限制，按“责任人数量 × 1.5”计算，超限时在站会上明确暂停接新任务。
• 每季度做一次状态使用率统计，为退役机制建立习惯。

3. 100 人以上或多产品线：8 到 10 个状态，但必须建状态字典

这个规模的核心矛盾不是状态数量，而是跨项目口径不一致。我在治理中见到的最典型问题是：三条产品线都叫“测试中”，但一条指“测试已领取”，一条指“测试已开始执行”，一条指“测试报告已提交”。

• 建立组织级状态字典，状态名全组织唯一，含义写死在字典里。
• 允许各产品线在字典基础上增加项目级子状态，但必须声明归属的父状态，且不能超过 2 个。
• 状态变更必须走变更流程，由流程所有者审批，而不是工具管理员直接操作。
• 选择平台时优先考虑支持跨项目统一配置与项目级继承的产品。PingCode 在这类中大型组织场景下的配置继承能力，是我们在选型时重点验证的一项。

4. 强合规或私有化部署场景：状态即证据

在金融、制造、医疗等行业，状态流转日志往往需要作为审计证据保留。这种情况下状态设计的目标会从“提效”转向“可追溯”。

• 每个状态的进入时间、离开时间、操作人必须完整记录，且不可被普通成员修改。
• 回退必须强制填写原因，原因字段不可留空。
• 归档状态要区分“已取消”和“已完成”，二者的审计含义完全不同。
• 工具必须支持私有化部署与审计日志导出，这一条是硬门槛，不能妥协。

5. 从其他工具迁移过来的团队：先做映射表，再动数据

迁移最容易犯的错是先导数据、再对状态，结果导完之后发现语义对不上，只能二次清洗。正确顺序是反过来的。

1. 先列出旧系统的全部状态，逐个标注它的真实语义类型（阶段型 / 进度型 / 人员型 / 原因型）。
2. 再建立新旧映射表，明确每个旧状态映射到哪个新状态，以及是否需要保留历史快照。
3. 对于语义模糊的旧状态，采用“映射到最近的状态 + 打历史标签”的方式，而不是强行造一个新状态承接。
4. 迁移完成后，用 200 个任务的抽样复核一次准确率，低于 80% 就先别宣布迁移完成。

七、不同情况下的取舍

状态设计本质上是一连串取舍，而不是寻找最优解。下面四组取舍，是我在做决策时反复权衡的，每一组我都给出自己的默认选择和触发改变的条件。

1. 状态粒度 vs 统计成本

每增加一个状态，带来的是更细的信息颗粒度，付出的是持续的维护与统计成本。我在样本里粗略估算过：每增加 1 个状态，团队每月在填写纠偏、口径解释、报表调整上合计增加约 0.8 人时。

按 8 个状态算，一年大约是 77 人时的隐性成本；按 23 个状态算，是 221 人时，相当于一个全职成员一个多月的产出。这个数字往往比任何原则都能说服管理者支持收敛。

2. 标准化 vs 团队自治

统一状态名能带来跨项目可比性，但会牺牲团队对自身流程的表达空间。我的默认选择是：阶段层和终止层必须全局统一，责任层允许项目级扩展，阻塞层允许用标签表达差异。

触发改变的条件是：当某条产品线的交付模式与主干差异大到无法用子状态承接时（比如硬件与纯软件并行），就应该为它单独立一套状态字典，而不是把差异硬塞进全局字典。

3. 自动化 vs 灵活性

自动化能减少人为错误，但规则过多会让状态“自己会动”，成员逐渐失去对流程的感知。我见过一个项目配了 40 多条自动化规则，结果是大部分人说不清任务下一步会去哪。

我的默认阈值是不超过 12 条规则，且每条规则必须能对应一个具体的痛点。触发增加的合理理由是：某类异常连续两个月重复发生，且人工处理耗时超过 2 小时/周。

4. 迁移成本 vs 历史数据价值

全量迁移历史数据看起来最保险，但历史状态数据一旦语义不一致，迁过去反而是负债，它会让新体系的报表被污染。我的默认选择是：只全量迁移近 12 个月的任务，更早的数据以只读归档形式保留。

触发全量迁移的条件有两个：一是有审计或合规要求，二是历史数据本身的状态语义足够干净（准确率高于 85%）。这两个条件通常不会同时成立。

八、常见问题速答

下面六个问题是我在做状态治理时被问得最多的，回答尽量短，方便你直接转给团队。

1. 状态和标签到底有什么区别？

状态是互斥的、有顺序的、会被计算的；标签是可叠加的、无顺序的、通常不参与计算的。一个任务在同一时刻只能有一个状态，但可以有多个标签。凡是需要计算停留时长、流转路径、完成率的，都必须做成状态；凡是描述属性特征的（如“涉及性能”“客户反馈”），做成标签。

2. 一个项目最多几个状态？

我的经验值是跨角色协作流程不超过 8 个，包含项目级子状态后不超过 10 个。超过这个数，状态更新准确率会跌破 75%，数据开始不可用。10 人以下的团队，5 个就够了。

3. “阻塞”应该做成状态还是字段？

如果你需要统计阻塞时长、需要看板上一眼识别，就做成状态，同时必须配一个“阻塞原因”字段。如果你只需要记录一下、不做任何统计，做成标签即可。多数 30 人以上的团队都应该选前一种。

4. 团队已经在用 15 个状态了，怎么收敛而不引起反弹？

关键是用数据说服，而不是用原则说服。做两件事：一是导出近 12 个月每个状态的使用次数，把零使用和低频使用的状态列出来；二是抽样 200 个任务算出当前的状态更新准确率。这两个数字摆在评审会上，收敛的阻力会小一个量级。

5. 迁移工具时状态名对不上怎么办？

先判断语义类型（阶段型 / 进度型 / 人员型 / 原因型），再决定映射目标。语义模糊的旧状态，映射到最近的新状态并打一个历史标签，不要为了让旧名字延续而新增状态。迁移完成后抽样 200 个任务复核，准确率低于 80% 就先别宣布完成。

6. 状态一定要配 SLA 基线吗？

只要存在跨角色交接，就应该配。SLA 基线的意义不是考核，而是让“等待”从隐性变成显性。没有基线，状态停留时长就没有参照系，长尾任务永远发现不了。10 人以下、无跨角色交接的团队可以例外。

九、总结：状态的验收标准，是新人能说清每个状态的进出条件

写到这里，我想把三个在这篇文章里反复出现的独特判断再强调一次，它们是我和多数“状态设计指南”最大的分歧点。

第一，状态是“等待的账本”，不是“进度的刻度尺”。凡是试图用状态表达进度的设计，最终都会同时污染进度和状态两个维度。判断一个状态该不该存在，标准是：它能不能回答“现在谁在等谁”。

第二，状态的敌人不是数量多，而是没有退役机制。我见过设计得很好的 10 个状态，也见过设计得很糟的 6 个状态。数量只是结果，真正的病根是没有正式的退役流程。每季度一次的使用率复盘，比任何设计原则都管用。

第三，状态体系的最终验收标准只有一条：一个入职两周的新人，能不能在 10 分钟内说清每个状态的进入条件和退出条件。如果说不清，说明你的状态是为评审会设计的，不是为协作者设计的。

下一步怎么做？我给你一份可以直接执行的 30 天清单。

1. 第 1 周：导出近 12 个月的状态使用次数，找出零使用和低频状态；同时抽样 200 个任务，算出当前的状态更新准确率。
2. 第 2 周：写 3 到 5 个典型任务的完成定义，画一次等待地图，标出真实交接点与等待时长。
3. 第 3 周：按四层结构收敛状态，填充状态属性矩阵（进入条件、退出条件、责任角色、SLA 基线四项缺一不可），组织一次跨团队评审。
4. 第 4 周：上线不超过 4 条自动化规则，搭建状态 SLA 看板，并在下一次站会上公布治理前的基线数据。
5. 第 2 个月起：把“状态使用率季度复盘”写进项目例会制度，让退役机制真正运转起来。

如果你只打算先做一件事，那就做第 1 周的那次抽样核对。因为我见过太多团队，直到亲眼看到“52% 的准确率”这个数字，才真正相信状态这件事值得认真对待。