阶段状态落地方案：管理层开展项目阶段的流程优化案例解析

2023年4月，我接手一家约800人的智能硬件公司的研发流程诊断。第一次管理层访谈，会议室里出现了三个互相矛盾的数字：工程VP打开工具看板说”12个项目都在进行中”，供应链负责人说他手上只有3个项目的样机排期，质量负责人说待验证的有7个。三份数字都对不上，因为”阶段状态”这个字段谁都可以随手改，也没有任何规则约束它什么时候必须改、改成什么才算数。三个月后我们重做了阶段状态的落地方案，把”状态”从一个可填可不填的字段，变成触发评审、触发资源、触发升级的动作开关。

这篇文章拆解的就是那次改造的完整过程，包括我们一开始判断错的地方。

一、核心结论：阶段状态能不能落地，取决于它是否绑定了动作

我参与过六次阶段状态相关的流程改造，失败的只有一类：把阶段状态当成”更细的进度条”。字段加上了，颜色画上了，看板也挂上了，三个月后管理层的评价是”看板很好看，但我不信”。原因不复杂，状态没有绑定任何动作，改与不改对当事人没有任何后果。

所以先把结论摆出来：阶段状态的本质是”进入条件 + 停留判据 + 退出动作”的三元组，颜色只是它的副产品。管理层真正需要的不是”现在在哪个阶段”，而是”状态变化之后，谁必须动、动到什么程度、不动会怎样”。

1. 结论一：状态的本质是条件与动作，不是颜色

很多团队设计阶段状态时，第一件事是打开工具画状态流，然后开始争论”待评审”和”评审中”要不要拆开。这个顺序是反的。正确的顺序是先回答一个问题：这个阶段的完成，用什么可验证的事实来判定？

在我的方案里，每个阶段状态都必须回答三个问题。进入这个状态需要满足什么客观条件（比如需求基线已冻结、关键物料到货）；停留在这个状态时，判断它是否健康的标准是什么（比如滞留超过10个工作日自动升级）；退出这个状态会触发哪些动作（比如自动创建下一阶段的评审任务、自动通知采购排期）。

任何一条答不上来的状态，都会被我从方案里删掉。这条规则在六次改造里帮我砍掉了平均四成的状态定义。

2. 结论二：管理层要的是状态变化触发的决策，而不是状态快照

管理层月度例会上看到的那张”阶段分布饼图”，信息量其实接近于零。因为它是快照，快照只说明现状，不说明趋势，更不说明需要谁做什么决策。

真正有决策价值的信号是三类：状态发生了非预期变更（比如从”开发中”退回”方案设计”）、状态在某处滞留超阈值（比如5个项目同时卡在”待验证”）、状态变更频率异常（某个项目一个月内改了7次阶段状态，这通常意味着立项时范围没定义清楚）。

我后来给管理层设计的看板只有一屏，不放分布图，只放这三类异常。会议时长从90分钟压到45分钟，因为讨论对象从”我们现在怎么样”变成了”这三件事谁来定”。

3. 结论三：状态数量与落地率成反比，5±1 是甜点位

这是一个反常识但反复验证的规律。团队总想把状态设计得尽量精确，于是一套流程里出现”未开始、方案中、方案评审、开发中、开发评审、测试中、测试评审、待发布、已发布、已关闭”十个状态。设计者觉得很严谨，执行者觉得很麻烦，最后的结果是大家统一改成”进行中”。

我统计过手上17个项目的实际数据：状态数在4到6个之间时，状态回填及时率稳定在84%以上；状态数超过9个，回填及时率掉到60%以下，而且状态误报率（状态与实际进度不符的比例）从6%涨到23%以上。原因很直白，状态越多，判断成本越高，判断成本越高，人就越倾向于凭感觉选一个最省事的。

4. 结论四：门禁评审的目标是风险交割，不是签字

把阶段门禁做成”审批流”是我见过最普遍的错。审批流的默认逻辑是”同意/不同意”，而阶段门禁的真实逻辑应该是”上一阶段遗留的风险，谁接手”。

我们后来把门禁评审的输出，从”通过/不通过”改成了三个必填项：本阶段未解决的风险清单、每项风险的接收人、接收人承诺的关闭时间。评审通过的标准不是”没问题”，而是”所有遗留问题都有明确接收人”。这个改动让阶段准出后的问题反弹率从34%降到了11%。

二、背景与真实场景：一个800人公司的阶段状态失控现场

为了让后面的判断有具体语境，先把改造前的现场描述清楚。这家公司做智能硬件，研发周期长、跨部门多，一个项目从概念到量产要经过五个阶段，涉及研发、供应链、质量、生产四个体系。

1. 改造前：同一时间存在三个版本的”真相”

改造前，阶段状态由项目经理在工具里手工维护。工程侧看到的看板显示12个项目进行中，供应链侧拿到的样机排期表只有3个项目，质量侧的验证任务表上有7个项目。差异的来源有三个：项目经理更新不及时、不同部门对”进入下一阶段”的判定标准不同、以及”进行中”这个状态本身承载了太多含义。

最典型的一次事故是某项目的”验证阶段”状态在工具里显示为进行中，实际上样机因为一颗物料的替代认证没通过，已经停了三周。项目经理知道，质量负责人不知道，供应链不知道。等到月度例会暴露出来，已经错过了原定的产线排期窗口。

2. 管理层为什么会被误导

这里有一个我认为非常关键的判断：管理层被误导，通常不是因为下属故意隐瞒，而是因为状态字段的粒度不足以承载真实复杂度。

一个”进行中”的状态，可能意味着”正常推进”，也可能意味着”卡在某个供应商回复上等了三周”，还可能意味着”项目实际上已经名存实亡但没人宣布终止”。当这三种情况在报表上长得一模一样时，管理层只能靠会议上的口头补充来还原真相，而口头补充永远是滞后且不完整的。

3. 阶段状态失控的四类典型信号

我在诊断阶段会看四个信号，它们比任何访谈都更能说明问题：

• 状态变更的时间戳分布：如果80%的状态更新集中在周会前两小时，说明状态是”为汇报而写”，不是”为管理而写”。
• 状态与实际交付物的偏差率：随机抽10个项目，比对状态与最近一次交付物提交时间，偏差超过7天的比例超过30%就要警惕。
• 回退状态的使用频率：如果状态只能前进不能后退，团队会用”新建一个项目”来绕过，导致项目数量虚高。
• 跨部门状态口径的一致性：同一个项目，研发、质量、供应链三个视角描述的阶段是否一致。

这家公司四项全中。第一项尤其严重：状态更新的时间戳有76%集中在周会前两小时，其中相当一部分是把上周忘记更新的状态一次性补上。

三、拆解五个常见误区

在讲具体方案之前，先把我在复盘中最常遇到的五个误区说清楚。这五个误区几乎在每个失败的阶段状态方案里都能找到至少三个。

1. 误区一：把阶段状态等同于完成百分比

最常见的做法是”开发中 60%”。这个设计看似精确，实际完全不可验证：谁来判定是60%而不是55%？是按工作量、按时间、还是按交付物数量？

更严重的问题是，百分比会诱发”进度美化”。我见过一个项目连续三周报”开发中 90%”，最后一周直接跳到”已发布”。原因不是团队偷懒，而是90%这个数字没有任何人能够证伪。

正确的替代方案是用”退出条件的满足项数”来表达进度：开发阶段的5项准出条件达成了3项，就是3/5，每一项都有明确的证据来源。这比百分比粗糙，但可验证。

2. 误区二：状态由项目经理单人维护

单人维护看起来省事，实际上制造了单点故障。项目经理有多个项目，状态更新必然滞后；更重要的是，当项目经理个人判断与实际情况不符时，没有任何机制能纠正。

我主张的规则是”谁产生状态变化的事实，谁负责更新状态“。硬件到货由供应链更新，测试报告完成由质量更新，代码封版由研发更新。项目经理的角色从”填表人”变成”校验人和升级人”。

这个改动在落地时阻力最大，因为涉及权限重新分配。但只要撑过前六周，状态回填及时率的提升幅度通常是最明显的。

3. 误区三：状态与个人考核直接挂钩

这是最危险的一条。一旦”状态按时更新率”进入个人KPI，数据就会迅速失真，不是因为大家想造假，而是因为人会优先优化被考核的指标本身，而不是指标背后的目标。

我见过一个团队把”阶段准出一次通过率”纳入项目经理考核后，门禁评审的严格度肉眼可见地下降，因为评审人也是考核链条上的一环。三个月后一次通过率涨到92%，但阶段后的返工量涨了40%。

我的建议是：状态数据用于诊断和触发动作，不直接用于个人绩效。如果一定要考核，考核团队级的”阶段延期率”和”阶段后返工率”，而不是状态字段本身。

4. 误区四：只在月度经营会上看状态

月度频次对硬件项目来说太慢。一个阶段平均滞留14天，月度会议发现时可能已经错过了两个决策窗口。

我的做法是把状态消费分成三层：日层级看”异常变更”（系统自动推送）、周层级看”滞留超阈值清单”（项目经理和职能负责人会商）、月层级看”阶段健康度趋势”（管理层）。三层看的东西不同，频率不同，参与人不同。

5. 误区五：状态只进不退，缺少回退与挂起

如果状态机不允许回退，团队一定会用别的方式绕过。最常见的三种绕过方式是：新建一个项目、把状态一直挂着不关、以及干脆不用工具改用飞书表格。

我的方案里一定会包含两个”负面状态”：回退和挂起。回退要求填写回退原因和补救计划，挂起要求填写挂起原因、挂起审批人和计划恢复时间。这两个状态的存在，反而让正常状态的含金量提高了，因为管理层知道，如果一个项目显示”开发中”，它没有处于回退或挂起状态。

四、专业判断逻辑：一套可落地的阶段状态模型

下面是我在多个项目中逐步收敛出来的一套模型。它不是唯一答案，但在我接触的100人到2000人规模的研发组织里，适配度比较高。

1. 先定义阶段边界，再定义状态

阶段和状态是两个维度，很容易被混在一起。阶段回答的是”这件事在生命周期的哪个位置”，状态回答的是”它在这个位置上的健康状况和推进情况”。

我的做法是：阶段数量控制在4到6个，且每个阶段必须有一个可交付物和一个准出评审。如果一个阶段既说不清交付物、也不需要评审，它就不该作为一个阶段存在。

硬件项目常见的五阶段是：概念与立项、规划与方案、开发与执行、验证与试产、结项与移交。软件项目通常压到四个：立项与规划、开发、测试与验收、发布与结项。

2. 状态设计的三要素：进入条件、停留判据、退出动作

每一个状态都必须完整填写这三个要素，缺一不可。我用一张表来固化这个结构，下面是一个实际使用的示例（已脱敏）。

这张表的实际价值远超它的字数。我们把它作为工具配置的输入源，直接决定了状态机的字段、必填项、自动化规则和看板口径。

3. 状态机的极简模型与配置示意

状态机不是越复杂越好。我通常只保留三条主线：前进、回退、挂起。前进路径是主干，回退和挂起是两条异常分支，且都必须带原因字段。

下面是我们实际用于工具配置的伪代码示意，它描述的是状态与动作的绑定关系，不涉及具体厂商实现。

# 阶段状态机配置示意（伪代码）
work_item: 项目阶段

states:

未开始

进行中

待评审

已挂起

已回退

已完成

transitions:

未开始 -> 进行中:

条件: 启动会完成 且 责任人确认

动作: 生成阶段任务清单 / 通知责任人 / 记录启动时间

进行中 -> 待评审:

条件: 准出清单 5 项全部提交

动作: 创建评审任务 / 指定评审人 / 锁定评审时间窗

待评审 -> 已完成:

条件: 评审通过 且 遗留风险 100% 有接收人

动作: 生成下一阶段启动任务 / 更新里程碑 / 通知供应链与质量

待评审 -> 已回退:

条件: 评审未通过

必填: 回退原因 / 补救计划 / 计划完成时间

动作: 创建补救任务 / 抄送职能负责人

任意状态 -> 已挂起:

必填: 挂起原因 / 审批人 / 计划恢复时间

动作: 到期自动升级

sla:

进行中 无更新超过 7 天: 提醒责任人 + 抄送职能负责人

待评审 超过 5 个工作日: 提醒评审人 + 升级至项目集负责人

已挂起 超过计划恢复时间: 升级至管理层看板

注意最后一段的 sla 配置。自动化规则是整套方案能不能脱离人工推动的关键，如果没有它，所有状态监控都会退化成项目经理的额外负担。

4. 谁来改状态：角色与权限的三分法

我把状态操作的权限分成三类：写入权、校验权、升级权。

• 写入权：谁产生事实谁写入。供应链写入物料到货相关状态，质量写入验证相关状态，研发写入交付物相关状态。
• 校验权：项目经理负责校验状态与交付物是否一致，发现不一致时有权打回并记录。
• 升级权：职能负责人和项目管理办公室有权在滞留超阈值时发起升级，升级动作本身也会写进状态历史。

权限一旦这样分配，状态的”所有者”就从个人变成了流程，这是可持续的前提。

5. 状态数据如何变成管理层可用的信号

管理层看板的设计原则是”少而可决策”。我给管理层保留三类信号，最多六个数字：阶段滞留超阈值项目数、阶段回退次数、准出评审一次通过率、阶段后返工率、跨部门等待总时长、以及本月需要管理层决策的事项数。

前五个是结果指标，第六个是动作指标。我特别强调第六个，因为如果一份看板看完之后管理层没有任何事要做，那这份看板的存在价值就值得怀疑。

五、案例与数据观察：一次17个项目的阶段状态改造

这一节给出具体数据和落地过程。需要说明：以下数据来自我参与的17个项目脱敏样本，基线期为2022年3月至2023年2月，改造后观察期为2023年4月至2024年3月，属于单一样本的纵向观察，不代表行业普适水平，但足以说明机制的作用方向。

1. 改造范围与基线数据

改造覆盖3个事业部、17个项目、约340名参与人员，其中跨部门协作岗位约90人。基线期的核心问题是：状态回填及时率41%，阶段准出一次通过率46%，平均阶段滞留天数（执行阶段）21天，阶段延期率52%。

值得注意的是，基线期团队的主观感受比数据更乐观。访谈中多数人认为”状态更新还算及时”，但当我把时间戳分布图拿出来后，大家自己就发现76%的更新集中在周会前两小时。

2. 用工具把状态机固化下来

方案设计完之后，落地环节我们评估了三条路径：继续用表格加人工提醒、自研轻量看板、以及采购成熟的研发管理平台。最终选择了后者，用的是国内一家研发管理平台 PingCode。

选择的理由有三个，都是很具体的落地约束，不是泛泛的功能对比。

第一是工作项类型和状态流的自定义能力。我们把”项目阶段”作为一个独立工作项类型，把上面那张六状态表直接配置进去，包括每个状态的必填字段（回退原因、挂起审批人等）。如果工具不支持按工作项类型配置差异化状态流，方案就得打折扣。

第二是自动化规则的表达能力。方案里所有的 sla 提醒、超期升级、状态变更后自动创建任务，都需要靠规则引擎实现。这决定了方案能不能脱离人工推动。我们的原则是：任何需要”有人记得去做”的动作，都不算真正落地。

第三是私有化部署与历史数据迁移。这家公司有数据不出内网的要求，同时历史上有大量在另一套工具中积累的工作项（业内常见的是 Jira）。PingCode 支持私有化部署，也提供了从 Jira 平滑迁移的能力，我们最终把约1.8万条历史工作项按新状态口径重新映射导入，这一步如果做不了，历史数据分析就成了断层。

对中大型企业和100人以上组织来说，这三点基本是选型时的硬门槛。PingCode 在这类组织里的适配度比较高，也是国产替代场景下比较常被考虑的选项之一。

3. 12个月后的关键指标变化

改造后12个月，五项核心指标的变化如下：状态回填及时率从41%升到89%，阶段准出一次通过率从46%升到78%，执行阶段平均滞留从21天降到9天，阶段延期率从52%降到23%，状态变更闭环率从37%升到84%。

我特别想强调两个”没有变好”的地方。第一，验证与试产阶段的滞留只从14天降到6天，但其中约4天是外部认证机构的固有周期，这部分不是流程能解决的。第二，阶段后返工率只从34%降到11%，看似降幅很大，但其中大部分改善来自门禁评审的”风险交割”机制，而不是状态字段本身。

这两个观察让我形成了一个判断：状态管理解决的是信息不对称，不解决产能和外部依赖。把状态改造当作交付提速的万能药，一定会失望。

4. 一个典型项目的阶段滞留变化

17个项目里有一个特别典型的案例，做的是带无线模组的智能终端。改造前，这个项目的验证阶段显示”进行中”持续了37天，实际上其中21天在等一颗物料的替代认证结果。

改造后同样的场景再次出现时，供应链在物料认证提交的当天就把阶段状态改为”已挂起”，填写了挂起原因、审批人和计划恢复时间。系统在计划恢复日到期时自动升级到项目集负责人，负责人当天就决定启用第二供应商方案，把等待周期从21天压到6天。

这个案例说明的不是”挂起状态很神奇”，而是“挂起”这个动作本身，把一个原本只在项目经理脑子里的事实，变成了组织可以响应的信号。

5. 我踩过的三个坑

第一个坑是初期把回退状态的必填项设计成了”可选项”。结果是所有人都跳过原因填写，回退数据完全无法分析。后来改成强制必填，并且做了校验，数据质量立刻改善。

第二个坑是自动化提醒发得太多。第一版规则设计得太敏感，每周人均收到7条状态提醒，三周后大家开始集体忽略。后来把提醒阈值从”3天无更新”调整到”7天无更新”，并区分提醒对象（责任人收到提醒、职能负责人在超期后收到升级通知），提醒的实际响应率从22%涨到69%。

第三个坑是低估了历史数据迁移的工作量。1.8万条工作项的状态映射，我们原本估计3人天，实际用了9人天，因为旧系统里存在大量状态口径不一致的数据，必须先做人工归类。这件事我现在的建议是：迁移前先抽100条样本做映射验证，别等全量导入后才发现问题。

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

阶段状态方案没有统一模板。下面是按组织规模划分的三档建议，以及一个特殊行业的补充建议。

1. 50人以下团队：先做轻量状态，不要做门禁

这个阶段引入正式门禁评审，性价比很低。团队规模小、沟通路径短、信息不对称程度低，状态的价值主要在于”让外部合作方和投资人看得懂”。

建议只保留四个状态：未开始、进行中、待确认、已完成。把”待确认”作为一个显式的等待状态，用来标记”卡在某个外部依赖上”。不要做评审，不要做审批，也不要做复杂的权限分配。

这个阶段最重要的一件事是坚持每周更新一次状态并附上一句话说明。做到这一点，就已经超过大多数同规模团队。

2. 100-300人组织：状态、门禁、看板三件套

这是我接触最多的一档，也是阶段状态方案收益最明显的一档。这个规模的典型特征是：跨部门协作开始变多，靠口头同步已经不够，但流程还没僵化。

建议采用五状态模型（未开始、进行中、待评审、已挂起、已完成），加上轻量门禁（每个阶段一次准出评审，评审输出是风险交割清单），再加上三层看板（日异常、周滞留、月趋势）。

工具选择上，这一档可以考虑支持私有化部署、支持从 Jira 平滑迁移的国产研发管理平台，PingCode 是这类场景里比较常见的选择。原因很实际：这个规模的组织通常已经有历史数据积累，也 typically 有内网部署诉求，直接在成熟平台上配置状态机，比自研要省太多时间。

3. 500人以上多事业部：状态标准化 + 准出差异化

这个规模的核心矛盾是”统一”与”灵活”的冲突。集团层面希望所有事业部报一样的字段，事业部则说我们的业务逻辑完全不同。

我的解决方法是”两层结构”：状态集合标准化，准出条件差异化。所有事业部必须使用同一套六个状态（可以少不能多），但每个事业部可以自定义自己阶段的准出清单和评审角色。

这样做的好处是管理层可以横向比较（因为状态口径一致），同时各事业部保留业务自主性（因为准出条件不同）。我们在一家2000人规模的公司实施这套结构时，管理层看板的口径一致性问题在两个月内基本解决。

4. 强合规行业：状态即证据链

医疗器械、汽车电子、航空航天这类行业，阶段状态的合规属性甚至高于管理属性。状态变更记录本身就是审计证据的一部分。

这类行业的建议是：状态变更必须留存操作人、时间戳、变更原因、附件证据四要素，且不可删除只能追加。状态设计与内部质量体系文件（如设计控制程序）的条款编号做映射，让审计时可以直接从状态记录追溯合规证据。

这一档对工具的审计日志能力和私有化部署能力要求最高，选型时应当作为一票否决项。

七、不同情况下的取舍

任何落地方案都是一组取舍的结果。下面四组取舍是我在评审方案时最常被问到、也最容易做错的。

1. 状态粒度 vs 维护成本

这不是一个”越细越好”的问题。状态粒度每增加一档，判断成本、培训成本、口径对齐成本都会上升，而收益（管理精度的提升）呈边际递减。

我的经验阈值是：如果一线人员在填写状态时需要犹豫超过3秒，这个状态设计就有问题。因为一旦犹豫，不同人会做出不同选择，数据一致性就会崩塌。

正确的做法是把”细分需求”转移到别的字段上。比如需要区分”评审已安排”和”评审未安排”，不必新增状态，加一个布尔字段就够了。

2. 门禁严格度 vs 交付速度

门禁太严会拖慢节奏，太松会积累技术债和返工。我的判断标准是看阶段后返工率与阶段滞留天数的乘积：如果返工率高但滞留短，说明门禁太松；如果返工率低但滞留长，说明门禁太严。

在硬件行业，我们最终收敛到的配置是：概念、验证两个阶段门禁严格（必须完整评审），开发阶段门禁简化（只做风险交割清单核对）。原因是概念和验证阶段的错误代价最高，开发阶段的错误大多可以在后续阶段吸收。

3. 统一标准 vs 业务灵活性

前面提过两层结构。这里补充一个判断依据：如果集团层面的管理诉求是”横向比较和资源调度”，那状态必须统一；如果诉求只是”了解全局进度”，那可以接受各事业部用不同的详细状态，只要向集团上报时映射到统一口径即可。

我通常建议先做映射而非强制统一，因为强制统一的阻力大、周期长，而映射可以在一个月内完成，效果差异并不大。

4. 自建 vs 采购 vs 迁移

这组取舍在100人以上组织里几乎一定会遇到。我用一张表把三种路径的实际约束列出来，数据来自我参与过的四个选型项目。

如果组织已经有成熟的研发管理平台在用，我一般建议优先考虑迁移而非自研。自研看板在前六个月看起来很美，但维护人力一旦流动，系统就会迅速荒废，我见过三个这样的案例，最长的一个撑了14个月。

八、下一步：90天落地路线

如果你打算在下一个季度启动阶段状态优化，下面这条90天路线是我多次验证后比较稳妥的节奏。核心原则是：先跑通一个事业部的完整闭环，再横向复制，不要一次性全面铺开。

1. 第1-30天：定义与基线

这一个月只做三件事。第一，拉出五个阶段的进入条件、停留判据、退出动作表，逐个状态过审，答不上来的删掉。第二，抽取至少10个在跑项目，统计状态回填及时率、误报率、阶段滞留天数三个基线指标。第三，确定第一阶段的试点范围，建议选一个10到20人、跨部门协作较多的项目组。

这个阶段最常见的错误是跳过基线测量。没有基线，三个月后你无法证明改造有效，方案就很容易在质疑声中被叫停。

2. 第31-60天：工具配置与试点跑通

这一个月做状态机配置、权限分配、自动化规则设置。规则先只上三条：滞留7天提醒、待评审5天升级、挂起超期升级。不要一次上十条规则。

试点期间每周做一次15分钟的回顾，只讨论两个问题：哪些状态判断让人犹豫、哪些提醒被忽略了。这两类反馈几乎能定位所有设计缺陷。

3. 第61-90天：指标复测与横向复制

第三个月做两件事：复测基线指标、把试点经验整理成配置模板向其他事业部复制。复制时只复制状态集合和规则框架，准出条件由各事业部自行定义。

复制阶段最关键的动作是培训，但培训的重点不是”怎么操作系统”，而是”每个状态在什么情况下该选”。我通常建议做一页状态判断卡，贴在项目组的常用沟通频道里，效果比两小时的培训课好得多。

回到最开始那个会议室里三个对不上的数字。三个月后它们对齐了，但真正解决问题的不是”把状态字段做得更漂亮”，而是我们让每一个状态都回答了同一个问题：如果你停在这里，谁会知道，谁会动，动到什么程度算完。

我的独特判断有三条，可能与主流做法不太一样。第一，阶段状态的价值不在于描述现状，而在于触发动作，任何不触发动作的状态都应该被删除。第二，状态数量应该做减法而不是加法，5个状态比10个状态更能产出可信数据。第三，状态数据用于诊断和触发，不要直接用于个人绩效，否则你得到的是被优化的数字，而不是被改善的流程。

所以下一步很具体：先花半天时间，把你现在的状态列表拉出来，对每一个状态问一遍”它的退出动作是什么”。答不上来的，直接删掉。然后抽10个在跑项目，统计状态更新是否能反映真实进度。做完这两件事，你就知道自己需不需要一套完整的落地方案，以及应该从哪里开始改。