实际进度管理指南：项目负责人如何做好进度管理，协同管理全流程

我见过太多项目负责人栽在同一个坑里：周报上写着"整体完成 80%，进度正常"，两周后突然宣布延期一个月。你去追问，得到的回答是"供应商没交货""测试环境一直没准备好""需求又变了"。这些理由可能都是真的，但它们不该在延期发生后才被说出来。问题不在于执行不力，而在于项目负责人管的"进度"和执行团队理解的"进度"，根本不是同一个东西。

这篇文章只讲一件事：从计划落地那一刻起，到项目交付为止，项目负责人到底该管什么、怎么管、什么情况下必须做取舍。我会把它拆成基准设定、事实采集、偏差计算、协同机制、纠偏复盘五个环节，每个环节都给出具体动作、失败信号和判断标准。文章里的数据来自我带过的十几个跨部门交付项目和一些同行的复盘样本，属于经验观察，不是行业统计报告，引用时请注意这个边界。

一、先给结论：进度管理管的不是时间，是事实和决策

如果只让我留一句话给项目负责人，我会说：你的核心职责不是催任务，而是保证"实际发生了什么"这件事始终可见，并且在偏差出现时让决策发生。

这句话听起来朴素，但它直接推翻了三种常见的做法。第一种是把自己当成高级催办员，每天在群里问"这个做完了吗"；第二种是把自己当成表格管理员，执着于让甘特图保持漂亮；第三种是把自己当成新闻发言人，向上汇报时只讲好消息。这三种做法有一个共同后果：信息在传递过程中被美化了，而项目负责人成了最后一个知道真相的人。

1. 进度管理的四个交付物

判断一个项目负责人是否在做真正的进度管理，我通常看他有没有稳定产出这四样东西：

• 一个被正式确认的进度基准：包含里程碑、关键路径、依赖关系和缓冲，并且经过关键干系人签字或书面确认。
• 一份可持续更新的事实台账：每个任务的完成状态有明确证据来源，而不是靠执行人自己报一个百分比。
• 一套偏差预警机制：明确什么情况触发黄灯、什么情况触发红灯、触发后谁必须在多长时间内响应。
• 一本变更记录：范围、资源、需求、供应商的每一次变化都有痕迹，能回溯、能归因。

这四样东西缺任何一样，进度管理就会退化成"靠人盯人"。而靠人盯人的项目，一旦超过三四十人、涉及三个以上部门，基本必然失控。

2. 为什么"完成百分比"是最危险的一个数字

"这个模块完成 80%"是我最警惕的一句话。原因是百分比是一个纯粹的自我评估，它没有口径、没有证据、没有验收标准。同样是"80%"，可能意味着代码写完但没联调，也可能意味着联调完了但没测试，还可能意味着测试完了但缺陷没修。

更麻烦的是，百分比天然倾向于在后期停滞。一个人做任务，前 80% 可能只花了一半时间，剩下 20% 要花另一半时间。当所有人都按"完成度"汇报时，你在项目中期看到的是一幅过于乐观的图景，真实风险被系统性地推迟暴露。

3. 计划进度、基准进度、实际进度必须分开管理

这三个词在日常对话里经常被混着用，但在管理上它们是完全不同的东西。

我在一个制造业客户的数字化项目里见过一次典型事故：团队一直拿"计划进度"当对照标准，而计划进度是三个月前拍的脑袋，中间需求已经改过两轮。结果每次例会都在讨论"为什么比原计划慢了 15 天"，却没人意识到原计划本身早就失效了，真正的对照标准应该重新基线化。讨论了六周，项目还是延期，团队士气被磨掉一大截。

二、真实场景：一个跨部门项目是怎么一步步滑向延期的

我把它写成一个典型的复合型场景，这类情况在中大型组织里出现频率很高。

1. 项目背景与初始状态

某企业要在内部上线一套新的业务流程系统，涉及业务部门、研发部门、运维部门、外部供应商四方，总周期 16 周，团队规模约 60 人，分属四个汇报线。项目负责人是从业务部门抽调过来的，有业务经验但没有跨部门指挥权。

启动会上，各方都表了态，计划也排得很完整，WBS 拆到了三级，甘特图画得很漂亮。这是这个项目最顺利的一天。

2. 第一个裂缝：完成定义没有统一

第 3 周，研发侧汇报"接口开发完成"，业务侧认为"接口还不能调"，运维侧认为自己还没参与。三方的"完成"标准完全不同，但没有人在启动时把这件事说清楚。

这个裂缝的代价在后面才显现出来：第 8 周做集成测试时，发现有一批接口的数据字段与业务侧的理解不一致，需要返工。返工本身用了 5 个工作日，但它落在关键路径上，直接吃掉了项目仅有的 3 天缓冲。

这就是为什么我说"完成"这个词必须在项目第一天被定义清楚。不是定义成一个抽象概念，而是定义成可验证的证据：代码合并并通过评审？接口文档评审通过并完成联调？还是业务侧签字确认可用？

3. 第二个裂缝：协同靠会议，决策不闭环

第 5 周开始，项目负责人发现进度落后，于是把周会改成一周两次，又加了一个每日站会。会议数量上去了，延期却没有缓解。

我让他统计一下这四周的会议产出，结果很说明问题：四周开了 14 次跨部门会，形成了 31 条"待办事项"，其中只有 9 条有明确责任人和截止时间，最终按期关闭的只有 5 条。剩下的 26 条，有的没人认领，有的认领了但没跟进，有的在下次会上被重新讨论一遍然后再次悬空。

开会不等于协同。协同的本质是责任接口清晰、决策有记录、超期有升级。当一个组织只增加会议频率，却不增加决策闭环机制时，会议本身会变成一种成本，而不是解决方案。

4. 第三个裂缝：变更不留痕，延期无法归因

第 7 周到第 11 周，项目经历了三次需求调整、两次供应商交货延期、一次关键人员离职。每一次变化都被口头讨论过，但没有一次形成正式的变更记录。

等到第 13 周复盘时，项目负责人被高层问"为什么会延期"，他只能笼统回答"变更太多"。这个回答在管理上毫无价值，因为没有变更记录，就无法区分哪些延期是合理的、哪些是管理失控造成的。高层的感受是"这个负责人说不清楚"，而不是"项目确实遇到了不可控因素"。

5. 结果：延期 6 周，但真正的问题不是 6 周

项目最终延期 6 周交付。但我认为比延期本身更严重的，是三件事：团队对进度汇报失去信任，跨部门协作关系变得紧张，项目负责人的管理权限在项目后半程事实上被架空，因为高层开始直接找各部门要数据。

这三个后果，会在下一个项目里继续发酵。

三、拆解六个常见误区：它们为什么"看起来对"但实际有害

下面这六个误区，是我在复盘项目时出现频率最高、也最容易被合理化的一批。每一个我都给出替代做法。

1. 误区一：把完成率当成验收标准

"完成率"是自我评估，"验收"是第三方确认。这两者之间隔着一条鸿沟。

替代做法：为每个关键交付物定义"完成定义"，并列出验收证据。比如"接口开发完成"的定义可以是：代码合入主干、通过代码评审、接口文档更新、完成与下游系统的联调、下游负责人书面确认。只要有一条没满足，这个任务状态就不能标记为完成。

2. 误区二：把会议数量当成协同力度

会议是同步信息的工具，不是解决问题的机制。真正解决问题的机制是：明确的决策人、明确的决策时限、明确的责任接口。

替代做法：把会议拆成两类。一类是同步会，控制在 15 分钟以内，只讲偏差和阻塞；另一类是决策会，只在有明确待决事项时召开，会前发材料，会上只做决定，会后 24 小时内发出决策记录。

3. 误区三：所有任务都当关键任务

当所有任务都被标红时，红色就失去了意义。团队会逐渐对预警脱敏，这是最危险的状态。

替代做法：明确关键路径，只对关键路径上的偏差做高强度预警。非关键路径任务只要浮动时间还够，可以正常波动，不必频繁上报。

4. 误区四：计划不留缓冲，或缓冲被公开消耗

很多团队要么不留缓冲，要么留了缓冲但所有人都知道"还有 10 天缓冲可以烧"。后者的危害更大，因为缓冲会以最快速度被消耗完。

替代做法：在关键路径的多个位置分散设置缓冲，而不是在末尾堆一个总缓冲。同时明确缓冲的使用规则，比如"消耗超过 30% 必须提交说明并召开专题会"。

5. 误区五：只报喜不报忧

这个误区往往不完全是个人品质问题，而是组织环境问题。如果汇报坏消息的人总是被批评，那么坏消息就会消失，但问题不会消失，只会以更晚、更贵的方式暴露。

替代做法：把"提前预警"和"解决问题"分开考核。前者应该被鼓励，后者才应该被追责。项目负责人要在第一次预警时就明确表态："你提前说了，这很好，我们一起来解决。"

6. 误区六：工具堆得越多，管理越扎实

我见过一个团队同时使用看板工具、进度表格、即时通讯群、邮件、在线文档五套系统记录同一批任务。结果是没有任何一套是准确的，每个人只更新自己顺手的那一个。

单一信息源是进度管理的基础设施，不是可选项。所有任务状态只在一个地方维护，其他所有输出物，周报、仪表盘、汇报材料，都从这个源自动生成或引用。

四、专业判断逻辑：实际进度管理的五步闭环

把上面的场景和误区抽象一下，实际进度管理可以归纳为五个环节的闭环。这五步不是线性的，而是每两周或每个里程碑滚动一次。

1. 第一步：定基准，让对照标准稳定下来

基准的质量决定了后面所有判断的可信度。我在做基准时一定会确认五件事：

1. WBS 拆到可估算的粒度。一个任务如果需要超过 5 个工作日估算不准，就说明拆得还不够细。
2. 里程碑必须可验证。不是"完成设计"，而是"设计文档评审通过并归档"。
3. 依赖关系明确到人和部门。不是"依赖研发"，而是"依赖研发二组的接口联调完成"。
4. 关键路径被显式标注，并且所有人都知道哪些任务在关键路径上。
5. 缓冲分散设置且规则明确，谁可以用、用多少需要说明。

基准一旦确认，就进入受控状态。后续任何修改都必须走变更流程，而不是在例会上口头调整。这一条执行得越严格，后面的偏差分析就越有价值。

2. 第二步：采事实，让证据代替汇报

这一步的核心是"完成定义 + 证据来源 + 更新频率"三件事。

完成定义刚才已经说过。证据来源的意思是：每个任务的状态变化应该能指向一个客观产物，比如代码提交记录、评审记录、测试报告、客户确认邮件。更新频率则要根据任务性质区分，关键路径任务每天更新，普通任务每周更新，长周期任务按里程碑更新。

这里的关键判断是：项目负责人不需要亲自验证每一个任务，但必须确保每一个"完成"都有对应的验证入口。如果某个任务的完成状态是"执行人说完成了"，而没有任何客观产物，那它就只是一个待验证的声明。

3. 第三步：算偏差，但要算对偏差

偏差计算不是简单地拿实际减去计划。更有效的做法是分三层看：

至于挣值管理里的进度偏差和进度绩效指数这类指标，它们在中大型、范围相对稳定、工作量可量化的项目里很有价值，但不是所有项目都适用。如果项目范围本身高频变化，或者交付物难以量化，硬套这些指标只会制造虚假精确感。这一点我后面还会展开讲取舍。

4. 第四步：做协同，把责任接口制度化

协同不是态度问题，是结构问题。落到可执行层面，我通常推动四件事：

• 责任接口表：每个跨部门交付点，明确谁提供、谁接收、验收标准是什么、超期找谁。
• 变更控制机制：任何影响范围、进度、资源的变更，必须走统一入口，形成记录。
• 分级升级路径：执行层解决不了的问题，48 小时内升到项目负责人；项目负责人解决不了的，72 小时内升到项目指导委员会。
• 单一信息源：所有状态只在一处维护，所有汇报材料从这里派生，禁止平行维护第二套数据。

我在一个超过 100 人规模的交付项目里推动过这套机制，用的就是某项目管理平台作为单一信息源，把需求、任务、缺陷、测试、发布串在一条链路上，配合每两周一次的里程碑复盘。这个项目原本平均每个月要花十几个人时在手工汇总进度上，机制跑顺之后这块工作量降到每月三四个小时，省下来的时间全部投到偏差分析和风险处置上。

5. 第五步：纠偏与复盘，让这一轮的经验进入下一轮

纠偏手段无非几种：赶工、快速跟进、调整范围、重排资源、调整质量门槛。选择哪一种，取决于当前最稀缺的资源是什么。

但我更想强调的是复盘。很多团队的复盘会开成了追责会，或者开成了走过场的感想会。有效的复盘应该回答三个问题：偏差是发生在估算环节、执行环节还是协同环节？哪一条机制在这次项目里没有生效？下一个项目要改变哪一个具体做法？

如果一次复盘不能产出一条可复用的规则或模板，那这次复盘基本白开了。

五、案例与数据观察：机制生效前后的变化

下面这个案例来自一个中大型企业的内部系统交付项目，团队规模 120 人左右，跨 5 个部门，周期 20 周。项目负责人在第 6 周引入了一套完整的进度管理机制，我把前后对比整理出来。

1. 案例背景与介入时点

介入前，项目已经出现明显征兆：第 4 周的里程碑延误 5 天，跨部门阻塞任务积压 17 个，周会上讨论的问题有相当比例是两周前就提过的老问题。项目负责人当时的做法是增加会议、亲自催办，效果有限。

第 6 周，团队做了一次结构性调整：明确完成定义、建立受控基准、设置分级预警、统一信息源，并把这套机制承载在一个项目管理平台上。这个平台是 PingCode，它主要服务中大型企业及 100 人以上组织，对多部门、多角色、长周期的交付场景支持比较完整。

2. 六项关键指标的前后变化

这些数字来自项目内部的过程记录，属于单一案例的观察，不能当作行业普遍水平。但它们至少说明一件事：进度管理的改善，主要不来自更努力的催办，而来自信息结构和决策机制的改变。

其中我认为最有价值的一个变化是"变更记录完整率"。它从 20% 提到 92% 之后，第 20 周的复盘会第一次做到了按变更类型归因，哪些延误来自需求调整，哪些来自资源冲突，哪些来自估算偏差。这个归因能力，比任何一个漂亮的进度曲线都更值钱。

3. 工具在这里扮演什么角色

我必须把话说清楚：这套提升不是工具带来的，是机制带来的，工具只是让机制可以低成本地持续运行。如果机制缺失，再好的工具也只会变成另一个被荒废的表格。

但工具的作用也不能低估。在 120 人、5 个部门的规模下，靠文档和邮件维护单一信息源的成本高到不现实。当需求、任务、缺陷、测试、发布在同一个平台上串成链路，任何一处状态变化都能被关联方看到，项目负责人需要的人工对账量会大幅下降。

这也是为什么 PingCode 这类面向中大型组织的平台在复杂交付场景里比较常见。它支持私有化部署，对有数据合规要求的企业比较友好；同时支持从 Jira 平滑迁移，对于那些原本用 Jira 管理研发流程、又需要国产替代方案的团队，迁移成本相对可控。这两点在评估工具时值得单独拿出来权衡，而不是只看功能列表。

4. 一个让我印象深刻的细节

机制生效后第三周，项目负责人告诉我一件事：他终于不用在周会上问"这个到底做完了没有"了。因为每个任务的状态都关联了客观产物，做完没做完在系统里是明确的。

他说这句话的时候语气很平静，但我理解它的分量。当项目负责人不再需要花大量精力去确认基本事实时，他才有可能真正去做判断和决策。这就是我一直强调的：进度管理的第一步，是把事实从主观汇报里解放出来。

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

机制再对，也不能不分场景地全套照搬。下面按团队规模和项目复杂度给三套建议。

1. 小团队（10 人以内、单一交付流）

不要上复杂体系。看板 + 每周一次 30 分钟站会 + 一份风险清单，基本就够了。

• 看板分四列：待办、进行中、待验证、已完成。其中"待验证"这一列是关键，它强制区分"做完了"和"确认做完了"。
• 每周站会只回答三个问题：上周计划完成什么、实际完成什么、有什么阻塞。
• 风险清单每周更新一次，只记录会影响里程碑的风险，其他不进清单。
• 不需要正式的变更流程，但要用一张简单的记录表记下每次需求或范围调整，写清楚调整原因和对进度的影响。

2. 中型团队（10 到 50 人、跨 2-3 个部门）

这个阶段是机制建设的关键窗口期。如果在这个规模不把基准、完成定义、变更记录建起来，等到百人规模再建，成本会高出一个量级。

1. 建立受控的进度基准，明确关键路径和缓冲规则。
2. 统一完成定义，并为关键交付物指定验证证据。
3. 建立跨部门责任接口表，明确每个交付点的提供方、接收方和验收标准。
4. 设置分级预警：任务层黄灯、关键路径红灯、里程碑偏离触发升级。
5. 每两周做一次里程碑复盘，重点看偏差归因，而不只是看进度条。
6. 确定单一信息源，其他所有汇报材料都从这里派生。

3. 大型团队（50 人以上、跨 4 个以上部门或含外部供应商）

到这个规模，管理复杂度会指数级上升，必须引入平台化支撑和更正式的治理结构。

• 治理层：设立项目指导委员会，明确变更审批权限和升级决策时限。
• 流程层：变更控制、风险登记、问题升级三条流程必须成文并被执行。
• 数据层：所有状态在一个平台上维护，形成从需求到发布的可追溯链路。
• 节奏层：执行层每日同步偏差，项目层每周评审，治理层每月评审里程碑和风险。
• 工具层：评估平台时重点看三件事，能否承载多部门权限模型、能否支持私有化部署、迁移与集成成本是否可控。

在这个规模上，PingCode 这类面向中大型组织的平台确实比通用工具更贴合，尤其是有私有化部署要求和 Jira 迁移需求的团队。但我要提醒一点：平台选型是最后一步，不是第一步。流程没理清就选平台，只会把混乱搬进系统里。

七、不同情况下的取舍：什么必须做，什么可以缓

资源永远是有限的。项目负责人最难的判断不是"什么该做"，而是"什么现在可以不做"。

1. 三种情况下必须死守的三件事

无论项目多小、多急，这三件事我建议绝不妥协：

1. 完成定义必须统一。这是最便宜也最必要的一件事，一次会议就能定下来，但它决定了后面所有数据是否可信。
2. 关键路径必须显式标注。不标关键路径，就无法区分"重要"和"紧急"，所有任务都会变成同一优先级。
3. 变更必须留痕。哪怕只在文档里记一行，也比口头讨论强。它决定了项目结束时你能不能讲清楚发生了什么。

2. 可以阶段性放弃的三件事

在资源极度紧张或周期很短的项目里，下面三件事可以暂时不做，但要清楚代价：

• 挣值管理类指标。如果项目范围高频变化、交付物难量化，硬算这些指标只会产生误导性的精确感。放弃它，用里程碑达成率和关键路径延误天数替代。
• 精细到人的工时统计。在信任度较高的团队里，工时统计的收益往往低于它带来的抵触成本。可以退化到按任务粒度跟踪，只在关键路径上细化。
• 复杂的仪表盘。早期阶段，一张列出红灯任务和阻塞任务的清单，比一个二十个图表的仪表盘更有用。信息过载会稀释注意力。

3. 一个需要反复权衡的取舍：严格程度与团队信任

这是我认为最有张力的一个取舍。机制越严格，数据越准确，但团队感受到的管控压力也越大；机制越宽松，团队越自在，但数据质量越不可控。

我的判断标准是看两件事：一是项目失败的成本有多高，二是团队的自我管理成熟度有多高。如果失败成本极高而团队成熟度一般，就该偏向严格；如果失败成本可控且团队本身有良好习惯，可以偏向轻量。

但有一条底线：无论哪种取向，"提前预警"这个行为都必须被奖励，而不是被追责。一旦团队觉得报坏消息会有麻烦，再严格的机制也会被数据美化架空。

4. 工具选型的取舍原则

我一般按这个顺序判断：先看团队规模和部门数量，再看是否有数据合规或私有化部署要求，再看现有工具的迁移成本，最后才看功能丰富度。

之所以把功能丰富度放最后，是因为绝大多数团队的瓶颈不是功能不够，而是流程没理清、数据没人维护。一个功能中等但团队真正在用、数据保持更新的平台，价值远高于一个功能强大但实际使用率三成的平台。

在评估具体平台时，有私有化部署诉求的团队可以重点看这一项是否原生支持；有既存 Jira 流程的团队，则要把迁移平滑度作为硬指标来测，包括历史数据能否完整迁移、工作流能否保留、权限模型能否对应。这几项在评估阶段多花一周，比上线后返工三个月划算得多。

八、30 天落地行动清单

如果你现在就想动手，这份清单可以直接照着执行。它按四周排布，每周聚焦一件事。

1. 第 1 周：统一"完成"的定义

1. 召集关键执行人开一次 90 分钟的会，只讨论一个议题：我们说的"完成"具体指什么？
2. 为所有关键交付物写出完成定义，格式统一为"产物 + 验证方式"。
3. 把完成定义写进任务系统的字段里，让每个人在标记完成时必须填写验证证据。
4. 检查现有任务中，有多少个"已完成"其实没有证据。这些要退回状态。

2. 第 2 周：建立受控基准与责任接口

1. 重新检视当前进度基准，确认里程碑是否可验证、依赖关系是否明确到人。
2. 标注关键路径，并在团队内公开，让所有人都知道哪些任务碰不得。
3. 为每个跨部门交付点填写责任接口，包含提供方、接收方、验收标准和超期升级对象。
4. 明确缓冲的位置和使用规则，写下来并让大家知道规则存在。

3. 第 3 周：设置预警与决策机制

1. 定义黄灯和红灯的触发条件，越具体越好，比如"关键路径延误超过 3 个工作日"。
2. 确定分级升级路径和各层级的响应时限。
3. 把周会拆成同步会和决策会，前者限时，后者会前发材料、会后发决策记录。
4. 确定单一信息源，并停止在其他地方平行维护任务状态。

4. 第 4 周：做一次完整复盘，固化规则

1. 回顾这四周的偏差，逐一归类到估算环节、执行环节还是协同环节。
2. 列出这四周里哪一条机制没有生效，找出原因。
3. 把有效的做法固化成模板，写进团队的工作手册。
4. 确定下一轮的复盘节奏，通常是每两周一次或每个里程碑一次。

四周结束后，你会得到一个基本成型的机制。它不完美，但比"靠人盯人"稳定得多。接下来的工作就是按周期滚动运行，让它在你的项目里长出适合的形状。

九、几个常见问题的直接回答

这些问题我在培训和工作坊里被问过很多次，这里直接给出我的判断。

1. 项目已经乱成一团了，还能抢救吗？

能，但要先放弃"追回全部延期"这个目标。乱局中的第一步不是加速，而是止损：先把事实摸清楚，把所有任务状态按完成定义重新核一遍，通常你会发现真实进度比汇报出来的低 15% 到 30%。接受这个数字，重新基线化，再谈纠偏。假装进度还在、硬撑原计划，只会让问题以更贵的方式爆发。

2. 高层只想要一句话结论，怎么办？

把汇报结构固定下来：一句话说当前状态，一句话说最大风险，一句话说需要高层做什么决定。三句话之外的所有细节放在附件里。关键是"需要高层做什么决定"这一句不能省，如果每次汇报都没有需要决策的事项，高层会逐渐觉得这个项目不需要他关注，等你真需要支持时，反而拿不到注意力。

3. 团队抵触填数据和走流程，怎么推动？

先减少他们需要填的东西，再谈执行。很多抵触来自重复录入，同一份信息填在三个地方。把信息源统一、把必填字段压到最少、把数据采集尽量变成流程副产品（比如任务状态变化自动记录时间戳，不用人工填），抵触会明显下降。剩下的部分，靠让他们看到数据真的被用来解决问题，而不是被用来追责。

4. 敏捷项目还需要这套东西吗？

需要，但形态不同。敏捷不排斥基准和偏差，它只是把周期压缩了，迭代目标就是短期基准，迭代评审就是偏差复盘。真正的差别在于变更的常态化程度，敏捷项目对变更更宽容，但宽容不等于不留痕，迭代回顾时你依然需要知道这一轮为什么没做完。

5. 项目负责人没有管理权限，怎么推动跨部门协同？

靠三样东西：透明的数据、明确的接口、上层的授权。数据透明让问题无法被否认，接口明确让责任无法被推脱，上层授权让升级有去处。这三样里，项目负责人自己能掌控前两样。所以我的建议是：先把数据做到无可争议，再拿着它去找授权，这比一开始就抱怨没有权限要有效得多。

十、总结：把催进度这件事，升级成管系统

回到最开始那句话：实际进度管理的核心，是让事实可见、让偏差可算、让决策发生。这三件事做成了，延期依然可能发生，但它会是可解释、可处置、可复盘的延期，而不是一场突然爆发的灾难。

我见过的最好的项目负责人，都有一个共同特征：他们不追求让进度看起来好看，追求的是让真实情况尽快浮出水面。因为他们知道，早两周发现的问题，处理成本可能只有晚两周发现的三分之一。

如果你现在正被延期困扰，下一步不用做太多，就做一件事：把你这周拿到的所有"完成"状态，逐条问一句"证据是什么"。你会发现真实进度和你以为的进度之间，有一条不小的缝隙。看见这条缝隙，就是改善的起点。