3、项目计划：WBS工作分解、甘特图制作、关键路径法
项目计划这件事，说白了就是回答三个问题：做什么、谁来做、什么时候做完。很多新手项目经理一上来就打开Excel画甘特图，结果画到一半发现漏了一堆任务，工期排得乱七八糟。嗯，我当年也干过这种蠢事。
后来我带过一个千万级的系统集成项目，前期计划没做好，中期返工了三次。从那以后，我养成了一个习惯：先做WBS，再画甘特图，最后算关键路径。顺序不能乱，一步都不能省。
核心逻辑：WBS是骨架，甘特图是血肉，关键路径是神经。三者缺一不可。
3.1 WBS工作分解：把大象装进冰箱
WBS全称是Work Breakdown Structure，工作分解结构。我见过最离谱的项目计划，就一行字：「开发一个电商系统，工期3个月」。你想想看，这能叫计划吗？这连方向都算不上。
WBS的核心原则就一条：把大任务拆到不能再拆为止。拆到什么程度？我个人习惯是拆到每个任务包不超过40小时（也就是一个人一周的工作量）。
我的经验：WBS要遵循「100%原则」——下一层的工作加起来必须等于上一层的全部内容，不能多也不能少。我曾经在一个项目中漏掉了「用户验收测试」这个子任务，结果上线前才发现没人测，差点翻车。
举个例子，一个「客户管理系统」的WBS可以这样拆：
| 层级 | WBS编号 | 任务名称 | 负责人 | 预估工时 |
|---|---|---|---|---|
| 1 | 1.0 | 客户管理系统 | 项目经理 | - |
| 2 | 1.1 | 需求分析 | 产品经理 | 80h |
| 3 | 1.1.1 | 客户访谈 | 产品经理 | 24h |
| 3 | 1.1.2 | 需求文档编写 | 产品经理 | 40h |
| 3 | 1.1.3 | 需求评审 | 全员 | 16h |
| 2 | 1.2 | 系统设计 | 架构师 | 120h |
| 2 | 1.3 | 开发实现 | 开发团队 | 400h |
| 2 | 1.4 | 测试部署 | 测试团队 | 160h |
避坑指南：我曾经见过一个团队把WBS拆到了「写一行代码」的粒度，结果光维护WBS就花了一半时间。记住，拆到可管理、可估算、可分配就够了，别走火入魔。
3.2 甘特图制作：把计划画出来
有了WBS，甘特图就好办了。说白了，甘特图就是给每个任务加上开始时间、结束时间、负责人，然后用横条画出来。
我建议用Excel或者Project做甘特图，但如果你团队小，用在线协作工具也行。关键不是工具，而是依赖关系——哪些任务必须等前面的做完才能开始？
常见的依赖关系有四种：
- 完成-开始（FS）：A做完，B才能开始。最常见，比如「设计完才能开发」。
- 开始-开始（SS）：A开始了，B才能开始。比如「写文档和写代码可以同时开始」。
- 完成-完成（FF）：A做完了，B才能做完。比如「测试完成，开发才算真正完成」。
- 开始-完成（SF）：A开始了，B才能完成。这个很少用，了解一下就行。
我的习惯：画甘特图时，先排硬依赖（比如必须等审批的），再排软依赖（比如建议顺序）。硬依赖排错了，整个计划都得重来。我吃过这个亏，有一次把「服务器采购」和「环境搭建」排成了并行，结果服务器没到，开发干瞪眼了一周。
甘特图里还有一个重要概念——里程碑。里程碑不消耗时间，它只是一个检查点。比如「需求评审通过」、「系统上线」就是里程碑。我习惯在甘特图上用菱形标记里程碑，一眼就能看出项目进展到哪了。
3.3 关键路径法：掐住项目的命门
关键路径法（CPM）是项目管理里最实用的工具之一。它要回答的问题是：整个项目最短需要多少天？哪些任务一天都不能晚？
怎么找关键路径？我教你一个笨办法，但很管用：
- 列出所有任务和它们的工期
- 标出任务之间的依赖关系
- 从开始到结束，找出所有可能的路径
- 计算每条路径的总工期
- 最长的路径就是关键路径
举个例子，假设有四个任务：
| 任务 | 工期（天） | 前置任务 |
|---|---|---|
| A. 需求分析 | 5 | 无 |
| B. 系统设计 | 3 | A |
| C. 前端开发 | 4 | B |
| D. 后端开发 | 6 | B |
| E. 联调测试 | 2 | C, D |
路径一：A → B → C → E = 5+3+4+2 = 14天
路径二：A → B → D → E = 5+3+6+2 = 16天
关键路径是路径二，总工期16天。这意味着：只要后端开发（D）晚一天，整个项目就晚一天。而前端开发（C）有2天的浮动时间，晚两天都不影响总工期。
避坑指南：我曾经在一个项目中，所有任务都按计划完成了，但项目还是延期了。为什么？因为关键路径上的一个任务虽然按时完成了，但它的前置条件（比如第三方接口）没准备好。记住，关键路径上的任务不仅要看自己，还要看外部依赖。
小技巧：关键路径不是一成不变的。项目进行中，如果非关键路径上的任务延期太多，它可能变成新的关键路径。我建议每周重新算一次关键路径，尤其是在项目中期。
3.4 三者如何配合使用
最后说说这三者的配合。我一般按这个流程走：
- 第一步：用WBS把项目拆成可执行的任务包。这一步不要想时间，只想要做什么。
- 第二步：给每个任务包估算工时，标出依赖关系，画成甘特图。这一步要回答「谁在什么时候做什么」。
- 第三步：用关键路径法找出最长的路径，重点盯住这些任务。这一步要回答「哪些任务不能出问题」。
嗯，说到这里，我想起一个真实的案例。有个团队做ERP系统，WBS拆了300多个任务，甘特图画了密密麻麻一片。结果项目经理没算关键路径，所有任务都按「重要」来管，最后发现一个不起眼的「数据迁移脚本」卡了整整两周，整个项目延期。如果早算关键路径，提前给这个任务加人，根本不会出问题。
所以，别嫌麻烦。WBS、甘特图、关键路径法，这三步走下来，你的项目计划才算真正「能打」。