进度管理如何做好实际进度？PMO实操方法与操作步骤

去年 Q3，我负责的一条支付网关项目，周报上连续 5 周显示"完成度 92%"。第 6 周我问项目经理还差多少，他说"大概两周"；第 8 周再问，还是"大概两周"。最终从第一次报出 92% 到真正上线，用了 47 天。更让我难受的是，这不是某个人的问题，那 5 周里没有人撒谎，所有人都真心认为自己"快完成了"。问题出在我们度量进度的方式上：我们测的是主观感受，不是可验证的完成量。

这篇文章讲的是 PMO 最核心也最容易做虚的一件事：怎么把"实际进度"做准。我会给出我对实际进度核算的核心判断、四层模型、五个典型误区，以及一套 30 天可落地的操作步骤。文中所有数据来自我在两家中大型研发组织做 PMO 负责人时的一手记录，涉及约 320 人研发团队、38 个并行项目的持续观察，部分数值做了脱敏处理，但比例关系保持真实。

一、先给结论：实际进度不是"报出来的"，是"算出来的"

先说我最终形成的判断，后面所有方法都是围绕这三条展开的。

1. 进度可靠性取决于"完成定义"，不取决于"汇报频率"

大多数 PMO 提高进度准确性的第一反应是加频率：周报改日报、日报改站会。我在 2022 年做过一次对照实验，把一条 60 人产品线的站会从每周两次改成每天一次，持续 8 周。结果进度偏差的识别时间只提前了 1.2 天，但团队每周多消耗约 90 人时的会议时间，工程师满意度评分从 7.4 掉到 5.9。

高频汇报解决的是"信息新鲜度"，不是"信息真实性"。如果一个任务的完成标准本身是模糊的，你每天问一次，得到的也只是每天一次的模糊答案。

2. 实际进度 = 可验证完成量 ÷ 基准工作量，两个变量都必须可核对

我把这个公式写在每一份项目章程的第一页。它有两个前提：分母是冻结过的基准，不是随时可改的"当前计划"；分子是能拿出产出物或证据的完成量，不是"我觉得做了八成"。任何一条不满足，算出来的都是情绪指数，不是进度。

3. PMO 的角色是度量设计师，不是催报员

我见过太多 PMO 把自己做成了"进度催收部门"：每天盯着谁没填、谁填得晚、谁填得少。这种定位下，PMO 越努力，一线越倾向于把数据填得"好看一点"，因为数据变成了考核工具而不是管理工具。PMO 真正该设计的是三件事：完成标准、数据采集的自动化程度、偏差暴露后的处理机制。

二、真实场景：我亲历的三次进度失控

抽象的道理不如具体的现场。下面三个场景是我这些年印象最深的，它们分别对应三类不同的失控机制。

1. 场景一：92% 停留了 47 天

回到开头那条支付网关项目。项目计划 6 个月，第 4 个月末周报显示完成度 92%，此后连续 5 周这个数字几乎不动，最后一次是 94%。我调取了当时的任务清单，发现"完成度"是项目经理在周会上口头问一圈后估出来的：开发说"接口都通了"，测试说"主要场景过了"，于是综合给出 92%。

真正卡住的是三件事：一是渠道方沙箱环境的回调验签规则和我们文档不一致，排查花了 9 天；二是对账文件的字符集在真实渠道下是 GBK 而不是 UTF-8，导致 3 天的返工；三是压测暴露的连接池泄漏，修复加回归 11 天。这三件事全都不在"剩下的 8%"里，因为它们是"未知的未知"。

这个场景的教训不是"要问得更细"，而是：当一个任务被描述成一个 0-100 的连续刻度时，最后 10% 会变成一个巨大的黑洞，因为没人能说清剩下那 8% 里到底装了什么。

2. 场景二：一个里程碑被平移了 6 次

第二个项目是一个微服务拆分工程。原计划有 4 个里程碑，其中"交易域拆分完成"这一个，在 5 个月里被改了 6 次日期，从 3 月 15 日一路挪到 7 月 28 日。每次延期的理由都很充分：依赖方接口没就绪、测试环境被另一个项目占用、核心开发休了陪产假。

问题在于，这 6 次平移没有任何一次触发了升级流程。因为在我们当时的规则里，"里程碑日期调整"属于项目经理权限内的事项，只需在周报里标注。等到我意识到这个里程碑实际已经偏移 135 天时，整个下半年的发布节奏全部被打乱。

3. 场景三：外包团队和自研团队的口径打架

第三个场景更隐蔽。一个项目里有两家外包团队和一组自研团队，三方都在周报里报完成度。上线前两周我们做联调，发现自研团队认为 API 已完成 85%，外包 A 认为对方只完成了 60%，外包 B 认为完成了 95%。

追下去才发现，三家的"完成"定义完全不同：自研团队认为接口代码写完、本地自测通过就算完成；外包 A 认为要联调通过才算；外包 B 认为只要接口文档评审通过就算。三方都没有错，错在我们从来没有在合同和任务模板里定义过统一口径。

跨团队项目里，进度口径不统一造成的偏差，往往比真实的工期偏差更大。而且这种偏差会互相掩盖：一方虚高的进度会被另一方虚低的进度抵消，项目经理看到的总数看起来还挺正常。

三、为什么实际进度天生难测：三个结构性原因

在给方法之前，我想先说清楚对手是谁。如果只是"执行不到位"，加管理力度就够了；但实际进度难测有很大一部分是结构性的，用力用错方向只会增加成本。

1. 剩余工作的展开是非线性的

软件项目的剩余工作量不随已完成百分比线性递减。业界常说的"90-90 法则"指的正是这个：前 90% 的代码占 90% 的时间，剩下 10% 的代码还要占 90% 的时间。原因在于，剩下那部分往往是集成、异常路径、边界条件、性能和安全，而这些工作的"未知系数"远高于主干功能开发。

我在内部做过统计：把 2021 年到 2023 年 46 个项目的任务数据按阶段拆开，主干功能开发阶段的估算偏差中位数是 18%，而集成与联调阶段的估算偏差中位数是 63%。换句话说，越接近尾声，你的估算能力越差。

2. 不确定性不是被消除的，是被推迟的

项目早期看起来进展很快，往往是因为大量不确定性还没有被触发。接口没联调，就不知道字段对不上；没压测，就不知道连接池会泄漏；没灰度，就不知道老客户的历史数据有脏值。

所以"进度看起来正常"在项目前 2/3 阶段的信息量非常低。我在评审一个项目是否健康时，更关注"已经消除了多少不确定性"，而不是"完成了多少工作量"。具体做法是数"闭环的可交付物"，而不是数"写完了多少代码"。

3. 组织激励会系统性地扭曲进度信息

这一条最容易被忽略，但杀伤力最大。如果进度数据被用来考核、排名、扣绩效，那么理性的个体行为就是把进度报得乐观一点，把风险往后拖一拖，因为延期在当下是个人成本，而风险暴露是未来的、可能不会落到自己头上的成本。

我做过一个不太严谨但很有说服力的观察：在同一家公司里，把进度数据从考核指标中移除、改为只用于资源调配之后，第一个季度报出的"黄色风险项目"数量上升了 140%。这看起来像是项目变糟了，实际上是数据变真了。

如果你既想要真实的进度数据，又用这些数据去惩罚人，你只能得到前者或后者，不会同时得到。这是 PMO 必须向管理层争取的第一项授权。

四、拆掉五个常见误区

下面这五个误区，我在不同公司见过至少三轮。它们看起来是操作细节，本质上都会让进度数据失效。

1. 误区一：用百分比代替完成标准

"这个需求完成了 70%"，这句话在管理上几乎没有信息量。70% 是按什么算的？代码行数？功能点数？还是工程师的直觉？如果三个人对同一个任务给出 60%、70%、85% 三个数字，你无法判断谁对。

我的做法是取消所有主观百分比，改成状态枚举：未开始 / 进行中 / 待评审 / 已完成 / 已验收。百分比只在一种情况下使用：任务被拆解成有明确数量的子项时，用已完成子项数除以总子项数，这是可核对的。

2. 误区二：用时间比例推算进度

"这个任务计划 10 天，已经做了 6 天，所以进度 60%。"这是纯粹的自我安慰。任务的完成度与消耗时间之间没有函数关系，一个任务可能在第 3 天就完成了 90%，也可能在第 9 天还停留在 40%。

时间是有价值的指标，但它衡量的是成本消耗，不是产出进度。把成本指标当产出指标用，是进度管理里最普遍的错误。

3. 误区三：把工时填报当成实际进度

工时数据回答的是"人力花在哪里了"，不回答"做完了多少"。我在一家公司看到过非常极端的案例：某模块填报了 480 人时，看起来投入巨大，但实际代码零合并，因为方案被推翻重做了两轮。工时数据在这里反而制造了"很努力、有进展"的假象。

4. 误区四：只有终点里程碑，没有中间可验证产出

如果一条 6 个月的项目只有"上线"这一个里程碑，那么在第 5 个月之前你都得不到任何真实的进度信号。这不是执行力问题，是可观测性问题。

我的经验值是：任何超过 6 周的工作包，都必须至少有一个中间可交付物，而且这个交付物要能被第三方验证，比如一份评审通过的接口文档、一次通过的功能演示、一组跑通的集成测试用例。

5. 误区五：只看时间偏差，不看范围偏差

一个项目"按期完成"，但交付范围比原计划少了 30%，这在进度上是成功还是失败？很多 PMO 的报表只统计时间偏差，因为范围偏差需要更复杂的基线管理，做起来麻烦。

后果是团队学会了最省事的做法：保时间、砍范围。短期看里程碑很漂亮，长期看产品竞争力被一点点削掉。

五、专业判断逻辑：四层实际进度核算模型

这是我最终沉淀下来的一套结构。它的核心思路是：不要把进度当成一个数字，而是当成一套分层核算体系，每一层都有自己的证据要求。层与层之间是逐级汇总的关系，上一层只接受下一层已经核验过的结果。

1. 第一层：任务级，二值判定 + 完成定义

最底层的任务不允许有中间状态。要么未完成，要么完成，完成的唯一标准是"完成定义"里写的条件全部满足。完成定义必须写成可打勾的清单形式，而不是一句描述。

任务：支付渠道回调验签适配
完成定义（DoD）：

代码已合并至 main 分支且通过 CI

单元测试覆盖率 ≥ 80%，边界用例含验签失败分支

与渠道方沙箱完成一次全链路回调验证，附日志截图

对账文件在 GBK 字符集下的解析用例通过

由测试同学完成交叉验证并在任务上留痕

未全部勾选之前，任务状态只能是"进行中"。

这样做的好处是把"快完成了"这种模糊表达从系统里彻底移除。任务的进度只有 0 和 1，不存在 0.7。

2. 第二层：工作包级，按可验证子项加权

工作包由若干任务组成。因为每个任务都是二值的，工作包的进度就可以用精确的加权公式计算，而不是估算。

权重怎么定？我不建议用工作量人天做权重，因为人天本身也是估算。我的做法是用关键路径贡献度 + 复杂度分级的组合权重，复杂度分 1、2、3、5、8 五档。这套权重在项目启动会上一次性冻结，中途不调整。

工作包进度 = Σ(已完成任务权重) / Σ(全部任务权重)
示例：

任务 A（权重 3）已完成

任务 B（权重 5）已完成

任务 C（权重 8）进行中

任务 D（权重 3）未开始

工作包进度 = (3 + 5) / (3 + 5 + 8 + 3) = 8 / 19 ≈ 42%

这个数字是可以被任何人复算的。任何人对进度有疑问，打开任务列表就能验证，而不是去问项目经理"你当时怎么算的"。

3. 第三层：里程碑级，门禁 + 交付物验收

里程碑不是"一堆任务做完了"，而是一个门禁。它要求一组特定的交付物通过指定角色的验收，验收不通过就不算达成。

我在设计里程碑时坚持两点：一是每个里程碑必须有 2-4 个明确的验收交付物；二是验收人不能是执行人本人。第二点看起来是常识，但在实际情况中，超过一半的里程碑是自评达成的。

4. 第四层：项目级，SPI + 关键路径剩余时长

到了项目层，我同时看三个数字，任何一个异常都会触发分析。

• SPI（进度绩效指数）：已完成工作的预算价值 ÷ 计划工作的预算价值。SPI 低于 0.9 需要解释，低于 0.8 需要干预方案。
• 关键路径剩余时长：从今天到关键路径上最后一个任务完成所需的估算时间。这个数字如果连续两周不下降，说明关键路径上存在阻塞。
• 未闭环风险数：已识别但还没有应对措施的风险数量。这个数字上升，通常预示着未来的进度偏差。

我不建议只看 SPI，因为它对滞后指标敏感、对前置信号不敏感。SPI 掉到 0.85 的时候，问题往往已经发生两三周了。关键路径剩余时长的周环比变化，是我认为最灵敏的领先指标。

六、具体案例：320 人研发组织用 PingCode 落地进度核算

讲完模型，说一个我深度参与的真实改造。这家公司做企业级 SaaS，研发 320 人，同时并行 38 个项目，横跨 12 条产品线。我作为外部顾问参与了这个项目从诊断到落地的 6 个月。

1. 改造前的四个具体症状

诊断阶段我们采集了两周的数据，发现四个症状都很典型。

第一，进度数据准确率只有 58%。我们的口径是"计划完成日与实际完成日偏差在 7 天以内计为准确"，也就是说超过四成的任务在完成时间上说了假话，只是没人知道是故意的还是估错了。

第二，PMO 每周花 12 小时在手工汇总上。三个 PMO 同学每周一整天在做同一件事：从各个项目群里收表格、拼 Excel、对齐格式。

第三，里程碑按期达成率 46%，且 80% 的延期是在里程碑当天才被发现的。

第四，跨团队口径不统一。这个项目里 3 家外包团队各有各的完成定义，联调阶段集中爆发。

2. 我们做了什么：三件事，没有第四件

（1）统一完成定义，写进任务模板和外包合同

我们把五类典型任务的完成定义模板固化下来：开发类、测试类、文档类、集成类、上线类。每类都有明确的勾选项。任务创建时必须选择类型，系统自动带出完成定义清单。

同时，我们把同样的清单写进了外包合同的验收条款。这一条是这次改造里争议最大、效果最好的一步。

（2）用任务流转自动产生数据，取消人工填报

这一块是我们选择工具的关键考量。这家公司原来用的是 Jira，有大量自定义字段和历史数据，不可能推倒重建。他们最终选择了 PingCode，主要原因是两点：一是支持 Jira 的平滑迁移，历史项目、字段映射、工作流都能带过来，不需要团队重新学习一套心智模型；二是支持私有化部署，这家公司的安全合规要求不允许研发数据出内网。

PingCode 主要服务中大型企业及 100 人以上组织，这个定位和他们的体量是匹配的。落地时我们做了三件配置工作。

第一，把任务状态机改造成五个状态，取消"完成度"这个手填字段。任务状态只能通过满足完成定义清单来推进。

第二，把工作包权重字段做成必填，在项目启动会上一次性录入。

第三，配置自动化的周度进度快照。系统每周五 18:00 自动生成每个工作包的加权进度、每个项目的 SPI 和关键路径剩余时长，推送给对应角色。

自动化规则示例（伪配置）：
触发条件：每周五 18:00

执行动作：

计算所有进行中工作包的加权进度
= Σ(已完成任务权重) / Σ(全部任务权重)
计算项目 SPI
= 已完成任务权重和 / 按计划应完成任务权重和
计算关键路径剩余时长
= 关键路径上未完成任务的原估算工时之和
若 SPI < 0.9 或 关键路径剩余时长周环比降幅 < 5%
则标记为"需说明"，推送至项目经理和 PMO
生成项目周报草稿，等待项目经理补充异常说明后发布

（3）把进度数据从考核体系中剥离

这一条不是技术工作，是管理动作。我们向管理层明确了一个原则：进度数据只用于资源调配和风险预警，不作为个人绩效的直接依据。项目经理的绩效评估看的是"对偏差的识别和处置质量"，不是"偏差有没有发生"。

这个原则宣布后的第一个季度，报出的风险项目数量从平均 4 个上升到 11 个。管理层的反应很关键，他们没有恐慌，而是把这 11 个逐个过了一遍，其中 7 个通过资源调整化解了。

3. 六个月后的变化

改造满 6 个月时我们做了一次复盘，几项核心指标的变化如下。需要说明的是，这些数据来自该公司的内部度量系统，属于单一样本观察，不能直接外推到其他组织，但趋势我认为是有参考价值的。

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

四层模型是个完整体系，但不是所有组织都需要一次上齐。下面按组织规模和项目特征给出我认为更现实的路径。

1. 50 人以下团队：只做第一层和第三层

这个规模不需要 SPI，不需要加权公式，甚至不需要专门的 PMO 角色。你需要的只有两件事：每个任务有明确的完成定义，以及每 6 周至少有一个可验证的中间交付物。

具体做法：用最简单的任务看板，给每类任务写一份 5 行以内的完成定义清单，贴在团队 wiki 里。每周站会上只问一个问题："哪些任务卡住了，卡在哪。"不要追问百分比。

这个阶段最容易犯的错误是过早引入复杂报表，结果团队时间被度量吃掉，产出反而下降。

2. 100 到 500 人组织：第二层和第四层是收益最高的投资

这个规模通常有 5 到 20 条产品线并行，资源争抢是主要矛盾。此时加权进度和项目级三指标能带来的收益最大，因为你需要在一个统一口径下比较不同项目的健康度。

关键动作是：把工作包权重录入变成项目启动会的强制议程，把周度进度快照做成自动化。同时必须同步推进的一件事是，把进度数据从个人考核里拿出来。

工具层面，这个规模的组织往往有历史工具包袱。从既有工具平滑迁移的能力，比工具本身的功能丰富度更重要，因为迁移成本会直接转化为团队的抵触情绪。这也是我建议在这个阶段重点评估迁移路径和部署方式的原因。

3. 500 人以上或多项目组合管理：先建度量标准，再谈工具

这个量级上，工具不是瓶颈，标准才是。你会遇到的问题是：事业部 A 和事业部 B 对同一个词的理解不一样，某条产品线把"上线"定义为代码发布，另一条定义为灰度 10%。

我的建议是先成立一个跨部门的度量小组，用 4 到 6 周时间产出一份《进度度量标准》，内容包含：完成定义模板、复杂度分档规则、里程碑门禁清单、偏差分级与升级路径。这份标准评审通过之后，再去配置工具。反过来做，你会花很多钱把一套混乱搬到新系统里。

4. 外包占比高的项目：把完成定义写进合同

这一条单独拎出来说，因为它不属于规模问题，而是治理问题。如果你的项目有超过 30% 的工作由外部团队承担，那么统一口径的唯一有效手段是合同条款，不是会议共识。

具体做法是把完成定义清单作为验收附件，明确交付物、验收人和验收方式。这一条能消除我在第二节场景三里描述的那类问题。

八、取舍：三组必须做出的权衡

任何度量体系都有代价，PMO 的专业性体现在能否把代价说清楚，而不是假装没有代价。下面三组权衡是我在每次方案评审时都会主动摆出来的。

1. 采集粒度与管理成本

任务拆得越细，进度越准，但管理成本越高。我做过测算：以 200 人团队为例，任务平均粒度从 5 人天降到 1 人天，进度数据准确率大约提升 12 个百分点，但团队每周在任务维护上的额外耗时约为 60 人时，且任务列表的可读性明显下降。

我的经验阈值是：任务粒度控制在 0.5 到 5 人天之间。超过 5 人天的任务必须拆，低于 0.5 人天的任务合并。这个区间在准确性和成本之间取得了比较好的平衡，也是我在多个组织里反复验证过的。

2. 数据准确性与心理安全感

这是一个纯粹的取舍，没有两全方案。数据越准确，暴露的问题越多；问题暴露越多，如果没有配套的容错机制，团队越倾向于下一次报得保守一点。

我倾向于选择"高准确 + 高安全"的组合，代价是管理层要忍受短期内"问题变多"的视觉冲击。如果管理层做不到这一点，那就只能退到"中等准确"，同时接受进度偏差会晚 2-3 周被发现。

3. 自动化程度与例外处理能力

自动化能把 PMO 从汇总工作里解放出来，但过度自动化会带来一个副作用：一线失去了对数据的解释权，遇到例外情况时倾向于改状态去适配系统，而不是提出流程问题。

我的做法是保留一个"异常说明"强制字段。任何被系统标记为"需说明"的项目，项目经理必须填写偏差原因和应对措施，这个字段不做格式化，允许自由文本。这个设计看起来很小，但它是自动化与人之间最重要的缓冲。

九、落地操作步骤：PMO 30 天启动清单

如果你认同上面的判断，下面是一套可以直接拿去用的 30 天启动方案。我刻意把它设计成"不需要任何采购决策就能开始"的形式，因为最容易失败的落地方式是等工具到位再动手。

1. 第 1 周：诊断与基线采集

1. 选取 3 个近期已完成的项目作为样本，抽取其任务计划完成日与实际完成日，计算偏差分布。这就是你的准确率基线。
2. 统计这 3 个项目从"首次报出 85% 以上完成度"到"实际完成"的平均天数。这个数字通常会让人吃惊。
3. 访谈 5 到 8 名一线工程师，只问一个问题："你在什么情况下会把任务标记为完成？"记录所有不同答案。
4. 整理出当前组织内存在的所有"完成"定义版本数量。这个数字就是你的口径分裂程度。

2. 第 2 周：定义与对齐

1. 基于第 1 周的访谈结果，起草五类任务的完成定义模板：开发、测试、文档、集成、上线。
2. 找 2 名一线工程师和 1 名测试负责人做一次 90 分钟的工作坊，逐条过模板，删掉所有无法验证的条目。
3. 起草复杂度分档规则（1、2、3、5、8 五档），每档给出 2-3 个本组织内的真实任务作为参照。
4. 就"进度数据不用于个人考核"这一条向管理层取得明确表态，最好有书面记录。

3. 第 3 周：试点与配置

1. 选择 1 个正在进行的中等规模项目作为试点，不要选最简单也不要选最复杂的。
2. 在现有工具中配置五状态任务机，取消手填完成度字段。
3. 为试点项目补录工作包权重，在项目启动会（或补开的对齐会）上一次性确认。
4. 配置自动化每周快照，即使现阶段的自动化只是把数据导出再做一次计算也可以接受。

4. 第 4 周：验证与校准

1. 对比试点项目在新口径下的进度数字与项目经理的主观判断，记录差异点。
2. 逐条分析差异原因，判断是完成定义不清晰还是权重不合理，做一轮修订。
3. 把试点结果做成一份 3 页的复盘，包含改造前后对比、遇到的阻力、下一步计划。
4. 向管理层汇报，重点讲清楚数据准确率提升和 PMO 耗时下降这两个数字。

5. 第 5 周起：规模化与固化

1. 按每两周 3-5 个项目的节奏推开，不要一次性全量替换。
2. 把完成定义模板写进项目立项的标准流程和外包合同的验收条款。
3. 建立"异常说明"机制，所有被标记为需说明的项目必须在 24 小时内给出书面原因和应对措施。
4. 每个季度做一次口径校准，因为随着业务变化，原来的完成定义可能已经不再适用。

十、我的独特判断与你的下一步

写到这里，我想把最核心的一个反常识判断再说一遍：进度管理做不好的组织，缺的通常不是管理力度，而是"可验证性"的设计。

大多数团队把精力花在"如何让进度报得更及时"上，但及时的错误信息比不及时的错误信息危害更大，因为它会让你更早、更自信地做出错误决策。我见过的最惨的项目，不是数据滞后导致的，而是连续三个月看着一份看起来很健康的报表，直到无法挽回。

另一个我想强调的判断是：进度核算体系的生命力取决于它的重量。任何需要一线每周额外投入超过 15 分钟的度量体系，都会在 6 到 9 个月内自然衰减。这也是为什么我在这套方案里反复强调自动化采集、取消手填字段、把 PMO 从拼表里解放出来，不是因为这些动作更"先进"，而是因为只有足够轻的体系才能活得足够久。

关于工具选择，我的态度比较务实：工具的价值不在于功能清单有多长，而在于它能不能承接你已有的工作流、能不能在你需要的部署环境里运行、能不能把数据采集变成流转的副产品而不是一项额外任务。对于中大型组织，我建议在选型时重点确认三件事：历史数据的迁移路径是否平滑、是否支持私有化部署、以及能不能在不写代码的前提下把完成定义和权重配置进去。PingCode 在这三点上是符合我上面标准的选项之一，但更重要的还是你先把完成定义和度量标准想清楚，工具只能放大你已经想清楚的东西，无法替你思考。

如果你准备开始，我的建议是从最小的一步走起，而且今天就能做：

1. 今天：打开你正在做的项目，找出那个被标记为"完成 80% 以上"但已经停留超过两周的任务，问执行人一个问题，"还差哪些具体的事才算完成？"把答案写下来。
2. 本周：为团队里最常见的三类任务写完成定义清单，每类不超过 5 条，每条都必须能被第三方验证。
3. 本月：选一个中等规模项目做试点，取消手填完成度，改用状态机加完成定义清单，对比一个月前后的数据准确率。
4. 本季度：向管理层争取"进度数据不用于个人考核"的明确表态。这一条如果拿不到，前面三步的效果会在半年内被消耗掉。

进度管理的终局不是做出更漂亮的报表，而是让"项目现在到底什么状态"这个问题，在任何时刻都有唯一且可信的答案。这个目标不容易达到，但它比大多数人想象的更接近可实现，前提是你愿意先把"完成"这两个字定义清楚。