进度跟踪每日进展全流程：产品经理流程优化与一文讲清

我带过一个跨端交付项目，研发 30 多人，前后端、iOS、Android、测试、数据五条线，每天早上 9 点半站会。前六周站会稳定在 25 分钟以上，我每天整理的进展汇总表有 40 多行更新，看起来一切尽在掌握。第七周周三，后端一个核心接口已经比计划晚了 9 天，而我在延期发生的前一天，日报上写的还是"正常推进"。那次复盘我发现，问题不在于团队不汇报，而在于我搭的这套每日跟踪机制，从头到尾只生产"记录"，不生产"决策"。

这篇文章我想把这套机制拆开讲清楚：产品经理该跟踪什么、按什么节奏跟、用什么模板、什么时候升级、怎么把跟踪嵌进研发流程，以及在不同团队规模下怎么做取舍。

一、先给结论：每日进展跟踪的产出应该是"决策"，不是"记录"

1. 一条我用过三年的判断标准

我现在判断一次每日跟踪有没有价值，只看一件事：今天产生的信息，有没有改变任何一个人的行动？

如果一条更新读完，没有任何人调整排期、认领任务、升级风险、拉人协作，那这条更新就是噪音。它消耗了写的人 5 分钟、读的人 2 分钟，产出是零。一个 30 人团队每天每人写 5 分钟，一年是 600 多个工时，接近一个人 3 个月的产能。这笔账很少有人算过。

这条标准听起来很朴素，但它会直接推翻很多团队正在做的事情。日报模板里"今日完成、明日计划"两栏，本质上是记录；只有加上"阻塞/需要谁协助/风险信号"三栏，它才开始生产决策。

2. 每日跟踪真正要解决的问题是"不确定性衰减"

项目延期很少是某一天突然发生的，它通常是一条持续 5 到 15 天的缓慢恶化曲线：某个人开始含糊其辞、某个依赖迟迟没交付、某个测试环境反复出问题、某个需求在开发中途被改。

每日跟踪的价值，就是让这条曲线在早期变得可见。跟踪频率越高，你能看到的斜率越早，可选的应对手段就越多。到了最后三天才看到，你能做的只剩加班和砍需求。

我习惯用一个粗略的判断公式来分配跟踪精力：跟踪优先级 = 不确定性 × 影响面 × 时间窗口紧迫度。一个已经做了三年、接口稳定的模块，不确定性低，不需要每天跟；一个从没做过的第三方支付对接，不确定性高，即使它两周后才开工，也应该从今天开始每天盯。

3. 产品经理在这件事上的角色是"信息流设计者"

很多人把产品经理在进度跟踪里的角色理解成"催办员"，谁慢了催谁，谁没更新问谁。这个定位会让你迅速成为团队里最不受欢迎的人，而且效果越来越差。

我更倾向的定位是：设计一条信息流，让风险和阻塞自动流到有能力处理它的人面前，而不是流到你面前再转发。你要做的是设计字段、设计规则、设计升级路径，然后让工具和流程去跑。你只在规则失效的时候出手。

二、真实场景：三个项目里我看到的每日跟踪失效路径

1. 场景 A：30 人跨端项目，站会变成 19 分钟流水账

那是 2021 年一个智能硬件配套 App 项目，研发 30 人。站会按座位顺序轮流发言，每个人讲"昨天做了什么、今天做什么"。前 10 个人讲完，会议已经过去 15 分钟，剩下的时间只够勉强听完，没有时间讨论任何问题。

更麻烦的是，会上暴露的两个跨端接口问题，我记在了笔记本上，会后就淹没在当天 40 多封消息里。三天后再想起来，对方的排期已经排满了。

失效点不是会议本身，而是"发现问题"和"处理问题"之间缺少一条路径。会议只负责暴露，不负责承接。

2. 场景 B：远程分布式团队，日报沦为打卡仪式

另一个项目是 12 人的分布式团队，三个时区。我们要求每人每天下班前填日报。前两周执行率 100%，第三周开始掉到 70%，第五周不到 40%。

我去看那些仍然在填的日报，内容是"继续开发订单模块，预计明天完成"，连续五天几乎一字未改。填的人在应付，读的人也不看。整套机制名存实亡。

原因很直接：当一个人发现自己的更新从没得到过任何反馈，他就会停止认真更新。这是人性，不是态度问题。

3. 场景 C：需求持续插入，进度表永远是"还有两天"

第三个场景最典型。业务方每天在群里提需求，产品经理判断"这个很小，加一下吧"，开发被迫中断当前任务。结果每张卡片的"剩余两天"连续出现 8 次，燃尽图是一条几乎水平的直线。

这种情况下，进度跟踪工具并没有失效，它非常准确地把"你在原地踏步"画了出来。失效的是变更管理机制，没有人评估插入需求对在制任务的影响，也没有人拒绝。

4. 三个场景指向同一个结构性问题

把这三个场景放在一起看，会发现它们缺的东西各不相同：A 缺"问题承接路径"，B 缺"反馈闭环"，C 缺"变更准入"。但它们有一个共同点：

跟踪机制只覆盖了"上游采集"，没有覆盖"中游处理"和"下游闭环"。大多数团队的每日跟踪是半截工程，收集得很勤快，处理得很随意。

三、拆解误区：产品经理在每日跟踪上最常犯的七件事

1. 误区一：把"收集"当成"跟踪"

收集是单向的，跟踪是闭环的。收集只要求别人交作业，跟踪要求有人对交上来的信息负责。

我见过很多团队，日报收得非常齐，但没有任何人负责把其中的风险挑出来。产品经理的角色被简化成"汇总"，而不是"分流"。信息进来没人分流，等于没进来。

2. 误区二：把"日报模板"当成"机制"

模板只是一个字段集合，机制是"谁在什么时间填、谁在什么时间读、发现异常后谁在多长时间内响应"。只换模板不建机制，三周后就会退化成形式主义。

我自己的经验是，模板的字段数控制在 5 个以内。超过 5 个，填写成本上升，准确度反而下降。

3. 误区三：把"站会"开成"汇报会"

站会上最典型的错误是让每个人回答"昨天做了什么"。这本质上是在向产品经理或主管汇报，而正确的方式是向团队同步，让信息在成员之间流动。

判断标准很简单：如果你的站会上大部分时间是你和某个人在对话，其他人低头看手机，这个会开错了。

4. 误区四：只盯任务状态，不盯依赖和风险

任务状态是滞后指标。一张卡片从"进行中"变成"阻塞"，意味着问题已经发生了。依赖和风险才是先行指标，"某第三方接口的下游方还没确认字段格式"这件事，在没有变成阻塞之前就应该被跟踪。

我的做法是在看板上把任务卡拆成两类字段：状态字段（待办/进行中/已完成）和信号字段（无风险/有依赖/有阻塞/需决策）。产品经理每天真正要看的是信号字段，不是状态字段。

5. 误区五：跟踪颗粒度全员一致

给一个刚入职三周的工程师和一个带过五个项目的资深工程师用同样的跟踪频率，是资源浪费；反过来，对资深工程师完全不问，又会漏掉他可能遇到的跨团队问题。

合理的做法是按"人 × 任务"两个维度分档，具体我会在第四节给出分档标准。

6. 误区六：工具先行，规则缺位

很多团队遇到协作混乱，第一反应是换工具。换完之后混乱依旧，只是混乱换了个地方发生。

我坚持一个顺序：先写清楚"什么事、谁来做、什么时限"，再决定用工具怎么承载。工具解决的是自动化执行，不是帮你思考规则。

7. 误区七：只跟踪，不删减

跟踪机制会自然膨胀。一开始只有日报，后来加了站会，再加周报、风险表、燃尽图、迭代评审。半年后团队每周要花 6 小时在各种同步上。

我建议每季度做一次"跟踪机制审计"，把过去三个月没有产生过任何行动的信息字段直接删掉。删减和新增一样重要。

四、专业判断逻辑：跟踪什么、多久一次、谁来处理

1. 跟踪对象分层：六类对象，六种跟法

我把每日要跟踪的对象分成六类，每一类的负责人、更新频率和判断标准都不同。混在一起跟，必然会有遗漏或者过度。

这张表是我自己项目上实际用过的分类，最大的作用是提醒我：不要把每天的时间都花在第一行"任务"上。任务状态是最容易被工具自动捕获的，反而是最不需要人工盯的部分。

2. 节奏设计：异步更新 + 短同步 + 周复盘 + 里程碑锁

我不建议把所有信息都塞进每日站会。合理的节奏是分层的：

• 异步更新（每天，各自时间）：承载状态变化、字段更新、附件上传，不需要开会。
• 短同步（每天一次，15 分钟上限）：只处理阻塞、依赖、需要当面对齐的三类信息。
• 周复盘（每周一次，45 分钟）：看趋势、看累计流、看机制本身是否需要调整。
• 里程碑锁定（节点前 3 天起，每日）：临时提高跟踪频率，锁定交付风险。

关键是第三层和第四层经常被忽略。只有前两层的团队，会在每次交付前重复"最后三天救火"的循环。

3. 责任设计：四个角色缺一不可

一套能跑起来的每日跟踪，需要四个角色：

1. 更新者：任务的直接执行人，负责如实填写状态和信号字段。
2. 识别者：通常是产品经理或交付负责人，负责每天从更新中挑出需要处理的信息。
3. 升级者：有权调动资源的人，通常是项目负责人或业务方代表，负责接收升级并决策。
4. 关闭者：负责确认风险解除、更新记录，避免问题反复出现。

很多团队只有第 1 个和第 2 个角色，导致识别出来的问题没人有权处理，最后全部堆在产品经理身上，慢慢变成催办。

4. 一个可复用的跟踪强度判断方法

前面提到公式是"不确定性 × 影响面 × 时间窗口"。落地时可以简化成三档：

• 高强度跟踪：新领域 + 影响交付主线 + 窗口小于两周。每天必看，必要时当面确认。
• 中强度跟踪：熟悉的模块 + 影响部分功能 + 窗口两到四周。隔天看一次即可。
• 低强度跟踪：稳定模块 + 影响局部 + 窗口一个月以上。只在周复盘时扫一眼。

我自己踩过的坑是：一开始对所有人所有事都用高强度，结果自己的注意力被稀释，真正关键的那两件事反而没盯住。分层不是偷懒，是保护注意力。

五、全流程 SOP：从早会前 30 分钟到周复盘结束

1. 早会前 T-30：数据准备与异步更新收口

站会质量很大程度上取决于会前的准备。我把每天早上 9:00 到 9:20 定为"数据沉淀窗口"，要求所有人在这 20 分钟内完成自己任务的字段更新，包括状态、剩余工时预估、信号字段。

产品经理在这 20 分钟里做的事情是：

• 扫一遍看板上的信号字段，标出所有"有依赖""有阻塞""需决策"的卡片。
• 对照昨日遗留的风险清单，检查有没有到期未处理的项。
• 把需要在站会上讨论的议题控制在 3 个以内，写进会议邀请。

这 20 分钟是整套机制里投入产出比最高的一段。没有它，站会就会变成信息收集会。

2. 站会中 T+0：15 分钟的三个问题

站会上我坚持每个人只回答三件事，而且顺序固定：

1. 我负责的关键任务，今天会推进到哪一步？（只讲影响主线的任务，不讲全部）
2. 我遇到了什么阻塞，需要谁协助？（当场指向具体的人）
3. 我识别到什么新风险？（没有就说没有，不勉强）

规则有三条：时长超过 15 分钟立即中断，未讨论的议题转会后；细节讨论一律会后单独拉人；产品经理不逐人追问，只记录和分流。

这里有一个反直觉的点：站会上不需要每个人都发言。如果某个人的工作今天不涉及跨人协作，他完全可以只更新工具、不发言。强迫所有人说话，是站会超时的主要原因。

3. 站会后 T+15：承接与分流

站会结束后的黄金 15 分钟，决定会议有没有价值。产品经理需要完成三件事：

• 把会上暴露的每个阻塞，变成一条有责任人、有截止时间的记录。
• 把需要外部资源的问题，升级给对应的升级者，并明确期望回复时间。
• 把不需要当天处理的议题转入周复盘议题池。

我见过太多团队，会上讨论得很热烈，会后没有任何书面承接，第二天问题原样重现。站会真正的产出不是讨论，是那张会后 15 分钟内填完的阻塞登记表。

4. 日中：异常升级与依赖协调

白天的工作是产品经理投入时间最不固定的一段。我的做法是设定两个固定的检查点：中午 12:30 和下午 16:30。每个检查点花 10 分钟做三件事：

看有没有新的阻塞产生、看有没有升级出去的问题超时未回、看依赖方有没有按约定交付中间产物。三个问题都没变化，就不用做额外动作。

这里的关键是不要实时盯。实时盯会让你陷入消息流，一天下来做了很多协调，但没有任何结构性改进。

5. 日终：简报与次日风险清单

日终我建议只发一份不超过 200 字的项目简报，内容包括：今天推进了哪几个关键节点、当前最大的一个风险是什么、明天需要谁配合什么。

不要发全量进度列表。全量列表是给工具看的，200 字简报是给人看的。两者的读者不同，不要混用。

同时，产品经理要在工具里维护一份"次日风险清单"，通常是 3 到 5 条，只保留当天判断最需要关注的项。清单每天更新，不累积。

6. 周度：趋势复盘与机制删减

周复盘不看单点，看趋势。我通常看四个数：本周阻塞的平均关闭时长、依赖按时交付率、延期首次暴露的平均提前天数、团队主动升级问题的次数。

最后一个数尤其重要。如果主动升级次数持续偏低，说明团队的升级通道是堵的，大家觉得升了也没用，就会选择自己扛。

周复盘还要做一件事：删掉一个无效字段或一次无效会议。机制不删减，一定会膨胀。

每日项目简报模板（200字以内）
【今日推进】

支付网关对接完成联调，明日进入压测

订单详情页 UI 走查完成，遗留 2 个中优先级问题

【当前最大风险】

风控侧规则接口文档承诺周三交付，目前未确认，若周四仍未交付将影响压测窗口

【明日需要配合】

需要测试同学 10:00 前提供压测账号

需要风控侧确认接口文档交付时间

六、产品经理流程优化：把跟踪嵌进研发流程，而不是叠加在流程上

1. 需求阶段：验收标准与依赖预判

如果需求评审时没有定义清楚验收标准，那么到了开发阶段，进度跟踪就必然变成"到底做完了没有"的扯皮。这类扯皮消耗的沟通成本，往往比开发本身还高。

我在需求评审时会强制补三样东西：可验证的验收标准、外部依赖清单、以及最晚确认时间。依赖清单里要写清楚"需要谁在什么时间提供什么"，否则这个依赖在开发第一天就会变成一个黑盒。

2. 开发阶段：看板规则、在制品限制、阻塞标签

开发阶段最有效的两个规则是列的在制品数量限制和阻塞标签的强制使用。

在制品限制的意思是，如果"开发中"这一列只允许同时存在 5 张卡片，那么第 6 张卡就必须等。这个限制会强迫团队先完成再开始，减少多任务并行带来的切换损耗。

阻塞标签的作用是让"卡住"这件事从隐性变成显性。规则可以设为：任何卡片被标记为阻塞超过 24 小时，自动通知产品经理和对应升级者。这条规则让阻塞不再依赖人的自觉上报。

3. 测试与发布：质量门禁与发布清单

测试阶段最容易被忽视的每日跟踪指标不是"测了多少用例"，而是缺陷的收敛速度。如果新增缺陷数连续三天大于关闭缺陷数，无论测试进度看起来多好，这个版本都不应该按原计划发布。

发布前我会锁定一份清单，逐项确认：回滚方案是否演练过、监控告警是否配置、灰度范围和时间是否确认、客服话术是否同步。清单不是形式，它把发布风险从人的记忆转移到了流程上。

4. 变更管理：插入需求必须做影响评估

需求插单是每日跟踪机制最大的破坏源。我的做法是建立一张简单的影响评估表，任何新需求进入当前迭代前，必须回答四个问题：

1. 这个需求会让哪张在制卡片停下来？
2. 停下来之后，原定交付时间会推迟几天？
3. 有没有替代方案，比如放到下个迭代？
4. 提出需求的人是否接受这个推迟？

把这四个问题问出来，很多"很急但其实不急"的需求会自己消失。不是因为你在拒绝，而是因为成本被显性化了。

七、案例观察：用 PingCode 承载一套每日跟踪系统的实际过程

1. 背景：一个 180 人研发组织的机制改造

我参与过一个 180 人规模的研发组织，五条产品线，跨三个办公地点，原来用的是海外研发管理工具。触发改造的原因有三个：数据合规要求、许可证成本逐年上涨、以及原工具的报表能力无法满足管理层的周度趋势分析需求。

选型时我们重点看了几个方向，最后落在 PingCode。主要考虑三点：它主要服务中大型企业及 100 人以上组织，组织级权限和项目集管理能力匹配我们的体量；支持私有化部署，能满足合规要求；同时支持从 Jira 平滑迁移，历史数据和工作流不需要推倒重来。

迁移这件事我的判断是：对 100 人以上的组织，迁移成本往往被低估。字段映射、工作流差异、历史报表重建，这三块占了大头。所以"能不能平滑迁移"应该是选型时的硬指标，而不是加分项。

2. 迁移动作清单：我们实际做的六件事

整个迁移我们用了 11 天，其中前 4 天全部在梳理字段，没有动系统。这四天是值得的。

• 字段盘点：把原系统里所有自定义字段导出，逐个判断"是否还有人用"。结果 47 个字段砍到 19 个。
• 工作流映射：把原有的状态机画在白板上，和新平台的状态重新对应，保留必要的状态，合并语义重复的状态。
• 历史数据迁移：只迁近两年的数据，更早的归档为只读附件。
• 报表重建：把管理层最常看的四张报表在新平台上重做一遍，作为验收标准。
• 试点团队先行：先让一条产品线用两周，暴露配置问题。
• 全量切换与旧系统只读：旧系统保留三个月只读权限，作为过渡期的查询兜底。

3. 每日跟踪的具体配置思路

我们在新平台上搭的看板并不复杂，核心是四条规则：

1. 卡片必须填写"依赖方"和"最晚确认时间"两个字段，否则不允许流转到开发中。
2. 卡片进入"阻塞"状态超过 24 小时，自动推送通知给产品经理和该产品线的交付负责人。
3. 每条产品线维护一个风险登记视图，按"影响交付时间"排序，每日站会直接打开这个视图。
4. 周度生成一份累计流图，观察各状态的停留时间变化，而不是只看完成数量。

私有化部署带来的一个额外好处是，我们可以把内网的单点登录和内部的告警系统打通，让阻塞通知直接进到团队日常使用的沟通工具里。通知落不到日常工具上，规则等于没有。

4. 上线 8 周后的观察数据

以下是我们在脱敏项目上记录到的变化，数据来自团队内部的周度统计，不是行业基准，仅供同规模团队参考。

最后一项数字我认为最有价值。主动升级次数上升，说明团队开始相信"升级是有用的"，而不是把问题捂着。一个团队愿不愿意主动暴露问题，是每日跟踪机制是否真的跑通的唯一可靠信号。

5. 踩过的三个坑

第一个坑是通知过载。上线第一周，我们配的自动通知太多，产品经理一天收到三十多条，很快就不看了。后来把通知收敛到"阻塞超过 24 小时"和"依赖超期"两类，效果才出来。

第二个坑是字段设得太全。一开始我们要求必填 7 个字段，执行率迅速下滑。后来砍到 3 个必填、2 个选填，完成率回到 90% 以上。

第三个坑是只做迁移不做培训。我们把注意力都放在了数据和配置上，忽略了对新人的使用培训。结果新加入的成员在两个月内仍然不清楚信号字段该怎么填，这部分数据一直是脏的。

看板自动化规则配置思路（伪配置）
规则一：依赖字段校验

触发条件：卡片从「待开发」流转到「开发中」

校验项：依赖方 不为空 且 最晚确认时间 不为空

校验失败动作：阻止流转 + 提示填写

规则二：阻塞超时通知

触发条件：卡片处于「阻塞」状态 且 停留时长 大于 24 小时

动作：通知 产品经理 + 交付负责人

通知频率：每 24 小时提醒一次，最多 3 次

规则三：周度趋势报表

生成周期：每周一 08:00

内容：各状态平均停留时长、新增阻塞数、阻塞关闭数、依赖超期数

推送对象：产品线负责人 + 项目经理

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

1. 5 人以下小团队：不要建机制，用一个共享视图

这个规模下，任何正式的日报和站会都是浪费。你们的沟通带宽本来就足够，问题在于信息没有留痕。

我建议只做一件事：一个共享看板，三列，待办、进行中、已完成，每张卡片写清楚负责人和预期完成时间。每天看一次，不做会议，不做日报。等团队超过 8 个人再考虑加站会。

2. 10 到 30 人单产品团队：异步更新 + 每日 15 分钟站会

这个规模是每日跟踪机制性价比最高的区间。建议：每日异步更新（字段不超过 5 个）、每天 15 分钟站会、每周 30 分钟复盘。

产品经理需要承担识别者角色，每天花 20 分钟筛信号字段。这个投入在这个规模下完全可以承受。

3. 50 到 200 人跨部门项目：分层机制 + 明确升级人

这个规模下，最大的风险是产品经理成为所有信息的瓶颈。必须分层：各产品线自己维护每日跟踪，产品经理只处理跨产品线的依赖和风险。

同时必须明确升级人。没有升级通道，跨部门问题会在产品经理这里堆积成堰塞湖。升级人不需要是高管，但必须有权调整本部门的排期。

4. 分布式或跨时区团队：异步为主，同步为辅

跨时区团队不要追求每天开站会，成本太高。建议以异步更新为主，同步会议压缩到每周两次，且必须有书面议程。

关键是更新要结构化。纯文本日报在跨时区场景下几乎不可用，因为阅读者需要逐字读完才知道有没有和自己相关的内容。字段化的更新可以让人五秒钟扫完。

5. 有合规和私有化要求的组织：把部署方式当硬指标

金融、汽车、能源这类行业，数据不能出内网是硬约束。这种情况下，选型时要把私有化部署能力和权限体系放在功能丰富度之前考虑。

另外要提前评估迁移路径。对超过 100 人的组织来说，一次迁移投入 10 到 20 人天是常见量级，把它算进决策成本里，比事后补救便宜得多。

九、不同情况下的取舍：没有"全都想要"的选项

1. 跟踪颗粒度 vs 团队负担

颗粒度越细，风险越早暴露，但团队填写负担越重。这不是可以同时优化的两个方向。

我的取舍原则是：对高不确定性、高影响面的对象加密，对其他对象降频甚至停掉。不要试图找到一个"适合所有任务"的颗粒度，那个颗粒度不存在。

2. 同步会议 vs 异步更新

同步会议解决的是"需要来回讨论才能对齐"的问题，异步更新解决的是"信息分发"的问题。用同步会议做信息分发，是最大的浪费。

判断标准很直接：如果这条信息只需要被知道，不需要被讨论，就不要开会。反过来，如果一个问题讨论了三轮还没结论，那也不是会议的问题，是决策权的问题。

3. 工具深度配置 vs 迁移与维护成本

功能越强的平台，配置越复杂，迁移和维护成本越高。100 人以下的团队往往高估了自己对复杂配置的消化能力。

我见过不少团队买了功能齐全的平台，最后只用了其中的看板功能，其余全部闲置。这种情况不如选一个简单但能被充分使用的工具。

4. 标准化 vs 团队自治

统一模板便于横向对比和汇总，但会牺牲不同团队的适配度。我的做法是：字段结构统一，字段内容自治；节奏统一，会议形式自治。这样既能汇总，又不至于让每个团队都别扭。

5. 短期提速 vs 长期可预测

最难的取舍是这一条。短期提速靠加班和堆人，见效快；长期可预测靠机制建设，见效慢但可持续。

我的判断是：如果项目周期少于 3 个月，优先短期方案；如果团队要长期存在，必须有人在建机制。两者不冲突，但需要明确谁来负责长期那一部分，通常不应该是在救火的那个人。

十、收尾：一套明天就能开始的行动清单

1. 我认为最值得记住的三个判断

第一，每日跟踪的产出应该是决策，不是记录。如果一条更新没有改变任何人的行动，它就是噪音，应该在季度审计时被删掉。

第二，产品经理的价值在设计信息流，不在催办。把风险和阻塞的流转路径设计好，比每天多问十句进度有效得多。

第三，机制的失效往往发生在中游和下游，不在采集端。大多数团队不缺更新，缺的是承接、升级和闭环。

2. 本周可以做的五件事

1. 把现有的日报或看板字段列出来，删掉过去三个月没产生过任何行动的两项。
2. 给看板加上两个信号字段：依赖方、最晚确认时间，并设为流转必填。
3. 把站会时长压到 15 分钟，只讨论阻塞、依赖、需决策三类信息。
4. 指定一个明确的升级人，并公开说明"什么问题在什么时限内可以升级给谁"。
5. 本周复盘时只看四个数：阻塞平均关闭时长、依赖按时交付率、延期暴露提前天数、主动升级次数。

3. 一个月后再看的两个数

一个月后，我建议重点看两个数：主动升级问题次数有没有上升，延期首次暴露的提前天数有没有变长。

前者反映团队对机制的信任，后者反映机制的实际预警能力。这两个数如果同时改善，说明你的每日跟踪不是形式，而是真的在降低项目的不确定性。

如果只改善一个，或者都没改善，不要急着换工具，先回到"跟踪什么、谁承接、谁决策"这三个问题上，重新检查一遍。工具只能放大已有的规则，不能替代规则本身。