# 周报上的 85% 为什么不动了：用交付物状态、剩余工作量和卡点清单看项目真在推进

百分比完成度的四个坑、90% 症状，以及换成“还要多少”和“在等谁”之后怎么判断会不会延期

> 进度与排期 · 项目管理基础 · 任务拆解 · 约 6 分钟 · 10 月 28 日

## 本篇要点

1. “完成了百分之多少”会骗人，是因为它的分母在开工时并不存在，做到一半才发现的新活持续把分母撑大，比率可以长期原地不动。
2. 没做完的活会被按“看起来”给部分学分，而返工在没被发现之前账面上记的是“已完成”，所以项目常停在 90% 附近，真实进度可能只有 75% 到 80%。
3. 同一个状态可以报出不同完成度：2 天的活计划需 16 小时、已做一天 8 小时，按工时是 50%，若工期定成 5 天，按工期只有 20%。
4. 就算百分比算得准，它也答不了“会不会延期”，因为剩余工作不是均匀的一层，80% 完成可能还需要超过原工期 20% 的时间。
5. 更可靠的三样替代物是：只认“已记录实际完成日期且不再回头改”的交付物状态、能加总和前后对比的剩余工作量、写清“卡在谁手上、要什么、什么时候给”的卡点清单。
6. 判断能不能按期靠一道除法：剩余工作量除以每周实际产能，再与剩余周数比较；计划完成日和预计完成日要分开报，预计日第一次越线就说。
7. 百分比仍可用于小任务和对外粗略沟通，但不能用来推完成日期。

---

周二下午填周报，“客服系统迁移：完成 85%”。两周后再填，还是 85%。你没偷懒，小李也没偷懒，活每天都在干。这个 85% 为什么站着不动？

## “快做完了”的那段路，往往最长

先看一个不是工作的例子。有人写自己盖房子的经历：验房那天跟包工头从头走到尾，列出 43 项没做完的事；六周后再走一遍，清单变成了 46 项 [1]。这六周里工人天天在工地上，待办反而多了三项。

项目管理里这个现象有名字，叫“90% 症状”：项目在 90% 上停住，最后 10% 的工作花掉远超 10% 的时间。返工循环的研究里还有一个更刺眼的记录——项目真实做到 75% 到 80% 的时候，报告上写着 90%，而写下这个数的人并不是想撒谎 [4]。

为什么会这样？下面四个原因，一个比一个更贴近你手上那张表。

## 原因一：分母是边做边长的

WBS 上写的那些活，是开工那个时点能想到的活（参见[用 WBS 把定好的范围，拆成能派出去的活](https://pangzhengboyin.com/articles/wbs-decompose-scope-into-work-packages-ae48b54e)）。做到一半你会发现：数据得先清洗、接口要重开一个、安全评审要排队。分子在长，分母也在长。

于是比率可以一直不动：今天做完三项，同时发现五项新的，账面还是 85%。百分比变化的速度取决于分母，而分母恰恰是开工时最不清楚的那一块。所以它系统性地高估前期——头一个月总是“已完成 60%”——又低估尾段。

## 原因二：没做完的活按“看起来”给分，返工不给分

人给自己打分很宽容。算法想清楚了，心里就记成“这事一半做完了”，可调试、联调、跟供应商对字段还没开始，这些活不在账上。

更麻烦的是返工：返工在没被发现之前，账面上是“已完成”。等联调那天集中爆出来，数字往回退，或者干脆卡在原地不动。

## 原因三：同一个百分比，算的口径可以不一样

百分比不是一个数，是一个比值，分母可以是工期，也可以是工时。

一条活计划 2 天做完、需要 16 小时，实际干了一天、8 小时。按工时算是 $8/16=50\%$；同样这一天，如果这条活的工期定成 5 天，按工期算就是 $1/5=20\%$ [2]。

同一个状态，两个数，都不算算错。所以“完成 60%”这句话，没说清分母是什么，别人既没法验证，也没法跟你上周的数比。它唯一稳定的好处是：报的人安全。

## 原因四：完成度回答不了“会不会延期”

就算百分比算得又准又诚实，它还是答不了你最想问的那个问题。一个工作包 80% 完成，可能还需要超过原来 20% 的时间，因为剩下的不是均匀的薄薄一层，而是最硬的那一块 [3]。

进度讲的是已经发生的事，能不能按期是另一道题。

## 换成三样能验证的东西

### 一、交付物状态：只认“验收过了没有”

把百分比换成三档：未开始 / 在做 / 已验收。再加一条硬规矩：只有记下了实际完成日期、而且之后不再回头改的，才算完成 [2]。

好处是状态不可争辩，分母是清单而不是感觉：清单上多出一行，比“还剩 20%”诚实得多。

### 二、剩余工作量：问“还要多少”，不问“做了多少”

让每条活报一个 to go 数字，单位统一，比如还要几个人天。

它能加总、能验证、能前后对比，而且分母变了会立刻显形：上周还剩 6 人天，这周还剩 9 人天，说明发现了新活。这是信息，不是坏消息。

有了它就能做一道很朴素的除法：剩余工作量 ÷ 每周实际能投进去的产能 = 还需要几周。把这个结果跟离截止还有几周放在一起看，你得到的是一个明确判断。

同时报两个日期：计划完成日、预计完成日。预计完成日第一次越过计划完成日就要说，不要拖到最后一周才跳——那是最伤信任的报法 [5]。

![剩余工作量随时间下降：理想是一条斜线，实际长期贴着水平线，就说明这几周没有真正减少工作量](https://www.wrike.com/blog/content/uploads/2020/10/What-Is-a-Burn-Up-Chart-2.png)

### 三、卡点清单：进度不动，往往是在等

进度停住时，第一反应是“干得慢”，实际更常见的原因是在等：等评审、等接口、等一个人腾出手、等一个决定。

卡点写一句话，必须有三个要素：卡在谁手上、需要他给出什么、什么时候能给。写成“等运维配合”没有用，因为没有人可以被追。

```mermaid
flowchart LR
  A["这周交付物状态变了吗"] -->|没变| B["不是慢，是在等：翻卡点清单"]
  A -->|变了| C["剩余工作量比上周少了多少"]
  C --> D{"剩余工作量 ÷ 每周产能 ≤ 剩余周数？"}
  D -->|是| E["按现状能赶上，继续"]
  D -->|否| F["算缺口：减范围、加人，还是改日期"]
```

## 一张周跟踪表

还是拿客服系统迁移举例：

| 交付物 | 状态 | 剩余工作量 | 计划完成日 | 预计完成日 | 卡点 |
| --- | --- | --- | --- | --- | --- |
| 迁移脚本 | 在做 | 4 人天 | 3/8 | 3/12 | 等供应商给字段映射，周哥 3/5 前确认 |
| 培训材料 | 已验收 | 0 | 3/6 | 3/6 | — |
| 安全评审材料 | 未开始 | 2 人天 | 3/9 | 3/9 | 评审窗口没定，需总监找安全部门排期 |

三条规矩：

- 已验收的才划掉，在做的不划。
- 预计完成日一改，同一格写清原因和“需要谁做什么决定”。
- 只留十来行真正需要判断的交付物，别把 WBS 抄一遍。跟踪表变成第二份工作，第三周就没人填了。

## 那百分比是不是完全不能用

不是。任务足够小、口径固定、分母也不再变的时候，百分比可以当对外沟通的粗略说法。底线只有一条：别拿它推日期。它回答“已经做了多少”，不回答“什么时候能做完”。

## 收个尾

“完成 85%”之所以让人安心，是因为它听起来像“还差一点”。可项目真正要盯的是两件事：还剩多少没人碰过的活，还有多少人正在被别人等着。

一句话：进度不是投进去了多少，而是有多少东西已经不需要再动。

## 思维导图

```mermaid
flowchart LR
  A["周报上的 85% 不动"] --> B["为什么骗人"]
  B --> B1["分母边做边长"]
  B --> B2["部分学分与隐性返工"]
  B --> B3["口径不明：工期算或工时算"]
  B --> B4["完成度答不了会不会延期"]
  A --> C["换成三样可验证的"]
  C --> C1["交付物状态：已验收才算完"]
  C --> C2["剩余工作量 to go"]
  C --> C3["卡点清单：卡谁、要什么、何时给"]
  C2 --> D["剩余工作量 ÷ 每周产能 vs 剩余周数"]
  C3 --> D
  D --> E["能赶上 或 算缺口：减范围、加人、改日期"]
```

## 术语表

- 90% 症状：项目长时间停在接近完成的同一个百分比上，最后一段工作花掉远超它比例的时间，多数由未暴露的返工造成。
- 剩余工作量（to go）：还要投入多少才能做完，与“已经做了多少”相对；能加总、能前后对比，分母变化会立刻显形。
- 已验收才算完成：只有记录了实际完成日期、之后不再回头修改的交付物才计入完成，其余一律算在做。
- 卡点：让某条交付物停下来的具体等待，必须写到卡在谁手上、需要他给出什么、什么时候能给。
- 计划完成日与预计完成日：前者是排期时定的，后者按当前状况重算，两个日期分开报，延期会自己浮出来。

## 来源

1. [Why 'Percent Complete' Is Never a Measure of Progress — 百分比完成度为何不能当作进度指标，含验房清单 43 项变 46 项的例子](https://www.projectmanagement.com/articles/548040/why--percent-complete--is-never-a-measure-of-progress)
2. [Percent Complete's Limitations — 按工期算与按工时算的完成度差异，以及完全完成以实际完成日期为准](https://proactiveschedulemanagement.com/percent-completes-limitations/)
3. [M1.4 — Progress Measurement — 进度应是可观察的实际成果；80% 完成仍可能需要超过 20% 的原工期](https://projectcontrols.com/wiki/1079180/m14-progress-measurement)
4. [The Rework Cycle: Benchmarks for the Project Manager — 返工循环与 90% 症状：真实 75%~80% 被报成 90% 的成因说明](https://www.wcu.edu/pmi/1998/J93MAR17.PDF)
5. [Monthly Reviews a COR Actually Uses — 计划完成日与预计完成日并列报告，预计日临近才跳变是最伤信任的报法](https://precisionfederal.com/insights/monthly-reviews-a-cor-actually-uses)

---

原文：https://pangzhengboyin.com/articles/why-percent-complete-misleads-progress-tracking-44110ae0

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具：每篇 5–10 分钟，边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com