甘特图是一种横向条形图，把任务和时间对应起来。每一个条形代表一个任务——位置表示开始时间，长度表示持续多久。画好的甘特图能让项目里的每个人都清楚地看到：什么事情要做、顺序是什么、截止时间是什么时候。
它最适合的场景是：项目有多个互相依赖的任务，而且需要多个人协调工作。普通的待办清单看不出"任务 B 必须等任务 A 完成才能开始"，也看不出"两个任务都压在同一个人身上"。甘特图把这两件事都变得可见。
开始之前你需要准备什么
在打开任何工具之前，你需要先想清楚三件事：
- 任务清单 — 项目里每一件需要做的事，不是大的阶段，是具体的工作项
- 每个任务的工期估算 — 大概需要多少天或多少周
- 依赖关系 — 哪些任务必须等其他任务完成才能开始
跳过任何一项，做出来的甘特图看起来整齐，实际上是错的。建立在估算上的时间线，是对团队和利益相关方的虚假承诺。
第一步：列出任务
先头脑风暴，把项目里所有要做的事写下来，然后按逻辑分组。
以一个软件产品发布为例：
调研阶段
- 利益相关方访谈
- 竞品分析
- 需求文档
设计阶段
- 线框图
- 视觉设计
- 设计评审
开发阶段
- 后端 API
- 前端实现
- 集成测试
发布阶段
- QA 验收
- 部署上线
- 发布公告
任务的粒度要合适——一个人能负责，能给出具体工期。"做产品"不是任务，"实现用户认证模块"才是。
第二步：估算工期
为每个任务指定工期（天或周）。要诚实——过于乐观的估算会引发一连串的延期。
几个需要注意的地方：
- 算上评审环节。设计不是设计师画完就结束了，要等利益相关方审核和修改。
- 有外部依赖的任务（等客户、等供应商、等审批）要留缓冲。
- 如果你真的不知道某个任务要多久，这本身是重要信息。要么弄清楚，要么在它周围建充足的缓冲。
第三步：梳理依赖关系
依赖关系把任务列表变成一个有序序列。最常见的类型是完成才能开始：任务 B 必须等任务 A 完成后才能开始。
逐一检查你的任务，标注哪些任务被其他任务阻塞：
- 视觉设计依赖线框图通过评审
- 开发依赖设计定稿
- QA 验收依赖开发完成
- 发布公告依赖QA 通过
先用文字列出来，再画到图上——在文字里更容易发现逻辑问题。
第四步：确定时间线
有了任务、工期和依赖关系，就可以排时间线了。从项目开始日期出发，往后推：
- 把没有依赖关系的任务放在最前面
- 对每个有依赖的任务，等前置任务完成后才开始安排
- 找出关键路径——决定项目最早完成时间的那条最长依赖链
关键路径是甘特图里最重要的东西。关键路径上任何一个任务延期，整个项目就延期。不在关键路径上的任务有浮动空间——可以在一定范围内推迟，不影响最终结束日期。
第五步：指定负责人
每个任务都需要一个具体的负责人。不是"研发团队"，是一个有名有姓的人。这样做有两个作用：一是方便做资源规划（能直接看出谁同时被分配了五个重叠的任务）；二是让责任清晰——没有明确负责人的任务，往往没人真正负责。
第六步：画出来
现在可以动手画图了。结构很直接：
- 行：每行对应一个任务（或任务组）
- 列：时间周期（根据项目长度选天、周或月）
- 条形：从开始到结束日期，对应每个任务
- 箭头：连接有依赖关系的任务
- 里程碑：用菱形或标记点表示关键节点（代表时间点，没有持续时长）
保持图表可读性。如果有 80 行任务，考虑在顶层只显示阶段，让读者按需展开细节。一张看不懂的图没有任何作用。
示例：网站改版项目
下面是一个六周网站改版项目的甘特图示意：
| 任务 | 第 1 周 | 第 2 周 | 第 3 周 | 第 4 周 | 第 5 周 | 第 6 周 |
|---|---|---|---|---|---|---|
| 利益相关方访谈 | ████ | |||||
| 内容审计 | ████ | ████ | ||||
| 线框图 | ████ | ████ | ||||
| 设计评审 | ████ | |||||
| 开发 | ████ | ████ | ||||
| QA | ████ | |||||
| 上线 | ▲ |
这个项目的关键路径是：线框图 → 设计评审 → 开发 → QA → 上线。这条链上任何一个任务拖了，上线日期就得推。
常见错误
做得太细。 有 200 行任务的甘特图是伪装成图表的电子表格。每一行应该代表有意义的工作，不是每一个具体动作。
忽视依赖关系。 把任务条形依次排列，不加任何依赖关系，那不是甘特图，只是时间轴。依赖关系才是甘特图用来规划的核心。
做完就不更新。 项目开始时画好、之后从不维护的甘特图，是历史文件，不是规划工具。当现实偏离计划时，就更新图表。
混淆里程碑和任务。 里程碑是一个时间点——"设计通过审批"或"上线日期"。它没有持续时长。如果你给里程碑画了一个条形，你把一个时间点当成任务处理了。
按 100% 容量规划。 如果每个人被分配的任务恰好填满了所有工作时间，一天请假就会引发一连串的延期。给每个人预留至少 20% 的缓冲。
什么时候甘特图不是最好的选择
甘特图适合范围明确、任务可预测、依赖关系清晰的项目。在这些场景下效果不好：
- 早期探索阶段 — 还不知道任务是什么时，思维导图或看板更合适
- 持续运营型工作 — 支持队列或内容日历，看板比甘特图更自然
- 高度不确定的项目 — 如果估算可能差出 50%，甘特图只是制造了虚假的精确感
对于跑迭代 Sprint 的敏捷团队，甘特图通常太死板。Sprint 规划 + 看板能以更低的维护成本实现同样的协调效果。
甘特图真正有价值的前提，是你花时间正确地建立它——诚实的估算、真实的依赖关系、明确的负责人。建立在这些基础上的图表，能给团队一个可以导航的坐标。建立在一厢情愿上的图表，只是推迟了现实打脸的时刻。
