设计甘特图的关键，是把任务拆到可估算的粒度、理清依赖与关键路径、排入时间轴并保存基线，再建立固定的更新与纠偏节奏。只画出漂亮的任务条，图很快会过期；能支撑每周进度判断和调整，才算设计完成。下面按准备、拆解、依赖、排期、更新、分工、示例和检查的顺序展开。
要点总览（TL;DR）
- 甘特图设计先定范围、任务粒度和维护责任人，再进入拆解与排期，否则图做完容易无人更新。
- 任务从交付物倒推拆解，每个任务补齐负责人、工期、完成标准和前置任务，才能进入排期。
- 依赖关系逐条确认后计算关键路径，关键路径上的任务需要更密的跟踪和更早的风险预警。
- 排期后保存基线并设定有判定标准的里程碑，基线是判断延误的参照。
- 固定每周更新实际进度与剩余工期，记录偏差和纠偏动作，下次更新时复核是否生效。
设计甘特图前先定清三件事
甘特图是项目计划的表达方式，设计前需要先确定输入。范围、粒度和维护责任没有定清，图做完后往往无人更新，也无法用于进度判断。
第一，明确项目范围与交付物边界。用一段范围说明写清本次要交付什么、不包含什么、验收以什么为准。范围说明不必很长，但要能回答“哪些工作应该出现在图上”。范围含糊时，任务拆解会不断膨胀，甘特图变成愿望清单。
第二，约定任务拆解粒度。常用判断标准是：一个任务能由一名负责人估算工期，完成后有可检查的产出，工期大致落在半天到两周之间。粒度过粗，进度无法判断；粒度过细，更新成本过高。可以在准备阶段写一条粒度约定，例如“任务工期不超过10个工作日，超过则继续拆分”。
第三，指定维护责任人与更新节奏。甘特图需要有明确的所有者，通常由项目经理维护整体结构和基线，任务负责人更新自己任务的实际进展。更新节奏与项目例会对齐，例如每周一次，在固定时间前完成状态更新。
| 准备项 | 要写清的内容 | 完成标志 |
|---|---|---|
| 范围说明 | 交付物、验收标准、不包含事项 | 团队评审无异议 |
| 粒度约定 | 单个任务的工期上限与拆分规则 | 拆解时可直接套用 |
| 维护责任 | 整体维护人、任务更新人、更新频率 | 责任人和时间点已通知到人 |
第一步：把交付物拆成可排期的任务清单
任务拆解从交付物倒推，而不是从“大家平时做什么”正向罗列。先列出最终交付物，再问“要完成它，必须先产出什么”，逐层向下拆，形成工作分解结构（WBS）。按交付物或项目阶段分层，比按部门分层更容易检查完整性。
拆解完成后，每个任务至少补齐以下字段，才能进入排期：
- 任务名称：用动词加对象描述，例如“完成接口联调”“提交测试报告”，避免“跟进”“处理”这类无法判断完成状态的写法。
- 负责人：一名主要责任人，协作人另列，避免责任分散。
- 工期估算：以工作日为单位，注明估算依据，例如历史同类任务或团队经验。
- 开始与结束条件：写清任务启动需要的前置产出，以及完成的可检查标准。
- 依赖字段：标出前置任务，供下一步确定依赖关系。
拆解时同步识别并行与串行。可以同时开展、互不等待的任务适合并行，能压缩总工期；存在产出交接或共享资源的任务需要串行。把判断结果直接写进任务清单，排期时就不必重新讨论。
| 任务名称 | 负责人 | 工期（工作日） | 前置任务 | 完成标准 |
|---|---|---|---|---|
| 需求说明定稿 | 产品负责人 | 3 | — | 评审通过并归档 |
| 界面设计稿 | 设计师 | 4 | 需求说明定稿 | 设计稿评审通过 |
| 接口开发 | 后端负责人 | 6 | 需求说明定稿 | 接口文档与自测通过 |
| 页面开发 | 前端负责人 | 5 | 界面设计稿 | 页面可联调 |
| 联调与修复 | 前端负责人 | 3 | 接口开发、页面开发 | 主流程跑通 |
第二步：确定依赖关系与关键路径
依赖关系决定任务在时间轴上的先后。常见类型有四种：完成-开始（前置任务完成后，后续任务才能开始）、开始-开始（前置任务开始后，后续任务才能开始）、完成-完成（前置任务完成后，后续任务才能完成）、开始-完成（前置任务开始后，后续任务才能完成）。项目排期中最常用的是完成-开始，存在并行搭接时才会用到开始-开始等类型。
把任务清单中的前置关系逐条确认，形成依赖关系表。确认时重点检查两类问题：一是漏标依赖，导致排期把本应串行的工作排成并行；二是多余依赖，把本可并行的任务强行串行，拉长总工期。每条依赖最好注明依据，例如“需要设计稿评审通过才能开发”。
依赖链确定后，计算每条路径的工期总和，总工期最长的那条路径就是关键路径。关键路径上的任务没有浮动时间，任何一天延误都会直接推迟项目完成时间。因此这些任务需要更密的跟踪频率、更明确的负责人和更早的风险预警。非关键路径任务有一定浮动时间，可以在资源紧张时适当调整，但浮动时间被消耗完后同样会进入关键路径，更新时需要重新计算。
| 依赖类型 | 含义 | 典型场景 |
|---|---|---|
| 完成-开始 | 前置完成后，后续才能开始 | 设计评审通过后开始开发 |
| 开始-开始 | 前置开始后，后续才能开始 | 开发启动后同步开始编写测试用例 |
| 完成-完成 | 前置完成后，后续才能完成 | 全部用例执行完成后才能出具测试报告 |
| 开始-完成 | 前置开始后，后续才能完成 | 新流程上线后，旧流程才能收尾 |
第三步：排入时间轴并设定基线与里程碑
把任务按工期和依赖排入日历，形成任务条。排布时先按依赖关系确定最早开始时间，再检查资源冲突：同一负责人在同一时间段被安排多项任务，或关键资源被多个并行任务占用，都需要调整顺序或补充人手。资源冲突的处理结果要回写到任务清单，保持图与清单一致。
里程碑用于标记重要时间点、事件或决策点，例如“需求评审通过”“版本提测”“上线发布”。每个里程碑要有判定标准，写清以什么产出或什么会议结论作为达成依据，避免里程碑变成单纯的日期标记。里程碑数量不宜过多，覆盖关键决策点即可。
排期完成后保存基线版本。基线是后续判断“是否延误”的参照：没有基线，只能看到当前计划，无法区分计划调整和执行偏差。基线保存后，计划变更应作为新版本记录，保留变更原因，便于回溯。
在工具层面，ONES 的项目计划能力支持按目标、交付物或项目阶段分解工作，为任务设置前后置依赖，并用里程碑标记重要时间点；同时支持设置计划和里程碑基线，对比计划与执行的偏差。这些能力对应本步骤的排期与基线动作，具体配置方式以实际使用版本为准。
第四步：建立更新与偏差纠偏机制
甘特图进入日常使用后，需要固定的更新循环。建议每周一次，与项目例会同步，更新内容包括：任务的实际开始与完成日期、剩余工期、依赖关系是否发生变化、负责人是否调整。更新由任务负责人完成，项目经理检查整体一致性。
更新后做三类偏差识别：
- 进度滞后：实际完成晚于基线，或剩余工期超出原估算。重点看关键路径上的任务。
- 依赖变化：前置任务延期导致后续任务无法按原计划开始，需要重排后续任务。
- 资源冲突：同一人员被多项任务同时占用，或关键资源可用时间发生变化。
识别偏差后要有明确的纠偏动作，并记录处置结果。常见动作包括：调整任务工期并说明依据、重排任务顺序、增加人手或缩减范围、把无法在团队内解决的问题升级为风险。每次纠偏都记录“偏差描述、影响范围、采取动作、责任人、复核时间”，下次更新时核对是否生效。
在协作工具中，任务状态和日期的更新可以直接反映到甘特视图。ONES 支持制定项目里程碑和甘特图、多时间跨度查看进度，并支持成员共享甘特图；ONES Plan 的甘特图可监控和规划相关项目与迭代，查看工作量和进度。把任务状态更新与每周例会绑定，可以减少单独维护一张图的工作。
| 更新项 | 更新人 | 更新时点 | 记录内容 |
|---|---|---|---|
| 任务实际开始/完成 | 任务负责人 | 每周例会前 | 日期、完成标准核对结果 |
| 剩余工期 | 任务负责人 | 每周例会前 | 新估算及依据 |
| 依赖与基线对比 | 项目经理 | 每周例会 | 偏差描述与影响范围 |
| 纠偏动作 | 项目经理与责任人 | 例会当场或会后 | 动作、责任人、复核时间 |
角色分工与各环节交付物
甘特图设计涉及拆解、排期、更新和审核四类动作，角色不清会出现“图有人画、没人改”的情况。下表给出常见分工，团队规模较小时可以一人兼任多个角色，但职责要写清。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 项目经理 | 确定范围与粒度约定，组织排期，维护基线与整体结构，主持偏差评审 | 项目目标、范围说明、团队资源情况 | 范围说明、基线版本、偏差处置记录 |
| 任务负责人 | 拆解自己负责的交付物，估算工期，标注依赖，按节奏更新进展 | 交付物要求、粒度约定 | 任务条目、工期估算、更新后的任务状态 |
| 团队成员 | 确认任务可执行性，反馈资源冲突，执行纠偏动作 | 任务清单与排期结果 | 执行反馈、冲突信息 |
| 评审人（技术负责人或业务负责人） | 审核任务完整性与依赖合理性，确认里程碑判定标准 | 任务清单、依赖关系表、里程碑清单 | 评审意见与确认结论 |
评审节点建议设在两处：任务清单和依赖关系完成后评审一次，确认没有漏项和错误依赖；基线和里程碑设定后评审一次，确认排期可执行。两次评审的结论都应记录，作为后续变更的参照。
一个示例：两周迭代的甘特图设计过程
以下为演示情景，用于说明从拆解到更新的完整过程，不代表真实项目数据。
某团队计划完成一次两周迭代，交付物是一个登录功能改版。拆解后得到任务清单：需求确认2天、设计稿3天、前端开发4天、后端接口开发3天、联调2天、测试2天。依赖关系为：需求确认完成后开始设计与接口开发；设计稿完成后开始前端开发；前端开发与接口开发都完成后开始联调；联调完成后开始测试。按此排布，关键路径为需求确认→设计稿→前端开发→联调→测试，合计13个工作日，接近两周迭代周期，前端开发和联调是需要重点监控的环节。
第一次周更新时，前端开发实际进度落后1天，原因是设计稿返工。项目经理在图上更新实际进度和剩余工期，识别出联调的开始时间将被推迟，测试时间被压缩。纠偏动作是：把测试中的部分用例提前到联调阶段并行执行，同时请设计负责人确认返工范围，避免二次返工。更新记录中写明偏差、影响、动作和复核时间。第二次更新时核对，联调按调整后的时间开始，测试未再延期。
这个示例说明，甘特图的价值体现在更新环节：偏差被发现得越早，可调整的空间越大；关键路径上的任务需要优先获得资源和关注。
完成检查：甘特图是否可用于进度控制
设计完成后，用以下清单逐项核对。全部满足，甘特图才具备进度控制的基础。
- 范围说明已写明交付物边界和验收标准，团队已确认。
- 每个任务有明确负责人、工期估算和完成标准，工期符合约定的粒度上限。
- 任务清单覆盖全部交付物，没有明显漏项。
- 依赖关系已逐条确认并注明依据，并行与串行安排合理。
- 关键路径已识别并标注，关键路径上的任务有更密的跟踪安排。
- 里程碑有判定标准，数量适中。
- 基线已保存，计划变更以新版本记录并保留原因。
- 更新频率、更新内容和更新责任人已明确，并已通知到人。
- 偏差识别与纠偏动作有记录模板，上次更新中的动作已复核。
- 甘特图与实际任务状态保持同步，图上的信息可以直接用于例会判断。
如果其中某项缺失，优先补齐影响进度判断的项：任务粒度、依赖完整性和基线。这三项决定甘特图能否反映真实进度，其余项可以随项目推进逐步完善。
常见问题
任务拆到多细才算合适？拆得太细会有什么问题？
常用判断标准是：一个任务能由一名负责人估算工期，完成后有可检查的产出，工期大致落在半天到两周之间。拆得太细会让更新成本明显上升，每周例会前要逐条核对大量小任务，反而拖慢进度判断；拆得太粗则无法从完成状态看出真实进展。可以在准备阶段写一条粒度约定，例如“任务工期不超过10个工作日，超过则继续拆分”，拆解时直接套用。
关键路径在项目进行中会变化吗？多久重新计算一次？
会变化。非关键路径上的任务如果延误到消耗完浮动时间，就会进入关键路径；依赖关系调整、范围变更或资源重新分配也可能改变最长路径。建议在每次周更新后重新检查一遍路径工期，重点看原关键路径任务是否延误、非关键路径任务是否已用尽浮动时间。不必每天重算，但计划发生较大调整时应立即复核。
基线保存后计划需要调整，应该直接改原图还是另存新版本？
建议另存新版本并记录变更原因。基线的作用是提供“原计划”的参照，直接覆盖原图后就无法区分计划调整和执行偏差，也无法回溯变更过程。ONES 支持设置项目计划和里程碑基线，对比计划与执行的偏差，并可通过对比版本细节追溯变更。实际操作中，把变更原因、影响范围和批准人写进变更记录，下次更新时对照新版本判断进度。
团队规模小、没有专职项目经理时，甘特图由谁维护？
可以由一人兼任多个角色，但职责要写清。常见做法是团队负责人维护整体结构、基线和偏差评审，各任务负责人更新自己任务的实际开始、完成日期和剩余工期。关键是更新时点和内容固定下来，例如每周例会前完成状态更新，例会上只讨论偏差和纠偏动作。角色合并后仍要保留评审环节，至少由技术或业务负责人确认任务完整性和依赖合理性。
甘特图和每周例会怎么配合，才能避免图变成摆设？
把更新动作绑定到例会节奏：会前任务负责人更新实际进度和剩余工期，会上项目经理对照基线讲偏差、影响范围和拟采取的动作，会后记录责任人与复核时间。下次例会先核对上次动作是否生效。这样甘特图承担的是进度判断依据的角色，例会讨论的是偏差和调整，而不是逐条念任务状态。工具上，任务状态和日期更新能直接反映到甘特视图，可以减少单独维护一张图的工作。
