项目计划与进度管理：从 WBS 到燃尽图，把"进度"讲清楚
这篇补什么
在《项目开发全流程手册：8 个节点》里，我把项目拆成 8 个主节点，外加一条贯穿全程的管理线（节点 0）。那条管理线有四股：计划与进度、变更、风险、沟通。当时”计划与进度”只用一行表格带过：
| 计划与进度 | 项目计划书、里程碑、甘特图、周报 | 拆解 WBS、定里程碑、每周同步进度与风险 |
但这一行，恰恰是项目经理每天都在打的仗。开发计划怎么排、进度怎么量、延期了怎么早发现——这些展开来分量不小，塞进那篇手册会让节点 0 头重脚轻，所以单独成篇。
它和另外两篇的分工是：
一句话定位：“开发计划”和”项目进度”不是某个独立节点，而是从立项到运维一直存在的管理动作；其中宏观计划归节点 0，迭代级的任务拆解落在节点 4 开发。
计划与进度的全景
flowchart LR
A[范围<br/>做什么] --> B[WBS<br/>拆成任务]
B --> C[估算<br/>工期与依赖]
C --> D[排期<br/>甘特图/里程碑]
D --> E[基线<br/>冻结计划]
E --> F[跟踪<br/>周报/燃尽图]
F -.偏差.-> G[纠偏<br/>赶工/砍范围/走变更]
G -.更新.-> D
style A fill:#e6f7ff,stroke:#1890ff
style E fill:#f9f0ff,stroke:#9254de
style F fill:#fff7e6,stroke:#fa8c16
记住这条主线：范围 → 拆解 → 估算 → 排期 → 基线 → 跟踪 → 纠偏 → 回到排期。 计划不是排完就锁死的甘特图，而是这个不断闭环的过程。下面逐段展开。
一、WBS：把项目拆到”能估”的粒度
计划做不准，九成是因为拆得不够细。WBS（Work Breakdown Structure，工作分解结构）就是把”做一个订单系统”这种大到无法估算的目标，层层拆到每个叶子任务都能回答”谁做、几天、依赖谁”。
拆解遵循两条原则：
- 100% 原则：某一层的所有子项加起来，必须正好等于父项——不多做、不漏做。父项之外冒出来的活，说明范围没界定清楚，该回立项/需求补边界。
- 拆到能估为止：叶子任务的工期控制在 1～5 个人天。太粗估不准，太细管理成本高。一个人天以内的活不必单列，5 天以上的继续拆。
以”手机验证码登录”为例：
1 | |
注意几点：
- 叶子任务是”可交付物”，不是”活动”。写”发码接口”（能提测的东西），不写”写代码”（没有明确完成标志的动作）。
- 业务规则要带进任务描述。”发码接口（含频控 60s/次）”比光写”发码接口”能估得准，也不容易漏。这些规则的权威源在 SRS，WBS 里引用即可（见《文档体系梳理》里 PRD 与 SRS 的边界）。
- 测试、联调、评审、文档都要占工期。最常见的低估就是”只排了写代码的时间”，把测试和联调当成不花时间的附赠。
最容易踩的坑
- 按”人”拆而不是按”交付物”拆。 一上来就分”张三负责登录、李四负责下单”，会漏掉跨人的联调和集成。先按交付物拆出完整的 WBS，再往上派人。
- 拆解层级和目录/模块混为一谈。 WBS 是”活儿”的分解，不是代码目录结构。别让它退化成 package 树。
二、估算：为什么你的估算总是偏乐观
人对工期的估计有系统性偏差（规划谬误），几乎永远偏乐观。几个能立刻改善准确度的做法：
- 三点估算：对不确定的任务，给出乐观(O)、最可能(M)、悲观(P)三个值，取 (O + 4M + P) / 6 作为期望工期。它会自动把”万一出岔子”的尾部风险纳入进来。
- 估”理想工时”后要打折落地。一个人一天并没有 8 小时纯开发时间——开会、答疑、上下文切换会吃掉 30%
40%。按 **每人天有效产能 56 小时** 折算排期，别拿理想工时直接填日历。 - 留缓冲，但把缓冲放在明处。不要把缓冲偷偷塞进每个任务（那样会被帕金森定律吃掉——“工作会自动膨胀到填满所有可用时间”）。把缓冲集中成一个显式的”项目缓冲”放在里程碑前，谁动用、动用了多少，一目了然。
最容易踩的坑
- 让”最懂的人”一个人估。 专家会不自觉地按自己的速度估，落到普通成员身上就爆。让实际干活的人参与估算。
- 把估算当承诺。 估算是概率，承诺是签字。对外给日期时，用的应该是”估算 + 缓冲”后的值，而不是最乐观的那个数。
三、排期：里程碑、依赖与关键路径
任务估完，要排进时间轴。这一步产出里程碑和甘特图。
里程碑是几个”标志性的、可对外承诺的时间点”，通常对应节点门禁：需求冻结、设计评审通过、开发提测、测试通过、验收签收、上线。里程碑要满足：
- 可验证——用产出物或门禁定义”到没到”，而不是”差不多了”。”需求冻结”= PRD/SRS 通过评审且开发测试确认，不是”需求写得差不多”。
- 数量克制——一个中型项目 5~8 个里程碑足够，多了就失去”标志性”的意义。
关键路径（Critical Path） 是决定项目最短工期的那条任务链——链上任何一个任务延期，整个项目就延期。识别它的意义在于：你的盯防精力应该优先压在关键路径上，而不是平均用力。不在关键路径上的任务有”浮动时间”，晚一两天不影响大局；关键路径上的任务晚一天，交付日期就晚一天。
flowchart LR
S([开始]) --> A["需求冻结 5d"]
A --> B["接口设计 3d"]
A --> C["UI 设计 4d"]
B --> D["后端开发 8d"]
C --> E["前端开发 6d"]
D --> F["联调 3d"]
E --> F
F --> G["测试 5d"]
G --> H([上线])
style A fill:#fff1f0,stroke:#f5222d
style B fill:#fff1f0,stroke:#f5222d
style D fill:#fff1f0,stroke:#f5222d
style F fill:#fff1f0,stroke:#f5222d
style G fill:#fff1f0,stroke:#f5222d
上图红色链 需求冻结→接口设计→后端开发→联调→测试 是关键路径（5+3+8+3+5 = 24 天）。前端那条 需求冻结→UI→前端开发→联调（5+4+6 = 15 天到联调）有富余，前端晚一两天不影响大局——但后端晚一天，上线就晚一天。所以后端是要重点盯的对象。
最容易踩的坑
- 只画甘特图，不标依赖。 没有依赖关系的甘特图只是一堆并排的条，看不出”谁卡谁”。一旦某个任务延期，你无法判断它会不会顺着依赖链把上线日推掉。
- 把接口契约冻结的时间点漏排。 前后端并行开发的前提是接口先定死（见全流程手册”设计→开发”门禁）。接口没冻结就并行，联调阶段会互相返工，关键路径直接失控。
- 忽视资源冲突。 甘特图上两个任务并行，但都要同一个 DBA，实际就串行了。排期要看人力是否真的能并行。
四、基线：计划要有一个”冻结版”
排期确认后，要把它**冻结成计划基线（Baseline）**存档。此后实际进度都和这个基线比，才谈得上”提前”还是”延期”。
没有基线的后果是：计划一路悄悄改，每次汇报都”符合最新计划”，于是永远不延期——直到上线前一天突然发现来不及。基线就是那把尺子：变可以，但要看得见变了多少、为什么变。
任何影响里程碑的计划调整都走变更，和需求变更单一样留痕（这就是节点 0 里”计划与进度”和”变更管理”两股线的交汇点）。
五、跟踪：进度到底怎么衡量
计划落地后进入日常跟踪。这里有一条最重要的原则：
别用”完成百分比”衡量进度。
“开发完成 80%” 是信息量最低的汇报——剩下的 20% 往往吃掉 80% 的时间（联调、异常处理、边界情况都在最后冒出来）。用二值化的、可验证的交付物来衡量：
- ❌ “登录功能做了 80%”
- ✅ “登录：发码接口已提测、校验接口开发中、前端未开始”
一个任务只有两个状态对外有意义：已提测 / 未提测（或已完成 / 未完成）。”做了一半”约等于”没做”，因为没法验证、也没法交付。
燃尽图：一眼看出会不会延期
燃尽图（Burndown Chart） 把”剩余工作量”随时间画出来。理想线是从总量匀速降到 0 的斜线，实际线是每天更新的剩余量。两条线的关系一眼说明问题：
flowchart LR
A["实际线在理想线<br/>下方"] --> A1["领先，可能<br/>估重了或超预期"]
B["实际线贴着<br/>理想线"] --> B1["健康，按计划走"]
C["实际线在理想线<br/>上方且不收敛"] --> C1["要延期，早纠偏"]
style C fill:#fff1f0,stroke:#f5222d
style B fill:#eafaf0,stroke:#2bab6a
燃尽图的价值是趋势预警：不用等到 deadline，看实际线的斜率就能外推出”照这个速度会在哪天燃到 0”。如果那个预测日期晚于承诺日期，现在就得纠偏，而不是到时候再说。
甘特图和燃尽图分工不同：甘特图看”谁在什么时候做什么、谁卡谁”（安排视角），燃尽图看”整体还剩多少、会不会按时完”（趋势视角）。 两个都要，回答的是不同问题。
挣值管理 EVM：同时回答”进度”和”成本”
进度看着正常，钱可能已经花超了；或者进度慢了，但花的也少。要同时回答这两问，用挣值管理（EVM，Earned Value Management）。三个基础量：
| 指标 | 含义 | 通俗说 |
|---|---|---|
| PV（计划值） | 到今天，按计划应该完成的工作量（预算口径） | 计划走到哪 |
| EV（挣值） | 到今天，实际完成的工作量（按预算折算） | 实际走到哪 |
| AC（实际成本） | 到今天，实际花掉的成本 | 实际花了多少 |
两个关键比值：
- SPI = EV / PV（进度绩效）：< 1 说明进度落后。
- CPI = EV / AC（成本绩效）：< 1 说明成本超支。
举例：计划到今天应完成 100 人天的活（PV=100），实际只完成了 80（EV=80），却已经花掉 90 人天的成本（AC=90）。那么 SPI=0.8（进度只有计划的 80%）、CPI≈0.89（每花 1 分钱只挣回 0.89）——又慢又超，双红灯。这比”感觉有点赶”精确得多，也能早暴露问题。
中小项目不必上完整 EVM，但 SPI/CPI 这两个比值的思路值得借：进度和成本要分开看，别用”钱还没花完”来掩盖”进度已经落后”。
最容易踩的坑
- 只报进度，不报剩余风险。 “本周完成了 X” 是过去式，管理者更关心”照这个速度能不能按时到里程碑”。汇报要给趋势和预测，不只是流水账。
- 进度靠嘴问。 “你那个好了吗？””快了。”——这种进度没有任何锚点。用可验证的交付物状态（已提测/未提测）和看板，让进度自己说话。
- 延期了才第一次说。 进度管理的全部价值在于早发现。燃尽图/SPI 一旦露出苗头就同步，越早纠偏，可选的手段越多（赶工、加人、砍范围、走变更改期）；拖到最后，就只剩”硬着头皮延期”一条路。
六、纠偏：发现要延期，有哪些牌可打
进度落后不是等来的，是提前算出来的。一旦燃尽图/SPI 预警，手上大致有这几张牌，各有代价：
| 手段 | 做法 | 代价 / 风险 |
|---|---|---|
| 赶工（Crashing） | 加人、加班、加资源压缩关键路径 | 成本上升；加人有磨合期，短期可能更慢 |
| 快速跟进（Fast Tracking） | 把本该串行的任务改成并行 | 返工风险上升（比如接口没定死就并行开发） |
| 砍范围 | 和产品/业务方协商，本期少做非核心功能 | 需要走变更、要业务方点头 |
| 改期 | 正式调整里程碑/上线日 | 走变更、更新基线、对齐干系人 |
| 什么都不做 | 接受偏差继续观察 | 只适用于偏差在缓冲范围内 |
关键是：这几张牌都要尽早打。加人只有在早期才来得及磨合，砍范围只有在开发前谈才不浪费已投入的工作量。拖到最后，能打的牌越来越少。
附：一份能直接套用的周报模板
周报不是流水账，是给干系人做决策的信息。一份好周报回答三件事：到哪了、有没有风险、需不需要你帮忙。
1 | |
要点：状态用红黄绿灯（让人一眼抓重点）、进展按交付物二值化（不写百分比）、风险带责任人和应对（不只是列出来）、明确列出”需要你决策/支持什么”（周报最该有、却最常被漏掉的一栏）。
小结
计划与进度这条线，串起来就是一句话：
把范围拆成能估的任务（WBS），估出带缓冲的工期，排进标好依赖的甘特图，冻结成基线；然后用可验证的交付物、燃尽图和 SPI 持续跟踪，一露苗头就纠偏。
几条无论项目大小都别省的底线：
- 拆到能估的粒度——拆不动就估不准，估不准就管不了。
- 计划要有基线——没有尺子，就永远”不延期”。
- 进度用交付物衡量，不用百分比——“完成 80%”是最没用的汇报。
- 进度和成本分开看——别用”钱没花完”掩盖”进度落后”。
- 偏差要早说——进度管理的全部价值在于早发现，越早纠偏越主动。
本文是”项目全流程”系列第三篇，聚焦贯穿全程的计划与进度管理。配合《全流程手册：8 个节点》（每步做什么）和《文档体系梳理》（产出放哪）一起看更完整。欢迎交流指正。