软件迭代计划
使用场景: 研发同学或 Scrum Master，规划两周 Sprint
第 1 天： Sprint 计划会
第 1–8 天：功能开发（3 个任务并行）
第 6–9 天：代码审查
第 9–10 天：QA 测试
第 10 天： Sprint 演示（里程碑）
第 10 天： 回顾会议
这样组织的原因: 把并行的开发任务显示在同一横排，让人一眼看出哪两个工程师依赖同一个前置任务，需要提前协调。
真实案例
营销活动时间线
使用场景: 营销经理，协调内容、设计和付费投放多个团队
第 1 周： 策略和需求简报
第 2–3 周：内容创作
第 2–3 周：视觉素材制作（并行）
第 4 周： 审核和审批
第 5 周： 付费投放设置
第 5 周： 活动上线（里程碑）
这样组织的原因: 内容和设计并行推进缩短了整体周期，但甘特图清楚地说明两者都必须在审批节点前完成，这才是真正的卡点。
网站改版项目
使用场景: 数字代理商项目经理，管理客户项目
第 1–2 周： 现状调研
第 2–4 周： 信息架构
第 4–7 周： UX 线框图
第 7–10 周： 视觉设计
第 10–14 周：开发
第 14–15 周：验收测试和上线
这样组织的原因: 每个阶段有清晰的交接点，客户和团队都知道什么时候需要反馈、什么时候进入下一阶段，不用等周会才能同步进度。
活动筹备计划
使用场景: 活动策划，协调供应商、场地和物流
提前 8 周：确认场地
提前 6 周：确认演讲嘉宾
提前 4 周：开始市场宣传
提前 2 周：最终确认餐饮人数
提前 1 周：确认当天流程
活动当天： 正式举办（里程碑）
这样组织的原因: 从活动日期倒推任务截止时间，让依赖关系一目了然——嘉宾确认延期，市场推广就跟着延期。
研究项目计划
使用场景: 研究生或研究员，规划数月周期的研究
第 1 个月：文献综述
第 2 个月：研究设计
第 3–4 个月：数据收集
第 5 个月：数据分析
第 6 个月：撰写草稿
第 7 个月：修改和提交
这样组织的原因: 长周期研究项目更需要甘特图，因为每个阶段都有最短持续时间——图上能直接看出跳过文献综述会把后续所有任务推后多少。
产品季度路线图
使用场景: 产品经理，向研发和管理层分享季度计划
Q1 1 月：调研和需求文档
Q1 2 月：设计和原型
Q1 3 月：Alpha 版本
Q2 4 月：Beta 发布（里程碑）
Q2 5 月：根据反馈迭代
Q2 6 月：正式发布（里程碑）
这样组织的原因: 季度粒度的甘特图比 Sprint 计划粗，但给管理层提供了他们需要的全局视图，方便规划人员调配和对外公告时机。
使用技巧
- 任务名称控制在五到七个字以内，确保左侧列放得下，不会换行导致行高不一致。
- 按阶段或工作流用颜色分组，读者扫一眼颜色就能判断项目哪个部分在延期，不需要逐行阅读。
- 关键路径上的任务用醒目颜色标出——这些任务只要延期，最终交付日期就一定延期。
- 每次周例会时对照甘特图更新实际进度，把计划条和实际条并排显示，滑点一出现就能看到。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=gantt
使用这个模板