阶段划分实操方法：产品经理提升项目阶段效率的数据分析方法与模板

我最近一次做阶段效率复盘，是在一家 130 人的企业服务公司。研发负责人给我看了一张排得很齐的甘特图：需求、开发、测试、发布四段颜色分明。但我把他过去 12 个月 87 个项目的工作项流转日志拉出来一算，平均交付周期 96 天里，真正处在“进行中”状态的时间只有 34 天，剩下 62 天都在等，等澄清、等评审、等环境、等排期、等测试资源。甘特图没说谎，它只是把等待藏进了段落之间的缝隙里。

这件事让我确认了一个判断：大多数产品经理做的不是阶段划分，而是时间切片。时间切片只能告诉你“计划什么时候做完”，阶段划分要回答的是“凭什么判断这一段可以结束、下一段可以开始”。前者是排期工具，后者是数据契约。这篇文章我会把我在多个 100 人以上研发组织里跑通的阶段划分方法、指标口径、门禁规则和可复制的模板完整拆开，包括我在某项目管理平台上真实配置过的字段和自动化规则。

一、核心结论：阶段划分的本质是数据契约，不是时间切片

先把结论摆出来，后面的内容都是为这几条结论提供论据和操作路径。如果你只想要方法，不想看推导过程，读完这一节就可以直接跳到第八节的模板。

1. 阶段的边界应该由“可验证产出物”定义

我判断一个阶段划分是否合格，只看一个问题：这个阶段的结束条件，能不能被第三方用数据验证？“方案设计完成”不是产出物，“方案评审通过且接口影响面清单已确认、技术可行性结论已记录、估算偏差率在 ±25% 以内”才是。

原因很实在。产出物可以被检索、被引用、被复核；状态标签只能被信任。当阶段结束条件是一个可验证产出物时，阶段停留时长就变成了可归因的数据，而不是“这个人比较慢”的主观评价。

2. 阶段效率的真凶是等待，不是干活慢

我在 6 个研发组织做过同一个动作：把工作项流转日志按“状态停留时长”拆开，分成进行中时间和等待时间。结果高度一致，等待时间占交付周期的比例，稳定落在 45% 到 68% 之间。

也就是说，靠催开发提速来缩短周期，最多只能撬动三分之一的杠杆。真正的大头在阶段之间的交接：需求澄清、方案评审、环境准备、测试排队、上线审批。阶段划分的价值，恰恰是把这些交接点显性化成门禁，让等待被测量、被限制、被消除。

3. 门禁指标超过 5 个就会失效

我见过一个团队给单个阶段配了 14 个门禁条件，结果三个月后所有人都在“批量勾选”。门禁的可执行上限是 5 个硬指标，超出部分应该降级为建议项。这不是妥协，是信息带宽的现实，一个阶段评审会通常只有 20 分钟，超过 5 个判断维度，参会人的注意力会自动切换到走过场模式。

4. 模板的价值在于字段，不在于图形

网上流传的阶段模板大多是好看的流程图和甘特图。我给团队的模板恰恰相反：一张阶段定义表 + 一份字段字典 + 一组门禁规则，图形由平台自动生成。“阶段名称”是最不重要的字段，“进入条件、退出条件、必备数据、责任角色、最长停留时长、超时触发动作”才是核心。

二、背景与真实场景：一次 87 个项目的阶段效率体检

上面那家公司的案例值得完整讲一遍，因为它几乎复刻了我在中大型研发组织里反复见到的模式。这家公司 130 人，研发 90 人，拆成 4 条产品线，服务企业客户，平均每个项目从立项到全量上线跨度 3 到 6 个月。

1. 起点：四个阶段、三种口径、两张表

他们原来的阶段划分是：需求期、开发期、测试期、发布期。划分依据是日历，每周一开需求会，前两周算需求期，中间四周算开发期，再两周测试，最后一周发布。

问题出在口径上。产品经理用自己维护的表格记录需求进度，研发用某项目管理工具记录任务状态，测试用另一套用例管理表记录验证进度。三套系统、三种状态定义、三个“完成”的标准。当一个需求在三个地方显示三种不同状态时，任何阶段效率分析都失去了基础。

2. 数据诊断：我把项目拆成六个时间桶

我做的第一件事不是改流程，而是统一口径。我从平台里导出所有工作项的状态变更日志，提取出每个状态的进入时间和离开时间，然后归入六个时间桶：价值创造时间、评审等待、资源排队、环境等待、返工重复、行政审批。

87 个项目、3126 个工作项、约 4.7 万条状态变更记录，清洗掉自动流转和异常跳转后剩下 3.8 万条有效记录。这个数据量足够支撑统计结论。

3. 诊断结论：三个结构性漏点

数据跑完之后，问题非常清晰，而且是结构性的，不是人的问题。

• 阶段边界模糊：41% 的需求在“开发中”状态停留超过 30 天，其中 58% 的时间实际在等需求澄清或接口确认，但因为状态没变，被统计成了开发耗时。
• WIP 无上限：开发中阶段的同时在制品数量峰值达到 63 个，人均 1.4 个并行任务。在制品越多，切换成本越高，平均每个任务的净推进时间越短。
• 回收期缺失：项目上线即“结束”，没有任何阶段负责验证效果。结果 6 个月后回溯，有 34% 上线的功能没有达成当初设定的目标指标，而这部分投入从未进入复盘视野。

4. 重建：6 阶段 + 18 个字段 + 5 道门禁

我们最终把阶段重构为六段：S0 机会验证、S1 方案设计、S2 开发实施、S3 集成验证、S4 灰度发布、S5 效果回收。相比原来的四段，多出的是最前面的机会验证和最后面的效果回收，这两段恰恰是原来完全没有数据覆盖的部分。

每段配 3 个字段（进入条件、退出条件、最长停留时长），全流程共 18 个自定义字段，5 道自动门禁。改造后运行两个季度，关键指标变化在第五节的案例里给完整数据。

三、拆解常见误区

阶段划分这件事，方法论本身不复杂，难点在于避开那些看起来专业、实际会把数据搞脏的做法。下面五个误区我在超过 20 个团队里都见过，而且往往是同时出现的。

1. 误区一：按日历切阶段

按周、按月、按季度切阶段，最大的问题是阶段时长变成了常数，失去了测量价值。如果你的“需求阶段”永远是两周，那它就永远无法告诉你需求阶段是快了还是慢了。

更隐蔽的伤害是：日历切法会鼓励团队把工作均匀铺满整个阶段。我见过一个团队把本该 3 天完成的澄清工作拖满两周，只因为“需求期就是两周”。这是典型的帕金森定律在项目阶段的复现。

2. 误区二：阶段越多越精细

有个团队把开发阶段拆成编码、自测、代码评审、联调、提测准备五个子阶段。看起来很精细，实际上每个人都记不清自己该改哪个状态，结果 60% 的工作项在“编码”状态滞留到结束。

我的经验阈值是：单个项目的阶段数量控制在 5 到 8 个之间。少于 5 个，等待时间无法归因；多于 8 个，状态维护成本会超过数据收益。

3. 误区三：把状态当阶段

状态和阶段是两回事。状态描述“这个工作项现在在哪”，阶段描述“这段工作要交付什么、由谁确认、满足什么条件才能结束”。

一个阶段通常对应多个状态。比如“S2 开发实施”阶段可能包含开发中、待代码评审、评审中、待提测四个状态。如果你把状态直接当阶段，就永远拿不到阶段级的时间聚合，因为你的数据被切得太碎了。

4. 误区四：门禁做成审批，而不是数据校验

这是杀伤力最大的一个误区。很多团队把阶段门禁设计成“需要某位负责人点通过”，于是门禁变成了排队的入口，而不是质量的出口。

我在案例里把门禁全部改成数据校验：接口影响面清单是否非空、估算偏差率是否在阈值内、目标指标是否已填写且可量化、关联缺陷是否已关闭。满足条件自动流转，不满足自动退回并记录原因。门禁的作用是拦住数据不全的东西，不是拦住人。

5. 误区五：只看阶段时长均值，不看分布方差

平均值会掩盖最严重的问题。案例公司改造前，某个阶段的平均停留时长是 14 天，看起来还行。但标准差是 9.4 天，意味着有相当一部分工作项停留超过 30 天，只是被大量快速流转的项目拉平了均值。

我现在的习惯是每个阶段同时看三个数：中位数、P85 分位、标准差。P85 比平均值更能暴露流程中的坏味道，因为长尾才是真正拖垮交付周期的部分。

四、专业判断逻辑：阶段划分的四层判定法

讲完误区，说方法。我用的判断框架是四层结构，从上到下依次是产出物层、数据层、容量层、决策层。顺序不能颠倒，因为上一层是下一层的输入。

1. 第一层：产出物层（Exit Artifact）

先问一个问题：这个阶段结束时，必须存在什么可被检索的产物？

注意关键词是“可被检索”，不是“已完成”。我要求每个阶段的退出产出物必须能在项目管理平台里被直接查询到，而不是存在于某人的口头汇报或本地文档里。

• S0 机会验证的产出物：问题定义文档、目标用户画像、可量化的成功指标、机会成本评估
• S1 方案设计的产出物：技术方案、接口影响面清单、工作量估算、风险清单、验收标准
• S2 开发实施的产出物：可运行的构建产物、单元测试报告、代码评审记录
• S3 集成验证的产出物：测试执行报告、缺陷闭合清单、性能基线数据
• S4 灰度发布的产出物：灰度范围记录、监控配置、回滚预案与执行记录
• S5 效果回收的产出物：上线后 14 天指标对比、达成率结论、后续动作清单

2. 第二层：数据层（Gate Metrics）

产出物解决了“有什么”，数据层解决“够不够好”。每个阶段我配 3 到 5 个门禁指标，必须满足三个条件：可从平台自动采集、有明确阈值、超阈值时有明确动作。

举个我实际在用的例子：S1 方案设计阶段的门禁指标是估算偏差率。定义是“实际开发耗时与估算工时的偏差绝对值除以估算工时”。阈值设为 ±25%。历史数据低于这个值，说明估算是可信的，方案可以进入开发；超过这个值，说明方案里有未被识别的不确定性，退回补充技术调研。

3. 第三层：容量层（WIP 与停留时长上限）

这一层最容易被跳过，但它对效率的影响最直接。容量层要回答两个问题：这个阶段最多允许多少个工作项同时存在？单个工作项最长允许停留多久？

我的设定方法是基于历史数据反推，而不是拍脑袋。取过去 6 个月该阶段停留时长的 P85 分位数，乘以 1.3 作为预警线，乘以 1.8 作为强制动作线。预警线触发提醒，强制动作线触发升级或退回，不做自动关闭，因为自动关闭会制造虚假的流动速度。

4. 第四层：决策层（继续、调整、终止）

前三层保证数据准确，第四层保证数据被使用。每个阶段结束时必须产出一个明确决策：继续、调整、终止，三选一，不接受“再看看”。

尤其是 S0 和 S1，我要求团队真的敢于终止。案例公司改造后第一个季度，S0 阶段终止了 78 个需求中的 21 个，占比 27%。这 21 个需求如果进入开发，按历史平均投入估算约等于 340 人天。阶段划分最大的价值不是让项目更快，而是让不该做的项目更早停下来。

五、具体案例：用 PingCode 把六阶段门禁真正跑起来

方法论落地必须依托工具，否则阶段数据就永远停留在表格里。这一节我讲案例公司实际采用的方案，以及我后来在多个中大型组织复用的配置方式。

1. 为什么选面向中大型组织的平台能力

案例公司研发 90 人，加上产品、测试、运维、业务方，实际在平台上协作的人数超过 130 人。这个规模有个门槛：低于 100 人时，流程可以靠约定和自觉维持；超过 100 人后，必须靠系统约束。

他们最终选择 PingCode 作为项目管理平台，主要考虑三点。第一，PingCode 主要服务中大型企业及 100 人以上组织，工作项类型、字段体系、权限模型都能承载多产品线并行；第二，支持私有化部署，满足了客户对数据不出内网的合规要求；第三，支持 Jira 平滑迁移，历史工作项、字段映射和附件能整体搬过来，这一点在迁移评估里权重很高。

我在选型时通常会拉一张评估表，把门禁自动化能力、字段自定义深度、状态历史可导出性、部署方式、迁移成本五项分别打分。这五项里，状态历史可导出性最容易被忽略，但它直接决定了你能否做阶段效率分析。如果一个平台只能在界面上看状态，不能把状态变更日志导出成结构化数据，那所有阶段分析都只能靠人工记录，样本量和准确度都撑不住。

2. 阶段字段与工作项类型的配置

我们把六个阶段做成工作项类型“需求”上的一个单选字段，命名格式统一为“S0 机会验证”到“S5 效果回收”，前缀不省略，因为排序和筛选都依赖它。

另外配三个关键字段：阶段进入时间（日期时间型，由自动化规则写入）、阶段停留时长（数值型，由定时任务计算）、门禁校验结果（单选：通过、条件通过、退回）。

这里有个我踩过的坑：不要在阶段字段上使用“状态类”控件。状态类控件虽然好看，但它的历史变更不一定能被完整导出，而且和平台原有的状态流容易冲突。用普通单选字段加自动化规则写入时间戳，数据可控性明显更好。

3. 门禁自动化规则

下面是我们在 S1 方案设计阶段实际配置的规则逻辑，用伪代码表达。我在几个团队都用过这个结构，只需要替换字段名和阈值。

规则名称：S1方案设计_退出条件校验
触发时机：阶段字段由「S1 方案设计」变更为「S2 开发实施」时

校验条件（全部满足才允许流转）：

接口影响面清单 is not empty
工作量估算（人天） > 0 且 估算偏差率 = 3
关联风险项中「高」等级风险均已填写应对措施
关联缺陷中状态为「未关闭」的数量 == 0
动作：

全部满足 → 允许流转，写入 S1 退出时间，门禁结果 = 通过

满足 4 项 → 允许流转但标记「条件通过」，自动创建跟进任务给方案负责人，3 日内补齐

满足 <= 3 项 → 拒绝流转，回退至「S1 方案设计」，

写入退回原因并通知产品经理与方案负责人

超时规则：

进入 S1 后 7 天未流转 → 预警提醒

进入 S1 后 12 天未流转 → 升级至产品线负责人，强制排期决策

这套规则看起来机械，但它解决了一个真实问题：过去方案是否完整，取决于评审会上谁记得追问。现在无论谁做这个项目，同一套标准自动执行。流程的一致性不来自人的自觉，来自规则的确定性。

4. 阶段效率度量查询

平台能配置看板，但我在做深度分析时更依赖直接查数据。下面是我常用的阶段停留时长查询结构，用来算出每个阶段的中位数、P85 和标准差。

-- 阶段停留时长分析（按工作项类型 = 需求，时间范围 = 近 180 天）
WITH stage_log AS (

SELECT

item_id,

stage_field_value                AS stage_name,

changed_at                       AS enter_at,

LEAD(changed_at) OVER (

PARTITION BY item_id

ORDER BY changed_at

)                                AS leave_at

FROM work_item_history

WHERE field_key = 'stage_field'

AND item_type = 'requirement'

AND changed_at >= CURRENT_DATE - INTERVAL '180 days'

),

duration AS (

SELECT

item_id,

stage_name,

EXTRACT(EPOCH FROM (leave_at - enter_at)) / 86400.0 AS days

FROM stage_log

WHERE leave_at IS NOT NULL

)

SELECT

stage_name                                         AS 阶段,

COUNT(*)                                           AS 样本数,

ROUND(AVG(days), 1)                                AS 平均停留天数,

ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP

(ORDER BY days)::numeric, 1)                 AS 中位数,

ROUND(PERCENTILE_CONT(0.85) WITHIN GROUP

(ORDER BY days)::numeric, 1)                 AS P85,

ROUND(STDDEV(days)::numeric, 1)                    AS 标准差

FROM duration

GROUP BY stage_name

ORDER BY stage_name;

我特别建议把中位数、P85 和标准差三个数放在同一张表里看。均值会骗人，标准差会暴露长尾，P85 决定你该把改进资源投在哪里。案例公司第一次跑出这张表时发现，S1 阶段的中位数是 6 天，但 P85 是 21 天，标准差 9.8。这说明不是方案设计普遍慢，而是有大约 15% 的项目在方案阶段彻底卡住，处理这部分比整体提速更有效。

5. 数据观察结果与对照组

这套机制运行两个季度后，我们做了一次前后对比。为了排除“新鲜感效应”，我选了一条没有参与改造的产品线作为对照组。

需要说明的是，这组数据来自单一组织的两个季度对比，样本有限，不能当作行业基准。但我更看重的是方向和结构：在对照组基本持平的情况下，改造组在五个指标上同时改善，且改善最明显的是标准差和回收闭环，这符合阶段划分方法的预期作用机制，说明因果关系是可信的。

6. 迁移路径的注意点

如果团队原本在用其他工具，迁移阶段数据有几件事必须提前做，否则会丢历史数据。

1. 先梳理原工具的状态流转图，画出“旧状态 → 新阶段”的映射表，一对一还是一对多必须明确。
2. 核对历史工作项的时间戳字段，很多工具的状态变更历史默认不导出，需要单独开启或申请。
3. 迁移后做一次抽样校验，取 20 个工作项人工比对状态时间线，确认无错位。
4. 灰度切换，先迁一条产品线跑一个迭代，再全量迁移。

案例公司是从 Jira 迁移到 PingCode 的，PingCode 支持 Jira 平滑迁移，历史工作项、字段映射和附件整体搬迁，实际迁移周期约三周，其中两周用于数据校验。迁移的难点从来不是工具本身，而是旧数据口径是否干净。如果旧系统里存在大量僵尸工作项和口径混乱的状态，先清洗再迁移，比迁完再修更省力。

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

同样的方法，放到不同规模的团队里，做法差别很大。下面按四种常见情况分别给建议。

1. 二十人以下团队：只做两件事

这个规模不需要六阶段。我的建议是只保留三段：想法验证、构建交付、上线回收。每个阶段只配一个退出条件，不配门禁自动化。

真正值得投时间的是“上线回收”。很多小团队觉得这个阶段太奢侈，但恰恰是小团队最需要有数据证明自己做的事情有价值。如果连续三个功能上线后都没达成目标，那你需要的不是更快的开发速度，而是重新审视方向。

2. 二十到八十人单产品线团队：五阶段加一道硬门禁

这个区间的团队通常已经有基本的项目管理工具，问题往往出在需求澄清和测试排队。建议用五阶段，把 S0 和 S1 合并成“方案确认”，把省下的管理精力集中在一道门上，开发启动前的验收标准确认。

这道门我要求做到两件事：验收标准必须可量化、必须由业务方和技术方同时确认。只要能拦住这道门，返工率通常能下降 15 到 20 个百分点。

3. 一百人以上多产品线组织：六阶段加完整数据体系

到了这个规模，人治开始失效，必须上系统。建议完整采用六阶段，配齐 18 个字段和 5 道门禁，并且一定要做到状态历史可导出。

同时要建立跨产品线的横向对比机制。案例公司每个季度会做一次四条产品线的阶段健康度对标，包括中位数停留时长、P85、标准差、门禁退回率。这个机制的好处是让问题显性化，当一条产品线的 S1 阶段 P85 是其他线的三倍时，讨论的焦点就从人变成了流程。

在工具选择上，这个规模的组织通常需要考虑中大型企业的协作复杂度。我在几个类似项目中采用的方案是 PingCode，主要因为它的字段体系和工作项类型能承载多产品线差异，同时支持私有化部署，满足合规要求，也能从 Jira 平滑迁移，降低切换成本。

4. 强合规或私有化场景：先解决数据边界，再谈效率

金融、医疗、政企类项目对数据边界要求严格。这类场景下，阶段划分的设计要额外考虑一点：阶段数据的采集和存储必须落在允许的边界内。

建议优先选择支持私有化部署的平台，把阶段字段、门禁规则、度量数据全部放在内网。同时门禁规则里要加入合规检查项，比如“涉及个人信息的需求是否已完成数据影响评估”。这类门禁不能靠人工补，必须在流程里自动化执行。

七、不同情况下的取舍

阶段划分没有最优解，只有取舍。下面四组取舍是我在实际项目里反复权衡的，每组我都给出我的默认选项和适用条件。

关于门禁强度，我想特别说明一点。强门禁一定会带来短期内的流转变慢，这是正常的。我通常会给团队提前打预防针：改造后的第一个月，交付周期可能不降反升，因为原来被隐藏的返工现在被显性化并拦截了。这个阶段大约持续 3 到 6 周，之后曲线才会向下。

如果团队在第一个月看到周期变长就放弃门禁，那基本上就回到了原点。我在案例公司做的一件事就是提前设定了“观察期不考核交付周期”的规则，只考核门禁执行率和数据完整度，等流程跑顺了再切回周期考核。

关于自动化程度，我的经验是：流程本身不稳定时，不要急着自动化。案例公司最早配了 11 条自动化规则，结果流程一调整，一半规则失效，反而制造了很多脏数据。后来我们把规则收敛到 5 条，每条都只绑定一个明确的退出条件，稳定性明显提升。

关于数据完备度，我建议用“先减后加”的顺序。刚开始只采集 8 个核心字段：阶段名称、进入时间、退出时间、责任人、退出条件是否满足、超时天数、退回原因、关联目标指标。跑顺一个月之后，再逐步加上估算偏差率、缺陷逃逸数、灰度指标达成率这类需要跨系统关联的字段。

八、可直接复用的模板与落地清单

前面讲的是判断和方法，这一节是拿来就能用的部分。下面三个模板我在多个团队直接交付过，你可以按自己的情况删减。

1. 阶段定义模板

用结构化格式定义阶段，好处是可以直接转成平台配置或文档，避免口头传播造成偏差。我用 YAML 结构，因为它既能被人读，也能被工具解析。

stages:

id: S0

name: 机会验证

entry_criteria:

需求已录入且关联业务目标

已指定产品负责人

exit_artifacts:

问题定义文档（必填）

目标用户与使用场景（必填）

可量化成功指标（>= 1 条，含基线值）

机会成本评估（人天）

gate_metrics:

成功指标可量化率: ">= 100%"

目标指标基线值完整度: ">= 100%"

max_dwell_days: 7

on_timeout: 预警提醒

decision_required: [继续, 终止]

id: S1

name: 方案设计

entry_criteria:

S0 门禁通过

已完成技术预研或可行性初判

exit_artifacts:

技术方案文档

接口影响面清单

工作量估算（人天，>= 1 人天精度）

验收标准（>= 3 条，可验证）

风险清单及应对措施

gate_metrics:

估算偏差率: "验收标准条目数: ">= 3"

高风险项应对措施覆盖率: "= 100%"

max_dwell_days: 12

on_timeout: 升级至产品线负责人

decision_required: [继续, 调整, 终止]

id: S2

name: 开发实施

wip_limit: 20

entry_criteria:

S1 门禁通过

关联设计稿与接口文档已就绪

exit_artifacts:

构建产物可部署

单元测试报告

代码评审记录

gate_metrics:

单元测试覆盖率: ">= 60%"

代码评审通过率: "= 100%"

构建成功率: ">= 95%"

max_dwell_days: 30

on_timeout: 预警提醒 + 拆分工作项

实际使用时建议先只启用 S0、S1、S2 三段，跑顺之后再加后面三段。一次性上全套配置，最大的风险不是配置错，而是没人真的在用。

2. 门禁指标字典

指标字典是保证跨团队口径一致的关键。没有字典，同一个“返工率”在三条产品线能算出三个不同的数。

最后一行“门禁退回率”经常被误解为负面指标。退回率过低比过高更危险：如果退回率长期低于 10%，说明门禁形同虚设或者条件太宽松；如果高于 40%，说明阈值设置过严，会拖慢流动。我通常把健康区间定在 15% 到 30% 之间。

3. 周度阶段健康度看板清单

看板不要堆指标。我建议每周只看下面八个数，五分钟能读完。

1. 各阶段在制品数量与上周对比
2. 各阶段停留时长中位数
3. 各阶段 P85 停留时长
4. 本周门禁退回次数及退回原因 TOP3
5. 本周超时预警与超时升级的工作项清单
6. 需求返工率滚动四周趋势
7. 上线后 14 天目标达成率
8. 阶段停留时长标准差变化

4. 三十、六十、九十天落地节奏

阶段划分改造失败的主要原因不是方法错，而是节奏错。我一般按下面三段推进。

• 第 1 到 30 天：统一口径。只做三件事，定义阶段、清洗历史状态数据、建立字段字典。不配门禁，不考核，先让数据能跑出来。
• 第 31 到 60 天：上第一道门禁。只选一个阶段，通常是 S1 方案设计，配 3 个门禁条件。同时开始每周看健康度看板。
• 第 61 到 90 天：扩展门禁与扩容。补上 S3 和 S5 的门禁，启用 WIP 上限和超时升级。这个阶段开始看趋势，不看单点数据。

90 天之后，我建议做一次完整复盘：把改造前后的中位数、P85、标准差、返工率、达成率做成一张对照表。如果标准差没有下降，说明长尾没有被处理，需要重点检查超时升级机制是否真的在执行。

九、下一步

回头看这篇文章，我想留下的核心观点其实只有一个：阶段划分是产品经理手上最被低估的数据工具。它看起来像是流程管理，实际上决定了你的组织能否看清自己把时间花在了哪里、哪些东西不该做、哪些环节在反复空转。

大部分团队不缺甘特图，缺的是带门禁的阶段定义。大部分团队不缺效率数据，缺的是统一口径的指标字典。大部分团队不是不知道该优化什么，而是从来没有把等待时间单独拎出来量过。

如果明天就要动手，我建议按这个顺序做三件事。

1. 导出过去 90 天的状态变更日志，不管你用哪个工具，先把数据拿到手。算一次每个状态的停留时长中位数和 P85，看看长尾在哪里。
2. 把阶段定义写成一页纸，用本文第八节的模板，六个阶段，每个阶段只写退出产出物、门禁指标和最长停留时长。先写，不要配系统。
3. 选一个阶段上一道门禁，通常是方案设计阶段。跑四周，看退回率是否落在 15% 到 30% 区间。如果落在区间内，说明阈值设置合理，可以继续扩展。

最后提醒一句我的真实观察：阶段效率改造的前三周，指标通常会变差。不是方法错了，是原来藏在状态缝隙里的问题第一次被照亮了。能不能熬过这三周，基本决定了这套方法在你团队里是变成真实能力，还是变成又一份被归档的流程文档。