追踪管理指南：管理层如何做好进度跟踪，流程优化全流程

2019 年我带过一个 260 人的研发组织，每周一早上 9 点，14 位管理者挤在会议室里，对着一份 47 行的 Excel 逐行过进度。会议平均开 105 分钟，最后真正产生决策的只有 3 条，剩下的时间都在解释口径：为什么 A 团队说的"完成"和 B 团队说的"完成"不是一回事。半年后我把这套跟踪机制全部拆掉重做，会议压到 35 分钟，偏差的平均发现时间从 9 天降到 1.5 天。这段经历让我形成一个判断：大多数管理层的进度跟踪问题，不是跟踪得太少，而是跟踪得太晚、太细、太依赖人工。

这篇指南把我在 7 个组织、累计约 2400 人规模上踩过的坑、验证过的方法和取舍逻辑完整拆开讲。

一、核心结论：管理层跟踪的是偏离，不是进度

先把结论摆在最前面。如果你只记得住一句话，请记住这句：进度跟踪的本质是偏差管理，不是进度播报。"进度播报"回答的是"现在做到哪了"，"偏差管理"回答的是"哪里偏离了、为什么偏离、谁来纠正、什么时候纠正完"。前者消耗的是汇报时间，后者消耗的是判断时间，而管理层的稀缺资源恰恰是判断时间。

第二个结论：跟踪频率必须与决策周期对齐，而不是与日历对齐。很多组织默认"周会 + 周报 + 每日站会"三件套，但你真正的决策节奏可能是两周一次的资源调配、一个月一次的版本评审。当跟踪频率高于决策频率时，多出来的那些汇报不会产生任何决策，只会产生噪音和防御性表达。

第三个结论：凡是靠人手工填写的字段，三个月后一定会烂掉。这不是对执行者的不信任，而是对注意力的尊重。一个人每天要填 6 个字段、每周要更新 3 张表，前两周能坚持，第三周开始应付，第六周开始批量补填，第九周数据就完全失去判断价值。我在至少 5 个团队里见过完全相同的衰变曲线。

第四个结论：流程优化的目标不是把流程画全，而是把返工点和等待点砍掉。一张漂亮的端到端流程图如果每个节点都在等审批、等联调、等测试环境，那它优化的是"可解释性"，不是"交付速度"。真正的优化收益，80% 来自缩短等待和减少返工，而不是来自增加审批节点。

二、真实场景：为什么周报越来越厚，判断力却越来越差

1. 三种典型组织的跟踪现状

我把接触过的组织大致分成三类。第一类是"表格驱动型"，通常 50 到 150 人，跟踪靠 Excel 加微信群，管理者对进度的认知来自个别骨干的口头汇报。这类组织的典型症状是：信息很快，但不可追溯，一旦骨干离职，进度认知直接归零。

第二类是"工具堆叠型"，通常 150 到 600 人，已经上了至少两套系统，一套管需求、一套管任务，中间靠人工同步。这类组织的症状是数据很多但互相打架，同一个需求在 A 系统显示"测试中"，在 B 系统显示"待验收"，管理者每次开会第一件事是吵架对口径。

第三类是"流程完备型"，通常 600 人以上，流程文档齐全、审批节点完整、度量指标一大堆，但交付周期依然很长。症状是每个环节都"合规"，但谁也不对端到端的交付结果负责，瓶颈在部门墙之间来回漂移。

2. 为什么 100 人是个分水岭

100 人以下时，靠"人盯人"是可行且高效的。创始人或研发负责人认识每一个人，知道谁快谁慢，一句话就能推动事情。这时候上重流程反而是负担。

但跨过 100 人之后会发生三个不可逆的变化。第一，管理层不再认识每个人，只能通过数据认识组织；第二，跨团队依赖数量呈平方级增长；第三，信息传递的每一跳都会衰减约 20% 到 30% 的准确度。这三个变化叠加，就意味着"人盯人"模式的边际成本开始超过收益。

我在一个 130 人的团队里做过一次对照观察：同一个跨团队需求变更，通过三层口头传递后，最终落在执行端的版本与原意偏差了 41% 的关键约束。而通过工作项系统直接关联变更记录时，这个偏差降到 8% 以下。

3. 一个真实的周一早晨

还原一个我亲历的场景。周一 8 点 50 分，项目经理把上周各部门提交的进度表合并成一张总表，发现有三个模块的状态描述互相矛盾。9 点会议开始，前 25 分钟用于确认"到底哪个状态是对的"，中间 40 分钟逐个团队汇报，最后 20 分钟讨论了两个风险但没形成结论，因为缺少准确的影响面数据。

会议结束后，三个待办被记录下来，但没有人负责验证。到下周三，其中一个待办已经因为延误两周变成了线上事故。整个链条里，没有一个人偷懒，但机制本身决定了偏差一定会在最晚的时刻才被看见。

这就是我想强调的核心问题：跟踪机制的价值不体现在"信息完整度"，而体现在"偏差被发现的时刻距离偏差发生的时刻有多远"。这个时间差，我称之为偏差发现延迟，它是衡量追踪管理成熟度最有效的单一指标。

三、拆解常见误区：七种把跟踪做废的方式

1. 误区一：把任务完成率当成进度

"本迭代完成 78% 的任务"，这句话几乎不包含任何可决策信息。任务完成率是工作量口径，不是价值口径。 20 个任务里完成 16 个，如果剩下的 4 个正好是决定能否上线的关键依赖，那实际进度是 0，不是 80%。

我在一个团队里做过统计：按任务数计算的完成率与按可交付价值计算的完成率，在迭代中期的偏差平均达到 27 个百分点。也就是说，用任务完成率判断进度，管理层的乐观程度会被系统性高估四分之一以上。

2. 误区二：用统一颗粒度管理所有工作

有些管理者要求所有工作项都必须拆到 8 小时以内，理由是"便于跟踪"。这个做法在稳定期有效，但在探索型工作上会造成严重扭曲：一个需要两周调研的技术预研，被硬拆成 10 个"任务"，执行者会为了填满状态而制造虚假进展。

正确做法是按不确定性分级，而不是按工时分级。确定性高的工作拆到天，确定性低的工作只设定检查点和退出条件。判断标准很简单：这项工作能否在一开始就说清"完成的样子"。

3. 误区三：把周报当成跟踪工具

周报是异步沟通工具，不是跟踪工具。它天然存在三个缺陷：一是滞后，写周报时偏差已经发生了一周；二是选择性，写的人会倾向于呈现对自己有利的叙事；三是不可聚合，每份周报的字段和口径都不一样，无法横向对比。

我的建议很直接：如果一件事只能通过周报被发现，那说明你的系统里缺少对应的信号采集点。周报应该用来做复盘和思考，而不是用来做状态同步。

4. 误区四：只跟踪执行，不跟踪决策

这是最隐蔽也最昂贵的误区。大部分跟踪系统只记录"任务卡在谁那里"，不记录"决策卡在谁那里"。但在实际项目中，真正拖慢交付的往往是那些悬而未决的决策：技术方案选型没定、资源优先级没排、验收标准没达成一致。

我在一个 300 人组织里做过一次归因分析，发现交付周期中超期最严重的 20% 工作项里，有 63% 的阻塞原因是"等待决策"或"等待外部确认"，而不是"执行能力不足"。如果跟踪体系里没有"决策项"这一类对象，你永远看不到这个瓶颈。

5. 误区五：数据靠人工汇总

人工汇总的问题不只是慢，更严重的是它引入了不可见的偏差。汇总者会根据自己的理解筛选信息，会为了会议效率而合并相似的表述，会在数据缺失时用经验填补。每一个动作都在削弱数据的可信度。

判断一个组织的跟踪体系是否成熟，有个很简单的测试：让负责汇总的人休假两周，看管理层的进度认知是否会断层。如果是，那这套体系本质上是人的能力，不是系统的能力。

6. 误区六：把仪表盘当成果

我见过太多"仪表盘项目"：花了三个月做了 20 个图表，上线三个月后访问量降到个位数。原因通常只有一个，图表展示的是"组织想知道什么"，而不是"管理者要用它做什么决定"。

一个可用的仪表盘，每个图表都应该对应一个明确的动作。比如"阻塞超过 3 天的工作项数"对应动作是"当天点名处理"，"跨团队依赖未确认项"对应动作是"进入周会议程"。没有对应动作的图表，就应该从仪表盘上删掉。

7. 误区七：流程优化的目标是合规，不是提速

运营团队天然倾向于通过增加节点来降低风险，这在金融、医疗等强监管场景是必要的，但在大多数研发场景是过度设计。每增加一个审批节点，都会带来额外的排队时间，而排队时间在交付周期中的占比往往被严重低估。

我实测过一个中型团队的审批链路：一道"技术评审"审批平均排队 1.8 天，但实际评审动作平均耗时 22 分钟。也就是说，98% 的时间花在等待，而不是在评审。优化这类流程的关键不是让评审更快，而是缩短排队。

四、专业判断逻辑：三层信号模型与阈值设计

1. 三层信号模型

我把管理层的跟踪信号分成三层。事实层回答"发生了什么"，包括工作项状态、阻塞记录、变更历史；趋势层回答"正在往哪走"，包括前置时间分布、返工率、燃尽速度；决策层回答"我们该做什么"，包括偏差阈值触发的升级、资源重排、范围裁剪。

大多数组织的跟踪体系只覆盖了事实层，部分覆盖趋势层，几乎没有覆盖决策层。结果是管理者每天看到大量事实，却很少被主动告知"这件事需要你现在决定"。

（1）事实层的关键要求是自动采集、不可编辑。状态流转本身就产生数据，不需要额外填报。

（2）趋势层的关键要求是可比、可回溯，能按团队、按时间、按工作类型切片对比。

（3）决策层的关键要求是有明确触发条件和责任人，不能只展示问题而不指派动作。

2. 跟踪颗粒度的能力匹配原则

颗粒度不是越细越好，而是要与团队的执行能力匹配。判断标准有两条：团队能否稳定地把工作项拆到目标颗粒度，以及管理层能否在目标频率上真正消化这些数据。

我通常这样设定：单个工作项的执行周期中位数控制在 1 到 5 天。低于 1 天说明拆得过细，管理开销大于价值；高于 5 天说明颗粒太粗，偏差会在颗粒内部积累而无法及时暴露。这个区间不是理论推导，而是我在不同规模团队里反复调整后得到的经验区间。

3. 偏差阈值与升级路径

阈值设计是决策层的核心。没有阈值的跟踪等于没有跟踪，因为所有信息都是平的，管理者无法判断哪一条更需要关注。

我常用的四类阈值：执行状态超过预期周期 50% 未更新、关键路径工作项阻塞超过 2 个工作日、跨团队依赖确认超过 3 个工作日未闭环、决策项超过约定截止日未关闭。每条阈值都对应一个自动升级动作和明确的责任人。

设计阈值时最容易犯的错误是把阈值设得太宽松，导致升级通知满天飞，最后所有人都不看了。我的建议是初始阈值设紧一点，先让少量高价值告警建立信任，再逐步放宽。

4. 流程优化的四个坐标

衡量一条流程是否需要优化，我只看四个坐标：频率（多久发生一次）、单次耗时（实际操作时间）、等待时间（排队时间）、返工率（需要重做的比例）。

优化的优先级排序是：高频率 + 高等待 → 优先优化；低频率 + 高耗时 → 可以容忍，或者干脆自动化掉；高频率 + 高返工 → 立刻查根因，通常是标准不清或输入质量差。不要在没有数据的情况下凭感觉优化，那大概率会把时间花在低频流程上。

5. 度量体系怎么设计才不会被博弈

任何被用来考核的度量，都会被优化。这不是道德问题，是组织行为的必然。所以我设计度量时遵循三条原则。

第一，用配对指标防止单点优化。只考核"交付速度"会导致质量下降，所以速度必须和"变更失败率"配对；只考核"缺陷数"会导致少报缺陷，所以缺陷数必须和"缺陷逃逸率"配对。

第二，用分布代替平均值。前置时间的平均值毫无意义，P50 和 P85 才说明问题。P50 反映常态，P85 反映长尾，而长尾通常才是客户感知到的体验。

第三，测量系统本身而不是测量个人。度量的目的是改善流程，如果变成个人排名，数据质量会在两周内崩坏。

# 工作项前置时间指标定义（示例）
metric: lead_time_days

description: 从工作项进入"就绪"状态到进入"已完成"状态的日历天差

scope:

include_status: [ready, in_progress, in_review, done]

exclude_types: [epic, sub_task_of_bug]

aggregation:

p50 # 反映常态交付能力

p85 # 反映长尾阻塞情况

p95 # 用于识别系统性瓶颈

segmentation:

by_team

by_work_item_type

by_month

guardrail_metrics:

change_failure_rate # 与速度配对，防止为提速牺牲质量

escaped_defect_ratio # 与缺陷数配对，防止少报

alert_rules:

condition: "lead_time_days > p85 * 1.5"

action: "自动生成阻塞排查待办，指派给团队负责人"

五、具体案例：一个 280 人研发组织的跟踪体系改造

1. 改造背景

2022 年我参与了一个 280 人研发组织的追踪体系改造。它由 7 条产品线组成，当时的跟踪方式是：各产品线用各自的工具和表格，每两周由项目管理办公室（PMO）手工汇总，形成一份 30 多页的进度报告递交给管理层。

改造前的关键数据：PMO 三人团队每周投入约 26 人时用于汇总；偏差平均发现延迟 11 天；迭代交付准时率 54%；变更失败率 19%。管理层对进度报告的信任度，在一次内部匿名调研中只有 3.1 分（满分 10 分）。

2. 第一步：把跟踪对象从人换成流

我们做的第一件事，是把所有产品线的工作项统一到一套对象模型上：需求、任务、缺陷、决策项、风险项。其中"决策项"是这个组织之前完全没有的对象类型。

这一步的价值在第三个月才显现出来。把决策项纳入跟踪后，我们发现积压超过 15 天的决策项有 37 个，其中 12 个直接阻塞了关键路径。这些决策项在过去从来不出现在进度报告里，因为它们不属于任何人的"任务"。

第二步是统一状态机。7 条产品线原本有 5 套不同的状态定义，统一后收敛为 6 个状态：待评估、就绪、进行中、待评审、待验收、已完成。状态减少本身不产生价值，但因为每个状态都有明确的进入条件，工作项的流动性变得可测量了。

3. 第二步：用自动采集替代人工填报

改造的核心动作是把 PMO 的手工汇总彻底取消，改为由系统自动聚合。这里的关键不是"把表格搬到线上"，而是让状态变更本身成为数据源，工作项流转时自动记录操作人、时间戳、前一状态，不需要任何人额外填写。

我们在这家组织里选择的是 PingCode。选型时我们评估了四个维度：一是能否承载 280 人、7 条产品线的复杂权限与项目结构；二是能否通过 API 把状态数据同步到内部数据仓库；三是私有化部署能力，因为该组织的数据合规要求不允许核心研发数据出内网；四是历史数据的迁移成本。

最终落地的方案是私有化部署 + 与内部 BI 打通，工作项状态每 15 分钟同步一次到数据仓库，趋势层指标由 BI 侧统一计算。这样做的额外好处是，管理层看到的指标和团队看到的原始数据来自同一份源，口径争议大幅减少。

4. 第三步：迁移与落地节奏

迁移是这类改造中最容易被低估的环节。这家组织原本使用一套海外工具，历史工作项约 21 万个，附件约 3.4 TB，自定义字段超过 180 个。我们采用 PingCode 的 Jira 平滑迁移能力，分三批完成，每批间隔两周。

第一批迁移的是已关闭的历史项目，只做归档不做映射，主要目的是验证字段映射规则。第二批迁移进行中的项目，这一批最复杂，需要处理状态映射和人员映射。第三批迁移新立项的项目，直接按新模型创建。

整个过程实际耗时 6 周，比原计划的 4 周多出两周，多出来的时间几乎全部花在自定义字段的清洗上，180 多个字段里有 60 多个无人能说明用途。这段经验让我后来在做任何迁移评估时，都会先做一次"字段考古"，把无人使用的字段砍掉再迁，能省下大量时间。

对于有国产替代诉求的组织，这类工具还有一个实际优势：私有化部署加上本地化支持，在数据合规和响应速度上都更可控。我不想把话说得太满，选型是否合适，还是要看组织自身的合规要求和 IT 承载能力。

5. 改造后的数据结果

改造上线 9 个月后，我们对比了几个关键指标。PMO 的汇总投入从 26 人时/周降到 3 人时/周；偏差平均发现延迟从 11 天降到 2.3 天；迭代交付准时率从 54% 提升到 79%；变更失败率从 19% 降到 11%。

另外一个不在计划内的收益是：管理层的进度报告阅读率从 22% 上升到 74%。原因很简单，报告从 30 多页变成 2 页，每一条都对应一个需要关注或决策的事项。

6. 踩过的坑

第一个坑是一次性铺开所有度量。我们最初上线了 14 个指标，第三个月发现团队开始"为指标工作"，比如为了让前置时间好看而把工作项拆得过细。后来砍到 5 个核心指标，其中 2 个是配对指标，情况才好转。

第二个坑是把告警直接发给个人。早期我们把阻塞告警发到具体执行人，结果造成明显的防御性行为：有人会提前把工作项状态改掉以避免告警。改成发给团队负责人、并要求在团队内讨论后处理，这个问题基本消失。

第三个坑是低估了迁移后的适应期。工具上线不等于体系上线。前三周很多人还在用旧习惯工作，我们在第 4 周做了一次"双轨期复盘"，明确了哪些动作必须以系统为准，此后数据质量才真正稳定下来。

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

1. 50 人以下的组织

不要上复杂的跟踪体系。这个阶段的正确做法是：用一块看板把所有在做的事情可视化，每周一次 30 分钟的同步会，只讨论阻塞项。不要设 KPI 指标，不要做周报模板，不要上多套工具。

判断是否需要升级信号很简单：如果同一个人连续两周在会上说"卡在等某某确认"，那就说明需要把"跨团队依赖"这个对象显性化，而不是加会议。

2. 50 到 200 人的组织

这个区间的主要矛盾是口径不统一。建议动作有三步：先统一工作项类型和状态机；再把状态变更自动化，取消人工汇总；最后建立不超过 5 个核心指标，其中至少 2 个是配对指标。

这个阶段可以开始考虑引入专业工具，但重点不是功能多少，而是能否自动产出可信的趋势数据。如果一套工具仍然需要专人每周导出整理，那它解决的是展示问题，不是跟踪问题。

3. 200 到 1000 人的组织

这个区间的关键任务是打通数据链路。建议把工作项数据接入内部数据仓库或 BI，让趋势层指标由统一口径计算，而不是每个部门各算一套。

同时必须建立决策项跟踪机制。我的经验是，这个规模的组织里，决策积压造成的延误通常占总延误的 40% 以上，但几乎没有组织在跟踪它。

如果存在数据合规要求或国产替代诉求，私有化部署的能力在这个阶段会变得重要。以 PingCode 为例，它主要面向中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，在这个规模区间的适配度较高。但工具只是载体，真正决定成败的是对象模型和阈值设计。

4. 1000 人以上或多事业部组织

这个规模的核心问题不再是数据采集，而是如何在统一口径和业务差异之间取得平衡。建议采用"最小公共集"策略：集团层只保留 5 到 7 个跨事业部可比的指标，其余指标由各事业部自定义。

另一个必须处理的问题是层级聚合。事业部看团队级数据，集团看事业部和关键项目级数据，两层的颗粒度、刷新频率、告警规则都应该不同。用同一套视图服务所有层级，是这个规模最常见的设计错误。

5. 强监管行业

金融、医疗、汽车电子等行业的跟踪体系需要额外满足可追溯性和审计要求。这类场景下，状态流转的完整审计日志是硬需求，任何允许状态被悄悄修改的设计都是不可接受的。

建议在设计阶段就把审计字段纳入对象模型：每次状态变更记录操作人、时间、原因、关联证据。这会增加约 15% 的存储和接口开销，但能省掉后续大量的合规解释成本。

七、不同情况下的取舍

1. 透明度与心理安全感之间的取舍

跟踪体系越透明，信息越准确，但团队感受到的监督压力也越大。这两者不是非此即彼，关键在于透明度对着流程还是对着个人。公开团队级的前置时间分布，通常能促进改进；公开个人的完成率排名，几乎必然导致数据失真。

我的做法是：聚合数据默认公开，个体数据只对直接上级可见，且不作为绩效输入。

2. 实时性与信噪比之间的取舍

实时数据听起来诱人，但大部分管理者并不需要实时。刷新频率过高会制造两类问题：一是告警疲劳，二是管理者倾向于对短期波动做出过度反应。

我的建议是分层设置刷新频率：事实层近实时，趋势层按天，决策层按周。把"发现"做成实时，把"反应"保持低频，这是控制信噪比最有效的方式。

3. 标准化与团队自治之间的取舍

统一状态机、统一字段、统一度量，会削弱团队对自己工作方式的控制感，尤其是那些工作性质差异很大的团队。但完全自治会导致数据无法聚合。

可行的折中方案是"最小公共集 + 扩展区"：定义一套所有团队必须遵守的公共字段和状态，同时允许每个团队在扩展区自定义字段，但扩展字段不参与跨团队对比。这个方案在 7 条产品线的组织里运行良好。

4. 自研、采购与开源的取舍

自研的优势是完全贴合业务，劣势是维护成本会随着组织变化持续上升。我见过一个团队自研的跟踪系统用了 4 年后变成技术债，因为最初的开发者离职，没人敢改核心逻辑。

采购的优势是功能成熟、迭代快，劣势是定制受限。开源的中间路线看似两全，实际需要投入相当的自建运维能力。

我的判断标准是：跟踪系统不是你的核心竞争力，就不要自研。把工程资源投在业务逻辑上，跟踪能力用成熟平台承载，对大多数组织是更划算的选择。

5. 一次到位与渐进演进的取舍

我强烈建议渐进演进。一次到位的大改造通常有三个致命问题：变更太大导致执行力分散、反馈周期太长导致问题发现太晚、没有中间收益导致内部支持度下降。

更稳的路径是：第一期只做状态自动采集，第二期做趋势指标，第三期做阈值告警和决策闭环。每一期控制在 6 到 8 周，每一期都有可衡量的产出。

八、30 天落地清单：从明天开始可以做什么

1. 第 1 周：盘点与对齐

第一件事是把自己的跟踪现状拍一张"X 光片"。列出当前所有用于跟踪的表格、系统、会议、报告，标注每一项的产出时间、维护人力、被引用次数。

我几乎可以保证，你会找到至少 3 项投入产出明显倒挂的跟踪动作。这些是第一批要砍掉的对象。改造的第一步从来不是加东西，而是先减东西。

1. 清点现有跟踪载体（表格、系统、会议、报告）
2. 标注每一项的维护成本与被使用频率
3. 识别重复采集同一信息的环节
4. 确定本期要保留的 5 个核心指标

2. 第 2 周：定义对象与阈值

把工作项类型收敛到 5 类以内，把状态机收敛到 7 个状态以内，并为每个状态写清进入条件。这一步的产出物应该是一页纸，而不是一份几十页的规范文档。

同时定义四类阈值：超期未更新、关键路径阻塞、跨团队依赖未闭环、决策项逾期。每条阈值都要写清触发条件和升级对象。

3. 第 3 周：自动化采集与试运行

取消人工汇总，改为系统自动聚合。这一周的重点是验证数据准确性，方法是随机抽取 20 个工作项，人工核对系统记录的状态与实际状态是否一致。一致率低于 90% 就不要进入下一周，先解决数据源问题。

4. 第 4 周：会议重构与复盘

最后一周重构会议结构。把原来用于同步进度的会议改成基于偏差的决策会议，议程只有三块：阈值触发的偏差项、需要决策的事项、上周决策的闭环情况。

会议时长控制在 45 分钟以内。如果超时，说明阈值设置太宽松或者决策责任人不明确。

# 30 天落地自检清单（可直接复制使用）
week_1:

跟踪载体清单已完成: true/false

识别出可砍掉的重复跟踪动作数量: ___

核心指标收敛到5个以内: true/false

week_2:

工作项类型 70）

guardrail:

是否出现为指标而工作的行为: true/false

是否出现防御性填报: true/false

结语：跟踪体系的上限，是管理层的判断力上限

回到最开始那个周一早晨。那场 105 分钟的会议之所以低效，不是因为参与的人不努力，而是因为机制把有限的时间分配给了信息搬运，而不是判断和决策。当我把这套机制改掉之后，最大的变化不是数据变多了，而是管理者开始被系统"提醒"去思考，而不是被要求去阅读。

如果这篇指南只能留下一个观点，我希望是这个：追踪管理的成熟度，不看你有多少指标、多少图表、多少流程节点，只看一个数字，偏差从发生到被你看见，平均需要多久。这个数字决定了一切流程优化的空间上限。

下一步，我建议你做三件具体的事。第一，本周内算出你自己的偏差发现延迟，方法是随机挑 10 个曾经造成延误的工作项，看它们的实际偏差时间和被记录时间差多少。第二，把你现在所有用于跟踪的载体列一张表，砍掉至少 30%。第三，从下周的会议开始，取消进度逐个汇报环节，只讨论阈值触发的偏差项和待决策事项。三周之后，你会对"跟踪"这件事有完全不同的理解。