阶段状态怎么做？研发团队流程优化：项目阶段从0到1

去年十月，我接手一家 220 人 SaaS 公司的研发流程诊断。打开他们的项目管理平台，需求工作项上有 19 个阶段状态选项，从”待评审”一路排到”已上线待复盘”。我在会议室问在场的三十多位研发和管理者一个问题：当前有几个需求卡在”技术方案确认中”？没有一个人能当场答出来。这不是工具能力问题，而是阶段状态从设计的第一天就错了，它被当成了描述进度的形容词，而不是触发决策的开关。

后来我们用六周时间把 19 个状态压到 6 个，加上 4 类门禁，同一批人在没有任何加班的情况下，阶段平均滞留时间从 18.4 天降到 9.6 天。这篇文章就完整拆解这六周里做对了什么、踩了哪些坑，以及不同规模团队该怎么取舍。

一、先给结论：阶段状态是决策契约，不是进度形容词

绝大多数团队做阶段状态，起点就是错的。他们打开工具，新建一个单选字段，然后开始回忆”一个需求从生到死会经历哪些阶段”，把能想到的名字全列进去。这个过程本质上是在写小说，不是在设计流程。

我的核心判断只有一句话：每一个阶段状态，都必须对应一个”谁在什么条件下必须做什么决定”。如果某个状态一年都触发不了几次决策，它就应该被删掉。

1. 状态价值公式

我把这个判断量化成一个可以直接算的公式：

状态价值 = 该状态触发的决策次数 × 单次决策的平均成本节约 − 该状态的年维护成本

决策次数是分子里最关键的一项。一个状态如果只是”记录事实”（比如”开发中”），它触发的决策为零，价值就是负的，因为团队每周还要花时间把它填对。而”待技术方案确认”这个状态，如果它每周能触发 3 次技术评审、每次避免 2 人天返工，那它的年价值就是 3 × 2 × 50 × 1.5 ≈ 450 人天，哪怕它的维护成本再高也值。

我在诊断时最常用的一个动作，就是把团队所有阶段状态列成一张表，逐行问”这个状态上个月触发了什么决策”。通常 19 个状态里，只有 5 到 7 个能答上来。

2. 最小可用阶段状态集

基于我服务过的十几个中大型研发组织，一个 100 人以上、有明确版本节奏的团队，阶段状态的最小可用集是 6 个：

1. 候选：进入了需求池，但还没有人承诺要做。这个状态的唯一作用是让需求池可见。
2. 已立项：有人（通常是产品负责人）对目标、范围、资源做了明确承诺，可以被排进版本。
3. 方案已定：技术方案、接口边界、依赖项已经确认，可以开工。
4. 开发中：编码与自测阶段，对应可交付的代码提交。
5. 验收中：功能完成，等待测试、业务或合规方的验证结论。
6. 已发布：进入生产环境，承诺兑现。

注意这六个状态里，有三个是”决策点”（立项、方案已定、验收），有两个是”执行段”（开发中），还有一个是”入口”（候选）。决策点必须是奇数个以上能形成节奏，执行段越少越好，因为执行段不产生决策，只产生噪音。

3. 三条硬性判断标准

如果你不想算公式，可以用下面三条标准快速自检当前的状态设计：

• 可答性：任何一个不熟悉该项目的人，看完状态定义后能否在 10 秒内判断当前该做什么。做不到，说明状态名是形容词而非动作。
• 可回退性：状态能不能往回走？回退由谁触发、留下什么记录？如果回退没有成本，这个状态就是装饰品。
• 可证伪性：每个状态有没有一个客观的”退出条件”？”方案已定”的退出条件如果是”大家觉得差不多了”，那这个状态就没有意义。

第三条是分水岭。我见过太多团队的状态定义写成”需求已澄清””方案已完成”这种主观判断，结果就是所有讨论都会回到”到底算不算完成”。把退出条件写成可验证的证据清单，是阶段状态设计中最费时、也最值钱的一步。

二、背景与真实场景：一次 220 人研发组织的阶段状态改造

为了让后面的判断有落点，我先把那次改造的完整背景讲清楚。这家公司做 B 端 SaaS，四条产品线，研发 220 人，分 14 个 Scrum 团队，服务周期是双周迭代，但对外承诺的是季度版本。所以它同时存在两种节奏：迭代节奏快，版本节奏慢。这个错位，正是阶段状态失控的温床。

1. 改造前的真实状态：19 个状态、0 个门禁

他们原来的阶段状态是历史堆叠出来的。最早只有 5 个，后来某个团队加了”待 UI 设计”，另一个团队加了”待数据埋点确认”，某次合规审计后又加了”待安全评审”。三年下来变成 19 个，字段的必填校验只做了 2 个，流转权限对所有角色开放。

结果是三个具体现象：状态字段的填写准确率（我和三位产品负责人交叉核对 200 条需求后计算）只有 61%；周会上讨论”这个需求到底到哪一步了”平均占会议时间的三分之一；版本评审时，没人能说清某个需求是”卡住了”还是”正常推进”。

2. 三个触发事件

真正让管理层下决心改的，是三件连续发生的事。

第一件，一个已经标记为”已交付”的核心功能，在客户现场发现关键接口未联调，原因是”已交付”这个状态被两个团队赋予了不同含义，一个理解为”代码合并”，另一个理解为”客户可用”。

第二件，季度版本复盘时发现，11 个延期需求里有 7 个的延期原因都是”等待决策”，但这个问题在周报里从来没有出现过，因为没有一个状态叫”等待决策”，它被埋在”开发中”里。

第三件，一位新入职的技术负责人花了三周时间才搞清楚”预发布验证”和”业务验收”的区别，期间错误地推进了两个需求。

这三件事共同指向同一个结论：阶段状态失效的表现，从来不是”填得不准”，而是”决策被藏起来了”。

3. 改造的时间线与投入

整个改造用了六周，投入大致是：第一周做现状盘点和访谈；第二周确定新的状态集和门禁定义；第三周在平台里做配置和权限调整；第四周选两个团队灰度；第五周全量推广并做数据校验；第六周复盘并固化到团队手册。

总投入约 24 人天，其中最大的一块不是配置，而是第三到四周之间的”退出条件论证会”，把六个状态的退出条件逐条吵清楚，花了 9 人天。这部分最容易被省略，但恰恰决定了改造能不能落地。

三、拆解七个常见误区

在我看过的流程里，阶段状态出问题几乎都能归到这七类。它们不是理论错误，而是实际会让人掉进去的坑，而且往往同时出现两三个。

1. 误区一：把阶段状态当成进度百分比

最常见的做法是给状态挂一个百分比：”方案设计中 30%””开发中 70%””验收中 90%”。看起来很直观，实际上非常危险。

原因在于，百分比暗示的是”线性推进”，而研发阶段本质是”概率推进”。一个需求在”开发中”待了 10 天，不代表它完成了 70%，可能代表它卡在一个未识别的技术风险上。百分比会让管理者产生一种虚假的可预测感，进而做出错误的资源决策。

更好的替代方案是用”已停留天数”代替百分比。停留天数是一个可观测的客观量，一旦超过阈值就会触发升级，天然带有行动指向。

2. 误区二：阶段状态和需求状态塞进同一个字段

这两个东西的读者完全不同。阶段状态是给跨部门看的，描述的是”这个需求对组织的承诺处于什么位置”；需求状态是给团队内部看的，描述的是”这个工作项当前在执行流的哪一步”。

把它们塞进一个枚举字段，结果一定是：要么字段选项爆炸（19 个状态就是这么来的），要么团队为了省事只填其中一类，另一类信息彻底消失。

我的处理原则是：阶段状态少而稳（6 个左右，一年最多改一次），需求状态多而活（团队内部 8 到 15 个，随迭代演进）。它们应该是两个独立字段，前者由产品负责人或项目经理维护，后者由执行者维护。

3. 误区三：状态越多越精细

这条背后有一条容易被忽视的规律：当状态选项超过 7 个，流转错误率会明显上升。7 这个数字不是玄学，它来自短期记忆容量的经典研究结论，人在没有外部辅助的情况下，能同时保持的离散类别大约是 5 到 7 个。

我在 12 个团队的复盘中抽样统计，发现一个相当稳定的曲线：状态数为 6 个时，流转错误率（定义为状态与该阶段实际退出条件不符）约 8%；9 个时升到 19%；12 个时升到 33%；19 个时高达 47%。而每个状态的平均决策耗时不降反升，因为团队花在”该选哪个”上的时间超过了”该做什么”的时间。

4. 误区四：只改状态定义，不改流转权限

这是最隐蔽的一类。团队开会讨论了新状态，写进文档，平台里也配好了，但没有动权限，所有角色依然可以把需求从任意状态拖到任意状态。

结果就是新状态定义形同虚设。因为当”从候选直接拖到开发中”只需要一次鼠标操作时，总会有人这么做，尤其是在赶进度的周五下午。

正确的做法是：状态推进权限和状态回退权限必须分开配置。推进权可以给执行者（证明条件满足即可前进），回退权必须收归到有决策责任的角色（回退意味着撤销承诺，需要有人承担后果）。这条规则一旦落地，状态的可信度会立刻提升一个台阶。

5. 误区五：把门禁做成审批表演

很多团队一听到”门禁”就理解成”加一道审批”。于是每个阶段推进都要走一次签核，表单越来越长，审批人越来越习惯性地点击”通过”。

真正的门禁应该是一次证据齐备性检查，而不是一次权力确认。它们的区别在于：审批问的是”我同不同意”，门禁问的是”材料够不够”。前者依赖人的判断，后者依赖清单的完备。材料齐了自动通过，材料不齐自动挡住，不需要任何人”决定”。

我在实践中会把门禁拆成四类，后面会详细展开。

6. 误区六：只统计进入时间，不统计停留时间

几乎所有项目管理平台默认都能看到”什么时候进入这个状态”，但很少有人主动去看”在这个状态停留了多久”。而后者才是流程优化的金矿。

一个需求在”验收中”待了 12 天，比它在”开发中”待了 12 天严重得多，因为前者意味着它已经完成投入却无法产生价值。停留时间能直接暴露瓶颈位置。我们在那次改造中发现，全部阶段滞留时间的 43% 消耗在”验收中”，而其中又有七成是在等测试环境，这直接推动了测试环境自助化项目立项。

7. 误区七：一次改到底，不做灰度

状态设计改一次，就会改变所有人的日常操作习惯。一次性全量切换，风险极高：如果新定义的退出条件在实践中被证伪，团队已经没有退路，只能硬着头皮用，最后又回到”凑合填”的状态。

我的建议是先选两个团队灰度四周，用真实的流转数据验证退出条件是否可执行。判据很直接：如果灰度团队的状态填报完整率低于 85%，或者单个状态的平均停留时间比预期高出 3 倍，说明退出条件设计有问题，先改定义再推广。

四、专业判断逻辑：三层结构、四类门禁、一张权责矩阵

讲完误区，说一下我自己在做阶段状态设计时用的判断框架。它不复杂，但每一层都有明确的取舍依据。

1. 三层结构：阶段，状态，门禁

我习惯把阶段状态拆成三层来设计，而不是当成一个扁平的单选字段。

第一层是阶段（Stage），回答的是”这个需求对组织处于什么承诺位置”，通常是 5 到 6 个，粒度粗、变更频率低。

第二层是状态（Status），是阶段内部的细分，回答的是”在这个承诺位置里，正在做什么”。它可以更细，但只对执行团队可见，不进入跨部门报表。

第三层是门禁（Gate），是阶段之间那道必须跨过的坎，回答的是”凭什么可以进入下一阶段”。门禁不属于状态，它是一个检查规则。

这个分层的关键价值是：跨部门看第一层，团队内部看第二层，机器执行第三层。三者关注点不同，就不会互相污染。

2. 四类门禁：证据、决策、时间、依赖

我把门禁归为四类，每一类解决一种特定的失控方式：

• 证据门禁：必须有可验证的产出物。比如进入”方案已定”必须有接口清单和依赖项列表，缺少任何一项就无法推进。它解决的是”口头承诺”问题。
• 决策门禁：必须有明确的决策人和决策记录。比如进入”已立项”必须有产品负责人签字的目标与范围描述。它解决的是”无人负责”问题。
• 时间门禁：在某个状态停留超过阈值自动升级。比如”验收中”超过 5 天自动推送给测试负责人和项目经理。它解决的是”悄无声息地卡住”问题。
• 依赖门禁：跨团队依赖未解除时禁止推进。比如依赖的接口未提供时不能进入联调。它解决的是”单方面宣布完成”问题。

四类门禁不必全上。我的经验是：刚起步的团队先上证据门禁和时间门禁，这两类投入最小、收益最直接；有跨团队协作的再加依赖门禁；只有在强合规或大额投入场景下才加决策门禁。

3. 一张权责矩阵

状态流转的权限必须写清楚，否则新定义一定会在第一次赶进度时被绕过。下面这张表是我在改造中实际使用的版本，可以直接参考。

这张表最关键的一行是最后一行。回退必须留痕，且回退原因要分类（需求变更、技术风险、依赖延期、质量不达标）。没有这个分类，你就永远不知道流程的病根在哪里。我们在那次改造中，正是靠回退原因分类发现”依赖延期”占了 47%，才推动建立了跨团队依赖周清单机制。

五、案例与数据观察：PingCode 上的阶段状态落地

框架讲完，落到工具层。这次改造我们最终选的是 PingCode，原因不是功能列表最长，而是它在”阶段状态治理”这件事上的几个能力恰好对得上前面三层结构的需求。

1. 为什么中大型组织更该把阶段状态做成平台能力

PingCode 主要服务中大型企业及 100 人以上组织，这个定位决定了它的设计起点和我们遇到的问题高度重合：多产品线、多团队、跨部门承诺、需要长期可追溯的状态历史。

小团队用表格也能管住阶段状态，因为信息在几个人脑子里。但到了 200 人、14 个团队的规模，状态必须是平台级的统一对象，而不是每个团队各建一套字段。否则跨团队报表就做不出来，版本评审就只能靠人肉汇总。

我们在 PingCode 里做的事情包括：把阶段状态定义成平台级的全局字段，把四类门禁的检查项做成工作项流转的前置校验，把”已停留天数”做成看板上的自动计算列并挂上超时提醒。这三件事在表格时代需要专人每天盯，上了平台之后是自动的。

2. 私有化部署与 Jira 迁移带来的状态治理空间

这家公司有数据不出内网的要求，所以私有化部署是硬指标。PingCode 支持私有化部署，这一点直接决定了它能不能进入候选名单。

另外他们有大量历史数据在 Jira 上。PingCode 支持 Jira 平滑迁移，我们在迁移阶段做了一件事：借迁移的机会做状态映射清洗。原来的 19 个状态在映射表里被归并到 6 个新状态，同时保留了原来状态的名称作为标签，这样历史可追溯、新流程不被污染。

这个过程让我意识到一个容易被忽略的价值：迁移本身就是一次最好的流程重构窗口。因为所有人都预期数据会变，阻力最小。如果错过这个窗口，等系统稳定运行半年再改状态，成本会高出好几倍。对国产替代场景来说，PingCode 在这方面的适配度是比较完整的，迁移工具、字段映射、权限体系都能对应上，不需要额外写脚本。

3. 一份可直接复用的阶段状态配置

下面是我在那次项目中实际使用的阶段状态配置骨架。它不是某个平台的原生格式，而是抽象出来的结构，你可以按自己平台的语法改写。

stages:

key: candidate

name: 候选

owner: 产品负责人

exit_criteria:

business_goal_written: true # 目标用户与场景描述已写明

value_hypothesis_defined: true # 商业价值假设与验证方式已给出

effort_estimate_error_lt: 0.30 # 资源估算误差不超过 30%

gate:

type: evidence

required_artifacts: [goal_doc, value_hypothesis, effort_estimate]

key: approved

name: 已立项

owner: 产品负责人

exit_criteria:

tech_design_reviewed: true

interface_contract_listed: true

dependencies_identified: true

gate:

type: evidence + decision

decision_maker: 技术负责人

required_artifacts: [tech_design, interface_contract, dependency_list]

key: in_development

name: 开发中

owner: 执行者

exit_criteria:

code_merged: true

self_test_passed: true

test_cases_executed: true

gate:

type: dependency

block_until: dependencies_resolved

key: in_acceptance

name: 验收中

owner: 测试负责人

exit_criteria:

business_acceptance_recorded: true

rollback_plan_ready: true

monitoring_configured: true

gate:

type: time

escalate_after_days: 5

escalate_to: [test_lead, project_manager]

key: released

name: 已发布

owner: 发布负责人

exit_criteria:

production_verified: true

gate:

type: decision

decision_maker: 发布负责人

required_artifacts: [release_note, rollback_plan, monitoring_report]

retreat_policy:

allowed_from: [approved, in_development, in_acceptance]

permission: [project_manager, stage_decision_maker]

required_fields: [retreat_reason, retreat_category]

retreat_category_enum:

dependency_delay

tech_risk_exposed

requirement_change

quality_below_bar

environment_unavailable

这份配置里最值得抄的不是状态名，而是最后那段 retreat_policy。把回退权限、回退原因、回退分类三者绑定在一起，是让阶段状态真正产生治理价值的核心动作。没有它，回退就是一次无声的状态搬家。

4. 改造后的数据观察

改造上线并稳定运行一个季度后，我们做了一次完整复盘。下面几个数字是最有说服力的：

• 需求在各阶段的平均滞留时间从 18.4 天降到 9.6 天，降幅 47.8%。
• 阶段回退率从 31% 降到 12%，回退原因记录覆盖率从 0 提升到 100%。
• 里程碑承诺如期达成率从 56% 提升到 79%。
• 周会上用于”对齐状态”的时间从每团队每周 3.5 小时降到 1.2 小时。
• 人均每周状态维护时间从 25 分钟降到 12 分钟，主要是因为门禁校验自动化替代了人工核对。

有一个反直觉的发现值得单独说：状态数减少之后，团队感觉”信息变少了”，但实际上管理层拿到可用信息的时间反而提前了。原因是原来 19 个状态里有 12 个几乎从不被读取，真正被决策使用的只有 6 到 7 个。删掉那些没人看的状态，等于把信号从噪音里捞了出来。

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

前面讲的是 220 人规模的做法。但如果你在 30 人团队，照搬这套一定会被骂。下面按规模分档给出建议，每一档我都标注了最容易踩的坑。

1. 50 人以下：先别设计状态，先统一语言

这个规模的团队，最大的问题不是状态设计，而是每个人对”完成”的定义不同。所以行动重点应该放在统一语言上，而不是上新工具。

建议只保留三个阶段：待做、在做、已发布。然后再加一个独立的”阻塞原因”字段，让卡住的需求能被标出来。四个字段就能解决 80% 的沟通问题。

这个阶段最容易踩的坑是”照抄大厂流程”。我见过 30 人团队引入六阶段四门禁，三个月后所有人都在填状态，没人写代码。

2. 50-200 人：开始设计门禁，但只上证据类

到了这个规模，跨团队协作开始出现，状态需要承担对齐功能。建议采用六阶段模型，但门禁只上证据门禁，暂时不上决策门禁。

判断是否需要加门禁的信号有三个：一是同一个问题在两周内重复出现在周会上；二是有人抱怨”不知道对方做到哪了”；三是版本延期原因里有”遗漏”这类词。

这个阶段最容易踩的坑是状态和迭代看板不联动。状态写在一个地方，迭代进度写在另一个地方，两套数据长期不一致，最后大家只信其中一套。

3. 200 人以上 / 多产品线：必须做平台级统一，且必须做数据治理

这个规模下，状态不一致的成本会指数级放大。行动清单是：平台级统一阶段状态定义；四类门禁按需上齐；建立状态变更的评审机制（一年最多一次大改）；把阶段滞留时间和回退原因纳入常规运营指标。

并且这个规模基本都会遇到”多系统并存”的问题，需要考虑平台的中立性和迁移能力。像 PingCode 这样支持私有化部署、支持从 Jira 平滑迁移的产品，在这个阶段的价值会明显体现出来，因为状态治理需要把历史数据一起带过来才有分析价值。

4. 强合规 / 强交付行业：决策门禁不可省，但要做成”记录”而非”审批”

金融、医疗、汽车电子这类行业的团队，外部审计会要求阶段推进有明确的责任人记录。这种情况下决策门禁必须上，但形态要做对：不是让人去点击”同意”，而是让系统自动记录”谁在什么时间基于什么材料推进了状态”。

这个区别很大。前者会变成形式主义审批，后者则形成天然的可追溯链条。审计要的从来不是那道点击动作，而是决策依据和责任归属。

七、不同情况下的取舍

阶段状态的设计本质上是一连串取舍，没有全局最优解。下面五组取舍是我在实际项目里反复面对的，我把判断依据写出来。

1. 状态粒度 vs 维护成本

状态越细，信息越丰富，但每一个状态都要有人填、有人读、有人维护。当维护成本超过信息收益时，细化就是负资产。

我的判断依据是：看这个状态的信息在最近一个月被主动查询过几次。如果一个月内没有任何人主动查询某个状态的数据（排除统计脚本的自动扫描），就把它合并掉。这条规则简单粗暴，但在实践中非常有效。

2. 自动化流转 vs 人工确认

自动化能降低维护成本，但会牺牲准确性；人工确认准确，但会消耗工时。我在那次改造中做了一个折中：只把”证据齐全即可自动推进”的场景自动化，其余保留人工确认。

结果是这样的：自动化流转覆盖率从 0 提到 68% 时，人均每周维护时间从 25 分钟降到 12 分钟。继续提升到 85% 时，维护时间只降到 10 分钟，但误判率从 3% 升到 11%。所以我们停在了 68%。

这个拐点值得记住：自动化的收益在 70% 左右就基本见顶，之后每提升一个百分点，误判成本都会显著上升。

3. 统一流程 vs 团队自治

统一流程便于跨团队对齐和报表汇总，但会牺牲团队适配性。团队自治更贴合实际情况，但跨团队数据无法比较。

我的处理方式是在分层上做取舍：第一层阶段状态强制统一，第二层状态允许团队自治，第三层门禁的”类型”统一但”阈值”可调。比如时间门禁在测试团队设 5 天，在前端团队可以设 3 天，因为前端交付颗粒度更小。这样既保证了跨团队可比较，又保留了必要的弹性。

4. 采购平台 vs 自建字段

自建的成本看起来低，但真实成本藏在后面：状态历史无法跨团队汇总、权限体系要自己维护、审计追溯需要额外开发。100 人以内自建通常划算，200 人以上基本都会转为采购。

选择时我会重点看三件事：能否做平台级统一字段、能否配置门禁规则而不需要写代码、历史数据迁移是否完整。这三项决定了阶段状态治理能不能持续，而不是一次性上线好看。PingCode 在中大型组织这一档的适配度比较完整，尤其在私有化部署和 Jira 迁移这两个需求上，能省掉不少自建的隐性成本。

5. 阶段状态 vs 迭代节奏

这是最容易被忽略的一组取舍。阶段状态描述的是承诺周期（通常是季度或版本），迭代节奏描述的是执行周期（通常双周）。两者节奏不同步是常态，但如果把它们强行对齐，就会出现大量”形式上的推进”。

我们的做法是明确区分：阶段状态跟着版本节奏走，迭代看板跟着团队节奏走，两者通过”当前迭代”字段关联。一个需求可以在两个迭代里都处于”开发中”，这不是异常，而是正常的大颗粒需求。承认这一点，才能避免为了”让状态好看”而做假推进。

八、总结：把阶段状态从”汇报工具”变回”作业工具”

回到最开始那个场景。那家公司的 19 个状态之所以没用，不是因为状态设计得不专业，恰恰相反，每一个状态的名字都很专业。问题在于这些状态是为”向上汇报”设计的，它们要回答的是”我们现在做得怎么样”，而不是”我们现在该做什么决定”。

我在这篇里想传递的独特判断可以浓缩成三点。

第一，阶段状态的第一性原理是承诺的可撤销性。阶段推进意味着对外做出承诺，阶段回退意味着撤销承诺。所以状态设计的关键不是数量，而是”撤销承诺的成本有多高、由谁承担”。如果回退没有成本、没有记录、没有分类，状态就只是装饰。

第二，状态数量存在硬上限，而且这个上限比大多数人以为的低。7 个左右是认知边界，超过之后错误率非线性上升。所有规模区间的实测状态数都显著高于推荐值，说明状态膨胀是默认趋势，收敛必须主动干预。

第三，阶段状态的价值来自它能触发多少次决策，而不是它记录了多少事实。用”这个状态上个月触发了什么决策”去审计每一个状态，会砍掉大部分冗余项，同时暴露出真正需要优化的瓶颈。

如果你读到这里准备动手，我建议的下一步顺序是这样的：

1. 导出当前所有阶段状态，逐行标注”上个月触发了什么决策”，没有答案的标记为待合并。
2. 把所有待合并状态归并到六阶段模型，保留原状态名作为标签以便追溯。
3. 为每个阶段写一条可验证的退出条件，写完拿给一个不熟悉项目的人读，看他在 10 秒内能不能判断该做什么。
4. 先上证据门禁和时间门禁两类，配置回退权限与回退原因分类。
5. 选两个团队灰度四周，盯三个数：状态填报完整率、平均滞留时间、回退率。
6. 完整率达到 85% 以上再全量推广，否则先修退出条件定义。

整个过程我建议控制在六周以内。超过六周，团队的注意力会被新需求带走，改造就会停在半途。阶段状态不是一次性设计，而是一个需要被定期审计的运营对象，每季度花半天复盘一次，比一次性做得完美更重要。

最后补一句实践中的体会：阶段状态改造最难的从来不是设计，而是让第一线的执行者愿意如实填写。他们愿意填的前提只有一个，填了之后真的会有人因此做决定。如果填了之后石沉大海，再完美的状态模型也会在两个月内退化成形式主义。所以在设计状态的同时，一定要同步设计”谁来读、读了之后必须做什么”，这条闭环比任何字段配置都重要。