状态怎么做？管理层落地方案：任务属性从0到1

我第一次被“状态”这两个字打脸，是在一个 130 人左右的研发组织里。当时管理层要做季度复盘，我在会上打开需求看板，想说“在途需求 214 个”，结果产品负责人立刻反问：这个 214 是包含“待评审”的还是不包含？测试负责人说他那边看到的是 236，因为“验收中”和“待验收”算两列，系统导出时会重复计一次。财务口的同事更直接，说他们拿到的“完成率”和研发给的差了 11 个百分点。

同一套工具、同一批数据，三个部门三个数，这场复盘会开了 100 分钟，前 40 分钟都在对数。

这件事让我确认了一个判断：绝大多数团队的状态设计失败，不是因为状态太少或太乱，而是因为从来没有人把状态当成一个需要被“设计”和“治理”的对象。它通常是某天早上某个人在工具里顺手加了一列，然后这列活了下来，长成了组织的一根毛细血管。等到管理层想用它做度量时，才发现这根血管里流的不是血。

这篇内容我想完整讲清楚一件事：状态作为一个任务属性，从 0 到 1 到底该怎么搭。我会把我在几个不同规模组织里踩过的坑、做过的收敛动作、观测到的数据变化都摊开讲，最后给出一套管理层可以直接拿去用的落地方案。

一、核心结论：状态不是标签，而是一份可执行的管理契约

先把结论放在最前面，后面所有内容都是为这几条做论证。

状态不是用来“看进度”的配色方案，它是组织对“谁在什么时候对什么负责”的一份书面约定。每加一个状态，就等于新增一个交接点、一次责任转移、一个可以被度量的时间区间。这句话听起来很抽象，但它可以直接推导出后面所有的判断标准。

1. 状态的三个真实职责

我观察过做得好的状态体系，它们基本只干三件事，多一件都是负担。

• 分工职责：谁手里的球。状态一换，责任人跟着换，这是最核心的作用。
• 度量职责：时间怎么切。只有状态稳定，状态之间的停留时间才有可比性，周期时间才能被拆解。
• 风险职责：哪里堵了。某个状态长期堆积，说明这是一个真实的瓶颈，而不是某个人不努力。

如果一个状态既不改变责任人，也不产生新的时间区间，还不能暴露风险，那它就是装饰品。装饰品的成本不是零，它会在每一次周会、每一次数据核对里收税。

2. 三条可以当场验证的判断标准

我通常用三条标准快速判断一套状态设计是否健康，这三条在客户现场基本一试就中。

1. 随机抽 3 个人问同一个状态的含义，答案是否完全一致。只要出现“大体上差不多”，就说明这个状态没有准入准出条件。
2. 随机抽 5 个历史任务，看它们的流转路径是否可解释。如果出现大量跳跃和回退且没人解释得清，说明状态机主干是假的。
3. 把这个状态删掉，流程是否会断。如果不会断，它就该被合并。

这三条标准背后其实是一个更狠的问题：你的状态体系，到底是给谁用的？答案不同，设计逻辑完全不同。给一线做协作用的状态，可以多一点、灵活一点；给管理层做度量用的状态，必须少、必须稳、必须口径唯一。绝大多数团队的混乱，是把这两种需求硬塞进了同一套状态里。

3. 一个反常识的结论

我要说一个可能不太受欢迎的判断：对于 200 人以内的组织，状态数量超过 8 个，几乎必然是负收益。这不是拍脑袋，后面第五节会给出实测数据。原因很简单：状态的数量增长是指数级的交接成本，而不是线性的信息增量。每多一个状态，就多一组“什么条件下进、什么条件下出、谁来判定”的隐性问题，而这些问题的解答成本会随人数平方级放大。

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

没有哪个团队是一开始就决定把状态搞乱的。它是一步步长出来的，而且每一步在当时看都无比合理。

1. 现场一：状态漂移，同一个词，三种理解

我在一家做企业服务的公司见过最典型的一次。他们的研发需求里有一个状态叫“开发中”。我去问三个角色，得到了三个答案。

研发说：我在写代码了，就叫开发中。产品说：我评审通过了、等研发排期，也算开发中。项目经理说：只要不是待办也不是已完成，我一般都放开发中。

结果就是这个状态成了一个黑洞。所有难以归类的东西都被扔进去，里面的任务有的还没排期，有的代码已经提测。当管理层问“现在有多少需求在开发中”，得到的数字既不能代表研发产能占用，也不能代表交付进度，它只代表没人愿意管的中间态有多少。

2. 现场二：状态膨胀，三个月从 5 个长到 23 个

状态膨胀通常有固定的剧本。第一个月，工具默认给了 5 个状态，大家用着还行。第二个月，某个业务线要求区分“待客户确认”和“待内部确认”，加到 7 个。第三个月，质量部门要求把测试拆成“冒烟测试中”“功能测试中”“回归测试中”，加到 12 个。再后来，跨部门协作需要“待法务”“待采购”，加到 19 个。最后有人加了一个“暂时挂起”，加到 23 个。

每一次加状态的人都有充分理由，但没有人问一个问题：这个状态会稳定存在多久，它的消费方是谁？

3. 现场三：状态和度量脱节，数据在，但不敢用

更麻烦的情况是状态很多，数据也全，但没人敢用。我见过一个团队，他们的状态停留时间报表做得很漂亮，但产品负责人私下跟我说，他不会在汇报里用这张表，因为“看一眼就知道不对”。

原因在于状态的准入准出没有约束。一个任务在“开发中”停留了 40 天，实际可能是开发了 3 天、然后被挂起 37 天。报表不会告诉你这件事，它只会显示一个 40 天的柱子，然后让所有人误判产能。

状态的数据价值，不取决于状态的多少，而取决于状态边界是否被真实执行。边界不执行的报表，比没有报表更危险，因为它会带来错误的决策信心。

4. 现场四：状态变成追责工具

这是我最不愿意看到的一种演化。当状态和绩效考核挂钩，一线会开始“优化”状态，而不是优化工作。任务实际做完了但先不点“完成”，等月底统一批量点；需求其实卡住了但要先拖进“开发中”，免得被标记为阻塞。

一旦出现这种情况，状态体系就死了。它不再描述工作，它开始表演工作。而管理层看到的每一个数字，都是被表演出来的。

三、常见误区拆解：为什么大多数状态设计都做废了

把上面这些现场抽象一下，可以归纳成五个反复出现的误区。我按危害程度从高到低排。

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

这是最普遍也最致命的误区。它的隐含假设是“信息越多越好”，但忽略了信息的采集成本和解释成本。

我做过一个粗略测算：每新增一个状态，团队每周额外付出的成本大约包括，状态判定争议 3-5 次、数据核对 10-15 分钟、新人理解成本（前两周内）约 2 小时。一个 50 人的团队，每多一个状态，一年隐性成本大约在 40-60 人时。这个数字单看不吓人，但 10 个冗余状态就是 400-600 人时，相当于白养半个全职岗位。

真正的精细，是把状态背后的准入准出条件写清楚，而不是把状态切碎。

2. 误区二：把状态当进度百分比

有人试图让状态承担进度表达的职责，于是出现了“完成 30%”“完成 60%”这种状态。这在研发场景里几乎必然失真。

研发工作的进度不是线性积累的。一个技术方案可能卡在最后一个边界条件上一周，也可能在最后两小时突然全部打通。用状态表达百分比，等于强迫一线去做一个他们自己都不相信的估算，最后只会得到一堆为了填表而填表的数字。

进度这件事，应该交给“剩余工作量”或“子任务完成数”来表达，状态只负责回答“这件事现在在谁手里”。

3. 误区三：把状态当审批流

这是把两个不同维度的东西混在一起。“待审批”是一个决策环节，“开发中”是一个执行环节，它们的语义完全不同。

当审批被建模成状态，会出现两种坏结果：一是审批环节的变化会污染执行数据的连续性；二是审批人不在时，任务会以一种极其显眼的方式堆积在某个状态里，但它其实并不代表工作卡住，只代表某个人在开会。

更合理的做法是把审批建模成任务的一个属性（比如“审批状态”）或者独立的工作项类型，而不是混进主状态机。

4. 误区四：只设计，不治理

我见过很多团队在项目启动时花两周设计了一套漂亮的状态，然后两年没再动过。但组织在变，业务在变，两年前合理的状态今天大概率不合理。

状态治理需要三个动作：定期审计（哪些状态连续 3 个月流转量低于阈值）、明确变更入口（谁能加状态、走什么评审）、强制清理（合并或废弃的决策机制）。缺了这三条，任何初始设计都会在 12 个月内腐化。

5. 误区五：让工具决定流程

工具的默认模板是给最普遍场景用的，它不可能是你的流程。但我见过太多团队直接接受工具的默认状态，或者反过来，为了适配工具的某个限制而扭曲自己的流程。

正确的顺序是：先画清楚业务上真实存在的责任交接点，再去看工具能不能承载；能承载就用，不能承载就换工具或者提需求。顺序反了，流程就会被工具的惯性绑架。

四、专业判断逻辑：状态从 0 到 1 的四层漏斗

讲了这么多问题，该给方法了。我用的是一套四层漏斗，顺序不能颠倒，颠倒就会做废。

1. 第一层：先定义工作项类型，再定义状态

这是最容易被跳过、但最重要的一步。很多团队直接开始设计状态，结果把需求、缺陷、技术任务全塞进同一套状态里。

但缺陷的流转逻辑和需求的流转逻辑根本不是一回事。缺陷有“复现，修复，验证，关闭”的闭环，需求有“收集，细化，排期，开发，验收，上线”的长链路。硬要用一套状态覆盖，只能取最大公约数，最后两边都不好用。

正确的起点是先问：我们到底有哪几类工作项？它们的生命周期本质区别在哪里？常见的合理拆分是三到五类：需求/用户故事、缺陷、技术任务、子任务、发布批次。类型定了，状态才有归属。

2. 第二层：画出正向主干与逆向回流

状态机的骨架是两条线，不是一条。

正向主干回答“正常情况怎么走”。我建议主干控制在 5-7 个状态，例如：待分诊 → 细化中 → 就绪 → 开发中 → 验证中 → 已完成。这条线要能让一个新人 3 分钟内记住。

逆向回流回答“异常情况怎么回来”。验证不通过怎么办？需求变更怎么办？主干被阻塞怎么办？很多状态设计的失败，就在于只设计了正向主干，没设计回流路径，于是一线只能自己发明，发明的方式通常是加一个新状态，或者干脆不回退。

3. 第三层：给每个状态写准入准出条件

这一步是把“标签”变成“契约”的关键。每个状态必须回答四个问题。

写不出来，就说明这个状态本身有问题。我通常会说：如果填不出进入和退出条件，这个状态就不应该存在。这一条能砍掉一半以上的冗余状态。

4. 第四层：为每个状态指定消费方

这是我在实践中加进去的一层，也是最有效的一层。每个状态必须明确写出“谁会消费它”，谁会因为这个状态的堆积而采取行动。

如果一个状态找不到消费者，它就没有存在理由。比如“待评审”，消费者是产品负责人，他每天要看一次；比如“待上线”，消费者是运维或发布经理。但如果某个状态三年没人因为它采取过任何行动，它就是一个数据坟场。

5. 状态命名的三条硬规则

命名听起来是小事，实际上是理解成本的直接来源。我坚持三条规则。

1. 用动名词或明确阶段，不用形容词。“处理中”含糊，“开发中”明确；“已完成”清楚，“已解决”模糊（谁解决的？解决了什么？）。
2. 状态名里不出现“待”字以外的部门名。“待财务”这种命名把人和状态绑死了，一旦职责调整，状态名就过时了。
3. 状态名长度控制在 4 个汉字以内。看板列宽有限，超过 4 个字会被截断，一线就会开始用简称，简称一出现，口径就开始漂移。

6. 配置示例

把上面这些落成可执行的配置，大概是这个结构。这是一个研发需求类型的简化状态机定义，实际使用时可以直接映射到主流项目管理平台的 工作流配置里。

work_item_type: 研发需求
states:

id: triage

name: 待分诊

entry: 提交人已填写业务价值、影响范围、期望时间

exit: 产品负责人完成类型判定与优先级初判

owner: 产品负责人

sla: 2 个工作日

consumer: 产品负责人 / 需求提交人

id: refining

name: 细化中

entry: 已判定为需求，且进入本季度候选池

exit: 验收标准、依赖项、技术方案要点已明确

owner: 产品经理

sla: 5 个工作日

consumer: 产品经理 / 研发负责人

id: ready

name: 就绪

entry: 验收标准齐备、依赖已确认、工作量已评估

exit: 被排入某个迭代

owner: 研发负责人

sla: ，

consumer: 迭代计划会

id: developing

name: 开发中

entry: 已排入当前迭代且开发已实际开始

exit: 代码合并主干、自测通过、已提交测试环境

owner: 研发负责人

sla: 按迭代周期，超期 20% 触发预警

consumer: 研发负责人 / 项目经理

id: verifying

name: 验证中

entry: 已部署到测试环境并完成冒烟

exit: 测试用例通过率 100% 且验收标准逐条确认

owner: 测试负责人

sla: 3 个工作日

consumer: 测试负责人 / 产品经理

id: done

name: 已完成

entry: 验证通过且验收标准逐条确认

exit: 无需退出（终态）

owner: 产品经理

sla: ，

consumer: 全部下游

id: blocked

name: 已阻塞

entry: 存在明确外部依赖且无法在 1 个工作日内自行解决

exit: 依赖解除，回到阻塞前的状态

owner: 项目经理

sla: 1 个工作日必须给出解除计划

consumer: 项目经理 / 管理层

transitions:

正向主干: triage -> refining -> ready -> developing -> verifying -> done

逆向回流: verifying -> developing （验证不通过）

阻塞旁路: any -> blocked -> 原状态

禁止跳转: triage 直接到 developing，ready 直接到 done

这段配置里最值得注意的是最后三行。明确写出“禁止跳转”，比写出允许跳转更重要。因为流程失控从来不是因为跳转不够多，而是因为跳转太自由。

五、案例与数据观察：一个 130 人组织把状态从 19 个收敛到 7 个

下面这个案例是我全程参与的一次状态治理，数据来自改造前后的实测导出，观测窗口是改造前 4 周和改造后 8 周，剔除了春节假期的影响区间。

1. 改造前的基线

组织规模 130 人，研发 82 人，分 3 条产品线，共同使用一套项目管理平台。改造前的状态情况是：研发需求 19 个状态，缺陷 11 个状态，跨类型混用严重。

具体症状包括：三个产品线对“已完成”的定义不同，A 线认为提测即完成，B 线认为上线才算；测试团队每周花约 6 小时人工核对状态；管理层周报里的“在途需求”有 3 个版本的数字。

2. 改造动作

我们做了四件事，顺序很重要。

1. 先做状态盘点，不做任何删除。导出过去 90 天所有状态的实际流转量，做了一个排序表。结果很震撼：19 个状态里有 7 个在 90 天内的流转量低于 5 次。
2. 再做状态映射，把 19 个映射到候选的 7 个。这一步必须让各产品线的人自己在同一张表上填，而不是由治理小组单方面决定。争议最大的是“验收中”和“待验收”，最终合并为“验证中”，但加了子状态标签来区分。
3. 然后写准入准出条件，逐条过。这一步花了整整两个半天，但它是整个改造中价值最高的部分。因为很多争议在写条件的过程中自然消解了。
4. 最后做数据迁移与冻结。冻结期间禁止任何新状态，为期 6 周，之后由项目经理统一受理变更。

3. 改造后的观测数据

改造完成 8 周后，我们对比了几组关键指标。

这里我要特别说明一点：交付周期从 19.4 天降到 16.1 天，并不是因为大家干活变快了，而是因为等待和澄清的时间变少了。状态边界的清晰，直接减少了两类浪费：一是任务在模糊态里悬停的时间，二是人在会议里对数的时间。

4. PingCode 在这次治理里承担了什么

这个组织最终选择用 PingCode 来承载改造后的状态机，我梳理一下它在这个场景里实际起作用的能力，而不是泛泛地讲功能列表。

第一，工作项类型与状态机的解耦配置。改造后他们有三类工作项（需求、缺陷、技术任务），每类独立配置状态机和流转规则。这一点很关键，因为把缺陷和需求塞进同一套状态，是前面提到的第一层误区。PingCode 允许按类型独立定义状态、流转规则和字段，这让“类型先行”的方法论真正落得下去。

第二，流转规则的强制约束。改造中他们设置了“禁止从待分诊直接跳到开发中”这类硬约束。这一条在纸面上容易写，在工具里如果实现不了，一线照样会绕过去。

第三，私有化部署与数据可控。这个组织属于受监管行业，流程数据和客户信息不能出内网。PingCode 支持私有化部署，这是他们选型的硬门槛之一，也让状态停留时间这类敏感度量可以直接在内部做深度分析，不必担心数据外流。

第四，从 Jira 平滑迁移。他们原来用的是 Jira，历史数据有近 4 年的积累。迁移最怕的不是数据搬不过来，而是状态映射搬错，旧状态和新状态如果映射关系混乱，历史数据的连续性就断了，前面所有的度量基线都作废。PingCode 在这块提供了迁移支持，他们把原来的 19 个状态做了映射表，迁移后历史任务的流转记录依然可追溯，这是这次改造能算清“改造前基线”的前提。

我特别想强调一点：工具能解决的是“执行一致性”和“数据可追溯”，解决不了“状态该有几个”。后者永远是管理决策，不是产品功能。把状态设计外包给工具默认模板，是我见过最贵的偷懒。

5. 这个案例里最容易被忽略的一点

改造完成后三个月，我回访了一次。他们又新增了 2 个状态，但这次是走评审流程加的，而且同步更新了准入准出条件和消费方说明。

我一点都不觉得这是失败。一个健康的状态体系不是永远不增长，而是每一次增长都有据可查、有据可退。真正危险的不是状态变了，而是状态变了却没人知道为什么变、变了之后谁来负责。

六、分场景行动建议：不同规模组织的落地方案

状态设计没有通用答案，规模不同，方案的重心完全不同。我按四种规模给出可直接执行的建议。

1. 20-50 人：一张白纸，最少的状态

这个阶段最大的风险是过早复杂化。我建议需求类的状态控制在 5 个：待办、进行中、待验证、已完成、已取消。

这个阶段不需要跨部门审批状态，不需要子状态，不需要为每条业务线定制。如果要区分“等待外部依赖”，用一个标签就够了，不要新增状态。

核心判断：这个阶段状态的价值是“让人不迷路”，不是“让报表好看”。任何为报表服务的状态都该推迟到有专职项目经理之后再考虑。

2. 50-200 人：主干统一，局部自治

这个规模是最容易出现状态分裂的区间。多条业务线、多个小组开始有自己的习惯，如果不干预，12 个月内必然出现“同一个词，不同理解”。

我的建议是主干统一、局部自治：全组织统一 6-7 个主干状态，不允许任何团队增删；但允许团队在主干状态上附加标签或子状态，用来表达团队内部的细微差异。

关键在于：标签可以自由加，状态不能自由加。标签不影响主干度量，状态会影响。这个边界必须写进规范里，并且在工具里做成技术约束。

3. 200-1000 人：按工作项类型分层

到了这个规模，一套状态通吃已经不现实了。这时候必须按工作项类型分层：需求一套状态机、缺陷一套、技术任务一套，各自的复杂度和流转规则可以不同。

同时要建立状态治理机制。我在这个规模的组织里通常建议三件事：每季度一次状态审计（调用量低于阈值的状态进入观察名单）；设立状态变更评审（由项目管理办公室或类似角色受理）；明确废弃流程（连续两个季度零流转的状态强制下线）。

这个阶段也是引入平台化工具性价比最高的阶段。因为流程复杂度已经超过手工管理的边界，而组织又还没有大到需要自研。PingCode 这类面向中大型企业的平台，在这个区间能提供的最大价值不是功能多，而是让复杂流程的约束可以被强制执行，同时保持数据口径的统一。

4. 1000 人以上：状态治理成为常态职能

这个规模的组织，状态已经不是流程问题，而是数据治理问题。建议设立专门的角色或小组负责状态体系，并且把状态定义纳入数据字典管理。

关键动作包括：状态定义变更需要走正式的变更流程并公告；状态变更必须评估对下游报表和历史数据的影响；重大变更要做灰度，先在一个事业部试点再推广。

另外，这个规模要特别警惕反向问题：流程过度统一导致一线效率受损。不同业务的流程差异是真实存在的，强行用一套状态会逼出大量线下绕过行为。这时候正确的做法是允许“受控的多样性”，同一套状态语义，但可以有不同的流转规则集。

5. 90 天落地路线图

如果你现在要动手，我建议按下面这个节奏走。这是我实际用过三轮的节奏，改动过的地方主要在前两周的时长。

1. 第 1-2 周：盘点和取证。导出过去 90 天所有状态的流转量，做排序表；同时抽查 30 个历史任务，看流转路径是否可解释。这一步不做任何决策，只收集事实。
2. 第 3-4 周：定义工作项类型。确定有哪几类工作项，明确每类的生命周期边界。这一步通常需要 2-3 次会议，争议会集中在边界案例上。
3. 第 5-6 周：设计主干与回流。画出正向主干和逆向回流路径，确定状态总数。同时给出禁止跳转清单。
4. 第 7-8 周：写准入准出条件。逐个状态填写进入条件、退出条件、责任人、停留阈值、消费方。这一步最花时间，也最有价值。
5. 第 9 周：配置与试运行。在工具里配置状态机、流转规则和通知策略，选一个 20-30 人的团队试运行两周。
6. 第 10-11 周：历史数据映射与迁移。建立旧状态到新状态的映射表，逐条确认，然后执行迁移。这一步的严谨程度直接决定了你能不能算出改造前的基线。
7. 第 12-13 周：全面切换与冻结。全员切换，进入 6 周状态冻结期，期间不接受任何新增状态申请。
8. 第 14 周起：进入常态治理。开启季度审计、变更评审、废弃机制。

七、取舍清单：状态设计里的五组权衡

方法讲完了，但真正难的不是执行方法，而是在具体处境下做取舍。我把最常见的五组权衡列出来，每组给出我的倾向和前提条件。

1. 统一 vs 自治

统一的好处是度量可比、协作顺畅；自治的好处是贴合业务、一线不抵触。

我的倾向是：语义必须统一，集合可以自治。也就是说，“开发中”这个词在全组织必须是同一个意思，但不同团队可以有不同数量的状态。前提是，自治的团队必须自己承担度量口径不一致的后果，如果他们不需要跨团队报表，那就随便。

2. 精细 vs 采集成本

每多一个状态就多一份采集成本。我见过一个团队为了区分“等待内部依赖”和“等待外部依赖”加了两个状态，结果一年下来，统计这两类等待时间的分析只做过一次。

我的倾向是：先加标签，观察三个月，如果这个区分真的被反复使用，再升级为状态。标签到状态的升级路径要留好，但升级的门槛要设高。升级的前提通常是：这个区分被至少 3 个团队、每月至少 10 次地实际使用过。

3. 强制流转 vs 自由跳转

强制流转保证数据质量，但会在一线遇到特殊情况时变成阻碍，逼出线下绕过。

我的倾向是：主干强制，旁路自由。正向主干必须按顺序走，但允许“任意状态 → 已阻塞 → 回到原状态”这样的旁路，以及必要的逆向回流（验证不通过回到开发中）。同时明确规定哪些跳转是禁止的，并且要有技术手段兜底。

4. 状态即度量 vs 状态即协作

这是最根本的一组权衡。状态如果主要为度量服务，就要少而稳；如果主要为协作服务，可以多而灵活。

我的倾向是：先满足协作，再满足度量，但绝不用同一套状态同时满足两者。做法是主干状态服务协作，同时用标签或独立字段承载度量需要的维度。把这两件事塞进同一套状态，是前面所有混乱的总根源。

5. 一次重构 vs 渐进演进

一次性重构的好处是干净彻底，坏处是风险集中，一旦设计有误，整个组织的流程都会受影响。渐进演进的好处是风险分散，坏处是老状态会长期残留，形成双轨制。

我的倾向是：200 人以下一次重构，200 人以上渐进演进。200 人以下沟通成本低，一次做完反而更省事；200 人以上必须分批切换，但要有明确的完成时间点，否则双轨制会永久化。我见过最糟的情况是：新旧两套状态并行跑了 18 个月，两边的数据都不完整，最后的结论是“这套数据没法用”。

八、最后：状态是组织认知的一面镜子

我想用一个观察收尾。这几年我进过不少组织的流程现场，发现一个稳定规律：状态体系混乱的组织，通常不只是流程乱，而是对“谁负责什么”这件事本身就没有共识。状态只是把这个更深的问题暴露出来了。

反过来也成立。我在状态治理过程中最常见的场景是，两个部门的人为“验收中”到底该谁负责争了四十分钟。争到最后往往发现，争议根本不是状态定义，而是这个环节的责任边界从来没被正式确认过。状态设计之所以有价值，不是因为它整理了几个标签，而是因为它逼着组织把模糊的责任边界写清楚。

还有一个我越来越确信的判断：状态数量的多少，和组织的管理成熟度没有正相关，甚至在某些区间是负相关。成熟度高的组织，状态往往不多，但每个状态的边界极其清楚，责任人和阈值都写在明面上；成熟度低的组织，状态往往很多，多到没人能说清每一个的含义。

如果你现在准备动手，我建议下一步只做一件事：导出过去 90 天所有状态的流转量，做一个排序表。不用分析，不用讨论，就是把这个数字摆出来。我几乎可以保证，你会看到一批“僵尸状态”，它们在纸面上存在，但在现实里已经死了。看到这份表之后，你的团队会自己开始讨论哪些该留、哪些该删，而这个讨论本身，就是状态治理的开始。

等这份盘点表做完，再回头看第四节的四层漏斗和第六节的 90 天路线，你会发现它们不再是一套抽象方法，而是一份可以直接照着走的施工图。