排期靠感觉，进度跟踪靠开会，延期后说不清延误出在哪个环节，这是不少项目管理者会遇到的局面。本篇文章将跟随一个企业服务小程序的功能版本上线案例，从零做一遍项目进度计划。主线会用三个工具：甘特图负责排期可视化，里程碑负责关键节点把控，关键路径负责总工期判断，三者合起来构成项目进度管理的基本闭环。
按什么顺序做项目进度管理
用一个案例串起三个工具
案例背景是企业服务小程序的功能版本上线，涉及需求确认、界面设计、前端开发、后端开发、联调测试、上线发布六个环节。干系人包括产品经理、设计师、前端开发、后端开发、测试、运营。为了便于演示，后文统一使用一套示意工期数据，以工作日计算。任务拆解、依赖关系确定后，这套数据会直接落进甘特图和关键路径计算。
项目进度计划怎么编排
项目进度计划怎么编排？建议按五步走：拆任务 → 估工期、理依赖 → 画甘特图 → 设里程碑 → 找关键路径。这个顺序不能乱。拆任务产出任务清单，估工期和理依赖产出排期数据，画甘特图把排期落到时间轴，设里程碑标出阶段检查点，最后找关键路径判断总工期。每步的输出是下一步的输入，前两步数据不完整，后面画图、判定都会失真。
先把项目拆成可执行的任务
任务拆到什么程度算合格
拆任务，先要回答"拆到什么程度算合格"。判断标准有三条：能指派给具体人，能在一周左右完成，有明确交付成果。比如"完成登录页初稿"比"做界面"更合格，前者有负责人、有时长边界、有可提交的产出，后者只是一句含糊指示。
拆太粗，排期只能靠拍脑袋；拆太细，管理成本反超收益。把任务拆到团队成员能直接执行的粒度，通常就够了。
梳理任务依赖关系
任务拆完，下一步梳理依赖关系。甘特图中任务之间有四种标准依赖类型：
- 完成-开始（FS）：前置任务完成后，后续任务才能开始。最常见的一种，比如界面设计做完，前端开发才能动手。
- 开始-开始（SS）：前置任务启动后，后续任务即可同步开始。比如界面设计启动后，前端和后端就能并行推进，不用等设计稿全部交付。
- 完成-完成（FF）：前置任务完成后，后续任务才能完成。比如联调测试结束，上线发布才算正式收尾。
- 开始-完成（SF）：前置任务开始后，后续任务才能完成。比较少见，通常用于交接场景，比如新系统上线后旧系统才能关闭。
回到案例，依赖链是：需求确认 → 界面设计 → 前端开发、后端开发（SS，并行推进）→ 联调测试 → 上线发布。其中前端和后端在界面设计启动后即可并行开始，属于开始-开始关系；其余环节均为完成-开始关系。这一步不打磨，甘特图和关键路径都会失真，因为时间轴怎么排、哪条路径决定总工期，都建立在依赖关系之上。
甘特图怎么做：排期、画图、连依赖
先估工期再填时间
甘特图怎么做？先从估工期开始。常见估算方式有三种：按人天估算，算清一个任务需要几个人做几天；参考同类任务的历史数据，比如上一次联调测试用了 5 天，这次沿用；关键任务预留缓冲，把接口变动、返工等不确定因素算进去。
案例示意排期如下表，后续画图和关键路径计算都用这组数据。
| 任务 | 前置任务 | 计划工期 |
|---|---|---|
| 需求确认 | 无 | 5 个工作日 |
| 界面设计 | 需求确认 | 8 个工作日 |
| 前端开发 | 界面设计 | 10 个工作日 |
| 后端开发 | 界面设计 | 12 个工作日 |
| 联调测试 | 前端开发、后端开发 | 5 个工作日 |
| 上线发布 | 联调测试 | 2 个工作日 |
这组数据中，需注意前端开发和后端开发与界面设计之间是 SS（开始-开始）关系------界面设计启动后两者即可并行推进，不需要等设计全部完成。后端开发耗时最长，联调测试和上线发布串在它之后，实际排期要从需求确认一直通到上线发布。
制作甘特图
工期估完，进入制作。三步完成：先按任务顺序在纵轴列出所有任务，横轴按工作日展开时间线；接着用箭头标出依赖关系，并行任务在纵轴上并排对齐；最后填入每条任务的起止日期，生成条形的任务横道。
制作甘特图不一定需要专业软件。团队日常用 Excel 的话，拉一张堆积条形图就能把排期可视化，任务量不大的项目完全够用。如果项目已经在禅道或类似工具里管理，直接开启甘特图视图会更顺手------任务拆解、分配、排期都在同一个地方，调整时间后图表自动更新，省去手动维护的麻烦。无论用哪种方式，甘特图的使用价值都是让人一眼看出排期冲突和进度偏差，这是项目进度管理中可视化程度最高的一环。
在甘特图中落地依赖关系
四种依赖类型落到甘特图上的表现不同。
FS 最常见：前置任务的横道结束后，后续任务横道紧接起点，两条横道首尾相连，形成串行链路。案例中需求确认 → 界面设计 → 联调测试 → 上线发布都属于这一类。
SS 是两条横道起点对齐或错开一个滞后量。案例中界面设计横道一开始，前端和后端的横道即可同步起画，在图上表现为三条横道起点接近、并排推进。
FF 是两条横道终点对齐。比如联调测试横道收尾时，上线发布横道也同步结束------不过案例中上线发布的前置是联调测试完成（FS），这里仅作说明。
SF 少见，表现为新任务横道开始后，旧任务横道随即结束。
把依赖关系画清楚，甘特图就不只是时间条堆叠，而是一张能反映任务间真实协作节奏的排期图。
项目里程碑怎么设置
里程碑不是任务
项目里程碑怎么设置？先分清里程碑和任务的差异。里程碑没有工期、不消耗工时，它是项目中的可验证时间点。任务问"做完了吗"，里程碑问"可以进入下一阶段吗"。比如"界面设计完成初稿"是任务，"设计评审通过"才是里程碑。
案例里的四个里程碑
案例可以设四个里程碑：需求确认通过、设计评审通过、测试验收通过、上线发布完成。每个里程碑都要有可验证的达成标准。
- 需求确认通过：需求清单、优先级和验收标准经产品与客户确认。
- 设计评审通过：界面交互稿通过评审，开发可据此进入编码。
- 测试验收通过：核心功能用例全部执行通过，无阻断级缺陷。
- 上线发布完成：版本发布至生产环境，运营完成公告与回滚预案确认。
这四个里程碑基本落在阶段转换处，每过一个节点，项目就获得一次"可以继续往下走"的放行判断。设置密度也有讲究：设太密，里程碑会变成检查清单；设太疏，团队失去把控节奏的抓手。三个到六个是常见区间。
关键路径怎么找
手动推算法
关键路径怎么找？先看手动推算法，分三步：列出所有任务链路径，累加每条路径的总时长，最长的那条就是关键路径。
回到案例，依赖关系只生成两条完整路径。
路径一：需求确认 5 天 + 界面设计 8 天 + 前端开发 10 天 + 联调测试 5 天 + 上线发布 2 天 = 30 个工作日。
路径二：需求确认 5 天 + 界面设计 8 天 + 后端开发 12 天 + 联调测试 5 天 + 上线发布 2 天 = 32 个工作日。
路径二较长，因此它是关键路径。关键路径决定项目最短总工期，路径上任何任务延误都会直接推后交付。
工具辅助法
任务量大的项目可以借助工具。日常用禅道的团队，项目看板里直接支持关键路径标识，不需要额外切工具。Microsoft Project 在甘特图视图中勾选"关键任务"一样能高亮关键路径。任务一多、依赖链一长，工具自动标识比手动推更方便。
关键路径不是固定的。排期或任务变更后需要重算。某项非关键任务延误超过浮动时间，也可能反超为新的关键路径。
项目延期怎么处理：监控与纠偏
先判断延误是否落在关键路径上
项目延期怎么处理？先判断延误是否落在关键路径上。
关键路径延误一天，总工期推后一天。非关键路径延误可以由浮动时间吸收，不立即影响交付。回到案例，联调测试计划 5 天、实际用了 7 天，它位于关键路径上，总工期从 32 个工作日变为 34 个工作日。如果延误发生在非关键路径，比如前端开发比计划多 1 天，只要不超过 2 天浮动时间，总工期仍保持不变。
常用的纠偏手段
延误无法消化时，常用的纠偏手段有三种。
赶工：增加资源或加班。适用于可拆分、可并行的任务，比如联调测试增加一名测试人员，缩短执行周期。
快速跟进：后置任务提前启动。适用于风险可控的环节，比如后端最后两个接口尚未完成时，测试先准备用例和数据。
调整资源：从非关键路径任务调人支援关键路径。比如前端开发提前结束，后端开发资源不足时，让前端临时顶上一段。
每次纠偏后要做两件事：更新计划基线，重新计算关键路径。基线用于对比后续偏差，关键路径重算用于确认纠偏是否真正缩短了总工期。
新手做进度计划的四个常见误区
排期新手在项目进度管理上容易犯四类错误。
任务拆太粗，工期估算没有依据。丢给开发一句"做功能"，却不拆分模块，估出来的数字没有基础。
没理依赖关系就直接填时间。先填好日期，画甘特图时才发现某个任务必须等另一个任务完成，被迫整段重排。
里程碑设成例行会议时间点，没有可验证的成果标准。"每周例会"不是里程碑，例会结束不代表阶段成果达成。
只盯关键路径，忽略非关键任务，结果非关键任务积压，反超为新的瓶颈。监控要覆盖全量任务，不能只看最长链。
三个工具在项目进度管理里怎么配合
甘特图、里程碑、关键路径不是三个孤立模块，它们构成日常监控循环。甘特图查进度偏差，看任务是否按计划推进；里程碑查阶段节奏，确认当前是否具备进入下阶段的资格；关键路径判总工期影响，判断偏差是否会推迟交付。
落实到每周固定动作，可以做三件事：比对计划与实际偏差，确认下个里程碑是否存在风险，重算关键路径是否发生变化。这套动作做完，基本能回答"项目当前处于什么状态、下一周哪里会卡"。
项目进度管理到这个阶段，就不再是排期靠感觉。甘特图、里程碑、关键路径各管一环，合起来构成从排期、监控到纠偏的闭环。
常见问题解答
甘特图适合小项目吗？
目标清晰、任务可拆、涉及多人协作，就值得用。单人三五天能做完的活，用清单即可。小项目任务少、依赖简单，强行画甘特图反而增加维护成本。
里程碑设置几个合适？
没有固定数量，按可验证的成果节点设，三个到六个是常见区间。过密会变成检查项，过疏失去把控节奏的作用。判断标准只有一个：每个节点是否有明确交付物和放行判断。
关键路径上的任务延期了怎么办？
关键路径上的任意任务延误，都会原样反映到总工期上。先看延误几天、距交付还有多少缓冲，再决定处理方式。轻微延误可接受就继续观察；影响较大就赶工、并行或从非关键路径调资源。改完计划要重算关键路径。
不会专业软件，能用 Excel 画甘特图吗？
可以。用堆积条形图能做出基础排期，适合任务少、依赖简单的场景。依赖关系复杂或多人协作时，换用禅道这类项目管理工具会更省事，任务变更和依赖关系都能自动联动，省去手动维护成本。
进度计划总被改动，正常吗？
正常。计划是基线不是枷锁，每次改动记录原因、评估对关键路径的影响，并同步给相关干系人。频繁改动本身是一条信息，说明前期估算或需求边界可能有问题。