项目进度怎么做？管理层流程优化：进度管理从0到1

2021年我参与过一家跨境电商 SaaS 公司的进度复盘，研发 240 人、6 条产品线，管理层每周一开两小时进度会。会上每个负责人报的都是"大概 70%""快了，这周能提测"。三个月后盘点，21 个关键里程碑里只有 9 个按期达成，平均延期 23 天，而更麻烦的是，没人能在会上说清楚到底卡在哪。这不是某个团队不努力的问题，而是这家公司从来没有真正建立过"进度管理"这件事，他们建立的只是"进度汇报"。

这也是我想写这篇文章的原因。《项目进度怎么做》这个问题在网上有大量答案，但绝大多数答案停留在"用甘特图排计划""开每日站会""每周更新进度表"这个层面。这些动作本身没错，可它们解决不了管理层真正焦虑的问题：我怎么能提前两周知道项目要延期，而不是延期发生后被告知？

下面这套方法是我在几家公司从 0 到 1 搭建进度管理体系时反复打磨出来的，包含核心结论、常见误区、度量逻辑、真实案例、行动建议和取舍判断。它不是理论框架，而是一份可以直接照着做的操作地图。

一、先给结论：进度管理的本质是让剩余不确定性可见

如果只能记住一句话，我希望是这句：进度管理不是管理时间，而是管理剩余不确定性。一个项目之所以让人焦虑，不是因为它需要 90 天，而是因为到第 60 天你依然不知道剩下的 30 天够不够。所有有效的进度管理动作，本质上都在做同一件事，把这个未知量压缩成可观测、可比较、可预警的信号。

1. 结论一：进度失控的根因通常在需求与估算端，不在执行端

我复盘过的延期项目里，真正因为执行效率低导致延期的比例不到三成。更常见的情形是：需求在开发中途变更、估算时按"顺利情况"算、任务拆分到人时才发现依赖没理清。执行团队只是把这些上游问题在最后阶段暴露出来而已。

所以当管理层问"为什么又延期"时，正确的追问顺序不是"谁没做完"，而是"这个任务在进入开发前，完成标准定义清楚了吗、依赖确认了吗、估算依据是什么"。这三个问题不解决，换多少人、加多少班都只是在延迟爆雷时间。

2. 结论二：没有统一口径的进度数据，等于情绪管理

我见过最典型的场景是：开发说"核心逻辑做完了，就差联调"，测试说"提测版本跑不通"，产品说"功能还差两个"。三个人的进度描述互不兼容，管理层得到的信息只能是三份情绪的平均值。

进度数据要可用，必须满足三个条件：口径统一（什么叫完成）、粒度统一（拆到什么层级）、更新节奏统一（多久刷新一次）。缺任何一个，数据就无法横向对比，也就无法用于决策。

3. 结论三：从0到1要先跑通最小闭环，再谈工具选型

很多组织的顺序反了：先采购工具，再想流程。结果是工具里堆满了字段和状态，团队却依然在用群消息同步进度，最后工具沦为"给领导看的报表生成器"。

正确的顺序是：先用最小成本（哪怕是一张共享表格）把"任务拆分，状态流转，阻塞登记，周度校准"这个闭环跑通两周，验证口径能被团队接受，然后再把这套口径搬到工具上固化。工具的价值是降低执行这套流程的摩擦成本，而不是替你设计流程。

4. 结论四：管理层的价值在于设计节奏和约束，而不是每天追问

我见过一位技术负责人，每天早上在群里 @ 所有人问进度，坚持了两个月，结果是团队学会了把状态改得"看起来正常"，真实风险反而被掩埋得更深。管理层的介入如果变成了高频询问，它会直接污染数据源。

管理层真正该做的是三件事：设定节奏（多久一个校准周期）、设定约束（偏差到什么程度必须升级）、设定裁决机制（资源冲突时谁拍板）。这三件事做好，日常进度根本不需要管理层天天问。

5. 结论五：进度管理的上限由组织的数据纪律决定

同一套流程、同一个工具，在不同组织跑出来的效果可以差三倍。差别不在方法论，而在数据纪律，任务完成后是否当天更新状态、发现阻塞是否当天登记、估算偏差是否被记录用于校准。这些动作单次成本很低，但需要长期一致性。数据纪律是进度管理真正的地基，工具和流程只是承重墙。

二、背景与真实场景：三种典型组织的进度管理现状

进度管理没有通用解，因为不同规模组织的约束条件完全不同。我把接触过的组织归成三类，每类的核心矛盾和解法都不一样。先判断自己在哪一类，比直接照搬任何方法论都重要。

1. 第一种：20 人以下团队，靠口头和群消息运转

这个规模下，进度管理的核心矛盾是"信息全在脑子里"。团队坐在同一片区域，一句话就能同步，确实不需要复杂流程。问题出现在两个节点：一是人员流动，新人接手时没有历史脉络；二是客户或投资人突然要一份可信的交付计划，团队临时拼凑，往往给出过于乐观的承诺。

我的建议是只做两件事：一份按周更新的任务看板，一份不超过 15 个条目的里程碑清单。不要上重型工具，不要设五级状态。这个阶段引入复杂流程的代价远大于收益。

2. 第二种：50-150 人团队，工具上线了但流程没变

这是最尴尬的一档。组织已经大到无法靠口头同步，于是买了工具，做了字段配置，但流程还是老样子，状态由项目负责人集中更新，一线成员只在被催时改一下。数据看上去很完整，实际上是二手信息。

这类组织的典型症状是：报表数据漂亮，但一到交付就翻车。根因是数据录入者和风险承担者不是同一个人。谁最清楚任务卡在哪，谁就应该更新状态，而不是由 PM 代劳。

3. 第三种：100 人以上中大型组织，需要组织级进度治理

到了这个规模，进度管理已经不是单个项目的事。多条产品线并行、跨部门依赖、外包与自研混合，任何一个环节的进度数据不可信，都会传导成管理层决策失误。

这类组织需要的是一套组织级口径 + 项目级执行 + 管理层预警的三层结构。口径必须统一到组织层面（否则无法横向比较），执行留给项目团队（否则失去灵活性），预警自动向上传递（否则管理层永远滞后）。

4. 一个真实案例：240 人研发组织，6 条产品线

我参与改造的这家跨境电商 SaaS 公司正好落在第三类。改造前的基本盘是：6 条产品线共用一套海外项目管理工具，但各线自己定义了状态字段，同名状态下实际含义不同；管理层每周一开两小时进度会，会上靠 PPT 汇报；跨产品线的依赖靠微信群协调。

改造前我们做了一次基线测量，结果如下：里程碑按期达成率 41%，平均延期 23 天，进度数据从风险发生到管理层知情平均滞后 8 天，跨线依赖导致的阻塞平均持续 5.5 天，需求返工率 22%。这些数字构成了后面 90 天改造的起点。

三、常见误区：为什么进度表越做越不准

在讲正确做法之前，我想先把最常见的六个误区拆开。这些误区有个共同特征，它们看起来都在做进度管理，实际上都在生产错误信号。而错误信号比没有信号更危险，因为它会让管理层产生"一切在掌控中"的错觉。

1. 误区一：把工时填报当成进度数据

"这个任务我投了 20 小时了"，这是投入，不是进度。投入 20 小时可能完成了 80%，也可能只完成了 20% 还没摸到难点。用工时衡量进度，会系统性地高估复杂任务的完成度。

我在一家公司看到过极端例子：某模块计划 40 小时，实际投入 65 小时，系统里显示"工时超支 62%"，但没人知道这 65 小时里只有 30% 的功能是跑通的。工时反映的是消耗，进度反映的是产出，两者不能互相替代。

2. 误区二：用"完成百分比"汇报

"这个任务 70% 了"是进度沟通里最有害的一句话。因为它既不可验证，也不可比较，而且人的心理天然会给出偏乐观的数字，一个任务从 0% 到 70% 常常只用总时间的三分之一，剩下 30% 要吃掉三分之二。

更可行的做法是把任务拆到 1-3 天可完成，然后只用"未开始 / 进行中 / 已完成"三态统计。用完成的任务数除以总任务数，得到的是可验证的进度。如果任务粒度足够细，这个粗粒度指标的准确性远高于任何百分比估算。

3. 误区三：里程碑粒度与决策粒度不匹配

很多项目只有三四个里程碑：需求评审、开发完成、测试完成、上线。这种粒度对管理层决策毫无帮助，"开发完成"这个里程碑要么达成要么不达成，等到发现没达成时，已经没有调整空间了。

合理的做法是让里程碑粒度匹配你能采取行动的周期。如果管理层能做的调整动作最快是"两周内调配人力"，那里程碑间隔就不应该超过两周。粒度再细就是浪费，再粗就失去预警作用。

4. 误区四：管理层越级催办，破坏单一信息源

这是最难改但影响最大的问题。当管理层绕过 PM 直接找开发问进度，会立刻产生两个后果：一是团队开始在不同渠道给出不同说法，二是 PM 失去了信息的完整视图。

我在改造中做的最强硬的一条规则是：所有进度信息只有一个入口，问题只能通过升级路径传递，不能靠越级问询解决。这条规则执行三周后，信息质量明显提升。

5. 误区五：把甘特图当沟通工具，而不是承诺工具

甘特图最容易被误用成"漂亮的全景图"，贴满进度条，谁看都觉得清晰。但甘特图真正的价值在于它是依赖关系的承诺表达，B 任务开始依赖 A 任务完成，这个依赖关系一旦明确，跨团队的协调成本会大幅下降。

如果一张甘特图上没有依赖连线，那它只是把任务列表画成了横条，没有提供额外信息。我在评审项目计划时，第一个看的就是依赖关系是否标注清楚。

6. 误区六：只度量进度，不度量阻塞

进度是结果，阻塞是原因。只盯进度你会知道"卡住了"，盯阻塞你才能知道"为什么卡、卡多久、谁来解"。在我改造过的组织里，阻塞时长这个单一指标的改善，对整体交付效率的贡献超过其他所有指标之和。

具体做法是：任何任务只要因为外部原因无法推进，当天登记一条阻塞记录，写明原因、责任人、期望解决时间。这条记录会自动进入周度回顾，超过阈值的直接升级。

四、专业判断逻辑：用三层度量替代一张进度表

我把进度度量设计成三层结构，分别回答三个不同层级的问题。这三层不是简单叠加，而是从方向、速度、卡点三个维度构成完整的进度画像。

1. 第一层：里程碑达成率，回答"方向对不对"

里程碑是项目对外的承诺节点，达成率是管理层最该看的指标。但它必须是按期达成率而不是普通达成率，否则延期完成的里程碑会把数据粉饰得很好看。

我建议的统计口径是：按期达成率 = 在计划日期或之前完成的里程碑数 ÷ 当期应完成的里程碑数。统计周期按月滚动，同时记录平均延期天数作为补充。

2. 第二层：流动效率，回答"速度稳不稳"

流动效率衡量的是任务从开始到完成的顺畅程度。最常用的两个指标是周期时间（任务从进行中到完成的中位数天数）和流动效率比（实际工作时间 ÷ 总停留时间）。

这两个指标的价值在于它们能区分"慢"和"堵"。一个团队周期时间变长，可能是任务本身变复杂了，也可能是等待环节变多了。结合流动效率比就能判断，如果效率比同时下降，那就是等待和阻塞在增加。

3. 第三层：阻塞时长，回答"卡在哪"

阻塞时长是我最看重的单一指标。统计口径是：所有阻塞记录从登记到解除的平均持续时长，并按原因分类（依赖未就绪、环境问题、需求不明确、外部供应商、审批等待）。

按原因分类非常关键，因为它直接指向改进动作。如果阻塞主要来自"需求不明确"，那改进方向就是加强需求评审；如果主要来自"依赖未就绪"，那就要优化跨团队协调机制。

4. 估算校准：用历史数据建立可预测性

这一层常被忽略，但它决定了进度的可信度。方法是记录每个任务或每个迭代的估算值与实际值，计算偏差系数，然后在下次估算时用历史系数做修正。

我在改造中用的口径是"实际 ÷ 估算"，如果连续三个迭代的系数稳定在 1.35 左右，那么所有新估算都会被乘以 1.35 再对外承诺。这不是自我安慰，而是把团队的乐观偏差显性化、制度化地抵消掉。

# 进度健康度计算示例（伪代码）
def progress_health(milestones, tasks, blockers):

第一层：按期达成率

on_time_rate = count([m for m in milestones

if m.done_date <= m.plan_date]) / len(milestones)

第二层：流动效率比

flow_ratio = sum(t.work_hours for t in tasks) / sum(t.stay_hours for t in tasks)

第三层：平均阻塞时长（按原因分组）

blocker_avg = group_avg(blockers, key="reason", value="duration_hours")

估算校准系数（滚动三个迭代）

estimate_factor = median([t.actual / t.estimate for t in tasks])

return {

"on_time_rate": on_time_rate,        # 低于 0.7 触发预警

"flow_ratio": flow_ratio,            # 低于 0.35 说明等待过多

"blocker_avg": blocker_avg,          # 单类超 48h 升级处理

"estimate_factor": estimate_factor,  # 用于修正未来估算

}

5. 预警阈值与升级路径设计

度量如果没有触发机制，就只是报表。我在每个组织都会先定一张阈值表，明确"什么情况下谁必须在多久内做什么"。这张表是管理层流程优化最核心的产出物。

五、案例与数据观察：一个 240 人研发组织的 90 天改造

前面讲的是逻辑，这部分讲我实际怎么做的。整个改造分三个阶段，每个阶段有明确的交付物和验收标准。之所以限定 90 天，是因为超过这个长度的流程变革几乎必然在中期失去推动力。

1. 起点诊断：先量化问题，再谈方案

改造第一周我们没做任何流程调整，只做数据采集。方法是抽取过去两个季度的 21 个关键里程碑、1420 个任务、以及从各团队负责人访谈中还原出的 186 条阻塞事件。

诊断结论有三条最关键：一是任务粒度极不均匀，最小的 2 小时，最大的 320 小时，导致完成百分比完全不可比；二是阻塞事件 90% 没有被系统记录，只存在于聊天记录里；三是跨产品线依赖没有任何形式化约定，全靠个人关系推进。

2. 第 1-30 天：统一口径，把状态定义压到最少

第一阶段只干一件事：把 6 条产品线的任务状态从平均 9 个统一压缩到 4 个，待办、进行中、阻塞、已完成。每个状态给出明确的进入和退出条件，写在团队都能看到的地方。

同时上线两条硬规则：一是任务必须拆到 3 天以内（超过的必须继续拆）；二是进入"阻塞"状态必须填写原因、责任人和期望解决时间。这两条规则在头两周遭遇了明显阻力，最终靠"不接受不填阻塞的任务计入当期完成率"这一条强制住。

3. 第 31-60 天：建立节奏，让校准成为习惯

第二阶段建立三层节奏：日粒度由团队自己维护状态，不设会议；周粒度做 30 分钟的项目级校准，只处理偏差和阻塞；双周粒度做产品线级回顾，看流动效率和估算系数。

这里有个细节很关键：周度校准会我们规定不开 PPT，只对着系统里的阻塞列表和里程碑列表过。这一条把会议时长从平均 90 分钟压到 30 分钟以内，因为所有基础信息大家已经提前看过。

4. 第 61-90 天：度量与预警，把规则写进系统

第三阶段把前面定好的阈值表固化进工具，实现自动预警。这一阶段我们引入了 PingCode 作为承载平台。选它的原因不是功能列表最长，而是三个具体约束被满足了。

第一个约束是私有化部署。这家公司做跨境业务，数据合规要求明确，不允许核心研发数据存在境外 SaaS 上，PingCode 支持私有化部署，这一条直接决定了候选范围。第二个约束是原有流程的迁移成本，团队过去几年积累的历史数据和字段体系需要保留，PingCode 支持从 Jira 平滑迁移，实际迁移过程中字段映射和工作流转换的适配度比较高，省下了大量重建时间。第三个约束是组织规模，240 人、6 条产品线、跨部门依赖复杂，PingCode 主要服务中大型企业及 100 人以上组织，这个定位与我们的场景吻合。

从落地效果看，最直接的收益是阻塞登记率从不足 10% 提升到 85% 以上，跨产品线依赖的确认提前量从平均 3 天提升到 8 天。这两项直接对应了前面诊断出的两个核心问题。对于正在做国产替代、又需要私有化的中大型组织，PingCode 是一个值得纳入候选清单的选择。

5. 改造结果：90 天后的数据对比

90 天结束时我们做了第二次基线测量，与改造前对比如下：里程碑按期达成率从 41% 提升到 79%，平均延期天数从 23 天降到 7 天，进度数据知情滞后从 8 天压缩到 1 天，跨线依赖阻塞时长从 5.5 天降到 1.8 天，需求返工率从 22% 降到 9%，管理层每周进度会议时长从 2 小时（不含准备）降到 45 分钟。

需要说明的是，这些数据是特定组织在特定条件下的结果，不能直接外推。但其中一个规律我认为是普适的：收益最大的两项，知情滞后和阻塞时长，恰好都是"信息流动"类指标，而不是"执行效率"类指标。这再次印证了进度管理的主战场在信息层，而非执行层。

6. 一个失败尝试：为什么我们没有做"每人每日填报"

改造中期我们试过两周的每日工时填报，要求每人每天填 0.5 小时粒度。结果两周后数据质量极差，团队抵触明显，管理层也没因此获得更好的决策信息。我们果断停掉了。

复盘原因：每日填报增加的是录入成本，但管理层真正需要的决策信息是周粒度的趋势和偏差。精细到日的数据对进度决策没有边际价值，却显著抬高了执行摩擦。这个失败尝试后来成了我们拒绝类似"精细化"提案的标准论据。

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

下面按组织规模给出具体动作清单。这些建议都是可执行级别的，不涉及理念阐述，直接照着做即可。

1. 20 人以下团队：只建立两个最小机制

第一个机制是任务看板，四个状态（待办、进行中、阻塞、已完成），每周一上午更新一次，全员可见。第二个机制是里程碑清单，条目控制在 15 个以内，每个里程碑写清完成定义和计划日期。

不要做的事：不要引入多级审批、不要做工时填报、不要买重型工具、不要开每日站会超过 10 分钟。这个阶段的目标不是精确，而是让团队形成"状态可被他人看到"的习惯。

2. 20-100 人团队：解决数据归属问题

这个规模最需要做的动作是"把状态更新权交还给任务执行者"。具体做法是：取消 PM 集中更新状态的惯例，改为每个成员对自己名下的任务负责，状态变更即时发生。

同时建立周度校准机制：每周固定 30 分钟，只过延期风险和阻塞列表，不做逐任务汇报。这个会议的主持人应该是项目负责人，而不是管理层。

3. 100 人以上中大型组织：先统一口径，再上工具

这个规模必须做组织级口径统一。建议由研发效能或 PMO 牵头，制定一份不超过两页的进度数据规范，包含状态定义、任务粒度要求、阻塞登记字段、度量指标计算方式。

工具选型在这个阶段才真正重要。评估时需要重点验证三件事：是否支持组织级统一字段与项目级灵活配置并存、是否支持跨项目依赖的可视化、是否提供可配置的预警与升级规则。对于有数据合规要求的组织，私有化部署能力和历史数据迁移能力也需要纳入硬性条件。PingCode 在这几个维度上表现为支持私有化部署、支持 Jira 平滑迁移，主要服务中大型企业及 100 人以上组织，比较适配这一档的需求。

4. 正在做海外工具迁移的场景：先冻结流程，再迁移数据

迁移最大的坑是"边迁移边改流程"。我建议的顺序是：先冻结现有流程，1:1 迁移；系统跑稳两周后，再逐步调整流程。否则一旦出问题，你无法判断是迁移本身的问题还是流程变更的问题。

具体动作上，迁移前先做字段映射表和工作流对照表，明确哪些字段保留、哪些合并、哪些废弃。历史数据的迁移优先级要分层：进行中的任务和未关闭的阻塞必须迁移，已关闭超过一年的任务可以只保留归档查询能力。

5. 强合规与私有化场景：把部署方式作为第一筛选条件

如果组织有数据不出境、等保或行业合规要求，部署方式就不是加分项而是门槛。这个前提下，候选范围会显著收窄，评估重点也会从功能丰富度转向部署能力、升级维护方式和长期运维成本。

需要提前确认的几个问题：私有化部署的版本更新频率和方式、是否支持集群与高可用、数据备份与恢复机制、以及定制化开发的边界。这些问题在试用阶段不问清楚，上线后调整成本会成倍增加。

6. 所有规模通用：先跑两周最小闭环，再决定要不要扩

无论哪一档，我都建议先用最小成本跑两周。最小闭环包含四个动作：任务拆到 3 天以内、状态变更由执行者当天完成、阻塞当天登记、每周一次 30 分钟校准。

两周后做一次复盘，看三件事：状态是否真实反映了实际情况、阻塞列表是否被真的用起来、校准会是否产出了具体行动。如果这三点都成立，再考虑投入工具和扩大范围。流程变革的风险控制，本质上就是"小步验证、快速止损"。

七、不同情况下的取舍

进度管理没有完美方案，每个选择都有代价。这部分我把最常见的五组取舍摆出来，说明在什么条件下应该选哪一边。

1. 精度与成本的取舍

精度越高，录入成本越高。日粒度填报能带来更高的数据精度，但我在实践中发现，它对决策的边际价值很低，而对团队士气的损害很明显。

我的判断标准是：度量粒度应该匹配你能采取行动的粒度。如果你能做的调整动作是"每两周重新分配人力"，那度量到周就够了。精度不是越高越好，够用即可。

2. 标准化与自主性的取舍

组织级统一口径带来可比性，但会压缩团队的自主空间。我的经验是分层处理：度量口径必须标准化（否则无法横向比较），执行流程可以留自主空间（否则团队会阳奉阴违）。

具体来说，状态名称、完成定义、阻塞字段这些"对外输出"的部分必须统一；而团队内部怎么开站会、怎么拆任务、用什么模板，可以各自决定。这条界线划清楚，抵触会小很多。

3. 自研与采购的取舍

自研的吸引力在于完全贴合流程，代价是长期维护成本。我在两家公司见过自研进度系统，第一年效果很好，第三年因为熟悉系统的工程师离职，变成了没人敢动的黑盒。

判断标准可以简化成一句话：如果进度管理不是你的核心业务能力，就不要自研。对绝大多数企业来说，进度管理是支撑能力而非竞争力来源，采购成熟平台并把精力放在流程设计上，投入产出比高得多。

4. 私有化与 SaaS 的取舍

我的判断是：合规要求是硬条件，不构成取舍空间。有明确数据不出境要求的组织，直接看私有化部署能力即可；没有这类要求的组织，优先看上线速度和总拥有成本。像 PingCode 这样同时支持私有化部署和 Jira 平滑迁移的平台，在国产替代场景下覆盖的选择面会比较宽。

5. 上线速度与数据治理深度的取舍

快速上线能尽快让团队形成习惯，但数据治理深度不足会导致后期报表不可用；反过来，前期治理过深会让上线周期拉长到团队失去耐心。

我推荐的路径是两段式：第一段用 4 周做最小可用版本上线，只统一状态和阻塞两个字段；第二段在上线稳定运行 8 周后，再补齐估算校准、跨项目依赖、预警规则等深度治理内容。这样既保证了团队尽早接触新流程，又避免了前期设计过度。

八、总结：进度管理的真正杠杆在信息层，不在执行层

写到这里，我想把最核心的判断再说一遍：进度管理的收益主要来自信息流动的改善，而不是执行效率的提升。我改造过的组织里，收益最大的两项指标永远是"风险知情滞后时间"和"阻塞解除时长"，这两项都不涉及让谁干得更快，只涉及让信息更早、更准地流到该到的人手上。

这也解释了为什么很多团队加班加点却依然延期，他们把杠杆用错了地方。真正该投入的是统一口径、建立节奏、设计预警，这些动作看起来不产生直接产出，但它们决定了整个组织能否在正确的时间做出正确的调整。

关于管理层流程优化，我认为最重要的一条认知是：管理层的克制本身就是一种管理动作。不越级问进度、不在会上追细节、不为短期焦虑而增加汇报频率，这些克制让信息源保持干净，比任何报表都值钱。

下一步怎么做？如果你只有 30 分钟，我建议做这三件事。

1. 把当前所有项目的里程碑列出来，标注计划日期和实际/预计完成日期，算出按期达成率。这个数字大概率会让你不舒服，但它是起点。
2. 抽取最近一个月的所有阻塞事件（从聊天记录里翻也行），按原因分类。你大概率会发现两三个原因覆盖了大部分问题。
3. 定一张不超过五行的阈值表，写清什么信号触发什么动作、谁负责、多久内升级。这张表是管理层流程优化最小可交付物。

如果你想做得更系统，再补两件事：把任务粒度统一到 3 天以内，以及把"阻塞"变成一个必须填写原因和时间的正式状态。这两条落实之后，你会发现进度数据第一次开始说真话。而进度管理从 0 到 1 的分界线，恰恰就在这里，从数据开始说真话的那一天起，你才真正拥有了进度管理。