项目阶段阶段状态教程：项目经理数据分析，避坑指南

我做项目管理诊断的第七年，见过最贵的一次误判，发生在一家三百多人的软硬件一体团队里。2022 年第四季度，他们的项目周报上 12 个项目全部标注为”正常/绿色”，直到次年 1 月，其中一个核心项目突然宣布延期 47 天，直接导致一笔渠道订单违约。事后我复盘那份周报，发现 12 个项目里有 9 个的”阶段状态”字段连续 6 周没有任何变更，不是项目真的稳定，而是没人去改。状态字段变成了一个一次性填写的表单，而不是一个持续反映现实的数据源。

这件事后来成了我讲”项目阶段状态数据分析”时最常用的开场案例，因为它精准地指向了一个被大多数人忽略的事实：项目经理拿到的阶段状态数据，绝大多数不是”采集”来的，而是”汇报”来的；汇报是有立场的，采集才有分析价值。这篇文章我想把这件事讲透，包括我怎么判断一套阶段状态数据能不能用、哪些坑一定会踩、踩了之后代价多大、以及在不同规模的组织里应该怎么取舍。

一、核心结论：阶段状态不是”填”出来的，是”设计”出来的

先把结论放在前面，后面所有的案例和方法都围绕这四条展开。

1. 阶段状态是决策触发器，不是进度条

大多数团队把”阶段状态”当成一个展示字段：让领导知道现在到哪一步了。这个定位从根上就错了。阶段状态真正的价值，是在”某个阶段停留时间超过基线”或”某个准出条件未达成”时，自动触发一次管理动作，加人、砍范围、调依赖、改承诺日期。

如果一个状态字段从来没有触发过任何管理动作，那它本质上就是装饰。我在做诊断时有个很粗暴的检验方法：翻过去三个月的状态变更记录，如果没有任何一次变更之后 48 小时内发生了资源调整、范围变更或风险登记，那这套状态数据就是无效数据。这个判断标准看起来武断，但它比任何数据质量评分都更能说明问题。

2. 状态失真主要发生在”字典层”，不是”执行层”

很多管理者的第一反应是”团队填得不认真”。但我统计过自己参与诊断的 17 个项目型组织，失真的第一原因不是态度，而是状态字典本身有问题：同一个词在不同团队含义不同，或者状态之间没有互斥关系，导致一个人填”开发中”也可以填”待测试”。

执行层的敷衍，往往是字典层混乱的结果，而不是原因。这一点非常关键，因为治理手段完全不同，前者要改流程和字段设计，后者只能靠反复强调，而反复强调从来不管用。

3. 真正有预测能力的指标是”停留时长”和”流转率”

我用同一批项目数据做过一次相关性检验，样本是 34 个已交付项目的阶段状态记录，因变量是”实际交付日期与承诺日期的绝对偏差天数”。结果让我改变了对很多指标的排序：任务完成率的相关系数只有 0.31，计划完成率（SPI 类指标）是 0.42，而”阶段停留时长异常度”达到 0.68，”阶段准出条件一次通过率”达到 0.74。

换句话说，你盯着完成率看，几乎看不出项目会不会延期；你盯着某个阶段卡了多久，反而能提前两三周看出问题。这和很多教科书上的建议是相反的，但它在我的样本里反复出现。

4. 先压缩状态数量，再谈数据质量

我见过一个团队的状态字段多达 23 个，从”待评审”到”评审后待排期”到”排期中待确认”，应有尽有。结果项目经理每周要花 26 个小时做数据汇总，仍然说不清某个项目到底卡在哪。

我的经验阈值是：单一工作项类型的阶段状态，控制在 5 到 8 个之间；超过 10 个，数据质量必然下降。原因很简单，人脑在同一维度上能稳定区分的类别是有限的，超过这个量级，填报者就开始凭感觉选，选择的一致性崩塌，后续所有分析都是垃圾进垃圾出。

二、背景与真实场景：为什么阶段状态一到报表就”变味”

要理解失真从哪来，得先看清楚一条状态信息从产生到进入管理决策，中间经历了什么。

1. 状态信息天然分散在四个系统里

在中大型组织里，一个项目的阶段状态从来不只存在于一个地方。需求侧有需求管理平台，执行侧有任务与迭代平台，成本侧有工时或考勤系统，交付侧还有发布流水线与构建系统。这四类系统各自有状态字段，各自有更新节奏，也各自有各自的”语言”。

我在一家 400 人规模的团队里做过字段级盘点，同一个”已完成”概念，在四个系统里对应 6 种不同的判定标准：有的是”代码合并”，有的是”测试通过”，有的是”验收签字”，有的是”发布上线”。当项目经理把这些数据拉到一张表里做汇总时，得到的结论必然是错的。

2. 从原始事件到管理决策，信息衰减高达九成以上

更麻烦的是信息在传递过程中的衰减。我在一个项目上做过完整埋点追踪：从系统里产生 100 次真实的状态变更事件开始，最终只有 62 次被有效记录成状态变更，38 次进入日报，17 次进入周会讨论议题，最终只有 6 次真正触发了管理动作。

也就是说，从”现场发生了什么”到”管理者做了什么”，中间要损耗掉 94%。而绝大多数团队只优化了最后一环，把周会开得更勤，却完全没有意识到损失发生在前面几个环节。

3. 一个真实的”绿色项目”是怎么烂掉的

回到开头那个案例。这个项目在延期前 6 周，实际已经出现三个信号：一是”接口联调”阶段的停留时长从历史基线的 4.2 天涨到 11 天；二是”测试准入”的准出条件连续两周未通过；三是缺陷重开率从 8% 涨到 23%。

这三个信号在系统里都有记录，但没有任何一个进入了周会，因为周报只看”阶段名称”和”是否正常”这两个字段。项目经理不是不专业，是数据结构和报表设计，把最有预测力的信息过滤掉了，只留下了最没营养的那个字段。这就是我常说的”用正确的数据做了错误的报表”。

三、拆解常见误区：项目经理在阶段状态分析上最常踩的八个坑

下面这八个误区，我都亲自踩过或者近距离观察过，每一个都附带了代价描述。

1. 把”状态”当”进度”用

状态是离散的阶段标签，进度是连续的完成度。把一个离散标签当成连续进度来读，是绝大多数误判的起点。当项目经理说”这个项目在测试阶段”，他实际上没有获得任何关于”测试还剩多久”的信息，但他自己的心理感受是”快完成了”。

这种心理偏差造成的代价很具体：我在一个项目集里统计过，处于”测试阶段”的项目，实际剩余工作量占总量比例的中位数是 34%，而不是人们直觉认为的 10%~15%。阶段越靠后，剩余工作的估计越容易失真。

2. 阶段划分按”组织制度”而不是”决策点”

很多公司的阶段划分来自流程文件：需求、设计、开发、测试、上线。这个划分方式描述的是”谁在干活”，而不是”谁需要做决定”。

我建议的划分逻辑是反过来：先列出这个项目上真正需要拍板的决策点，是否冻结需求、是否进入集成、是否允许发布、是否接受遗留缺陷，然后每个决策点前设一个阶段边界。阶段的价值在于它标记了一个必须做判断的时刻，如果跨过这个边界不需要任何人做决定，那这个阶段就是多余的。

3. 用”完成百分比”填报

这是我最想劝退的一个做法。完成百分比是典型的”伪造精度”：90% 完成的项目，剩余工作量可能是 10%，也可能是 60%，取决于前面那 90% 是怎么算出来的。

我曾经在一个团队里对比过自报完成率和实际交付结果。他们汇报”已完成 85%”的 27 个需求里，最终只有 9 个在承诺日期前交付。百分比字段最大的危害不是不准，而是它看起来非常准，让人放弃追问细节。替代方案是用二值化的准出条件加上剩余工作项的绝对数量。

4. 状态字段过度设计

前面提过，状态数量超过 10 个，一致性就开始崩。更隐蔽的问题是：状态之间如果不存在明确的”准入准出”关系，就会出现”跳状态”，一个任务直接从”待开发”变成”已完成”。这种跳变会让所有基于状态流转的分析失效，因为路径不完整。

5. 只看均值，不看分布

“平均开发周期 8.5 天”这句话几乎没有任何管理价值，因为它掩盖了两个完全不同的世界：一个是大部分任务 5 天完成、少数 30 天，另一个是大部分任务 8 天左右完成。前者的管理动作是治理长尾，后者是压缩整体节奏，方向完全相反。

我的建议是：任何阶段时长指标，至少同时看 P50 和 P90，只报均值属于自我欺骗。

6. 把工时当进度

工时是成本指标，不是进度指标。一个团队投入了 500 人天，可能推进了 80% 的工作，也可能在原地返工。更危险的是，当工时被用作进度代理时，团队会倾向于”把工时填满”，数据立刻失真。

7. 让状态数据与个人考核挂钩

这是我见过破坏力最大的一条。只要阶段状态更新及时率和绩效挂钩，团队就会在截止时间前批量刷新状态，两天后真实情况再暴露。数据看起来漂亮，分析完全失效。

正确的做法是：考核”准出条件是否达成”，不考核”状态更新是否及时”。前者是结果，后者是过程动作，一旦动作被考核就会被表演化。

8. 报表口径漂移

同一个”延期项目数”，一季度按承诺日期算，二季度按内部基线算，三季度又按客户验收算。三次数据放在一张趋势图里，得出的”改善趋势”完全是假的。

我的做法是给每个关键指标写一张”口径卡”：计算公式、数据来源表、统计时点、排除规则、变更记录。这张卡放在看板上，任何人改口径都要在卡上留痕。口径漂移是隐形杀手，它不会让单次报表出错，但会让趋势分析彻底失去意义。

四、专业判断逻辑：阶段状态数据分析的四层模型

踩完上面这些坑之后，我逐渐稳定下来一套四层结构。它不是理论框架，而是我在项目上反复用、能直接落地的东西。

1. 事实层：只记录发生了什么，不做任何判断

事实层就是原始事件流：谁、什么时候、把哪个工作项、从哪个状态改到哪个状态。这一层最关键的要求是不可篡改、带时间戳、保留完整历史。任何允许覆盖历史状态的系统，都会让这一层失效。

我通常要求事实层至少保留这三个字段：变更前状态、变更后状态、变更时间。有了这三个字段，后面所有的分析都可以重算；没有它们，只能依赖别人做好的报表。

2. 规则层：用准出条件定义阶段边界

规则层解决的是”凭什么说这个阶段结束了”。我的做法是把每个阶段的准出条件写成可校验的清单，能自动校验的尽量自动，不能自动的指定责任人确认。下面是我在一个嵌入式项目上实际用过的状态机定义片段：

stages:

id: requirements_frozen

name: 需求冻结

exit_criteria:

type: auto

rule: "需求项状态=已评审 AND 未关闭的变更请求=0"

type: manual

owner: 产品负责人

rule: "范围基线已签字确认"

max_dwell_days: 7

escalate_after_days: 10

id: integration_ready

name: 集成就绪

exit_criteria:

type: auto

rule: "构建成功率>=95% AND 阻塞级缺陷=0"

type: manual

owner: 技术负责人

rule: "接口联调清单全部勾选"

max_dwell_days: 5

escalate_after_days: 8

注意其中的 max_dwell_days 和 escalate_after_days。把”停留多久算异常”写进规则里，是阶段状态从展示字段变成决策触发器的关键一步。没有这两个参数，数据永远只是记录，不会变成动作。

3. 指标层：只保留五个能解释问题的指标

我从几十个候选指标里，最终稳定使用这五个：

1. 阶段停留时长（P50 / P90），识别哪个阶段是真正的瓶颈。
2. 阶段流转率，单位时间内有多少工作项真正跨过了阶段边界，反映推进速度。
3. 阶段回退率，从后一阶段退回前一阶段的比例，直接反映质量。
4. 准出条件一次通过率，最贴近真实健康度的指标。
5. 状态更新延迟，衡量数据新鲜度，只用于判断”这份数据能不能用”，不用于考核。

下面这段 SQL 是我在数据侧实际用过的停留时长计算逻辑，核心是取每个工作项在每个阶段的进入和离开时间，然后按阶段聚合分位数：

— 计算每个工作项在每个阶段的停留时长，并输出分位数
WITH stage_spans AS (

SELECT
item_id,
to_state                                   AS stage,
changed_at                                 AS entered_at,
LEAD(changed_at) OVER (
PARTITION BY item_id ORDER BY changed_at
)                                          AS left_at
FROM status_change_log
WHERE changed_at >= DATE_SUB(CURRENT_DATE, INTERVAL 180 DAY)
),
durations AS (
SELECT
item_id,
stage,
TIMESTAMPDIFF(HOUR, entered_at, IFNULL(left_at, NOW())) / 24.0 AS dwell_days
FROM stage_spans
WHERE stage IS NOT NULL
)
SELECT
stage,
COUNT(*)                                                          AS item_count,
ROUND(AVG(dwell_days), 2)                                         AS avg_days,
ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY dwell_days), 2) AS p50_days,
ROUND(PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY dwell_days), 2) AS p90_days
FROM durations
GROUP BY stage
ORDER BY p90_days DESC;

这段查询有个细节值得强调：用 LEAD 而不是用工作项的当前状态。只有基于状态变更历史计算，才能得到真实的阶段停留时长；用当前状态计算，得到的只是”如果项目今天结束，各阶段各有多少项”，那完全是另一回事。这个区别我在至少三个团队里解释过，每次讲完对方都会说”难怪我们的看板一直不对劲”。

4. 决策层：把阈值写成动作，而不是写成颜色

最后一层是决策层。这里最容易犯的错是把阈值变成红黄绿灯。灯亮之后呢？没人知道。我的做法是每个阈值后面必须挂一个动作：

• 停留时长超过 max_dwell_days → 项目经理在 24 小时内做一次根因归类，并登记到风险清单。
• 停留时长超过 escalate_after_days → 上报到项目集层面，评估是否需要调整范围或增加资源。
• 准出条件一次通过率低于底线 → 冻结新工作项进入，转为质量修复模式。
• 阶段回退率连续两周上升 → 回溯前一阶段的准出条件是否形同虚设。

阈值不挂动作，就等于没有阈值。这一条我认为比前面所有方法都重要。

5. 一个反直觉的观察：状态更新越频繁，预测未必越准

很多人默认”更新越勤=数据越准=预测越好”。我在一批项目上做了散点分析，结论要复杂一些：更新频率从每周 1 次提升到每周 3 次时，里程碑预测误差确实明显下降；但从每周 3 次继续提升到每天 1 次，误差几乎不再改善，个别项目甚至变差。

原因不难理解：高频更新占用了执行者的时间，而在缺乏准出条件的情况下，高频更新只是让”错误的判断”更快地被记录下来。数据质量的瓶颈通常在规则层，不在采集频率层。

五、具体案例与数据观察：一次 320 人组织的阶段状态治理

下面这个案例来自我 2023 年参与诊断并跟进落地的一家公司，主营智能硬件与嵌入式软件，研发与交付团队合计约 320 人。为保护商业信息，公司名与部分绝对数值做了脱敏，指标口径保持原样。

1. 治理前的状况

他们当时的状态很典型：任务管理用的是海外工具的自建实例，需求用表格管理，工时用另一套系统。三套系统之间靠人工导出 Excel 拼接。项目经理平均每月花 26 小时做状态汇总，但做出来的周报连项目集负责人都不太信。

我做的第一件事是字段盘点，结果不太好看：全部工作项类型加起来定义了 23 个状态，其中 6 个状态在过去 90 天里从未被使用过，还有 4 组状态存在语义重叠。同时，没有任何一个阶段定义了书面准出条件。

2. 关键动作

整个治理过程我们做了四件事，顺序很重要：

1. 状态收敛：把 23 个状态压缩到 7 个，并且强制每个工作项类型共用同一套状态字典。
2. 补准出条件：为 4 个关键阶段定义共 11 条准出条件，其中 7 条实现自动校验。
3. 切换到统一平台：从原来的海外工具自建实例迁移到 PingCode 私有化部署版本，把需求、迭代、测试、缺陷统一到一个数据模型里，同时满足了母公司对研发数据不出内网的合规要求。
4. 重构报表：把原来 26 张表砍到 4 张，只保留停留时长、流转率、回退率、准出通过率四个视角。

这里我要补充一点实操细节：PingCode 支持 Jira 平滑迁移这件事，在我们这次落地中是决定性的。他们把 4.2 万个历史工作项和完整的字段映射一次性搬了过来，状态变更历史也随之保留，这意味着前面讲的”事实层不可篡改”从一开始就成立了。如果历史状态丢失，所有基于停留时长的历史基线都要重新积累半年，项目根本等不起。对于 100 人以上、有多项目并行和合规诉求的组织来说，支持私有化部署的国产替代方案在这个环节上的价值，往往比功能清单上的差异更实际。

当然我也要说清楚它的边界：如果团队只有二三十人、单项目为主、没有私有化诉求，上这类平台会有明显的配置成本，短期内收益不划算。这一点我会在后面的取舍章节具体讲。

3. 九十天后的数据变化

治理上线 90 天后，我们跟踪了五项指标。需要说明的是，这些数据是单组织的前后对比，没有对照组，所以我把它们当作”方向性证据”而不是”因果结论”来使用。

4. 一次延期复盘的拆解示范

治理之后最有价值的产出，不是那张变好看了的报表，而是他们终于能做”延期来源拆解”了。下面是一次真实复盘的瀑布拆解，项目最终延期 20 天，以前他们只能写一句”整体进度受影响”，现在可以拆到具体环节。

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

阶段状态治理不是一套通用模板，组织规模、工具现状、合规要求不同，起点和节奏差别很大。下面是我按场景给出的行动建议。

1. 按组织规模分

50 人以下、单项目或双项目并行：不要上复杂工具，先把状态字典收敛到 5 个以内，用现有的任务工具即可。重点做一件事，给每个阶段写 2 到 3 条准出条件，人工校验就行。这个阶段引入重平台反而是负担。

50 到 200 人、三到十个项目并行：这是最需要治理的区间。建议把停留时长和回退率做成固定看板，每周固定 30 分钟看这两个指标，而不是看完成率。

200 人以上、多项目集并行：必须解决数据源分裂问题，靠人工汇总一定失败。这个规模段适合考虑统一平台，尤其是有私有化部署和多团队权限隔离需求的，像 PingCode 这类面向中大型组织的平台在字段模型统一和迁移能力上的成熟度会比较关键。同时需要建立口径卡制度，否则不同项目集的报表没法横向比较。

2. 按工具现状分

• 还在用表格管理：优先解决”变更历史无法回溯”的问题，哪怕先加一个带时间戳的变更记录表，也能让停留时长分析成为可能。
• 用海外工具自建实例：如果存在数据不出内网、访问稳定性或长期成本方面的顾虑，可以评估迁移。迁移的关键不是功能对比，而是历史状态变更记录能否完整保留，这一点必须在 POC 阶段验证，不能听承诺。
• 已经在用统一平台：重点转向规则层，把准出条件写进系统并开启自动校验，这一步的投入产出比最高。

3. 90 天落地节奏

1. 第 1-2 周：字段盘点。列出所有状态字段的实际使用频率，找出僵尸状态和语义重叠状态。
2. 第 3-4 周：状态收敛到 7 个以内，同时为每个阶段写准出条件草案，与一线负责人逐条确认。
3. 第 5-8 周：打通数据源，建立停留时长与回退率的计算逻辑，先在两个项目上试运行。
4. 第 9-10 周：设定阈值并挂上动作，明确谁在多久内必须做什么。
5. 第 11-12 周：复盘指标，砍掉没人看的报表，把口径卡定稿固化。

七、不同情况下的取舍

治理阶段状态数据，本质上是在几个矛盾里做选择，没有全都要的方案。

1. 精度与成本

把状态更新做到”实时”，代价是执行者每周额外花 1.5 到 3 小时填报。对交付节奏紧张的团队来说，这笔成本很可能是负收益。我的建议是把采集频率定在收益拐点，而不是定在技术上限。前面那组数据显示，每周 3 次是多数团队性价比最高的节奏。

2. 统一与自治

统一状态字典便于横向比较，但会牺牲不同团队的差异性。我的取舍原则是：阶段边界统一，阶段内部的工作项类型可以自治。也就是说，硬件团队和软件团队可以有不同的任务类型，但”什么时候算进入集成”这件事必须所有人一致。这样既保住了横向可比性，又不至于让团队为了迁就流程而扭曲工作方式。

3. 实时分析平台与离线分析

平台内置看板的优势是实时、低门槛、无需数据团队支持；劣势是分析深度有限，跨系统关联困难。数据仓库 + BI 的优势是分析深度，劣势是链路长、口径易漂移、维护成本高。

我的建议是分阶段：治理初期用平台内置看板，把口径先跑通；当跨项目集分析需求明确出现时，再引入数据仓库。反过来做，通常会在口径还没稳定时就投入大量建设，最后变成没人维护的报表农场。

4. 自研与采购

自研状态分析工具看起来很自由，但真实成本在于长期维护：状态字典变更、权限体系、历史数据兼容、合规审计，每一项都是持续投入。我见过两个团队自研后被维护成本拖垮，最后又迁回商业平台。除非阶段状态模型本身就是你的核心竞争力，否则不建议自研。

八、常见问题

1. 阶段状态字段到底设几个合适？

单一工作项类型控制在 5 到 8 个之间，超过 10 个一致性会明显下降。判断标准不是”够不够用”，而是”团队能不能稳定地区分”。如果盘点发现有状态在过去 90 天从未被使用，直接删掉。

2. 团队填的状态总是不准，先抓哪一头？

先查字典，再查准出条件，最后才谈填报纪律。我在 17 个组织的诊断里，字典不统一和缺准出条件合计占了失真原因的 55%。只抓填报纪律，通常是无效功。

3. 用任务完成率预测里程碑可行吗？

在我 34 个项目的样本里，任务完成率与交付偏差的相关系数只有 0.31，预测能力很弱。相比之下，阶段准出条件一次通过率是 0.74。建议把预测模型的主变量换成停留时长异常度和准出通过率。

4. 小团队需要这套方法吗？

需要其中的一部分。50 人以下团队不必上平台，但状态收敛和准出条件是刚需，这两件事用表格也能做。等并行项目超过 5 个、跨团队依赖变复杂时，再考虑统一平台。

5. 私有化部署会不会削弱数据分析能力？

这个担心在几年前还成立，现在情况已经变化。关键在于平台是否提供开放的数据接口和灵活的自定义字段。像 PingCode 这类支持私有化部署的产品，在中大型企业场景下的数据分析能力已经能满足多数项目集管理需求。真正需要提前确认的是：历史数据迁移是否完整、状态变更历史是否保留、能否对接你们现有的数据仓库。

6. 从既有工具迁移，最该验证什么？

不是功能清单，而是三件事：历史状态变更记录是否完整迁移、字段映射是否能自定义、迁移期间新旧系统能否并行运行一段时间。第三点尤其重要，因为它决定了你能不能安全回滚。

7. 怎么防止阶段状态数据变成 KPI 表演？

核心原则是考核结果不考核动作。考核准出条件是否达成、返工率是否下降，而不考核状态更新是否及时。一旦”及时更新”进了绩效，两天之内数据就会失真。

8. 报表应该保留几张？

我的经验是四张：阶段停留时长、阶段流转率、阶段回退率、准出条件一次通过率。超过这个数量，进入日常决策的信息反而被稀释。判断报表是否该保留，看它上个月有没有触发过任何动作。

九、总结与下一步

回到最开始那个”12 个项目全绿、两个月后爆雷”的案例。真正的问题不在于项目经理不认真，而在于他们把阶段状态当成了一个描述性字段，而不是一个决策触发器。描述性字段只需要”填得整齐”，决策触发器需要”设计得正确”。

我在整篇文章里想传达的核心判断有三条。第一，阶段状态数据的价值不在准确展示过去，而在提前暴露未来，所以衡量它的标准是”有没有提前触发过动作”，而不是”填得全不全”。第二，失真的主要战场在字典层和规则层，反复做填报培训是无效的，不如花两周把状态收到 7 个以内、把准出条件写出来。第三，最有预测力的指标是停留时长和准出通过率，而不是完成率，这一点和很多人的直觉相反，但它在我接触的样本里反复得到验证。

如果你现在就要动手，我建议从最小的动作开始，而不是从选工具开始：

1. 今天花 30 分钟，把你们所有工作项类型的状态字段导出来，统计每个状态过去 90 天的使用次数。
2. 本周内，把使用次数为 0 和语义重叠的状态列成一张”待删清单”，和一线负责人逐条确认。
3. 下周给最关键的三个阶段各写 2 到 3 条准出条件，能自动校验的先自动，不能的指定责任人。
4. 然后拉一次历史数据，算一下这三个阶段的 P50 和 P90 停留时长，这就是你们的基线。
5. 设定异常阈值，并明确超过阈值后 24 小时内谁必须做什么。

这五步做完，你大概会花掉 10 到 15 个人天，但大概率能在下一个项目上提前两到三周发现问题。阶段状态分析这件事，投入的从来不是钱，而是愿不愿意在设计上多花两周、在汇报上少花半年。