跟踪流程与规范：产品经理进度跟踪风险控制关键指标

去年 11 月，我参与复盘一个 30 人规模的 SaaS 团队。12 个迭代里有 8 个延期，平均延期 4.5 天，最长的一次卡了 11 天。但翻看这一整年的周报，几乎每一周的结论都写着"整体进度符合预期，风险可控"。

这不是个例。我带过和复盘过的十几个团队里，超过一半都出现过同一个现象：跟踪动作一个不少，延期还是一次不落地发生。每天站会、每周周报、每迭代评审，节奏全都有，可等到发现延期的时候，已经没有任何调整空间了。

问题不在跟踪的频率，而在跟踪的对象。大多数团队跟的是"结果"，完成百分比、里程碑状态灯、任务条颜色、燃尽图曲线。这些数字的共同特点是：它们只在事情已经发生之后才变色。你看到的不是风险，是讣告。

这篇文章我想讲的不是"有哪些进度指标"，而是一套能真正报警的进度风险控制体系怎么设计：信号层看什么、口径层怎么保证数据可信、阈值层什么时候算异常、动作层异常之后谁做什么、校准层这套体系自己怎么迭代。我会用自己带过和复盘过的团队案例说明，也会讲清楚在 PingCode 这类平台上具体怎么落地。

一、先给三条结论：进度跟踪的目标不是"准确"，而是"提前"

在展开细节之前，我先把三条判断放在最前面。如果你只读一段，读这三条就够了。

1. 进度跟踪的第一目标不是汇报准确，而是预警提前量

"这个需求完成 70%"，这句话准不准，其实无关紧要。真正有意义的问题是：这句话能不能让你提前 5 天就知道它可能延期？

我在复盘里做过一个粗略统计：同一批延期事项，用"完成百分比"识别出问题的平均时点，是在交付日前 1.2 天；而用"在制品停留时长 + 依赖阻塞时长"识别，平均时点是交付日前 6.8 天。整整 5 天多的差距，就是你有没有调整空间的差距，是能换人、砍范围、还是要向业务方道歉的差距。

所以我在设计任何进度跟踪表之前，第一个问题是：这个指标能提前几天发出信号？如果一个指标只能告诉你"已经延期了"，那它属于事后统计，不该占用跟踪表的中心位置。

2. 与其堆 20 个指标，不如盯稳四类信号

我见过最夸张的一张进度看板有 34 个字段，结果没有一个人能说清楚其中任意 3 个字段的口径。指标过载的直接后果不是信息更全，而是每个人都只挑对自己有利的那几个看。

我后来固定成四类信号：交付节奏、流动效率、质量返工、范围与依赖。四类各挑 1 到 3 个，总共不超过 10 个数。这个数量级的好处是，团队真的记得住，也真的会在会议上被追问。

3. 没有阈值和动作的指标，等于没有指标

这句话我想说重一点。一个指标如果没有配"超过多少算异常"和"异常后谁做什么"，它就只是装饰。我在一个客户那里看到看板上红灯亮了整整三周，问起来，所有人的回答都是"看到了啊，但不知道该找谁"。

红灯本身不解决问题。红灯后面那条"升级路径"才解决问题。

二、背景与真实场景：为什么周报全绿，交付还是延期

要讲清楚这个问题，我得先回到那次复盘现场，把当时的原始数据摊开。

1. 一次延期复盘的完整过程

那 8 个延期迭代里，我抽了最典型的一个：一个电商中台项目，计划 10 个工作日交付 6 个需求，最终用了 15 个工作日，延期 5 天。

复盘时我按时间线走了一遍：

1. 第 3 天：站会上所有任务都标黄（进行中），没有任何任务标红。此时需求 A 已经在一个"接口联调"状态里停留了 2 天。
2. 第 5 天：需求 A 的完成度写着 80%，负责人说"主流程跑通了，就差异常分支"。实际上异常分支要走另一个团队改配置。
3. 第 7 天：那个团队还没排期，负责人开始在群里 @ 人，但没人把它升级为"风险"。
4. 第 9 天：需求 A 完成度还是 80%。负责人开始加班。
5. 第 10 天：需求 A 完成度跳到 60%，因为重新评估后发现之前漏了一个子模块。
6. 第 12 天：需求 B、C 因为在同一批测试资源上排队，被动延期。
7. 第 15 天：全部交付。

这条时间线里最关键的一点是：真正的风险信号在第 3 天就出现了，某个任务在"接口联调"状态停留超过历史均值，而且它的出口依赖另一个团队。但当时的跟踪体系里，没有任何一个字段能捕捉到这个信号。

周报全绿，是因为"进行中"就是绿色的，"完成度 80%"看起来也健康。所有信息都在，只是没有一条能触发行动。

2. 为什么"周报全绿"和"实际延期"能同时成立

我把这个现象拆成三个机制，每一个都很常见：

第一是滞后性。完成百分比、里程碑状态、燃尽图，本质都是累计结果的快照。累计量变化缓慢，等到曲线明显下弯，剩余时间已经不够了。

第二是自报偏差。任务完成度由执行者自己填，而人在评估自己工作的剩余量时，系统性偏乐观。这不是态度问题，是认知问题，换成你我填也一样。所以需要引入不依赖自报的指标，比如状态停留时长、依赖等待时长，这些是系统自动生成的。

第三是聚合掩盖。迭代整体"完成 62%"这种数字，会把一个卡死的事项和五个顺利的事项平均掉。平均值是最擅长撒谎的统计量。

3. 100 人以上组织额外多出的三个难点

上面的问题在 10 人小队里靠"喊一嗓子"就能缓解。但到了 100 人以上的组织，会额外长出三个结构性难点，靠沟通是解不掉的。

难点一是跨团队依赖的数量级增长。5 个团队两两之间最多 10 条依赖边，10 个团队最多 45 条，20 个团队最多 190 条。依赖数量不是线性增长，而是平方级。你在周会上根本讲不完。

难点二是口径分裂。A 团队的"完成"指代码合入主干，B 团队的"完成"指测试通过，C 团队的"完成"指上线灰度结束。三个团队报表拼在一起，管理层看到的是一个没有物理意义的数字。

难点三是数据可信度衰减。组织越大，填表的人和用表的人距离越远，填表的动机就越弱。当填写变成负担，数据质量就会下滑，而基于差数据做的决策会比不做决策更糟。

这三个难点决定了：中大型组织的进度跟踪，必须从"人驱动"切换到"系统驱动"，口径由工作项状态机定义而不是口头约定，依赖由系统建关联而不是靠人记忆，数据由操作自动产生而不是靠额外填表。

三、常见误区拆解：六个让指标失灵的坑

这些误区我几乎在每一个团队都至少见过三个。它们的共同点是，单看都很合理，组合起来就把跟踪体系变成了形式。

1. 误区一：把完成百分比当主指标

完成百分比不是不能用，而是不能当主指标。它的致命弱点是由执行者自报且没有客观锚点。

更麻烦的是"回退"。我统计过一个团队的数据：在 200 多个需求里，完成度出现回退（后一次填报低于前一次）的比例约 17%。回退本身不是问题，问题是回退通常发生在临近 deadline 时，那时已经没有调整空间了。

我的做法是：完成百分比可以保留，但只作为辅助字段，且必须锚定到客观事件。比如不写"完成 60%"，而写"6 个子任务中完成 4 个"，并且每个子任务的完成都对应一次可验证的操作（合入、部署、验收通过）。

2. 误区二：认为指标越多越安全

我做过一次对照：同一个团队，先用 24 个字段的跟踪表跑 6 周，再用 8 个字段跑 6 周。结果是字段减少后，需求平均流转时间下降了 19%，会议时长下降了 27%，而前瞻识别的延期数量反而从 3 个增加到 5 个。

原因不复杂：字段越多，填写成本越高，数据质量越差，被使用的字段越少。最后团队只会盯住那一两个最容易填的字段，其他全是噪音。

3. 误区三：只看结果指标，不看流动指标

交付节奏类指标（周期时间、吞吐量、里程碑达成率）回答的是"交付了多少"，流动效率类指标（在制品数、队列时长、阻塞时长）回答的是"为什么是这个速度"。

只有前者，你知道延期了但不知道为什么；只有后者，你知道哪里慢了但不知道整体位置。两者都要有，但如果只能留一类，我留流动指标，因为它是前置的。

4. 误区四：口径不统一，各填各的

这是我认为最要命、也最容易被忽视的一个坑。同一份报表里，三个团队的"完成"含义不同，那么这份报表的汇总数字就是假的。而管理层恰恰最依赖汇总数字。

口径不统一还有一个隐蔽危害：它会让诚实的团队吃亏。执行"完成 = 上线"的团队，数据永远比执行"完成 = 代码提交"的团队难看。久而久之，所有人都往宽松的定义靠拢。

5. 误区五：有信号，没有触发动作

我看过太多看板，红黄绿的灯都在，但没有人对红灯负责。异常状态持续存在，团队逐渐脱敏，最后所有人对红灯视而不见。

判断标准很简单：随便挑一个红灯，问"它是什么时候亮的、亮了之后谁做了什么、做了什么之后它灭了吗"。如果答不上来，这个灯就是无效的。

6. 误区六：为汇报修饰数据

这一条我犹豫了很久要不要写，因为它听起来像道德批评。但我想说的是，它本质上是机制问题，不是人品问题。

当一个指标被直接用于考核团队或个人时，这个指标必然会被优化掉，而不是被改进。这是古德哈特定律：当一个度量变成目标，它就不再是好的度量。

所以我的建议是：进度数据只用于发现异常和调配资源，不直接挂钩绩效。合理的做法是把"发现问题后是否按约定升级"作为协作评价的一部分，而不是把"指标好不好看"作为评价的一部分。

四、专业判断逻辑：四层信号 + 五层设计

讲完误区，我把自己的判断逻辑完整摊开。这一节是全篇最"硬"的部分，也是我认为最值得照搬的部分。

1. 四层信号：每一层回答一个不同的问题

第一层是交付节奏类。回答"我们以多快的速度交付"。核心指标是周期时间（从开始到交付的时长）、吞吐量（单位时间完成事项数）和里程碑达成率。

这一层的问题是滞后，所以它更适合做趋势判断，而不是实时预警。我一般每周看一次，看的是趋势线而不是单点值。

第二层是流动效率类。回答"为什么是这个速度"。核心指标是在制品数量（WIP）、状态停留时长、阻塞等待时长、流动效率比率。

这一层是整套体系里预警价值最高的部分，因为它采集的是"卡住"这个事实本身，不依赖任何人的主观判断。一个任务在"联调中"停了 4 天，这是一个客观事实，不需要谁来评估风险等级。

第三层是质量返工类。回答"我们交付的东西有没有被退回"。核心指标是需求返工率、返工工时占比、缺陷逃逸率。

这一层的价值在于：返工是延期的隐性来源，而且往往在进度表上不可见。一个需求"完成"了又被退回重做，在完成百分比上可能完全不体现，但工时已经被吃掉了 30%。这就是为什么我坚持要求返工必须显性记录并计入周期时间，不能从重新提交那天开始算。

第四层是范围与依赖类。回答"外部条件变了多少"。核心指标是需求变更率、跨团队依赖阻塞时长、外部响应等待时长。

这一层在 100 人以上的组织里通常是最重要的，因为协同成本占比最高。但它在小团队里容易被忽略，因为小团队的依赖大多是"隔壁工位的人"，看着不像"依赖"。

2. 每个指标都要答三个问题

我给团队设计指标时，要求每一个指标都必须能被回答三个问题。答不上来的指标一律删掉。

（1）它预警什么风险

比如"状态停留时长"，它预警的是隐性的技术卡点或职责真空。一个任务在两个状态之间反复横跳，往往意味着没人真正拥有它。

（2）数据从哪里来

这一点决定了指标能不能长期活下去。我的优先级顺序是：系统自动产生的操作日志 > 流程中必然发生的动作 > 需要额外填写的字段。

状态变更时间戳、代码提交记录、流水线执行结果，这些是操作副产品，采集成本几乎为零。而"完成度百分比""风险等级"这类字段需要人额外想一下再填，长期必然失真。

（3）什么情况下它不可信

这一条最容易被省略，但最重要。任何指标都有它的失效场景，提前说清楚，团队才不会在错误的地方做决定。

• 周期时间：在团队不稳定或人员频繁调配的时期失真，因为样本分布已经变了。
• 吞吐量：在需求颗粒度差异极大的情况下不可比，比如把"改文案"和"重构支付"算作同一类。
• 里程碑达成率：在里程碑可以被重新定义的情况下虚高，必须配合"里程碑变更次数"一起看。
• WIP 数量：在"一个需求多人并行"的模式下不能简单计数，需要按可并行的独立工作单元计数。
• 变更率：在项目初期需求本来就该被澄清的阶段偏高属于正常，不分阶段看会误判。

3. 传统方法（EVM、DORA）的适用边界

这里我需要澄清一件事，因为很多文章把它们混在一起讲，导致产品经理用错工具。

挣值管理（EVM）里的进度绩效指数 SPI 和成本绩效指数 CPI，是用来衡量"进度和成本相对计划的偏差"，更适用于范围相对稳定、计划可以提前做完的项目（如工程交付、硬件项目）。在需求高频变化的互联网产品场景里，如果基准计划本身每周都变，SPI 的参考意义会大幅下降。

DORA 的四个指标（部署频率、变更前置时间、变更失败率、恢复服务时长）衡量的是研发交付能力，适合作为工程效能的长期趋势指标。但它不直接等于产品进度风险，一个团队的部署频率很高，也可能只是因为需求被拆得很碎，跟交付价值没有关系。

我的用法是：EVM 只在有稳定基线时作为参考，DORA 只在工程侧作为能力趋势，真正做产品进度风险预警，还是靠上面那四层信号。把工具放对位置，比用对工具更难。

4. 阈值与动作：黄线红线的设计方法

我之前反对直接给通用数字，因为阈值高度依赖团队基线。但完全不给方法也不负责，所以我说说我的设计步骤。

1. 先跑两周基线。不做任何干预，只采集数据，算出每个指标的中位数和第 75 分位数。
2. 黄线设在 P75。即"有四分之一的同类事项比它更糟"，此时提示关注，不要求动作，只需在站会上提一句。
3. 红线设在 P90 或中位数的 2 倍。触发红线后必须有明确责任人，且在当天给出处置结论。
4. 每季度校准一次。团队能力提升后，同样的绝对值可能已经不再异常；反过来，业务压力大时阈值可能需要收紧。

下面这张表是我在几个团队用过的阈值与动作矩阵模板，具体数值请当作示例，不要直接抄。

这张表里我最想强调的一点是最后一列。红线动作必须是具体的人 + 具体的时间 + 具体的产出物，不能是"加强关注""持续跟进"这类词。写不出具体动作，说明这个阈值不该设。

五、具体案例与数据观察：用 PingCode 把这套体系落地

方法论讲完，接下来说落地。这里我以 PingCode 为例，原因不是它有什么独门功能，而是它天然服务中大型组织和 100 人以上团队，而恰恰是这类组织的口径和依赖问题最难靠人力解决。

更重要的是，PingCode 支持私有化部署，也支持从 Jira 平滑迁移。对于需要国产替代、又不想把研发数据放到公有云的组织来说，这两个特性直接决定了方案能不能推进下去。

1. 第一步：把"完成"的定义写进工作项状态机

口径问题最好的解法不是发文档，而是让宽松的定义在系统上做不到。

我在一个约 120 人的客户那里做的第一件事，是把原来 5 个状态改成 7 个：待评估、已排期、开发中、待联调、联调中、待验收、已上线。关键改动是"待联调"和"联调中"的分离，因为跨团队阻塞绝大多数发生在这两个状态之间。

同时把"已上线"设为唯一计入完成的状态。开发中、联调中一律不计入。"完成度"这个字段被彻底删掉，换成子任务完成计数。

这个改动一开始阻力很大，因为完成度看起来更直观。但跑完两个迭代之后，数据可信度问题自动消失了，不是团队变诚实了，而是系统不再给人留下模糊表达的空间。

2. 第二步：让依赖变成有形的对象

跨团队依赖最大的问题是它只存在于人的记忆里。等到想起它，往往已经来不及了。

PingCode 里可以把跨团队依赖建成显式的工作项关联，并对关联设置状态同步。我在客户那边的规则是：任何需要外部团队提供产出的工作项，必须建立依赖关联，否则不允许进入"已排期"状态。

这条规则的作用非常大。以前阻塞时长没人统计，现在系统自动算出"从提出请求到对方响应"的等待时长。我们把这个数字设了阈值：超过 2 个工作日黄线，超过 5 个工作日红线。

上线后的第一个月，系统标记出 23 条超时依赖，其中 11 条是团队原本完全没有意识到的。这 11 条里有 4 条如果没人管，会在两周后直接造成延期。

3. 第三步：用看板列限制替代在制品开会讨论

关于 WIP 我有一条很实际的建议：不要在会上讨论 WIP 应该少一点，直接在看板上设列限制。

原因是讨论需要共识，共识需要时间，而时间正是你缺的东西。列限制是一个硬约束：列满了就进不来，团队必须先把已有的做完。

我在客户那里给"联调中"这一列设了限制，数量按团队基线定了 6。结果第一周实际触发了 9 次"列已满"，每次都要团队决定先推哪个。这个过程本身就在做优先级排序，而且比任何一次优先级会议都更快更真实。

四周之后，这个团队的平均周期时间从 11.4 天降到 8.2 天，降幅约 28%。这个改善不是因为人变强了，而是因为队列变短了，等待时间少了。

4. 第四步：把度量报表接到阈值，而不是接到月度汇报

很多团队用度量报表的方式是：月底导出一份，在会上展示。这个用法浪费了报表最核心的价值，它是用来做日常预警的，不是用来看历史成就的。

我的做法是把四类信号里的核心指标固化成一个每周更新的视图，每个指标都带基线参考值和当前值，超过阈值自动变色，并且每个变色项后面挂着责任人。这个视图直接在日常同步里用，而不是等到月度总结。

区别在哪？月度汇报是给上面看的，日常视图是给执行者用的。只有执行者每天都在看的数据，才会真正影响行为。

5. 第五步：把部署方式和迁移成本算进方案

这一步经常被技术选型文章忽略，但在 100 人以上的组织里，它往往是决定性的。

我参与过一个从海外工具迁移的项目，涉及 8 个团队、4 年历史数据、约 9 万条工作项。评估迁移成本时我们算过三块：数据映射成本、流程重建成本、团队再学习成本。前两块占大约 60%，最后一块占 40%。

PingCode 支持从 Jira 平滑迁移，这一点实质影响的是第一块和第二块成本，字段、工作项类型、状态流、历史记录如果能映射过去，迁移周期通常能压缩到原来的三分之一左右。而私有化部署影响的是合规审批能不能过，这条不过，方案再漂亮也推不动。

所以我给中大型组织的建议是：把"能不能迁"和"能不能私有化"放在功能对比之前评估。功能差距可以靠流程弥补，迁移和合规问题不能。

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

方法论是通用的，启动方式必须按情况调整。下面按团队规模分成几类，给出我的具体建议。

1. 10 人以内的团队

不要搭指标体系。你们最大的优势是信息传递成本低，最大的风险是过度设计。

我的建议只有一个动作：把任务状态拆细，让"卡住"变得可见。在"进行中"和"完成"之间加一个"等待外部"的状态，并且要求任何进入这个状态超过 2 天的任务，必须在当天同步里说明卡在哪。

指标方面，只看一个：状态停留时长。其他都不需要。

2. 20 到 50 人的单产品线

这个阶段要开始建口径。核心动作是统一"完成"的定义，并把完成百分比从主指标降级。

建议的指标体系是 6 到 8 个：周期时间、吞吐量、里程碑达成率、在制品数量、状态停留时长、跨团队阻塞时长、需求变更率、需求返工率。每周更新一次，每月做一次趋势复盘。

这个阶段的关键不是数据，是让数据产生动作。建议先挑两个指标设阈值，把"红灯→责任人→当天结论"这个循环跑顺，再扩到其他指标。

3. 100 人以上的多团队组织

这个阶段靠人管不住了，必须靠系统。启动顺序我建议是：

1. 先统一工作项状态机，跨团队一致，不允许各团队自定义完成定义。
2. 再建立依赖显式关联，把跨团队依赖变成有状态的对象，而不是聊天记录。
3. 然后设 WIP 限制，从最容易拥塞的状态开始，先设一列。
4. 接着做阈值和升级路径，明确红线由谁负责、多久给结论。
5. 最后做度量视图，把前面几步产生的数据组织成日常预警看板。

顺序不要颠倒。先做度量视图是最常见的错误，报表很漂亮，但底下没有可信数据，也没有人会因为报表改变行为。

4. 外包与混合交付团队

这类团队最大的问题是数据采集的动机不对称。外部团队没有动力如实填报进度，因为报了坏消息对自己没好处。

我的建议是只依赖系统自动产生的指标，不依赖自报指标。具体来说：看代码提交频率、看工作项状态变更时间戳、看交付物验收通过时间。这三类数据都不需要对方主动"填报"，是协作过程中自然产生的。

另外，把验收标准在合作开始前写死，并明确"验收不通过 = 不计入完成"。这条能避免大量扯皮。

5. 强合规行业的团队

金融、医疗、政企类项目通常有审计要求，此时进度跟踪体系还要额外满足可追溯性。

建议在标准体系上增加三样：状态变更的完整审计日志、需求追溯链路（从原始需求到上线版本）、以及变更的审批记录。这三样在私有化部署的环境里更容易满足，因为数据不出内网，审计也更容易通过。

需要提醒的是，合规要求会让流程变重，所以指标数量要相应减少，不要既满足合规又追求敏捷，最后两头不到位。

七、不同情况下的取舍

任何体系都有代价。这一节我把几个必须做的取舍讲明白，避免你照着方法做了一半发现成本扛不住。

1. 数据实时性 vs 团队填写成本

越实时的数据越贵。如果要求所有字段每日更新，团队每天要花 20 到 30 分钟在更新上，一个月就是 4 到 6 人天，这个成本在 30 人团队里不可接受。

我的取舍原则是：能不靠填写就不靠填写。优先选择操作副产品类的数据（状态变更时间戳、代码提交、流水线结果），这类数据是实时的，且填写成本为零。需要人工判断的字段（如风险等级、影响范围）改成每周更新一次即可。

如果只能二选一，我选"数据可信但更新慢"，而不是"更新快但需要大量手工填写"。

2. 指标数量 vs 执行能力

指标越多，覆盖越全，但被执行的概率越低。我见过的最优状态是团队每个人都能不查资料说出自己关心的 3 个指标和它们的红线。

取舍标准很直接：一个指标如果连续两个月没有触发过任何动作，就删掉或降级为观察项。大部分团队实际需要长期盯的指标不超过 8 个。

3. 自建表格 vs 采购平台

这个取舍取决于两个变量：团队规模和依赖复杂度。

20 人以内、依赖关系简单，用表格完全够，而且灵活。但一旦出现三个以上团队互相依赖，自建表格的成本会迅速上升，因为你需要维护关联关系、权限、变更历史和跨项目的汇总，这些用表格做会消耗掉一个人 30% 以上的时间，而且极易出错。

我的分界线大概是：跨团队依赖超过 15 条，或者需要按多个维度切片看数据时，就该考虑平台化方案了。

4. 私有化部署 vs 公有云

私有化部署的优势是数据可控、合规友好、可深度定制；代价是运维成本、升级成本和初期部署时间。

我的判断标准是：如果组织有明确的数据不出内网要求，或者需要和内部系统做深度集成（比如打通内部账号、CI 流水线、发布系统），私有化部署基本是必选项，这时候不用纠结成本。如果没有这些约束，公有云方案会明显更省事。

需要提醒的是，私有化部署的隐性成本主要在运维和版本升级，前者需要至少 0.2 个人力，后者需要在上线前就规划好节奏，否则很容易停在旧版本上。

5. 跨团队统一口径 vs 各团队自治

统一口径的好处是数据可比，坏处是会牺牲团队的适配性，不同团队的工作性质差异很大，用同一套状态定义可能别扭。

我的取舍是分层统一：把"完成"这个定义全局统一（必须统一，否则汇总数据没有意义），把中间状态的定义留给团队自治。这样既保证了对上层汇报的数据一致性，也保留了团队内部的灵活性。

具体做法是：全局只规定状态类别（未开始 / 进行中 / 等待外部 / 已完成），每个团队可以在这个类别下定义自己的细分状态。报表按类别汇总，团队按细分状态工作。

八、把跟踪从"汇报工具"改成"预警系统"

回到开头那个 12 个迭代延期 8 次的团队。后来我们做的改动其实不多：把"完成"的定义收紧到上线、删掉完成百分比、把"联调中"独立成状态并设列限制、给跨团队依赖加显式关联和 5 天红线。

四件事，两周落地，没有买任何新工具。三个月后，他们的延期事项从每 12 个迭代 8 次降到 3 次，平均预警提前天数从不到 2 天变成 6 天以上。

我想通过这个案例说明的核心观点是：进度跟踪的问题从来不是数据不够，而是信号选错了、口径乱了、阈值没设、动作没人认领。这四件事里，前三件几乎不需要技术投入，第四件需要的是管理决心而不是工具能力。

如果你现在就要动，我的建议是按这个顺序来：

1. 本周做一件事：把团队现有跟踪表里的所有字段列出来，逐个问"它能提前几天报警"。答不出"提前"的字段，全部标记为事后统计，不再占用日常跟踪位置。
2. 下周做一件事：把"完成"的定义写到工作项状态里，明确唯一计入完成的终态，并把完成百分比从主指标降级。
3. 两周内做一件事：挑 2 个指标（建议选状态停留时长和跨团队阻塞时长），按基线算阈值，设黄线和红线，并为红线指定责任人和响应时限。
4. 一个月后再做一件事：跑一次校准，看这两个指标在四周内触发了多少次、有几次真的避免了延期。有效就扩到四类信号，无效就先修机制，不要急着加指标。

最后说一句我的真实判断：没有任何指标体系能让你不延期，它们只能让你在还有选择的时候知道该选什么。选择权，才是进度跟踪真正要保护的东西。