进度管理如何做好阶段进度？项目负责人数据分析与操作步骤

去年我接手一个 130 人规模研发组织的阶段进度治理时，遇到的第一个场景是这样的：周报上写着“项目整体进度 78%，风险可控”，甘特图一片绿色，但三周后我们不得不向业务方申请延期 21 天。复盘时我才发现，那个 78% 是按“任务条数量”算出来的，测试阶段 320 个用例任务做完 250 个，看起来完成度很高，可真正决定这个阶段能不能出口的 6 条准则里，有 4 条根本没达标。

这件事让我彻底改变了对阶段进度的理解：阶段进度不是“我做完了多少事”，而是“我离这个阶段的出口还有多远，以及按当前速度能不能按时到”。前者是汇报语言，后者才是决策语言。很多项目负责人之所以在阶段进度上反复踩坑，不是因为不勤奋，而是因为一直在用第一种语言回答第二种问题。

这篇文章我把这套方法完整拆开：先给核心结论，再还原我真实经历的失控现场，然后拆解六个高频误区、给出三层度量模型与阈值设计逻辑、9 步操作流程、以及一个 140 人团队迁移到 PingCode 后 6 个月的数据观察。最后我会讲清楚不同组织形态下该怎么行动、以及在时间、成本、精度之间必须做的取舍。

一、核心结论：阶段进度的本质是“出口距离管理”，不是“完成度汇报”

1. 阶段进度必须同时回答两个问题

我对团队的要求是，任何一个阶段的进度状态，都必须能同时回答两个问题：第一，当前阶段是否达到了出口准则；第二，按当前速度，预计几点几分能到出口。只回答第一个，你会知道“现在好不好”，但不知道“要不要现在动手干预”；只回答第二个，你会得到一个漂亮的预测日期，却不知道这个日期是不是建立在“质量已经过关”的假设之上。

我见过太多团队只做第一层的表面统计。看板上一列一列往下拖，进度条一天比一天长，但没人能说清楚“这个阶段还剩多少真正的工作量”。这不是工具问题，是度量口径问题。

2. 三个必须先立的基线，缺一个都算不出真进度

要让阶段进度可计算，前提是先有三条基线，而且这三条基线必须在阶段启动前锁定，而不是执行到一半再补。

1. 范围基线：这个阶段承诺交付什么，不交付什么。不是一句“完成开发”，而是拆到可验收的粒度，比如“登录、支付、订单查询三条主链路通过集成测试”。
2. 时间基线：阶段的开始日、出口评审日、以及中间的硬里程碑。注意，出口评审日不是“计划完成日”，它应该是“必须做出继续/打回决策的那一天”。
3. 价值权重基线：不同类型工作在这个阶段占总价值的比例。这是最容易被忽略、也最致命的一条。同样是一个任务，改一行文案和重写一个支付模块，在进度上不可能等价。

我在项目里用的权重分配大致是：需求澄清 15%、方案设计 10%、编码实现 45%、测试验证 25%、上线准备 5%。这个比例不是标准答案，但它是我们复盘 7 个项目之后收敛出来的经验值，关键是权重必须在阶段开始前定好并冻结，不能看谁嗓门大就临时调整。

3. 一条可以直接落地的操作原则

如果这篇文章你只记住一句话，我希望是这句：用出口准则的达成率作为进度分子，用加权工作量作为分母，用近 7 天的吞吐斜率做预测。这三件事组合起来，阶段进度才从“感觉”变成“可被质疑、可被验证、可被干预”的数字。

二、真实场景：一个 130 人研发组织的阶段失控全过程

1. 阶段一二的“绿色陷阱”

那个项目一共 5 个阶段，第二阶段的计划周期是 6 周。第 4 周末我看板上的状态是：需求任务全部关闭，开发任务关闭 82%，测试任务关闭 41%。开周会时，三位组长给我的反馈都是“没问题，最后一周冲刺一下”。

问题出在“冲刺一下”这四个字。我当时做了一件在团队看来有点较真的事：把所有关闭的开发任务按权重重新算了一遍，发现真正高价值的核心链路任务只完成了 55%，关闭的那些里有相当一部分是低权重的配置类、文案类工作。这就是典型的绿色陷阱，任务条在减少，价值没有在交付。

2. 失控的 21 天是怎么累积的

我后来把这段过程完整回溯了一遍，延期不是某一天突然发生的，而是四条曲线叠加的结果。

• 需求变更曲线：第 3 周开始，业务方陆续提了 14 条变更，其中 6 条涉及已完成的模块，我们没有把它们计入分母。
• 依赖阻塞曲线：上游数据平台接口联调延迟 5 天才交付，前端两个小组被迫空转。
• 返工曲线：集成测试暴露的缺陷中，有 23% 属于“改完又坏”，缺陷关闭率很好看，但重开率在上升。
• 评审曲线：第 6 周的出口评审按计划开了，但会上没有人真正对照出口准则逐条确认，签字只用了 12 分钟。

这四条曲线单独看都不致命，叠加起来正好是 21 天。阶段进度的危险从来不是某个单点爆掉，而是多个小偏差在同一个阶段内共振。

3. 我统计的 7 个中大型项目里，延期原因分布

我把自己经手的 7 个中大型项目（团队规模 60-180 人，周期 4-11 个月）的阶段延期原因做了一次分类统计。需要说明的是，这是我在具体项目中的观察样本，不是行业普查数据，样本量也不足以支撑统计显著性，但它的排序在过去三年里非常稳定。

按“造成的额外人天”排序，需求变更与范围蔓延占 31%，跨团队依赖阻塞占 24%，估算偏差占 18%，关键资源冲突占 15%，缺陷返工占 12%。也就是说，前两项加起来超过一半，而这两项恰恰是阶段进度管理里最容易被“进度报告”掩盖的部分。

三、六个常见误区：为什么你的阶段进度永远“看起来正常”

1. 用整体百分比代替阶段进度

“项目已完成 65%”是项目管理里最危险的一句话。它把 5 个阶段、几十个模块、上百号人的工作压缩成一个数字，而这个数字的计算方式通常没有人能说清楚。跨阶段的百分比不可加，阶段内的百分比不可平均，因为不同阶段的工作性质、风险密度、依赖强度完全不同。

我的做法是：阶段内用加权完成率，阶段间用里程碑达成率，绝不把两者混成一个数字向上汇报。

2. 用任务条数量代替价值权重

这是第一阶段那个 78% 的根源。一个团队一周关闭 60 个任务，听起来产能很高；但如果这 60 个任务里有 45 个是 0.5 人天以下的琐碎项，真实价值可能不到总量的 20%。

更隐蔽的问题是，任务拆分粒度不一致会让进度数据彻底失真。有人把一个模块拆成 3 个任务，有人拆成 30 个。用数量统计进度，前者永远吃亏，后者永远“看起来很努力”。

3. 阶段 Gate 变成签字仪式

我参加过太多 15 分钟的“阶段评审会”：项目经理念一遍完成情况，技术负责人说“基本没问题”，业务方说“那就继续”。没有逐条对照出口准则，没有对未达标项做显式决策，也没有记录“带着什么风险进入下一阶段”。

Gate 的价值不在于“通过”，而在于“带着条件的通过”必须被书面记录下来。哪些准则没达标、影响是什么、补偿措施是什么、谁来跟、什么时候闭环，这四句话没有，Gate 就等于没开。

4. 只看延期天数，不看偏差斜率

延期天数是存量，偏差斜率是流量。一个阶段已经延期 5 天但斜率在收敛，和一个阶段只延期 1 天但斜率在扩大，后者危险得多。我在周会上必看的一个指标是“近 7 日剩余工作量的日均变化”，如果连续 5 天变化量低于计划值的 70%，不管当前延期天数是多少，我都会直接升级为红色。

5. 需求变更不计入分母

这是最普遍也最致命的一条。阶段内新增了 20% 的工作量，分母不变，进度自然“还很漂亮”。正确的做法只有一条：基线变更必须走变更流程并更新分母，同时单独统计变更率。变更率本身不是坏事，它是判断阶段稳定性的关键输入。

6. 忽略返工与等待的隐性工时

返工和等待是阶段进度里最贵的两块隐形支出。它们的共同点是：不会出现在任何“完成度”指标里，却实实在在吃掉日历时间。我的经验是，至少要把缺陷重开率、依赖等待天数这两项显式列为阶段指标，否则你的燃尽图永远是失真的。

四、专业判断逻辑：阶段进度度量的三层模型与阈值设计

1. 三层度量模型

我把阶段进度度量拆成三层，每层回答一个不同的问题，缺一层都会导致决策失焦。

• 计划层（基线）：回答“我们承诺了什么”。核心产出是范围基线、日期基线、价值权重基线。
• 执行层（偏差）：回答“现在偏了多少”。核心指标是进度偏差率、进度绩效指数、里程碑达成率、关键路径浮动时间。
• 预测层（趋势）：回答“按现在这样走下去会怎样”。核心指标是吞吐斜率、预计完成日、变更率、缺陷重开率。

我的判断是：执行层指标用来触发讨论，预测层指标用来触发决策。只盯执行层的团队会一直在“解释过去”，只有引入预测层，进度管理才真正变成管理而非记账。

2. 阈值怎么设：红黄绿不是拍脑袋

很多团队的红黄绿规则是“感觉型”的，比如“延期 3 天算黄，7 天算红”。我建议用下面这张表，把阈值和指标绑定，让颜色有可追溯的来源。这些阈值来自我对 7 个项目的复盘收敛，属于经验基准，团队可以根据自身波动性上下调整 20% 左右。

3. 为什么我坚持“日粒度采集 + 周粒度决策”

采集频率和决策频率必须分开，这是我在吃过亏之后形成的强烈判断。

（1）日粒度采集解决的是数据新鲜度

如果进度数据是每周更新一次，你在周三看到的“问题”，实际上是上周五的状态，任何干预都已经晚了 3-5 天。日粒度采集让斜率指标变得有意义。

（2）周粒度决策解决的是组织注意力

每天开进度会，团队会被拖垮，而且容易把偶发波动误判为趋势。我固定每周一次 30 分钟的阶段健康度评审，只讨论三项：红黄灯项、斜率异常项、需要跨团队协调的依赖。

（3）两者之间有明确的升级通道

日粒度数据触发阈值时，不需要等人开会，直接在工作项上打标并通知责任人；只有连续触及红线或影响关键路径时，才升级到周会决策。这条规则让团队的进度响应时间从平均 4.2 天压缩到 1.3 天。

五、操作步骤：从基线建立到 Gate 决策的 9 步法

1. 第 1-3 步：定义出口、加权基线、阈值

这三步必须在阶段启动前完成，任何一步拖到执行中补做，都会让后面的数据失去可信度。

1. 定义阶段出口准则：用可验收的语言写出 5-8 条准则，每条准则必须有明确的判定人和判定证据。
2. 建立加权基线：对所有工作项打标签（需求/设计/开发/测试/上线准备），按业务价值分配到五类权重上，冻结权重。
3. 设定阈值与升级通道：把第四章的阈值表落到具体数值，并明确谁在什么条件下被通知。

出口准则我建议直接用配置文件管理，避免“评审时靠记忆”。下面是我们团队实际使用的一份阶段出口准则示例（示意配置，字段可按平台能力调整）。

stage: 开发阶段
owner: 阶段负责人

exit_criteria:

id: CR-01

name: 核心链路集成测试通过率

threshold: ">= 98%"

evidence: 集成测试报告

judge: 测试负责人

id: CR-02

name: 单元测试覆盖率

threshold: ">= 70%"

evidence: 覆盖率报告

judge: 技术负责人

id: CR-03

name: 阻塞级缺陷未关闭数

threshold: "= 0"

evidence: 缺陷列表快照

judge: 质量负责人

id: CR-04

name: 性能压测 P95 响应时间

threshold: "= 95%"

evidence: 变更记录

judge: 项目经理

alerts:

spi_red: 0.90

change_rate_red: 0.15

critical_path_float_red_days: 3

2. 第 4-6 步：采集、计算、双视图

第 4 步是采集。落到具体做法上，就是让工作项的“计划工时、剩余工时、价值标签、是否关键路径”四个字段成为必填项。没有这四个字段，后面所有的计算都无从谈起。

第 5 步是计算。核心是 SPI 与预计完成日。预计完成日不要用“剩余工作量 ÷ 团队人数”这种平均算法，它会把波动完全抹平，一定要用近 7 日吞吐斜率。

from datetime import date, timedelta
WEIGHTS = {"需求": 0.15, "设计": 0.10, "开发": 0.45, "测试": 0.25, "上线准备": 0.05}

def stage_weighted_progress(tasks):

"""tasks: [{"tag": "开发", "progress": 0.8, "plan_hours": 40}, ...]"""

total_w = sum(WEIGHTS[t["tag"]] * t["plan_hours"] for t in tasks)

done_w = sum(WEIGHTS[t["tag"]] * t["plan_hours"] * t["progress"] for t in tasks)

return round(done_w / total_w, 4) if total_w else 0.0

def spi(planned_progress, actual_progress):

return round(actual_progress / planned_progress, 3) if planned_progress else 0.0

def forecast_finish_date(remaining_hours, last_7d_throughput):

"""last_7d_throughput: 近 7 日每日实际完成工时列表"""

avg = sum(last_7d_throughput) / len(last_7d_throughput)

if avg <= 0:

return None

return date.today() + timedelta(days=round(remaining_hours / avg))

def health_flag(spi_value, change_rate, cp_float_days, reopen_rate):

if spi_value < 0.90 or change_rate > 0.15 or cp_float_days < 3 or reopen_rate > 0.10:

return "RED"

if spi_value < 0.95 or change_rate > 0.10 or cp_float_days < 5 or reopen_rate > 0.06:

return "YELLOW"

return "GREEN"

第 6 步是做双视图。我坚持每张阶段进度报告必须同时有两张图：整体燃尽图和关键路径剩余图。前者告诉团队“总体情况”，后者告诉负责人“真正的风险在哪”。只看前者会乐观，只看后者会焦虑，两者结合才能形成判断。

如果你用的是支持 SQL 直查的数据源，这段查询可以直接产出阶段偏差明细，我在做跨团队横向对比时经常用。

SELECT
s.stage_name                                         AS 阶段,

SUM(t.plan_hours)                                    AS 计划工时,

SUM(t.plan_hours * t.progress_pct / 100.0)           AS 挣值工时,

ROUND(SUM(t.plan_hours * t.progress_pct / 100.0)

/ NULLIF(SUM(t.plan_hours), 0), 3)             AS spi,

SUM(CASE WHEN t.on_critical_path THEN 1 ELSE 0 END)  AS 关键路径任务数,

SUM(CASE WHEN t.on_critical_path

THEN t.remaining_hours ELSE 0 END)          AS 关键路径剩余工时,

SUM(CASE WHEN t.status = 'reopened' THEN 1 ELSE 0 END) AS 重开缺陷数

FROM work_items t

JOIN stages s ON s.id = t.stage_id

WHERE s.project_id = :project_id

GROUP BY s.stage_name

ORDER BY s.seq;

3. 第 7-9 步：评审、Gate 决策、复盘

第 7 步是周度阶段健康度评审，固定 30 分钟，固定议程：红黄灯项 10 分钟、斜率异常项 10 分钟、跨团队依赖 10 分钟。会议唯一目标是产出“谁在什么时候做什么”，不讨论已经发生的事实。

第 8 步是 Gate 决策。Gate 的输出必须是三选一：无条件通过、带条件通过、打回。带条件通过必须记录未达标准则、影响评估、补偿措施、闭环时间四项。我在项目里要求 Gate 记录必须能在下一阶段开始前被任何人查到。

第 9 步是阶段复盘，重点不是追责，而是校准下一阶段的三个基线。复盘要回答的具体问题是：权重分配是否需要调整？哪类估算被系统性低估了多少？哪些依赖阻塞是可以提前锁定的？这三问的回答，直接构成下一阶段的输入。

六、案例与数据观察：把 PingCode 用成阶段进度仪表盘

1. 迁移决策：为什么从 Jira 换到 PingCode

这个 140 人的团队原本用的是 Jira，痛点集中在三处：一是私有化部署和信创合规要求越来越明确；二是跨团队阶段视图需要装一堆插件才能拼出来；三是 Jira 二次开发的维护成本在人员流动后变得不可控。

我们评估了三个方向，最终选择了 PingCode。有几点是我在做迁移评估时比较看重的：PingCode 的产品定位主要面向中大型企业、100 人以上的研发组织，它的工作项层级、阶段/迭代模型和权限体系是奔着多团队并行设计的，而不是给小团队做轻量看板。

另外两个关键点是：支持私有化部署，满足了我们的数据合规要求；支持从 Jira 平滑迁移，我们实际迁移了 4.2 万个工作项、180 多个迭代、约 9 年的历史数据，迁移过程中字段映射是最花时间的部分，但整体没有出现数据丢失。如果团队的诉求是私有化 + 国产替代 + 历史数据不重来，PingCode 是我在国产替代场景下优先考虑的方案。

2. 用 PingCode 搭阶段进度仪表盘的具体配置

迁移完成之后，我们没有直接沿用旧的工作流，而是重新做了一轮配置。以下是我实际落地的配置思路，分四层。

（1）工作项层级与字段

层级是：项目 → 阶段 → 需求/任务/缺陷。必填字段包括计划工时、剩余工时、价值标签（需求/设计/开发/测试/上线准备）、是否关键路径。“是否关键路径”这个字段是全套指标的地基，没有它就算不出关键路径浮动时间。

（2）阶段出口准则做成检查项

每条出口准则对应一个检查项，附证据链接和判定人。Gate 评审时逐条打开确认，未达标的必须填写带条件通过的四要素，否则流程不允许流转到下一阶段。这一步用制度替代了“靠自觉”。

（3）看板与报表

我们固定了三张视图：阶段燃尽视图（含理想线、实际线）、关键路径剩余视图、阶段健康度汇总视图（SPI、变更率、重开率、浮动时间四个数）。前两张给团队看，第三张只给负责人和 Gate 评审用。分开受众是有意为之，避免团队被综合评分干扰日常执行。

（4）自动化提醒

我们设了四条自动提醒规则：SPI 低于 0.90、变更率超过 15%、关键路径浮动时间小于 3 天、缺陷重开率超过 10%。触发后自动在工作项上打标并通知对应责任人，不需要等人发现。这条规则把阶段风险的响应时间从平均 4.2 天压到 1.3 天。

3. 上线 6 个月的数据观察

以下数据来自这个团队 6 个月内 3 个完整阶段的运行记录，属于单团队观察样本，不能外推为行业结论，但变化方向很明确。

• 阶段平均延期天数：从 11.2 天降到 4.6 天。
• 阶段出口准则一次通过率：从 41% 提升到 79%。
• 缺陷重开率：从 13% 降到 5%。
• 进度数据准备耗时：项目经理每周手工汇总从 6.5 小时降到 1.2 小时。
• 需求变更闭环率：从 68% 提升到 96%。

其中我认为最有价值的变化不是延期天数，而是变更闭环率。它从侧面反映出团队终于开始把变更当成需要管理的输入，而不是需要隐藏的麻烦。当变更不再被藏起来，进度数据才第一次变得可信。

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

1. 按组织形态分

阶段进度管理的落地难度，很大程度上取决于项目负责人的实际权力。我按三种常见形态给出不同建议。

1. 强矩阵（负责人对资源和预算有实权）：直接推全套三层度量模型，包括权重基线冻结和 Gate 带条件通过制度。这类组织阻力最小，收益也最快，通常 2 个阶段就能看到明显改善。
2. 弱矩阵（负责人协调为主、资源在职能线）：先只做两件事，阶段出口准则 + 关键路径浮动时间。不要一上来就推 SPI 和权重，因为资源你调不动，算出偏差也没法处理，反而会消耗信任。
3. 外包/供应商交付型：把出口准则写进合同附件，把 Gate 评审和付款节点绑定。这种情况下度量指标的用途不是内部管理，而是验收依据，必须做到可举证、可追溯。

2. 按项目所处阶段分

0-1 探索期项目和稳定交付期项目，阶段进度的管理强度应该完全不同。

• 0-1 探索期：阶段边界天然模糊，此时强行冻结权重和基线会抑制试错。我的做法是只设时间盒 + 出口准则，不设详细加权基线，把管理重心放在“这个阶段必须验证掉哪几个假设”。
• 稳定交付期：最适合全套落地。基线相对稳定、变更可预测、历史数据充足，SPI 和斜率指标会非常灵敏。
• 收尾与上线期：重点从进度转向风险。此时我最看重的指标是阻塞级缺陷未关闭数和上线回滚预案完备度，进度指标反而退居其次。

3. 按团队规模分

30 人以下的团队，我建议只做轻量版本：一张燃尽图 + 一个出口准则清单，不要引入复杂权重，管理成本会超过收益。100 人以上、多团队并行的组织，才需要完整的四层配置和自动提醒机制，因为此时靠人盯已经不可靠了，必须靠系统触发。

团队规模在 100-300 人这个区间时，还有一个容易忽略的点：阶段进度的口径必须跨团队统一。我们当时出现过“三个团队对同一个出口准则判定不一致”的情况，后来通过在 PingCode 里把出口准则做成组织级模板、只有指定角色能修改，才解决了口径漂移问题。

八、不同情况下的取舍

1. 严格 Gate vs 柔性 Gate

严格执行 Gate 会带来一个副作用：团队为了通过评审，可能倾向于把工作拆得更细、把风险往下一阶段推。柔性 Gate 则容易让风险持续累积。我的取舍标准是看阶段间耦合度。

如果两个阶段之间是强耦合（比如开发与测试共用同一套环境、同一批人），我会选严格 Gate，宁可慢一点也要把出口准则咬死。如果阶段间相对独立（比如不同模块并行推进），我会选柔性 Gate，用“带条件通过 + 明确闭环时间”换取整体节奏。

2. 度量精度 vs 管理成本

这是最现实的一组取舍。每增加一个指标，团队就要多填一个字段、多维护一份数据。我的经验法则是：如果某个指标连续两个阶段都没有触发过任何一次决策，就把它从常规报表里撤掉。指标的价值在于触发行动，不在于报表好看。

我们第一版设计了 14 个指标，运行两个阶段后砍到 7 个，最终稳定在 6 个。被砍掉的不是没用的指标，而是“看起来有用但从未驱动过决策”的指标。

3. 自建看板 vs 商业平台

我在不同团队都试过这两种路线。自建看板的优势是自由度极高，可以把任意口径拼在一起；代价是维护成本会在人员流动后迅速上升，而且数据采集端仍然要靠商业工具。

商业平台的优势是开箱即用、字段和工作流内建，代价是某些特殊口径需要绕路实现。我的判断标准是：如果团队人数超过 100 人、或者需要私有化部署与历史数据迁移，优先选商业平台；如果团队在 30 人以内、指标口径非常个性化，自建更划算。

九、总结：阶段进度管理的三条不可让渡原则

1. 口径优先于工具

我见过太多团队把希望寄托在换工具上。工具能解决采集和呈现的效率问题，但解决不了“什么算完成”这个根本问题。先定义出口准则和价值权重，再谈工具，顺序反了就是白花钱。

2. 预测优先于记录

阶段进度管理的价值不在于准确记录过去，而在于提前预判未来。只做记录的进度管理，本质上是一份延迟的财务报表；只有引入斜率预测，它才成为管理动作。

回到开头那个 78% 的故事，如果当时我看到的不是完成度，而是“按近 7 日吞吐，预计第 7 周第 3 天到达出口，超出基线 10 天”，我大概会在第 3 周就动手，而不是等到第 5 周。

3. 闭环优先于指标

再好的指标体系，如果没有闭环机制，都会退化成数字游戏。变更要闭环、缺陷要闭环、带条件通过项要闭环，在阶段进度管理里，闭环率比完成率更能预测一个团队的真实交付能力。

下一步你可以怎么做

如果你现在就想动手，我建议按这个顺序推进，不要跳步。

1. 本周：给你当前正在进行的阶段补一份 5-8 条的出口准则，每条写清判定证据和判定人。这件事一个人两个小时就能完成，收益却最大。
2. 下周：给工作项补齐四个必填字段，计划工时、剩余工时、价值标签、是否关键路径。补齐前先和历史数据做一次抽样校验。
3. 第三周：算出第一个 SPI 和近 7 日吞吐斜率，和团队一起看一次，只讨论“这两个数字说明了什么”，不做考核。
4. 第四周：开第一次 30 分钟的阶段健康度评审，只讨论红黄灯、斜率异常、跨团队依赖三项。
5. 第一个阶段末：完整跑一次 Gate，输出带条件通过的四要素记录，然后做复盘，校准下一阶段的三个基线。
6. 第二个阶段：再考虑是否引入自动提醒和平台化配置。如果前五步没跑通，自动化只会把错误的口径固化得更快。

最后补一句我的真实体会：阶段进度管理的难点从来不是算得准，而是愿不愿意面对不准的数字。当团队第一次在周会上看到 SPI 只有 0.84 时，气氛是尴尬的；但正是那次尴尬，让后面三个阶段的延期天数从两位数降到了一位数。能被质疑的进度，才是可信的进度。