进度跟踪如何做好动态？实施团队制度设计与操作步骤

很多团队把"进度跟踪动态化"理解成"填得更勤"：日报从周报变成日更，站会从每周一次变成每天一次，看板刷新频率从三天一次变成实时。结果是信息量涨了五倍，决策质量一点没变，项目经理依然在周五下午才发现某个关键路径已经停了四天。我在过去几年里参与过七八个研发中心的进度管理改造，规模从 40 人到 600 人不等，一个反复被验证的结论是：动态进度跟踪的成败，取决于"偏差从发生到被决策者感知"这一段的时间，而不是取决于填报动作的频率。

这篇文章会把实施团队真正要设计的那套制度拆开讲清楚：信号怎么定义、节奏怎么排、阈值怎么设、响应谁负责，以及在 PingCode 这类中大型企业常用平台上，这些制度如何落到具体的字段、视图和自动化规则里。

一、先给结论：动态进度跟踪考的是"两个延迟"，不是"更新频率"

1. 动态的本质是一条信息回路，不是一个动作

绝大多数关于进度跟踪的讨论都停留在"要不要写日报""站会开多久"这个层面，但这些其实是回路末端的一个动作而已。真正的动态指的是：项目状态发生变化，不管是任务提前完成、被阻塞、范围变更还是人员被抽调，这个变化能够以可接受的成本、在可接受的时间内，传导到有权限调整资源的那个人手上，并触发一次真实的动作。

我用"回路"这个词是想强调它的闭环属性。只采集不判定、只判定不升级、只升级不响应，都属于断掉的回路。断在哪一环，动态就死在哪一环，而且在表面上看起来一切正常：看板在刷、工时在填、周报在发，所有人都在"做进度跟踪"。

2. 两个可测量的延迟指标

既然是一条回路，就可以被测量。我在每个项目里只盯两个数：

• 进度感知延迟：从某个任务实际发生偏离（真实剩余工作量超过计划、依赖未就绪、人员被占用）的那一天，到这条信息出现在一个会被决策者看到的界面上，间隔的自然天数。
• 响应延迟：从决策者看到偏差，到做出明确处置（调整范围、补人、调序、接受延期并同步给下游）的间隔天数。

这两个数加起来，就是一个组织"纠偏所需的最短时间"。它决定了一个项目最多能承受多大的意外，如果你的感知延迟加响应延迟是 15 天，那么任何在里程碑前 15 天内发生的意外，你都来不及处理，只能事后解释。

我见过最极端的对比是一家做工业软件的公司：他们的周会纪要写得极其工整，项目经理汇报时用红黄绿三色标签标注状态。但实测下来，一个任务从"实际已经延期"到"红色标签出现在周报上"，平均是 11.6 天。原因不是人不努力，而是采集节奏（每周一次）、汇总结算（会前一天汇总）、判定动作（会上讨论）和响应动作（下周执行）四件事串行叠加，每一环都拿走几天。

3. 制度设计要围绕延迟收敛，而不是围绕填报动作

这个结论会直接改变实施团队的设计顺序。常见的做法是先定"每天下班前填工时"，再考虑怎么用这些数据；正确的顺序是先定"什么变化必须在多久内被谁知道"，再倒推需要采集什么信号、用什么频率采集、谁负责判定。

填报动作是结果的副产品，不是制度的目的。当团队发现"我填的这个阻塞项，两小时内真的有人来处理"，填报质量会自己变好；反之，如果填了三个月没有任何动作，再严格的规定也会退化成敷衍。

二、真实场景：三个团队的进度跟踪为什么越管越乱

1. 场景 A：180 人研发中心，周报制下的"周一惊喜"

这家公司做企业级 SaaS，研发中心 180 人，同时在建项目 20 个左右。他们的进度管理相当规范：每个项目有详细的 WBS，每个任务有起止日期，每周五下午项目经理汇总进度写成周报，周一上午开项目例会同步。

问题出在"周一惊喜"。我参与诊断时做了一件很简单的事：随机抽 30 个已完成的任务，调出它们的实际状态变更记录（代码提交、任务状态流转、测试通过），再看这些变化第一次出现在周报上的时间。结果是平均 9.2 天的滞后，中位数 7 天，最长的 23 天。

更麻烦的是连锁反应。因为感知延迟接近两周，当问题出现在例会上时，团队已经失去了调整空间，能做的只剩下抱怨和加班。久而久之，例会从"决策会"退化成"追责会"，项目经理开始倾向于在周报里把黄色写成绿色，因为"报上去也是挨骂，不如再扛一周看看"。

2. 场景 B：每日站会开得很热闹，但没人真的处理阻塞

第二家是互联网业务团队，60 人左右，站会执行得非常到位：每天早上 9:30，全员站立 15 分钟，每人回答三个问题。听起来是标准敏捷实践。

但我跟了两周之后发现一个尴尬的事实：同一个阻塞项，平均会在站会上被重复提到 4.3 次，才有人真正去处理。因为它只是在会上被"说出来"，没有被登记成一个带责任人和时限的条目，散会之后它就回到了提出者的私人记忆里。

这就是典型的"感知快、响应慢"。站会解决了信息暴露，但没有解决响应归属。你甚至可以观察到一种畸形的现象：团队学会了在站会上用"我在等 XX 的接口"这种表述规避责任，说完之后所有人都点头，然后什么也不发生。

3. 场景 C：工具换了三套，制度一次没改

第三家最有代表性。两年内他们换了三套项目管理工具，每一套上线时都做过培训、都强调"这次一定要用起来"。但进度跟踪的规则始终是那句口头约定："大家及时更新一下状态。"

没有完成定义，没有更新时限，没有偏差阈值，没有升级路径。工具提供了燃尽图、累积流图、自定义仪表盘，但没有一个视图被真正用作决策依据。换工具解决的是"信息存放在哪里"，不解决"信息如何变成动作"。当制度缺位时，工具最多让混乱变得好看一点。

三、拆解六个常见误区

1. 把"动态"等同于"高频"

这是最普遍的一个。很多实施团队在设计制度时的第一反应是缩短周期：周报改日报，周会改日会。但没有配套的判定和响应规则时，高频只会制造更多的噪音。

我做过一个粗糙但有用的测算：一个 60 人团队每天写一份 5 分钟能写完的日报，加上阅读和汇总，每天消耗约 12 人时。如果这 12 人时没有换回任何一个提前暴露的偏差，它就是纯粹的净损失。判断频率是否合理，标准只有一个：这个频率下的信息，有多少比例真的触发了动作。

2. 把工具看板当成制度本身

"我们已经在某项目管理平台里建好看板了，大家按列拖动就行。"这句话我听过太多次。看板是载体，制度是约束条件的集合：谁在什么时点必须更新哪个字段、什么情况下必须标注阻塞、超过几天必须升级。

如果这些约束没有写下来、没有形成可检查的规则、没有和会议节奏绑定，看板就会自然退化成一块装饰品。三个月后你会看到卡片在一个列里堆积如山，而没有人觉得这有问题。

3. 用百分比汇报进度

"这个任务完成了 80%。"，这是我在进度会议上最怕听到的一句话。百分比进度的问题在于它不可验证、不可累加、且天然倾向于乐观。心理学上有个很稳定的现象：任务做到一半时，人的主观完成感往往远高于实际剩余工作量的比例。

更致命的是，80% 这个数字在数学上没有意义。两个 80% 的任务加起来不是 160%，也不是 80%，它什么都不是。当多个任务都用百分比汇报时，你根本推不出项目还剩多少工作量。

4. 只跟踪任务完成，不跟踪依赖与阻塞

在 100 人以上的组织里，真正杀死进度的往往不是"某人做得慢"，而是"某人在等另一个人"。跨模块接口、测试环境、第三方联调、硬件到位、审批流程，这些依赖项一旦断裂，任务本身的状态会停留在"进行中"，看起来一切正常。

我见过一个项目，关键路径上的任务在"进行中"状态停留了 27 天，任务负责人每天都在认真工作，但他真正能推进的部分在第 5 天就做完了，剩下 22 天全在等一个上游接口。因为进度跟踪只看了任务状态，没人看得到"等"这个动作。

5. 用计划日期对比实际日期，忽略剩余工作量重估

很多团队的做法是：计划 3 月 10 日完成，今天是 3 月 5 日，还没完成，那就是"还差 5 天"。这个算法在一切顺利时没问题，但当任务已经延期时，它会导致一个系统性的偏差，人们会默认"最后冲刺能追回来"。

正确的做法是周期性重估剩余工作量，而不是计算计划日期和今天之间的差值。一个已经延期 6 天的任务，如果重估剩余工作量是 12 天，那么它的真实预测完成日是今天加 12 天，而不是原计划日加 6 天。这两个数字往往差出一倍以上。

6. 制度只约束执行层，不约束决策层

这是我见过最隐蔽也最致命的一个误区。制度里写着"任务负责人必须在状态变化后 4 小时内更新"，但没有写"项目经理必须在收到阻塞升级后 1 个工作日内给出处置意见"。

结果就是执行层被严格约束，决策层完全自由。团队很快会发现：更新了也没人管，升级了也没人应。一旦这种预期形成，制度的崩塌是不可逆的，你再怎么强调纪律都没用，因为理性的人不会持续做无效动作。

四、专业判断逻辑：动态进度跟踪的四层设计模型

把前面这些问题抽象一下，我通常用四层模型来设计制度。这四层是有依赖顺序的：信号层不成立，后面三层全是空转；响应层不成立，前三层全是浪费。

1. 信号层：定义什么叫"可信的进度"

信号层要回答的问题是：一个任务说它"完成了 60%"，这个 60% 到底意味着什么？如果团队里每个人对"完成"的理解都不一样，那么所有上层建筑都不成立。

我的做法是强制三件事必须被显式记录：

• 完成定义（DoD）：什么样才算这个任务真的结束。"代码写完"不算，"代码合并 + 单测通过 + 联调验证"才算。
• 剩余工作量：用小时或人天表示，由执行者本人定期重估，而不是用百分比。
• 阻塞与依赖：当前任务是否在等待外部输入，等的是谁、等的是什么、已经等了多久。

这三件事在任何中大型项目管理平台上都可以落地成自定义字段。关键不在字段本身，而在于它是否是强制的，留空就意味着任务状态无法流转。这是制度能落到工具里的最重要的一环。

下面是我在某装备制造企业研发中心实际使用的一组进度信号字段定义，可以直接参考：

{
"task_id": "REQ-2043",

"完成定义": "接口联调通过 + 单测覆盖率≥70% + 文档更新",

"剩余工作量_人天": 3.5,

"阻塞项": ["等待 REQ-2031 鉴权接口就绪"],

"阻塞开始时间": "2025-03-04T09:00",

"阻塞已持续_小时": 54,

"置信度": "中",

"预测完成日": "2025-03-14",

"状态最后更新": "2025-03-11T18:00",

"更新人": "zhangsan"

}

这套字段看起来啰嗦，但它解决了一个根本问题：任何人看到这张卡片，都能在 30 秒内判断这个任务是不是健康，而不需要找执行者聊天。这就是"可信信号"的标准。

2. 节奏层：采集频率必须与决策频率匹配

节奏层的核心判断是：不要让采集频率和决策频率脱节。如果你每天采集但每周决策，那么多出来的六天数据只是在堆积焦虑；如果你每周采集但每天需要决策，那么你就是在盲飞。

我在 100 人以上组织里最推荐的节奏是"事件驱动为主 + 固定节奏兜底"：

1. 事件驱动部分：阻塞发生、依赖未就绪、剩余工作量重估变化超过 30%、预测完成日推迟超过 2 天，这四类事件触发即时通知。
2. 固定节奏部分：每天一次 15 分钟的短同步（只处理异常，不逐人汇报），每周一次 45 分钟的偏差复盘（只看红黄项）。

这样做的好处是，日常的信息流动不依赖会议，会议只处理真正需要多人协同的事。会议的价值在于处理分歧，而不在于收集信息，信息收集交给系统，会议只做决策。

3. 判定层：把"红色"变成一个可复现的规则

大多数团队的红黄绿判定是项目经理的主观感觉，这会导致两个后果：不同项目的红色不可比，以及项目经理有动机把红色写成黄色。

我的建议是把判定规则写成明确的条件表达式，让系统自动算，而不是让人来选。一套我在多个项目里验证过的规则如下：

规则化的最大价值不是精确，而是一致。当所有人知道"阻塞超过 24 小时就一定是红色"，就不存在"要不要上报"的心理博弈了。它把一个人的道德判断，变成了一条系统的机械规则，这对降低组织的汇报摩擦极为有效。

4. 响应层：没有承诺时限的制度等于没有制度

响应层是整个模型里最容易被跳过、但决定成败的一层。它要回答的是：红色状态出现之后，谁必须在多长时间内做什么。

我的经验是要把响应写成带时限的承诺，并且这些承诺要被公开跟踪。比如：

• 阻塞升级后 4 小时内，被依赖方必须给出明确的可用时间，不能回复"我看看"。
• 项目经理在收到红色升级后 1 个工作日内，必须给出四种处置之一：补资源、调范围、调顺序、接受延期并同步。
• 超过规定时限未响应的条目，自动进入上一级管理者的待办列表。

第三条是让制度真正有牙齿的关键。它不是用来惩罚谁，而是用来防止"沉默的失责"，大多数项目失控，不是因为有人做错了什么，而是因为没有人做任何事。

五、案例与数据观察：一个 200 人研发中心的六个月改造记录

1. 改造前的基线

这家企业做智能装备，研发中心 214 人，包含硬件、嵌入式软件、上位机软件、测试四条线，同时在建项目 38 个。他们原本用的是一套海外项目管理工具，后来因为数据合规和私有化部署要求，需要迁移到国产平台。

他们最终选择了 PingCode。这里我说明一下选择理由，因为这直接影响了后续制度落地的可行性：PingCode 主要服务中大型企业及 100 人以上组织，在需求、迭代、测试、缺陷、工时这些环节的字段可定制程度较高，支持私有化部署，而且提供从 Jira 平滑迁移的能力，对于有大量历史数据、又不希望业务中断的团队来说，迁移成本可控。对这家企业来说，最关键的是私有化部署，研发数据不出内网是硬要求。

改造前的基线数据（来自内部记录，已做脱敏处理）：

• 进度感知延迟：平均 9.2 天
• 响应延迟：平均 6.5 天
• 返工工时占比：18%
• 周例会时长：4.5 小时/周（含跨部门）
• 里程碑按期达成率：61%

2. 制度设计的四份"纸"

整个改造其实只产出四份文档，加起来不到 20 页，但它们把四层模型全部覆盖了：

1. 《进度信号字段定义》：规定哪些字段必填、完成定义怎么写、剩余工作量按什么口径估。这一条让"可信信号"从主观变成客观。
2. 《状态判定规则表》：就是前面那张红黄黑表格，被配置成平台上的自动化规则，系统自动打标，人不能改。
3. 《升级与响应时限》：明确每一级的响应时限和责任人，并写清楚超时后果。
4. 《同步节奏说明》：明确每日短同步和每周偏差复盘的时间、参与人、议程和输出物。

值得强调的是第二份。他们没有让项目经理手工标红黄绿，而是在项目管理平台里配置了自动化规则：当"预测完成日 – 计划完成日 > 3 天"或者"阻塞已持续 > 24 小时"时，系统自动把卡片标记为红色并推送给项目经理。这个动作把"要不要标红"从人际博弈变成了系统行为，是整个改造里最有价值的一次设计。

3. 六个月后的数据变化

最有意思的是周例会时长。改造的初衷不是减少会议，但结果会议自然缩短了，因为大部分信息在会前已经通过系统流转完成，会上只剩需要决策的分歧项。当信息采集不再依赖会议，会议才有可能回归它的本意。

另一个值得注意的数据是填报意愿。我在第 6 个月做了一次匿名调研，问"你是否认为更新进度状态对你有帮助"，选择"有帮助"或"很有帮助"的比例从改造前的 34% 上升到 79%。变化的原因很直接：他们发现填了阻塞之后，真的有人在 4 小时内回应。

4. 踩过的三个坑

这个项目并不是一次成功，中间有三个坑值得记录。

第一个坑是字段加太多。第一版设计里我让他们加了 14 个自定义字段，结果执行者填写负担过重，两周后开始批量填默认值。后来砍到 6 个必填 + 3 个选填才稳定下来。教训是：必填字段的数量上限，应该由执行者每次更新愿意花的时间决定，我一般建议控制在 90 秒以内。

第二个坑是迁移时没有清理历史数据。从 Jira 迁移过来时，他们把过去三年的全部任务都搬了过来，包括已经废弃的 12000 多条。这直接导致视图卡顿、报表失真。后来花了三周做数据归档，只迁移近 12 个月的活跃项目。如果你也计划做平台迁移，我的建议是：迁移的是结构，不是历史包袱；老数据用只读快照归档，不要混进活跃视图。

第三个坑是只发布制度不做演练。制度发布后的头两周，几乎没人按规则操作。后来他们做了一个动作：用真实的历史延期项目做了一次"桌面推演"，按新规则重新走一遍，看会在哪个环节触发红色、谁会收到通知、谁该在多长时间内响应。这次推演比任何培训都有效，因为它让每个人看到了"制度运行时我具体要做什么"。

六、实施团队的具体操作步骤

下面这套步骤是我在多个 100 人以上组织里反复使用过的落地清单。它不依赖某个特定平台，但需要平台支持自定义字段、自动化规则和权限分级。

1. 第一步：测出你的两个延迟基线

不要跳过这一步。找 20-30 个最近 3 个月内发生过的延期或阻塞事件，对每一个回溯：实际发生偏离是哪天、第一次出现在任何汇报或记录里是哪天、做出处置是哪天。算出平均值，这就是你的起点。

没有基线，你后面所有的改进都无法证明有效，也无法说服管理层继续投入。这一周的时间投入，是整个项目回报率最高的一步。

2. 第二步：定义"完成"和"可信剩余工作量"

挑选占比最高的 5-8 类任务（比如需求分析、接口开发、联调、测试用例执行），为每一类写一句可验证的完成定义。标准是：不参与这个任务的人读完之后，也能判断它是否完成。

同时规定剩余工作量用时长而非百分比表达，并且每周至少重估一次。这一条会引起最大阻力，因为重估意味着承认之前的估计不准。要提前和管理层沟通好：重估不是追责依据，而是预测依据。

3. 第三步：把必填字段压缩到 6 个以内

我的建议组合是：完成定义、剩余工作量、预测完成日、阻塞项、阻塞起始时间、状态最后更新。这 6 个字段能支撑前面所有的判定规则。其他信息可以作为选填，但不参与自动化判断。

字段一旦确定，就要在平台上配置成"不填不能流转状态"。这个强制约束是制度落地的技术保障。

4. 第四步：写判定规则，并且让系统来执行

按前面那张红黄黑表格的逻辑，在项目管理平台里配置自动化规则。关键是不要让人工选择状态颜色，而是让系统根据字段值自动计算。这一步能消除 80% 的汇报博弈。

如果你用的是 PingCode 这类支持自定义自动化规则的平台，可以配置成：当预测完成日推迟超过阈值、或阻塞时长超过阈值时，自动改状态、自动通知项目经理、自动在专属视图里置顶。整个过程不需要人做任何判断。

5. 第五步：明确升级路径和响应时限

至少设计三级升级：任务负责人 → 项目经理 → 研发负责人（或项目集负责人）。每一级要写清楚"收到什么信号、在多久内、必须做什么动作"。

响应时限要现实。我通常建议第一级 4 小时、第二级 1 个工作日、第三级 2 个工作日。时限的意义在于形成预期，而不是追求速度；一个稳定的 1 天响应，比一个偶尔 1 小时但经常失约的响应更有价值。

6. 第六步：重组会议，让会议只处理分歧

把原有的周会拆成两类：每日 15 分钟异常同步（只讲红黄项，绿项不发言），每周 45 分钟偏差复盘（只看本周新增红色、已解决阻塞、跨团队依赖）。

关键在于议程要提前自动生成，而不是靠人整理。可以在平台上配置一个"本周异常"视图，会议开始前 30 分钟自动推送给参会人。

7. 第七步：做一次桌面推演

用真实的历史项目（尤其是延期过的），按新规则完整走一遍：哪些字段会被填成什么值、哪条规则会被触发、谁在什么时候收到什么通知、谁应该做什么响应。把整个链条跑通一次，比发十份文档有效。

推演时最好让所有角色都参与，包括产品、开发、测试、项目经理，让他们亲眼看到自己在制度里的位置。

8. 第八步：上线后前四周每周复盘一次规则本身

制度刚上线时一定有问题：某个字段没人填得准、某个阈值太敏感或不敏感、某级响应实际上做不到。前四周要每周花 30 分钟只讨论"规则本身是否需要调整"，而不是讨论具体项目。

把"调整规则"和"处理项目问题"分开，是让制度快速稳定的关键。否则团队会把规则问题当成个案问题处理，制度永远长不大。

9. 第九步：三个月后重新测两个延迟

回到第一步的方法，重新测感知延迟和响应延迟。这两个数字是唯一能证明制度是否有效的证据。如果感知延迟降了但响应延迟没动，说明你把力气全花在了采集端，需要回头补响应层。

七、不同情况下的取舍

1. 团队规模：20 人以下别照搬

如果你的团队在 20 人以下，我建议大幅简化。这个规模下，信息传递本身不是瓶颈，大家坐在一个屋里，谁被卡住了喊一声就知道。此时建立复杂的字段体系反而是负担。

20 人以下团队最小可行的做法是：只保留"阻塞项 + 预测完成日"两个字段，每日 10 分钟同步，人工判定状态。规模小的时候，人际沟通的效率远高于制度化流程。

而到了 100 人以上、项目数超过 15 个时，制度化就是必需品。因为此时决策者不可能再靠聊天获得全局视图，跨团队依赖的数量级也超过了口头协调的能力上限。PingCode 这类主要服务中大型企业、100 人以上组织的平台，其价值恰恰在这个区间才充分体现，它提供的不是"看得更细"，而是"在复杂依赖网络中保持可判定性"。

2. 项目类型：稳态项目和探索型项目要用两套规则

稳态项目（需求明确、技术路径清晰、交付日期刚性）适合严格的字段约束和自动化判定，红黄黑规则可以直接用。

探索型项目（技术验证、新业务方向、需求高频变化）则相反。这类项目的最大风险不是"延期"，而是"做了不该做的事"。对它们，我更推荐把跟踪重心从"任务进度"转向"假设验证进度"，每周回答一次"这周我们验证了什么、推翻了什么、下一步要验证什么"。

用同一套进度制度管两类项目，是很多组织效率低下的隐性原因。稳态项目嫌流程太松，探索型项目嫌流程太重。

3. 成熟度：先补缺口最大的那一层

如果你的团队连基本的状态更新都不及时，就不要急着上自动化判定规则，先把信号层做扎实。反过来，如果团队更新很积极但问题依然频发，说明瓶颈在响应层，这时候该做的是给管理者定响应承诺，而不是给执行者加填报要求。

我见过太多团队在信号层反复折腾（换字段、换视图、换工具），而问题其实出在响应层。判断方法很简单：随机抽 10 个已升级的红色项，看有多少在 24 小时内得到了明确处置。如果低于一半，你的问题就在响应层。

4. 工具与迁移：私有化和迁移路径要提前想清楚

对中大型企业来说，工具选型往往不是功能对比问题，而是合规和迁移成本问题。我参与过的几个项目中，最终决策因素几乎都是私有化部署能力和历史数据迁移的平滑度。

如果你的团队现在用的是海外项目管理工具，并且有计划迁移，我的建议是：把迁移和制度改造合并成一次动作，而不是分两次做。因为迁移本身就是一次全员重新认识流程的机会，分开做会浪费掉这个窗口期。选择支持 Jira 平滑迁移的平台可以显著降低这次动作的成本，这也是很多国产替代方案被中大型组织纳入候选的重要原因。

5. 投入产出的取舍：不要一次改造所有项目

最后一条取舍关于范围。我强烈建议不要在全部门同时推行新制度。选 2-3 个有代表性的项目先跑三个月，拿到两个延迟的改善数据之后，再横向推广。

原因有两个：一是新制度一定需要调优，全量推行的调优成本巨大；二是横向推广时，一个"别人已经跑通并拿到数据"的案例，比任何行政命令都有效。

八、写在最后：先改一个变量，再谈体系

回头看这几个项目，我认为动态进度跟踪最反直觉的一点是：它成功的关键不在于"知道得更早"，而在于"知道了之后有人必须动"。信息采集是必要条件，但响应承诺才是充分条件。一个每天更新但无人响应的系统，比一个每周更新但每次都触发处置的系统要糟糕得多。

另一个值得记住的判断是：进度跟踪制度的设计目标，是降低组织内部的"解释成本"，而不是提高监控强度。当团队不再需要花大量时间解释自己为什么延期、不再需要揣测上报会不会挨骂，他们才有余力去解决真正的问题。这也是我在案例里看到填报意愿从 34% 涨到 79% 的根本原因，不是纪律变严了，而是反馈变真了。

如果你准备开始动手，我的建议是下一步只做一件事：挑一个正在延期或刚刚延期过的项目，按第六节的第一步，把它的两个延迟测出来。不要先买工具，不要先写制度，先拿到一个真实的数字。有了这个数字，你就有了和团队讨论的起点，也有了三个月后证明改进有效的方式。

等这个数字出来了，再按第四节的四层模型，看看你的团队最先断在哪一层，是信号不可信，还是判定没规则，还是响应没人负责。找到最弱的那一环，先补它。一次只补一环，三个月内你一定能看到变化。