阶段状态管理方法大全：产品经理项目阶段制度设计落地清单

我见过最离谱的一个项目阶段看板，上面挂着 19 个状态：需求评审中、需求评审通过待排期、已排期待拆分、拆分完成待开发、开发中、开发自测中、提测中、测试中、测试打回、测试通过待验收、验收中、验收打回、待发布、灰度中、灰度观察期、全量发布、上线待复盘、已复盘、已关闭。这个看板属于一家 260 人规模的 SaaS 公司，产品线只有两条。

结果是：状态越细，团队越不知道下一步该干什么。项目经理每天要花近两个小时手动改状态，季度复盘时我发现 38% 的卡片状态与实际情况不符，开发说”已经提测了”，卡片还停在”开发自测中”；测试说”这个需求被打回两次了”，卡片只记录了最后一次”测试通过”。

阶段状态管理从来不是”把流程画得更细”的问题，而是在什么节点、用什么证据、由谁来判断项目是否可以往前走的问题。这篇文章我把过去几年在 9 个研发团队做状态体系改造的复盘记录整理出来，包括设计逻辑、踩过的坑、可执行的清单，以及在不同组织规模下该怎么取舍。

一、先给结论：阶段状态管理的五条硬判断

在展开细节之前，我把最核心的判断放在前面。如果你只读一段，读这一段就够了。这五条是我在多次改造中反复验证过的，凡是违反其中某一条的方案，最后都会以某种形式崩掉。

1. 阶段管”承诺”，状态管”事实”

阶段（Phase）回答的是”我们现在答应做到哪一步”，它是管理层的沟通语言，相对稳定，一个季度内不应该频繁变。状态（State）回答的是”这张卡片此刻真实的处境”，它是执行层的操作语言，每天都在变。

把这两者混在一起，就会出现”阶段完成了 80%”这种没法验证的表述。阶段必须是离散的、可判定的，状态必须是实时的、可自动采集的。

2. 状态数量的上限由”新人 30 秒能否说出下一步”决定

不是由流程完备度决定。我做过一个小测试：把团队的状态清单给一个入职两周的新人看，让他在 30 秒内说出”一个开发中的需求，下一步该做什么”。超过 9 个状态的清单，回答正确率从 90% 掉到 40% 以下。

这个测试很粗糙，但它指向一个真实的认知约束：工作流状态是给人看的，不是给流程图看的。超过 9 个状态，就需要额外的”状态说明文档”，而一旦需要文档，状态就已经失败了。

3. 没有退出条件的状态，等于没有状态

这是我最常看到的缺陷。”测试中”这个状态，什么条件下可以离开？谁来判定？如果答案是”测试觉得可以了”，那就是没有退出条件。

合格的退出条件必须同时具备三要素：可观察的证据（用例通过率、缺陷遗留数、评审记录）、明确的责任角色（不是具体某个人，是角色）、时间窗口（超过 X 天未流转自动标黄）。

4. 状态数据必须自动留痕，人工填报的可信度会随时间衰减

我对比过两类团队的数据：一类要求成员每天手动更新状态，一类让状态跟随代码提交、构建流水线、测试执行自动流转。三个月后，前者的状态准确率从上线初期的 85% 掉到 52%，后者稳定在 90% 以上。

原因不复杂：手动更新的成本会被压缩，而压缩的方式就是”事后补录”。补录的数据永远是对的，也永远不是真的。

5. 阶段门禁的价值在于”提前暴露风险”，不在于”卡住谁”

很多团队把门禁做成了审批关卡，结果是所有人都在想办法绕过它。真正的门禁应该是一面镜子：进入下一阶段之前，系统自动把”你还没准备好的三件事”摆在你面前，让你自己决定。

二、背景与真实场景：一次”阶段全绿、交付全红”的复盘

上面那些结论不是坐在办公室里推出来的。它们的起点是一次很难看的项目复盘，我把它完整还原出来，因为它几乎浓缩了所有阶段状态管理的失败模式。

1. 场景还原

2022 年，我深度参与了一家 B 端 SaaS 公司的研发流程改造。当时他们有 3 条产品线、约 280 名研发人员，用的是自研的一套项目管理系统，状态字段是各团队自己配的，产品线之间互不兼容。

4 月的一次季度评审会上，三个产品线的项目阶段看板全部是绿色。P0 需求的阶段状态显示”待发布”或”灰度中”。但到了 6 月底，实际交付到客户手里的功能只有计划量的 61%，其中有两个 P0 功能延期了 47 天。

评审会现场我问了一个问题：“待发布”这个状态，平均停留了多久？没人答得上来。因为系统里根本没有状态变更的时间戳，只记录了当前值。

2. 我复盘出的三个根因

第一个根因是状态定义只写名字不写条件。翻遍当时的状态说明文档，12 个状态里只有 3 个写了退出条件，而且都是”XX 完成”这种无法验证的表述。

第二个根因是状态流转靠人推。开发改完自己改成”开发完成”，测试开始测了自己改成”测试中”，谁都不需要提供任何证据。状态变成了主观声明，而不是客观事实。

第三个根因是阶段与状态没有映射关系。”待发布”到底是属于”开发阶段”还是”发布阶段”？没人说得清，所以统计口径每隔一段时间就变一次，历史数据没法纵向比较。

3. 为什么产品经理天然倾向于”多设状态”

这一点我想单独说，因为它不是能力问题，而是激励机制问题。

产品经理的考核里通常有一条”需求交付及时率”。当交付延期时，最省力的应对方式不是解决阻塞，而是在流程里插入一个中间状态，把”延期”重新定义为”正在推进”。

“开发中”延期了，就加一个”开发完成待联调”；联调延期了，再加一个”联调完成待提测”。状态越加越多，报表上的红色越少，真实交付时间一点没变。

我在三个团队里都观察到过这个模式，它的副产品是状态清单只增不减。没人敢删状态，因为删掉就意味着承认那段历史是”假的”。

三、拆解七个常见误区：把状态管理做废的典型动作

下面这七个误区，我几乎在每一个做状态体系改造的团队里都能见到至少四个。它们不是孤立的错误，而是有因果链的：一个误区会催生下一个。

1. 用状态代替沟通

把”沟通清楚了”这件事寄托在状态变更上，是很多团队的隐性假设。于是出现”我改了状态就代表通知了”的现象，跨职能的协同反而更差。

状态是沟通的索引，不是沟通的替代品。它可以告诉你”该找谁了”，但它永远无法替代”找他干什么”。

2. 状态名称用动词而非结果

“开发中””测试中””评审中”，这类名称描述的是动作，不是结果。动作没有完成标准，所以无法判定何时可以离开。

把”开发中”改成”代码已合并主干”，把”测试中”改成”用例执行完成且阻塞缺陷清零”，状态立刻变得可判定。命名方式的改变会强制你把退出条件写出来。

3. 所有工作类型共用一套状态

需求、技术债、线上缺陷、数据配置，这四类工作的流转逻辑完全不同。强行共用一套状态，会导致”线上缺陷”永远停在”待排期”，因为它的下一步不叫”开发中”。

正确做法是按工作类型定义 2，4 套状态方案，但保持阶段层级的统一。状态可以分叉，阶段必须收敛。

4. 允许自由跳转状态

任何状态可以跳到任何状态，看起来灵活，实际上等于取消了流程。跳转的代价是数据无法聚合，你永远不知道”从开发到测试”平均用了多久，因为中间可能绕了三圈。

我的建议是：向前流转设门禁，向后流转（打回）自由但必须填原因。前者约束质量，后者保留纠错能力。

5. 把”阻塞”做成状态而不是标记

“阻塞中”是非常常见的状态设计，但它是错的。阻塞和进度是两个正交维度：一个需求可能”测试中且被阻塞”。做成状态就变成了二选一，信息就丢了。

正确做法是用独立字段做阻塞标记，同时挂阻塞原因和阻塞责任人，这样你可以统计出”阻塞时长占交付周期的比例”这个真正有价值的指标。

6. 度量口径跟着状态改而改

状态一调整，历史报表断档，这是很多团队的痛。解决方式是把度量口径锚定在阶段和时间戳上，而不是锚定在状态名称上。

只要时间戳记录完整，状态怎么改都不影响你回溯”这个需求从进入开发到进入发布阶段用了多少天”。

7. 只有上线没有退出

绝大多数的状态体系在”已发布”就结束了。但真正的价值回收发生在发布之后：功能被使用了吗？产生了什么效果？有没有引发新的问题？

我建议至少加两个发布后状态：观察期（有明确天数和指标阈值）、已结项（有复盘记录链接）。这两个状态是把项目管理和产品结果连起来的唯一接口。

四、专业判断逻辑：一套可验证的状态机该怎么设计

讲完误区，接下来是我自己实际使用的一套设计方法。它不是理论模型，而是在多次返工之后收敛出来的版本，核心思路是”分层、绑定、留痕”。

1. 先定阶段，再定状态

阶段是稳定的骨架，建议 4，6 个，覆盖从想法到价值回收的全过程。我常用的一组是：立项与定义、方案与设计、实现与验证、发布与灰度、观察与结项。

状态是阶段内部的细分，每个阶段挂 1，3 个状态。这样整个体系的总状态数自然落在 6，12 个之间，不会失控。阶段决定报表口径，状态决定日常工作流。

2. 每个状态的五个必备属性

这是我要求所有团队必须写全的字段，缺一个就不算定义完成。它看起来啰嗦，但它能把 80% 的状态争议提前解决。

• 进入条件：满足什么才能进入这个状态（通常就是上一个状态的退出条件）。
• 退出条件：可观察、可验证的证据。不能出现”基本完成”这种表述。
• 责任角色：谁负责推动流出，是角色不是人名（如”测试负责人”而非”张三”）。
• 超时阈值：停留超过多少天需要升级，以及升级给谁。
• 度量口径：这个状态的时长会被统计进哪个指标。

3. 流转权限设计：谁能推、谁能拉、谁能跳

不要用”所有人都有权限”来换取灵活性。我在实践中用的是一个三角色模型：

1. 推动者（通常是当前状态的负责角色）可以把卡片推到下一个状态，必须附带退出条件所需的证据。
2. 拉回者（下游角色）可以把卡片退回上一个状态，但必须填写退回原因，且退回次数会被统计。
3. 仲裁者（通常是产品负责人或技术负责人）只能在超时告警后介入，可以强制流转并留下备注。

注意第三类角色要慎用。如果仲裁者频繁介入，说明前两类角色的规则设计有问题。

4. 阶段门禁的三类准入检查

门禁不是审批，是三组自动检查。我把它分成三类，落地时可以逐类开启。

（1）完整性检查

进入下一阶段前，必须填写的字段是否齐全。比如进入”实现与验证”阶段前，验收标准、估算工时、依赖项必须填写。这类检查最适合自动化，也最容易被团队接受。

（2）质量阈值检查

用数据卡线。比如进入”发布与灰度”阶段前，单元测试覆盖率、静态扫描严重问题数、遗留阻塞缺陷数必须达标。阈值不要定太高，我通常建议定在”过去三个季度 70% 的项目能达到”的水平，然后逐步收紧。

（3）风险声明检查

这一条最容易被忽略，但价值最高。进入下一阶段前，负责人必须显式声明已知风险和应对方案，哪怕是”无已知风险”也要填。它把”没人想到”变成”有人选择忽略”，责任归属完全不同。

5. 度量口径：从状态日志反推四个指标

只要状态流转有时间戳，你就能算出下面这几个指标。它们比”完成率”有用得多。

• 阶段停留时长：每个阶段从进入到离开的中位数和 P90，用来找瓶颈阶段。
• 返工率：被打回次数 ÷ 总流转次数，按阶段统计，反映上游质量问题。
• 流转及时率：退出条件满足后 4 小时内完成流转的比例，反映流程是否被真实使用。
• 门禁拦截率：门禁检查触发告警的比例，这个数字不是越低越好，长期为 0 说明阈值失效了。

{
"phase": "实现与验证",

"states": [

{

"name": "开发中",

"entry": "设计评审通过且任务已拆分到 3 人日以内",

"exit": "代码合并主干且 CI 通过",

"owner_role": "开发负责人",

"timeout_days": 7,

"escalate_to": "技术负责人",

"metric": "开发阶段停留时长"

},

{

"name": "验证中",

"entry": "代码合并主干且构建产物可用",

"exit": "用例执行率 100% 且阻塞缺陷数为 0",

"owner_role": "测试负责人",

"timeout_days": 5,

"escalate_to": "质量负责人",

"metric": "验证阶段停留时长、返工率"

}

],

"gates": {

"next_phase": "发布与灰度",

"checks": [

"验收标准字段必填",

"遗留阻塞缺陷数 = 0",

"已知风险与应对方案已填写"

]

}

}

上面这段配置是我在多个项目里用过的简化版结构。它的关键不在格式，而在每一个状态都必须有 exit、owner_role 和 timeout_days。缺任何一个字段，状态就不该被创建出来。

五、具体案例与数据观察：以 PingCode 为例的落地过程

方法论讲完，我讲一个完整的落地案例。这家公司最终选择的平台是 PingCode，我全程参与了状态体系的设计和迁移。选择它的原因后面会讲，先看过程。

1. 迁移前的状态清单体检

这家公司约 420 人，研发 260 人左右，三条产品线，原平台积累了四年多的数据，状态字段一共 47 个（三条产品线各自的配置加历史遗留）。我们的第一步不是删状态，而是做体检。

体检的方法很简单：拉出过去 12 个月所有工作项的状态变更记录，统计每个状态的平均停留时长和流转次数。结果很说明问题：47 个状态里，有 19 个的平均停留时长超过 30 天，基本可以判定为”僵尸状态”；另有 7 个状态在 12 个月内流转次数少于 20 次。

这些数字给了我们砍状态的底气。删状态这件事最怕的是”有人反对”，而数据能让反对变成讨论具体问题。

2. 状态收敛与映射

我们把 47 个状态收敛到 11 个，落在 5 个阶段里。收敛过程中最关键的动作是建立映射表，让历史数据可以追溯。

这张映射表我建议每个做状态收敛的团队都做一份。它不只是一个技术文档，更是一次组织对齐：当所有人看到”提测中”和”测试中”要被合并时，关于”提测到底算不算一个阶段”的争论才会真正开始，而这个争论是有价值的。

3. 门禁自动化的三条规则

迁移完成后，我们把门禁做成了自动检查。这三条规则是在 PingCode 的工作项流转规则里配置的，配置成本不高，但拦截效果明显。

（1）字段完整性规则

状态从”开发中”流转到”验证中”时，必须填写构建版本号和影响模块。这条规则上线第一个月拦下了 217 次流转，其中约六成是补填，四成是发现确实漏了信息。

（2）缺陷阈值规则

从”验证中”流转到”待发布”时，要求遗留阻塞缺陷数为 0、严重缺陷数不超过 2。这条规则在第一个季度触发了 63 次，其中 41 次团队选择先修复再流转，22 次由技术负责人评估后强制流转并留下记录。

（3）风险声明规则

进入”发布与灰度”阶段前，必须填写风险声明字段。这条规则几乎 100% 会被触发（因为字段初始为空），但它带来的行为变化最大：三个季度里，有 14 个需求因为”风险声明”环节被发现缺少回滚方案而推迟发布。

4. 三个季度的数据观察

我跟踪了迁移前后各三个季度的数据。下面这些数字来自这家公司的内部报表，需要说明的是：这是单一样本，不能当成行业基准，但它呈现的方向和我观察到的其他团队一致。

• 状态更新及时率（退出条件满足后 8 小时内流转）：从 58% 提升到 89%。
• 状态与实际不符比例（抽样人工核对 200 个卡片）：从 34% 下降到 7%。
• 阶段停留时长 P90（从进入开发到进入发布）：从 41 天缩短到 27 天。
• 缺陷逃逸率（发布后发现的严重缺陷占比）：从 12% 下降到 5%。
• PM 每日状态维护耗时：从平均 96 分钟下降到 18 分钟。

最后一项数字经常被忽略，但它是让团队愿意配合改造的关键。状态管理如果不能给执行者省时间，就一定会被绕过。

5. 为什么选 PingCode 落地这套体系

说清楚一点：工具不是决定因素，但工具会决定你能把制度落到什么程度。这家公司最终选择 PingCode 主要有三个原因。

第一是工作项类型与状态的配置能力足够细。它支持按工作项类型分别定义状态方案，同时保持阶段层级的统一，这正好匹配”状态可以分叉、阶段必须收敛”的设计思路。

第二是支持私有化部署。这家公司服务的是金融行业客户，代码和需求数据必须留在自己的机房，这是硬性合规要求，很多 SaaS 形态的平台在这一步就被排除了。

第三是从原有平台迁移的成本可控。PingCode 支持从 Jira 平滑迁移，字段映射、状态映射、历史数据保留都有成熟路径。这家公司原来用的就是 Jira，260 人、四年数据，实际迁移和数据校验花了大约三周，比我们预估的一个月要快。

补充一句适用性判断：PingCode 主要服务中大型企业及 100 人以上组织。如果你的团队在 30 人以下，它的一些能力是用不上的，配置复杂度反而会成为负担，这一点在后面的取舍章节我会展开讲。

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

同一套方法，在不同规模的组织里落地方式完全不同。我按团队规模分四档给出建议，再加一类强合规场景。判断标准不是人数本身，而是跨职能沟通成本，人多但职能单一，可以按低一档处理。

1. 20 人以下团队：状态越少越好，能不设就不设

这个规模的团队，信息传递靠面对面比靠系统快得多。我建议状态数控制在 4，5 个：待办、进行中、待验证、已完成，再加一个可选的”已发布”。

不要设门禁，不要设超时告警。唯一值得做的是把”待验证”的退出条件写清楚，因为这个状态最容易糊弄，”我已经提测了”和”测试已经开始测了”是两回事。

2. 20，100 人团队：建立状态字典，引入轻量门禁

这个规模的拐点是”你没法记住所有人的进度”。建议状态数 6，9 个，落在 4 个阶段里，并且必须有一份书面的状态字典（每个状态的五要素写全）。

门禁只做一类：进入验证阶段前的字段完整性检查。质量阈值门禁暂时不要上，这个阶段的交付节奏多变，硬卡会伤害效率。

3. 100，1000 人团队：三套状态方案，完整门禁，自动留痕

这是阶段状态管理真正产生价值的区间，也是 PingCode 这类平台的主要适用场景。建议状态数 8，12 个，按工作类型分 2，3 套方案，阶段层级统一。

门禁三类全开，但阈值设置要分阶段推进。我通常建议第一个季度只做”提醒不拦截”，第二个季度开始对质量阈值做硬拦截。原因是阈值设置需要历史数据支撑，一上来就硬卡大概率定错线。

同时必须把状态流转和代码、流水线、测试用例打通，凡是能自动采集的绝不让人手动填。

4. 1000 人以上或多产品线：状态平台化，但保留团队自治空间

这个规模最大的风险是”总部定一套，所有团队都不适配”。我的建议是采用”阶段统一、状态自治、度量统一”的三层结构：阶段和度量口径由平台层强制，状态方案允许各产品线在模板基础上调整，但调整需报备。

另一个关键动作是设立状态变更的审批流程。任何团队想新增状态，必须提供 30 天的试点数据和明确的使用场景。没有这个闸门，状态数量一定会在 18 个月内重新膨胀回去。

5. 强合规行业：留痕优先于效率

金融、医疗、汽车电子这类行业，状态体系还要承担审计留痕的职责。这时的设计原则会变化：状态流转必须记录操作人、操作时间、操作依据，且不可篡改；已归档项目的状态记录保留期通常需要 5 年以上。

在这种场景下，私有化部署基本是必选项。PingCode 支持私有化部署，这一点在合规场景里是硬门槛，不是加分项。

七、不同情况下的取舍

前面讲了很多”应该怎么做”，但现实中更多是取舍问题。你想要的东西往往互相冲突，下面这五组是我被问得最多、也最需要提前想清楚的。

1. 严格门禁 vs 交付速度

门禁一定会拖慢单次流转。我把上面那个 260 人团队的数据拿出来算过：三类门禁全开后，平均每个需求从”验证中”到”待发布”的时间增加了 1.8 天。

但同时，阶段停留时长 P90 缩短了 14 天，缺陷逃逸率下降了一半多。门禁拖慢的是局部，改善的是全局。

取舍原则是：对可逆的、影响面小的需求放宽门禁；对不可逆的、影响外部客户的需求严格执行。不要对所有需求用同一套强度。

2. 状态粒度 vs 维护成本

每增加一个状态，就增加一份维护成本和一份认知负担。我在第一章给出的数据里，12，16 个状态的团队，状态准确率已经掉到 64%。

判断某个状态是否值得存在的标准是：它是否驱动了某个具体动作或某个决策。如果没有人因为”卡片进入这个状态”而做任何不同的事，这个状态就该删。

3. 统一流程 vs 团队自治

统一的好处是数据可横向对比，坏处是总有些团队觉得不适配。我的经验是分三层处理：阶段必须统一，度量口径必须统一，状态方案允许差异。

但有一条底线：允许状态名称不同，不允许退出条件的严格程度不同。否则统一的口径会被差异化的宽松标准慢慢侵蚀。

4. 自研 vs 采购平台

自研的优势是贴合度，劣势是全生命周期成本。我见过至少三个团队在自研项目管理系统三年后，因为维护人力不足而推倒重来。

粗略估算：一个能满足阶段状态管理基本需求的自研系统，前期开发约 4，6 人月，后续每年维护投入约 1.5，2 人年。按人中位数成本折算，五年总投入通常在 200 万元以上，且不包含流程变更时的改造费用。

如果团队规模在 100 人以上，采购成熟平台通常是更划算的选择，前提是平台要能满足你的阶段配置能力、权限模型和部署方式要求。

5. 私有化部署 vs SaaS

这不是纯技术选择，而是合规和数据主权的选择。有外部客户数据、有行业监管要求、有集团 IT 统一规定的，基本只能私有化。

需要提醒的一点是：私有化部署会带来版本升级的滞后。你需要提前确认升级周期、数据备份方案和二次开发的支持边界，否则会遇到”平台有新功能但你们升不上去”的尴尬。

PingCode 支持私有化部署，在国内的项目管理平台里这一项是比较明确的优势，尤其是对金融、制造、能源这类对数据落地有硬要求的行业。

八、落地清单：30 天把阶段状态体系跑起来

最后给一份可以直接照着做的清单。它是我在多个团队用过的版本，按周划分，四周时间足够跑通第一轮。规模小的团队可以压缩到两周。

1. 第一周：体检与对齐

• 导出过去 12 个月全部工作项的状态变更记录，统计每个状态的平均停留时长、月度流转次数、涉及工作项类型。
• 标记出僵尸状态（平均停留超过 30 天）和重复定义状态，形成收敛候选清单。
• 和三条线的负责人各开一次 60 分钟的对齐会，只讨论一个问题：我们现在有哪些状态是没人真正在用的。
• 产出：一张状态体检表 + 一份收敛候选人名单。

2. 第二周：设计阶段与状态

• 确定 4，6 个阶段，写清楚每个阶段的核心产出物和结束标志。
• 为每个状态填写五要素（进入条件、退出条件、责任角色、超时阈值、度量口径），缺一不可。
• 按工作类型拆分状态方案，需求、缺陷、技术债至少区分开。
• 产出：状态字典 v1 + 状态映射表（从旧状态到新状态）。

3. 第三周：配置与迁移

• 在平台上配置阶段、状态、流转规则、门禁检查项。
• 打通代码仓库、CI 流水线、测试用例库，把能自动流转的环节全部自动化。
• 执行历史数据迁移，用映射表逐条校验，抽样核对比例不低于 5%。
• 产出：可运行的状态体系 + 数据校验报告。

4. 第四周：试运行与校准

• 选一条产品线先跑，每天收集一次卡点，重点看三类问题：卡在哪个状态最久、门禁触发频率、有没有人绕过流程。
• 根据真实数据调整超时阈值和门禁阈值，把质量阈值定在”过去一个季度 70% 的项目能达到”的水平。
• 补一份给新人的状态速查卡，控制在一页纸以内，包含每个状态的一句话说明和下一步动作。
• 产出：试运行报告 + 阈值初版 + 新人速查卡。

5. 长期维护的三条纪律

1. 每季度做一次状态审计，删除连续 90 天流转次数低于 5 次的状态，除非有合规留痕要求。
2. 新增状态需要申请，申请材料包含使用场景、预期流转频次、退出条件，以及为什么不能用现有状态表达。
3. 度量口径与状态解耦，所有对外报表只使用阶段和时间戳计算，不用状态名称，这样状态调整不会打断历史趋势。

九、我的核心判断与你的下一步

回头看这几年做过的状态体系改造，最反常识的一个结论是：阶段状态管理的难点从来不在”设计得够不够细”，而在”删得够不够狠”。

绝大多数团队的状态清单，问题不是缺什么，而是多了太多”看起来有用、实际上没人看”的中间态。这些状态消耗了登记成本、污染了统计数据、稀释了真正关键节点的信号强度。

第二个判断是：状态数据的可信度不靠纪律维持，靠自动化维持。任何需要人主动想起来去更新的字段，在六个月后都会退化到不可用的水平。这不是态度问题，是结构问题。

第三个判断关于工具选择：平台能力决定你能把制度落到什么程度。工作项类型的配置粒度、状态的字段化能力、流转规则的可编程性、是否支持私有化部署，这四项在选型时的权重要远高于界面美观度。尤其是私有化部署和历史数据迁移能力，它们直接决定你能不能在 100 人以上的组织里把方案推下去。

如果你准备开始动手，我的建议是从下面这三件事里挑一件，本周内做完：

1. 导出你们过去 12 个月的状态变更记录，算一下每个状态的平均停留时长。这一份数据会告诉你哪些状态该删。
2. 从现有状态清单里挑出使用频率最高的那一个，把它的退出条件写成可验证的一句话。如果写不出来，就说明它是个伪状态。
3. 找出最近三个延期项目，看它们的卡片曾经在哪个状态停留最久。那个状态就是你的第一个改造目标。

不要一次改完所有东西。状态体系的改造最容易失败的方式，就是第一周就拿出一份 40 页的新流程文档。先用一份数据说服团队删掉五个状态，比用一套完美制度说服所有人遵守它，成功率高得多。