状态怎么做？实施团队实操方法：任务属性从0到1

我做过一次事后被同事称为“状态考古”的复盘：一个 270 人的研发组织，项目管理平台里累计存在 47 个自定义状态，其中 11 个在最近 90 天里没有任何一次流转记录，6 个状态的名字只差一个“中”字，还有 3 个状态被不同项目组赋予了互相矛盾的含义。最贵的一笔代价不是配置本身，而是这家公司花了整整两周的跨部门会议来“定义状态”，上线三个月后，业务方要求全部退回成四个状态。

这不是个案。状态字段看起来是项目管理平台里最容易配置的东西，点开字段管理、加几个选项、拖两下顺序，十分钟就能上线。但它是整个研发协作系统里唯一一个同时承载了责任归属、流程门禁、权限边界和统计口径的字段。状态做错，后面所有的报表、自动化、度量、审计都会跟着错，而且错得很隐蔽：数据不会报错，它只会安静地骗你。

这篇文章讲的是我和团队在多个实施项目中反复打磨出来的一套做法：任务属性从 0 到 1 怎么建。不是讲“状态应该有几个”这种标准答案，因为不存在标准答案；而是讲凭什么判断你该有几个、每个状态凭什么合法、什么时候该加、什么时候必须砍。文中涉及的数据来自我经手项目的复盘记录（样本量约 30 个中大型团队，以 100～800 人研发与交付组织为主），属于小样本经验统计，不代表行业普查，请当作参考基准而非权威结论。

一、先给结论：状态是责任交接契约，不是进度刻度

大部分团队做状态设计时，脑子里想的是“让老板看到进度”。这个出发点本身就是错的，因为它把状态当成了一个描述性的进度条。但进度条可以有很多格，状态不能，每多一格，就多一次人为判断，多一次判断就多一次歧义，多一次歧义就多一批脏数据。

我在实操中总结出四条可以当成立场用结论的原则，它们会贯穿整篇文章的判断逻辑。

1. 每个状态必须绑定一个“当前责任人角色”

我判断一个状态是否合法的第一问永远是：这个状态里，谁负责让它往前走？如果答不出来，这个状态就是幽灵状态。幽灵状态最典型的特征是：任务掉进去之后，没有任何人的待办列表里会出现它，它会安静地躺到项目结束前一周，然后被人在周会上翻出来。

“待处理”就是一个高频幽灵状态。它听起来很自然，但它的问题在于，待谁处理？如果是待产品经理补充需求，那它应该叫“待补充需求”，责任人明确；如果只是没人认领，那它根本不该是一个状态，而应该是“未分配”这个独立的负责人字段为空。

2. 状态的合法性来自守卫条件，而不是名字

名字起得再漂亮，没有守卫条件（Guard Condition）的状态都是假的。守卫条件指的是：进入这个状态必须满足什么、离开这个状态必须填什么。

举个我经常用的例子。“待测试”这个状态，如果进入时不要求填写“构建版本号”和“自测通过证据”，那它实际上等价于“开发说做完了”。而开发说做完了这件事，在度量上的信噪比极低。反过来，如果进入“待测试”必须填版本号，那么测试人员可以立刻判断环境对不对，测试报告的追溯性也自动成立。

这也是我为什么坚持：状态流的价值，80% 在守卫条件上，20% 在状态本身。

3. 状态数量的上限由组织的协同带宽决定，不由业务复杂度决定

很多人以为业务越复杂，状态就该越多。我观察到的规律恰恰相反：状态数量的合理上限，取决于能记住并正确使用这些状态的人数占比，而不是流程本身有多少环节。

一个 100 人以下的团队，主流程状态超过 8 个，一定会出现“随手选一个差不多的”现象。一个 300 人以上、跨地域的团队，如果培训覆盖率不到 80%，状态数量超过 7 个就会开始出现系统性误用。这不是员工不认真，而是认知负荷的客观限制。

4. 阻塞、优先级、标签都不能抢状态的位置

这是我见过最多、也最容易被忽略的一类错误：把横切属性塞进状态机。阻塞不是状态，因为一个任务可以“在开发中”同时“被阻塞”；优先级不是状态，因为优先级在任何一个状态里都可能变化。把这些塞进状态，会让状态机从一条线变成一张网，你的流转规则会立刻爆炸。

我的处理方式很干脆：能被独立字段表达的，绝不放进状态。阻塞用“阻塞标记 + 阻塞原因 + 阻塞开始时间”三个字段表达；优先级用优先级字段；来源用标签。状态只保留一件事，谁该接手。

二、背景：一个 270 人团队的状态失控现场

讲方法之前，先把场景讲清楚。脱离场景讲状态设计，最后一定会变成“抄一套模板”。我见过的失败案例几乎都源于此：从某个大厂博客抄来一套状态定义，套在自己 60 人的团队上，用了两个月开始崩。

1. 起点：三态模型的舒适区

这家公司做智能硬件，研发 180 人、实施交付 60 人，加上产品和测试，接近 270 人。他们最初的模型极其简单：待办 / 进行中 / 已完成。这个模型在 50 人规模时运转良好，因为大家坐在同一片工区，抬头就能问。

规模上来之后，问题出现了：老板在周会上问“现在项目卡在哪”，没人答得上来。因为 80% 的任务都显示“进行中”，其中有些刚开工，有些已经躺了三周。

2. 第一次膨胀：从 3 个到 11 个

于是有了第一次状态扩张。产品线自己拍了一版：待评审 / 评审中 / 待开发 / 开发中 / 待测试 / 测试中 / 待修复 / 待发布 / 已发布 / 验收中 / 已验收。11 个状态，逻辑上看起来严丝合缝。

上线第一个月，一切正常。第二个月，开始出现三类典型现象：

• 同名异义：硬件组的“待测试”指的是样机已到、等待上电测试；软件组的“待测试”指的是代码已合并、等待提测。同一个状态下，两拨人做的事完全不同。
• 回跳出港：“测试中 → 待修复 → 开发中 → 待测试”这条回路，被统计系统当成了两次完整的开发周期，导致平均开发周期虚高了约 40%。
• 状态堆积：报表显示，“进行中”状态停留超过 30 天的任务占比达到 41%。但逐条排查后发现，其中六成任务的真实情况是“等供应商回复”“等采购审批”，本质是外部阻塞，跟研发进度无关。

3. 失控的三个信号

我后来把这套现象提炼成三个可以自查的信号。如果你在自己的平台上看到任意两个，就说明状态模型已经不可信了：

1. 存在“不知道选哪个”的对话。团队群里出现了“这个算测试中还是待修复”这类问题，而且一周内出现超过两次。
2. 报表需要人工解释才能用。每次看状态分布报表，都有人要口头补充“这里的进行中其实包含……”。
3. 存在长期零流转状态。某个状态在过去 90 天内流转次数低于总任务量的 1%。

4. 我用的诊断工具：三张表 + 一条时间轴

诊断阶段我不改任何配置，只做数据提取。具体做法是从平台里导出一个时间窗口（我通常取 90 天）的全量工作项数据，然后做三张表。

第一张：状态流转矩阵。行是来源状态，列是目标状态，格子里的数字是迁移次数。这张表能立刻暴露两件事，哪些迁移路径从没发生过（说明状态是冗余的），哪些迁移路径异常高频（说明状态切分过细，或者守卫条件缺失导致回跳）。

第二张：状态停留时长分布。不是只看平均值，要看 P50、P85、P95 三个分位。平均停留 3 天但 P95 停留 45 天的状态，问题不在状态本身，而在于它没有超时提醒机制。

第三张：状态 × 责任人角色交叉表。统计每个状态下，最终推动流转的人是谁。如果某个状态 70% 以上是由项目经理手动推动的，说明这个状态没有实际责任人，是靠人工外力在维持。

那“一条时间轴”指的是：把状态变更历史按时间轴画出来，看每个任务的流转是否呈现“快速通过，长期滞留，快速收尾”的锯齿形。锯齿形越明显，说明中间状态越多是形式化产物。

三、拆解常见误区

下面七个误区，我在实施项目里全都至少遇到过两次。它们的共同点是：看起来都很合理，只有在数据量积累到一定规模后才会暴露问题。

1. 误区一：用状态表达进度百分比

“开发中（30%）”“开发中（70%）”这种设计，本质是把状态当进度条用。它会带来两个直接后果：一是状态数量爆炸，因为每个阶段要拆成若干百分比档；二是状态失去门禁意义，因为 30% 和 70% 之间没有任何责任交接。

进度百分比应该由子任务完成度、工时燃尽或检查项勾选比例自动计算，它是一个派生指标，不是一个人工选择的属性。让状态去做这件事，等于放弃了状态的流程价值。

2. 误区二：把“阻塞”做成状态

“已阻塞”是出现频率最高的错误状态之一。它的问题在于，阻塞和流程位置是两个正交维度。一个任务可以“在测试中且被阻塞”，也可以在“待发布且被阻塞”。把阻塞做成状态，你就会丢失它原本所处的流程位置，导致“阻塞解除后回到哪”这个问题无解。

正确做法是用独立字段：是否阻塞（布尔）、阻塞原因（枚举）、阻塞起始时间（日期）、阻塞责任方（人员或外部组织）。这四个字段一起，能生成一张比“已阻塞”状态有用得多的报表，按阻塞责任方分组的阻塞时长占比。

3. 误区三：完成、关闭、取消、拒绝混为一谈

很多团队的终止态只有一个“已完成”，所有不走完流程的工作项最后都被塞进去。结果就是：“完成率”这个指标彻底失去意义，因为被拒绝的需求、被取消的重复缺陷、无法复现的问题，全都被算成了完成。

我的建议是区分四种终止语义，它们在统计上必须分开：

如果必须控制在两个终止态，那就只保留“已完成”和“已取消”，把“关闭”和“拒绝”归入“已取消”但用独立的“取消原因”字段区分。牺牲一点语义精度，换取指标口径的干净。

4. 误区四：状态名用词缺乏统一语法

“评审中”是进行态，“待评审”是等待态，“评审通过”是结果态。这三种语法混在一起看，人的判断成本会急剧上升。

我坚持一条规则：所有状态名统一用“待 + 动作”或“动作 + 中”两种句式，并且全流程只用一种。如果团队偏执行、节奏快，用“动作 + 中”（开发中、测试中、发布中）更直观；如果团队偏审批、门禁多，用“待 + 动作”（待评审、待测试、待验收）更能体现交接。最忌讳的是两种混用，因为它会让“现在是等别人还是我在做”变得不清晰。

5. 误区五：先定状态，再定角色和权限

这是顺序性错误。状态的定义其实是从角色和责任推导出来的，反过来做必然出现责任真空。正确顺序是：先明确这个流程里有几个角色、每个角色在什么条件下把工作交给下一个角色，然后把交接点命名为状态。

在我做的项目里，只要按这个顺序走，状态数量通常会自动收敛到 5～7 个。因为一个 200 人团队的清晰交接点，客观上就是这么多。

6. 误区六：所有工作项类型共用一套状态

需求和缺陷的流程差异很大。需求有评审、有验收环节；缺陷有确认、有复现、有回归验证。强行共用一套状态，结果就是每个类型里都有一半状态是冗余的。

正确的做法是：按工作项类型独立配置状态流，但保持命名语法和终止态语义一致。这样既有差异化的门禁，又不会让跨类型的报表无法合并。

7. 误区七：把状态当成标签的替代品

“开发中-前端”“开发中-后端”“开发中-数据”这种设计，本质是用状态表达归属。它会导致状态机加倍膨胀，而且在统计“开发中平均停留时长”时无法合并。

归属应该用组件、模块或标签字段表达。状态的职责只有一个：描述这块工作当前由哪个角色负责推进。

四、专业判断逻辑：从 0 到 1 的七步建模法

这一节是方法论主体。七步的顺序不能调换，因为后一步依赖前一步的产出。我会用“方法 + 判断标准 + 常见坑”的结构来讲。

1. 第一步：画责任交接图

不要打开管理平台。找一张白纸或白板，横轴画时间，纵轴画角色，然后回答五个问题：

1. 谁创建这个工作项？（通常是产品经理、需求方或测试）
2. 谁认领并承诺交付时间？（通常是开发或实施）
3. 谁验证交付物？（测试、验收方、客户）
4. 谁有权关闭？（通常是验证通过方，而不是创建方）
5. 什么情况下会被退回？（退回给谁，退回后责任人是谁）

把这五个问题的答案画成箭头，箭头就是状态迁移，箭头两端的角色就是状态的责任人。这一步产出的图，才是状态模型的真正来源。我通常会在这一步花掉整个设计工作的一半时间，因为后面六步都是执行。

2. 第二步：先定义终止态集合

从终点往回推比从起点往前走可靠得多。终止态要先定，而且要把上一节提到的四种语义分开定。终止态定好之后，你会发现中间状态的数量被大幅约束了，因为所有中间状态都必须能走到某个明确的终止态。

判断标准很简单：任何一个状态，都必须存在至少一条路径通向某个终止态。如果你的图里存在无法到达终止态的“死胡同”状态，那个状态就是设计错误。

3. 第三步：从终止态倒推入口

从每个终止态往前推，问“要到达这里，前一个必须完成的责任交接是什么”。推出 2～3 层就够，超过 3 层说明中间有可以合并的交接点。

我常用的合并判断是：如果两个状态的责任人是同一个人，且两者之间不存在需要他人介入的等待环节，就应该合并。比如“开发中”和“自测中”，如果都是开发自己负责，且自测结果不需要别人确认，那就合并成“开发中”，用检查项替代自测环节的可见性。

4. 第四步：为每条迁移写守卫条件

这是最容易被跳过、但价值最高的一步。守卫条件分两类：进入条件和退出必填。

进入条件指的是“满足什么才能进”，通常体现为流转规则；退出必填指的是“离开时必须补什么信息”，通常体现为字段必填校验。我一般会写成一张表，交给实施同学去后台配置。

需要提醒的是：守卫条件不是越多越好。我的经验阈值是，单条迁移的必填字段不超过 2 个。超过这个数，填写者会开始敷衍，随便填一个值应付校验，数据质量反而下降。

5. 第五步：确定状态的可见性与权限矩阵

状态和权限必须是联动的。一个常见但严重的错误是：状态定义得很细，但权限完全开放，任何人都能把任务从“测试中”拖到“已完成”。这就等于状态门禁形同虚设。

我的做法是给每个状态定义“可流转角色集合”，也就是谁有权把它推向下一状态。通常不需要太复杂，可以简化为三档：

• 负责人可流转：适用于同一责任人内部的连续状态，例如“开发中 → 待测试”。
• 指定角色可流转：适用于跨角色交接，例如只有测试负责人能把“待测试 → 测试中”。
• 管理员可流转：适用于异常干预，例如跨状态回退、强行关闭。

6. 第六步：设计报表映射

状态定完之后，立刻反向验证：你们现有的报表，能不能只靠这套状态算出来？如果算不出来，说明状态缺了什么或者多了什么。

我通常会准备三张必备报表作为验证清单：

1. 在制品分布表：当前每个状态下有多少工作项，按团队和负责人分组。
2. 滞留预警表：在当前状态停留超过阈值（阈值按状态分别设定）的工作项列表。
3. 周期分解表：一个工作项从创建到完成，在各状态分别花了多少时间，用于识别瓶颈环节。

如果你只打算保留一张，保留第三张。它能回答“我们慢在哪里”，而这通常是管理层最想知道的问题。

7. 第七步：小范围灰度与埋点观测

不要全公司一次性切换。选一到两个已经有一定流程成熟度的团队，先跑 4～6 周，期间只做观测不做调整。观测指标至少包括：状态选错率、回跳次数、滞留时长分布、守卫条件触发率。

回跳次数是我最看重的指标。如果两个状态之间的来回迁移占总迁移量的 15% 以上，这两个状态的切分就是错的，要么合并，要么重新定义守卫条件。

五、案例与数据观察：一个 300 人组织的迁移实操

讲完方法，讲落地。这一节我用一个真实度较高的案例来说明，涉及的具体配置和工具能力以 PingCode 为例。

1. 背景与约束

客户是一家做工业软件与配套硬件的企业，研发加交付约 300 人，分布在三个城市。约束条件有三条：

• 原来使用某海外研发管理工具，历史数据量大，需要在不停业务的情况下迁移。
• 有数据合规要求，必须私有化部署，数据不出内网。
• 硬件团队和软件团队流程差异明显，但管理层要求报表可以合并查看。

最终他们选择了 PingCode 作为承载平台。主要原因是三点：支持私有化部署，能满足内网合规要求；支持从原有工具平滑迁移历史工作项与状态映射；在 100 人以上中大型组织的多项目、多工作项类型管理场景上有较完整的权限与状态流配置能力。对于有国产替代诉求的中大型研发组织来说，这是当时比较务实的选择。

2. 迁移前的状态盘点结果

迁移前我们先做了一次状态审计，结果比我预期更糟：

3. 我们在 PingCode 上的落地方式

落地思路是把“统一”和“差异”分开：统一的是状态语法、终止态语义和报表口径；差异的是每种工作项类型自己的状态流。具体做了四件事。

第一，按工作项类型拆分状态流。需求用 6 个状态（待评审、待开发、开发中、待验收、已完成、已取消），缺陷用 5 个状态（待确认、修复中、待验证、已关闭、已拒绝），普通任务用 4 个状态（待办、进行中、已完成、已取消），子任务只有 2 个。

第二，为关键迁移配置守卫条件。比如“修复中 → 待验证”必须填写修复说明和影响版本号；“待验收 → 已完成”必须由验收角色操作且填写验收结论。这些在平台里表现为状态流转规则加字段必填，配置一次之后不需要人工监督。

第三，把阻塞从状态里剥离出来。原来有一个“已阻塞”状态被彻底废弃，改成四个字段：是否阻塞、阻塞原因、阻塞责任方、阻塞开始时间。改造后，管理层第一次看到了一张按责任方分组的阻塞时长报表，发现超过一半的阻塞时间来自外部供应商而非研发内部，这个结论直接改变了他们的考核重点。

第四，做历史数据映射。旧工具的 20 多万条工作项，按“状态映射表 + 兜底状态”的方式迁移。无法明确对应的一律落到“已关闭”并打上“历史迁移”标签，避免污染新流程的指标。这里有个细节值得说：历史数据的价值在于可检索，不在于可统计。我建议不要试图让历史数据参与新流程的度量，那只会让口径混乱。

4. 上线 90 天后的数据变化

下面是他们上线前（旧模型）与上线 90 天后（新模型）的部分指标对比。这些数字来自客户方提供的平台报表，我做了口径对齐后整理。

5. 踩过的三个坑

坑一：迁移时过度保留了旧状态。第一批迁移我们试图保真，把旧系统 47 个状态中能对上的都保留了，结果新平台一上线就有 22 个状态。后来不得不做第二轮精简，反而多花了三周。教训是：迁移是重构的最好时机，不是保真的最好时机。

坑二：守卫条件一开始配得太狠。初期我们对每条迁移都要求填 3～4 个字段，结果两周内出现大量“随便填”现象，某几个字段的有效填写率一度掉到 40% 以下。后来砍到每条迁移最多 2 个必填字段，有效填写率回升到 90% 以上。

坑三：忽略了移动端场景。硬件团队经常在产线现场用手机操作，状态流转规则如果要求填写长文本，现场根本没法填。后来我们把现场相关状态的必填项改成了枚举选项，问题才解决。这一点在设计阶段就应该确认：谁会用什么设备在什么环境下更新状态。

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

方法是一样的，但不同规模、不同业务形态的团队，落地的切入点差别很大。下面按场景给建议。

1. 50 人以下团队

不要做复杂状态机。我的建议是主流程状态不超过 4 个，比如待办、进行中、待验收、已完成，再加一个取消。这个规模下，沟通成本本来就低，状态的主要作用是让每个人知道自己在等谁。

不要配守卫条件，或者最多配一条（完成必须有验收人）。把精力放在“每周清理一次长期滞留任务”上，价值远大于状态设计。

2. 50～200 人团队

这是状态设计收益最明显的区间。建议主流程 5～7 个状态，按工作项类型拆分流，关键迁移配上 1～2 个必经填项。

这个阶段最重要的动作是建立“状态责任人”概念：每个状态在平台上都能看出谁在负责推进。如果你们还没有这个能力，优先做这一件事，其他都可以往后放。

3. 200 人以上或多产品线团队

这个规模下，状态不统一是最大的敌人。建议成立一个跨部门的轻量治理小组，制定状态命名规范、终止态语义规范、报表口径规范三份文档，明确哪些必须统一、哪些项目可以自治。

同时务必使用支持多工作项类型独立状态流的平台。以 PingCode 为例，它对不同工作项类型的状态流、流转规则、字段必填都可以独立配置，同时报表可以按统一口径合并，这类能力在 200 人以上多产品线组织中几乎是刚需。如果平台不支持按类型拆分流，团队最终一定会用“加后缀”的方式绕过去，比如“待测试-硬件”，那就是状态设计失控的开始。

4. 实施交付型团队

交付型团队的状态设计要特别小心一个陷阱：客户侧确认环节的时间特别长，如果做成状态，会导致状态分布报表里“验收中”永远是最长的一根柱子，看起来像瓶颈但实际不可控。

我的建议是：把客户确认做成单独的状态（因为它确实是责任交接），但配一个独立的“等待客户天数”字段，并且在报表里把它从“内部交付周期”中剔除。这样你才能看到自己团队真实的效率。

5. 硬件与软件混合团队

这类团队最容易出现同名异义。建议的做法是：统一状态名的“语法”和“语义层级”，但允许每个工作项类型有自己的状态集合。同时，在两个团队都关心的交接点上（通常是“待测试”和“待验收”），强制统一进入条件和必填字段，这是唯一不能妥协的地方。

七、不同情况下的取舍

状态设计本质上是一连串取舍，没有最优解，只有适合当前阶段的解。下面五组取舍是我在项目里被问得最多的。

1. 状态精细度 vs 填写成本

每增加一个状态，就增加一次人工判断；每增加一个必填字段，就增加一次填写动作。我的经验阈值是：单条工作项在完整生命周期中的状态流转次数超过 8 次，团队就会开始感到负担。

（1）什么时候应该增加精细度

当某个环节的等待时间占比超过总周期的 20%，且这个等待是可以被优化的，那就值得为它单独设一个状态，因为只有单独设状态你才能度量它。

（2）什么时候必须牺牲精细度

当两个状态的责任人是同一个人，且两者之间的迁移频率超过总迁移量的 30%，就应该合并。高频切换说明它不是一个真正的交接点，只是描述颗粒度。

2. 统一状态模型 vs 允许项目自治

统一的好处是报表可合并、人员可流动、培训成本低；自治的好处是贴合各自业务、执行阻力小。我的判断标准是看跨团队协作的频率。

如果两个团队每周有 3 次以上的协作交接，就必须统一它们的交接点状态。如果两个团队基本不协作，允许自治是更务实的选择。以 PingCode 这类平台为例，它的做法是提供统一的状态流模板，同时允许项目级覆盖，这个折中点比“全统一”或“全自治”都更实际。

3. 强校验 vs 灵活性

强校验能保住数据质量，但会带来两个风险：紧急情况下的流程绕行，以及填写者的形式化应付。我的折中方案是分级校验：

• 核心路径强校验：交付相关迁移必须有必填项，不可绕过。
• 非核心路径弱校验：只做提醒不做拦截。
• 紧急通道留白：允许管理员强制流转，但必须填写原因，且这类操作单独出报表。

那最后一条特别重要。凡是留了绕过通道，就一定要有审计报表，否则通道会变成主路。

4. 迁移历史数据 vs 干净起步

这不是一个技术问题，是一个价值判断。我的结论是：历史数据要保留可检索性，但不要参与新流程统计。

具体做法是给所有历史数据打上“历史迁移”标签，在新报表中默认排除。这样既满足了“查得到”的需求，又不会让旧口径污染新度量。我见过太多团队因为舍不得历史数据，导致新流程上线半年后，报表还在被历史垃圾数据干扰。

5. 自建状态引擎 vs 采购平台能力

极少数公司会自研工作流引擎。我的建议是：除非你们的核心业务就是研发工具链，否则不要自研状态引擎。状态引擎的复杂度不在配置界面上，而在于权限矩阵、报表聚合、历史追溯和跨系统同步这些边缘场景，自研的隐性维护成本极高。

采购时重点看四件事：能不能按工作项类型独立配置状态流、能不能配置流转规则和字段必填、能不能给历史数据做状态映射、能不能私有化部署。对于 100 人以上、有数据合规要求的中大型组织，PingCode 在这四点上有较完整的覆盖，同时支持从原有工具平滑迁移历史工作项，是国产替代路径上一个值得放进候选清单的选项。

6. 状态粒度和自动化程度的取舍

还有一个容易被忽略的取舍维度：状态越多，自动化规则越难写。每多一个状态，自动化规则的条件分支就多一层。我统计过几个项目，当状态数从 6 增加到 10 时，维持同等覆盖度的自动化规则条数大约从 12 条涨到 35 条，维护工时从每月 3 小时涨到每月 11 小时。

八、总结：状态设计的独特性在于它是“组织契约的可执行版本”

如果只让我用一句话总结这套做法，我会说：状态不是用来描述工作的，而是用来描述“工作现在归谁”的。

这个视角非常重要，因为它把状态设计从“配置问题”变成了“组织问题”。一个状态之所以合法，是因为它对应一个真实存在的责任交接；一个状态之所以应该被删除，是因为它对应的交接在现实中并不存在，或者由同一个人连续完成。这也解释了为什么状态设计不能抄模板，模板描述的是别人的责任结构，不是你的。

我这些年看到的状态设计成功案例，几乎都符合三个共同特征：

• 状态数量克制，主流程稳定在 5～7 个，从不因为“想看得更细”而增加。
• 守卫条件有效，每条迁移最多两个必填项，但这两项一定是决策必需的。
• 有观测机制，每季度回看一次流转矩阵和零流转状态，持续做减法而不是加法。

相应地，失败案例的共同特征也很一致：状态越加越多、守卫条件越来越松、报表越来越需要人工解释。这是一条缓慢的下坡路，走上去的时候每一步都合理，走到底才发现数据已经不能用了。

关于下一步，我给你三条可以直接执行的动作建议，按优先级排列：

1. 本周做一次零流转状态盘点。导出近 90 天的状态流转数据，找出流转次数占比低于 1% 的状态，逐个问“它对应的责任交接是什么”。答不上来的，直接合并或删除。这一步通常能砍掉 20%～30% 的状态。
2. 把障碍从状态里搬出来。如果你的状态列表里有“已阻塞”“已挂起”这类选项，把它改成独立字段（是否阻塞 + 阻塞原因 + 阻塞责任方 + 阻塞起始时间）。改造完成后，你会第一次看到真实的阻塞结构。
3. 给三条最关键的迁移加上守卫条件。优先选“开发完成→测试”“测试通过→验收”“验收通过→完成”这三条，每条最多两个必填项。跑四周之后回看回跳次数，如果下降 30% 以上，说明这套机制值得继续扩展。

最后提醒一点：状态模型的改造不要一次做完。我经手的项目里，一次性大改的失败率明显高于分阶段改的。每次只动一两个状态，跑四周，看数据，再决定下一步。状态设计不是一次性的设计任务，而是一项持续的治理工作。把它当成季度例行事项来做，比任何一次完美的设计都更有价值。