甘特图怎么做：七个步骤
做一张甘特图花的时间比多数人以为的少, , 前提是顺序对。最常见的错误是从日期开始。日期是结果，不是起点。
动手之前先弄清三件事
第一，目标和交付期。第二，达成它所需的任务清单。第三，每项大致要多久、谁等谁。估算不必准确，有个能往下改的起点就够。第一次接触这种图，先读什么是甘特图。
要搭的这份计划
下面每一步都落在同一份计划上：明川文化传播的官网改版，每周五个工作日，2026 年 4 月 6 日（周一）启动。这是走完第七步之后的样子, , 先扫一眼，因为后面每一步各解释其中一列。
明川官网改版。八项任务、两个里程碑，按工作日排，2026 年 4-6 月。
| # | 任务 | 工期 | 前置任务 | 开始 | 结束 |
|---|---|---|---|---|---|
| 1 | 内容盘点与素材梳理 | 5 天 | , | 4 月 6 日（周一） | 4 月 10 日（周五） |
| 2 | 站点地图与线框图 | 6 天 | 1 | 4 月 13 日（周一） | 4 月 20 日（周一） |
| 3 | 文案撰写 | 10 天 | 1 | 4 月 13 日（周一） | 4 月 24 日（周五） |
| 4 | 视觉设计 | 8 天 | 2 | 4 月 21 日（周二） | 4 月 30 日（周四） |
| 5 | 设计定稿 | 0 天 | 4 | 4 月 30 日（周四） | |
| 6 | 前端开发 | 12 天 | 5 | 5 月 6 日（周三） | 5 月 20 日（周三） |
| 7 | 内容录入 | 6 天 | 3、6 | 5 月 21 日（周四） | 5 月 28 日（周四） |
| 8 | 测试与缺陷修复 | 7 天 | 7 | 5 月 29 日（周五） | 6 月 8 日（周一） |
| 9 | 客户验收测试（UAT） | 4 天 | 8 | 6 月 9 日（周二） | 6 月 12 日（周五） |
| 10 | 正式上线 | 0 天 | 9 | 6 月 15 日（周一） | |
十行，十周，一个算出来的完工日期：6 月 15 日（周一）。没有人敲过这个日期，它是最长那条链上各段工期的和，并且只要其中任何一个工期一变，它自己就会跟着动。
这里有一处必须手工登记的东西：五一假期 5 月 1 日至 5 日（周五至周二）放假，5 月 9 日（周六）调休上班。前端开发因此从 4 月 30 日之后的第一个可用工作日 5 月 6 日起算，中间又白捡回 5 月 9 日这个周六。法定节假日和调休都要在工作日历里标出来，否则一份跨了五一的十周计划，误差轻松就是三四天。
1. 先列任务，不写日期
先写清楚要做什么，不写日期、不排顺序、不指定负责人，动词开头："整理内容清单""设计首页""法务审核""上线"。
合适的粒度在几天到两周之间：更短属于待办清单，更长是阶段，应当拆开。检验方法是能说出唯一负责人，并用一句话讲清"做完"什么样；说不出来，说明这项任务要么太大，要么太含糊。明川这份清单是十行对十周，差不多正合适, , 每条横条都有意义，又能一屏看完。按项目类型套一份模板起步还有个好处：它会替你记住那些人人都会漏掉的常规任务。
2. 定工期与起止日期
每项任务给一个开始日期，再给结束日期或工期其中之一, , 定了两个，第三个自己就出来了。按工作日估，不按自然日：明川这十二天的前端开发，在日历上横跨了将近三周。
并且要估纯工作时间, , 审批、养护、采购这类等待应作为独立任务，而不是塞进工期里把它撑大。每项都往里加水分会把真实风险藏起来，一点不加又不给意外留余地。可靠的做法是估乐观、最可能、悲观三个值再加权："视觉设计"估 3、5、13 天，按 (3 + 4×5 + 13) / 6 得 6 天。只给一个数字的人，给的几乎总是乐观值。现在写下的都是猜测也没关系，第四步会让你改工期时不必重录任何东西。
3. 排顺序并归入阶段
把任务按实际发生顺序排好，再归到阶段下面, , 本例为调研、设计、开发、内容、上线四到五个阶段。阶段是一行摘要任务，它的横条由下属任务里最早的开始和最晚的结束算出来，所以你只能通过移动内容来移动阶段。
正是这个分组决定了一份大计划好不好读，也让你在对客户汇报时可以把明细折叠起来。gantts.app 还会自动给出 WBS 编号（1、1.1、1.2），每项任务因此有了一个稳定的引用号。
4. 连接依赖关系
依赖关系才是把一张静态图变成真正进度计划的东西：把互相牵制的任务连起来，移动其中一项，其余的自动跟着重排。画好连线交给工具去算，忍住那个"直接把日期写死"的冲动, , 那个日期本该由依赖关系来决定。
只连真正存在等待关系的任务。检验方法：如果 A 提前完成，B 能否提前开始？能，就是真依赖；不能，你只是把清单顺序照抄了一遍。四种类型，逐一放到明川这份计划上看：
| 类型 | 规则 | 在本例中的位置 | 用到的频率 |
|---|---|---|---|
| 完成-开始（FS） | A 完成前 B 不能开始 | 设计定稿之后才前端开发, , 本例九条连线全是这一种 | 几乎总是 |
| 开始-开始（SS） | A 开始前 B 不能开始 | 如果文案改成"线框图一开工就动笔"，而不是接在内容盘点后面 | 偶尔，用于并行推进的工作 |
| 完成-完成（FF） | A 完成前 B 不能完成 | 测试不早于最后一批内容录入完毕 | 较少 |
| 开始-完成（SF） | A 开始前 B 不能完成 | 本例没有。它主要用于新旧交接 | 几乎不用 |
这份计划里有两条连线值得单独指出来。第 7 行"内容录入"有两个前置任务, , 文案和前端开发, , 所以它从两者中较晚的那个结束时开始，也就是 5 月 20 日的前端开发。而第 3 行文案 4 月 24 日就写完了，直到 5 月 21 日才用得上，中间空出十六个工作日的余量。这个空档是真实信息：别处着火时，文案这个人就是从这里调出来的。
拖横条之前有一个行为要先知道：gantts.app 的排程是"按摆放位置"算的。依赖关系只能把任务推得比你摆的位置更晚，永远不会把它往前拉。你把"测试"扔到八月，再连上内容录入，它也不会被拽回五月, , 连线只规定了它最早可以什么时候开始，图上则老实显示你留下的那段空档。想把这些空档一次压实，点自动排程。
依赖关系还是第七步里关键路径的输入：没有连线，工具无从知道哪几项任务在决定交付期。如果你只肯给图加一样结构，那就加依赖关系。完整说明见四种依赖关系。
5. 设置里程碑
里程碑标记一个没有工期的重要时点, , 一次审批、一次交付，或者上线本身, , 画成菱形而不是横条。因为长度为零，它可以整体移动，但不能拉长缩短。明川这份计划有两个："设计定稿"和"正式上线"。两个都是需要交付团队之外的人动作的时点，这正是挑选里程碑最好的标准。
数月量级的项目设五到十个就够，习惯做法是每个阶段末尾放一个、交付期再放一个, , 它也是最好的依赖挂载点。要注意的是：里程碑标记的是决策、审批或条件达成，而不是随便某项任务的结束。
6. 指定负责人、更新进度、存基准
每项任务指定唯一负责人，并随着工作推进更新完成百分比。今天线越过一条还停在 0% 的横条，就是需要处理的偏差。一张图能不能一直有用，最大的单一因素就是进度有没有及时更新。
开工前还要做一件事：存一版基准。它把你们谈定的那份计划冻住，于是六周之后你比的是漂移量，而不是在争论当初到底承诺了什么。
第六周末的明川项目，基准存于 4 月 6 日：
| 任务 | 基准结束 | 实际／预测 | 偏差 | 完成度 |
|---|---|---|---|---|
| 内容盘点与素材梳理 | 4 月 10 日 | 4 月 10 日 | 0 天 | 100% |
| 站点地图与线框图 | 4 月 20 日 | 4 月 22 日 | +2 天 | 100% |
| 视觉设计 | 4 月 30 日 | 5 月 7 日 | +2 天 | 100% |
| 文案撰写 | 4 月 24 日 | 5 月 11 日 | +9 天 | 100% |
| 前端开发 | 5 月 20 日 | 5 月 22 日 | +2 天 | 40% |
| 正式上线 | 6 月 15 日 | 6 月 17 日 | +2 天 | , |
读偏差这一列，故事自己就讲出来了。文案晚了九个工作日，一分钱不花，因为它有十六天浮动时间可用。线框图丢的那两天，则原封不动地变成上线晚两天，因为那项任务在关键路径上。同样的延误，价钱天差地别, , 第七步存在的全部理由就在这里。
还要注意"视觉设计"那一行：基准是 4 月 30 日，实际 5 月 7 日，看日历隔了七天，但偏差只有 2 个工作日，因为中间横着一整个五一假期。工作日历没标对的话，这一行会报成 +7 天，然后所有人都会去追一个根本不存在的问题。
7. 复核关键路径并导出
最后，打开关键路径, , 决定完工日期的那条最长的依赖链。在明川这份计划里它是：内容盘点 → 线框图 → 视觉设计 → 设计定稿 → 前端开发 → 内容录入 → 测试 → UAT → 上线。十行里有九行在这条链上，这说明了一件不太舒服但很有用的事：这份计划几乎没有任何余地，而全项目仅有的浮动时间，都攒在文案这一项上。
gantts.app 报的数字是总浮动时间, , 完工日期开始移动之前这项任务能拖多久, , 而不是只对紧后任务而言的自由浮动时间，界面上也没有单独的自由浮动列。所以文案那十六天，是上线日期实打实的十六天保护。
把浮动时间放在不确定的地方, , 里程碑之前和关键路径末端，而不是每项任务上。分散的浮动会被悄悄吃掉，集中起来才看得见。复核完这条链、能重排的地方重排、确认完工日期现实之后，与执行者一起过一遍, , 只有一个人知道的计划是意见，不是计划, , 再导出：出报告用 PDF 或 PNG，进汇报材料用 Excel 或 PowerPoint。背后的算法见关键路径法。
最常见的错误
- 一上来就规划得太细。先从阶段层面起步，只在确有帮助的地方往下拆。300 行的计划没人维护，而过期的计划比没有计划更糟。
- 用固定日期代替依赖关系。前置任务延误时日期不动，计划从那一刻起就在说谎。
- 整份计划没有任何余量。明川十行里九行是关键的，第一个糟糕的星期就会让它崩掉。把应急余量明明白白放在交付期附近，而不是藏进每一个估算里。
- 从不更新进度。没人维护的图比没有图更糟，因为人们还在相信它。
- 不看关键路径。不知道哪几项在决定完工，就无从保护交付期。
- 不登记法定节假日和调休。春节、五一、国庆都会把跨假期的任务整段推走，而调休上班的周末又会还回来一两天。这两笔账不记，计划到后半程必然对不上。
在 gantts.app 里把它搭出来
同样这十行，在编辑器里的做法，按钮名称与界面上的一致：
- 打开✨ 粘贴生成甘特图，把提纲整段贴进去。括号里的工期、表示连线的
after、结尾的!（里程碑）会在粘贴时被识别, , 例如前端开发 (12d) after 设计定稿，再写正式上线 !。 - 也可以手工搭：＋ 任务加一行工作，◆ 里程碑加一个菱形，▣ 分组加一个阶段，再用缩进按钮把任务挂到它下面。
- 双击某一行，设置前置任务、负责人和进度。里程碑也在这里：把某行的类型改掉，它的结束日期就会塌回到开始日期上。里程碑拖不宽, , 有工期的里程碑就不是里程碑。
- 进工作日历，把五一假期 5 月 1 日至 5 日标为休息、5 月 9 日标为调休上班。这一步在排程之前做，后面才不用返工。
- 点自动排程，把每项任务移到连线允许的最早日期。6 月 15 日就是这一步算出来的。
- 勾上关键路径，九条关键横条会以斜纹显示；顺手确认文案不在其中。
- 开工前存基准，上面那张偏差表就成了应用自动填的东西，而不是你手工拼的。
- 十周的计划把缩放调到周刻度；开工后用◎ 今天把视图跳回当天。
- ⬇ 导出提供 📄 PDF 文档、📊 Excel (.xlsx)、📑 CSV（表格）和📽 PowerPoint (.pptx)；📤 分享…给一个🔗 分享链接。给客户看之前，先把视图切到仅里程碑, , 设计定稿和正式上线，别的都不显示。
二十行以内电子表格勉强够用，再多就吃力，因为依赖不会自动重算。gantts.app 直接在浏览器里运行，无需注册、无需下载，数据保存在你自己的设备上；也可以从模板库里的现成计划改起，或者看用 Excel 怎么做甘特图。
常见问题
甘特图怎么做？
列任务、定工期、排顺序归阶段、连依赖、设里程碑、指定负责人并存基准、复核关键路径后导出。日期由前面几步自然得出，不需要一开始就定。
动手之前需要准备什么？
三样：明确的目标和交付期、达成目标所需的任务清单、每项任务大概多久以及谁等谁。有这三样，几十分钟就能把图搭起来，之后再逐步修正。
怎样免费做甘特图？
在浏览器里做，无需注册和安装，例如用 gantts.app，依赖关系、关键路径和导出都免费；也可以用 Excel 或 Google Sheets 的堆积条形图，但超过二十项任务就会很吃力。
依赖关系怎么加？
在两条横条之间画一条连线即可，最常用的是完成-开始：前一项完成后一项才开始。加上之后，前置任务一移动，后面的日期会自动跟着重排，不需要手工改。
甘特图里的关键路径是什么？
决定项目完工日期的那条最长依赖链。链上任何一项任务延误，整个项目就跟着延误。gantts.app 会自动高亮它，你因此知道哪几项最要紧。在明川那个例子里，十行有九行都在这条链上。
一张甘特图放多少任务合适？
越少越好，够用即可。20 到 60 行仍然可读；超过 150 行就没人维护了，这时应该按阶段汇总，再给每个阶段拆一张明细计划。
单个任务多长合适？
几天到两周之间。更短属于待办清单，更长是阶段，应当拆开。判断标准是能指定唯一负责人，并用一句话说清什么算做完。
五一、国庆这类假期怎么排？
在"工作日历"里把法定节假日标为休息日、把调休上班的周末标为工作日，然后再点"自动排程"。跨假期的任务会自己顺延，偏差列也才算得对, , 否则一个七天假会被当成五个可用工作日，整份计划从那里开始失真。
延伸阅读
本文也提供英文版本。