3.2 制定项目进度计划
哪怕你有一个绝佳的想法、范围也界定得很清楚，没有时间线，项目还是动不起来。进度计划是时间的建筑图——它把"什么时候发生什么"框定下来，让执行成为可能。
制定进度计划远不止往日历里塞日期。它是一项高阶的规划工作，需要在任务顺序、工时估算、依赖关系和风险之间找到平衡。
为什么要做进度计划？
- 把工作流程可视化：让所有人共享对整体过程的同一种认知
- 分配现实的截止日期和归属：每个任务都需要一个时间框架和一个负责人
- 对齐节奏预期：团队和干系人对推进速度有共同的感知
这些做到位之后，跟踪进度和应对延期会变得容易和高效得多。
制定项目进度计划的步骤
1. 识别任务（基于 WBS）
从范围界定阶段产出的工作分解结构开始，把所有任务列出来。这能确保覆盖完整，也能理顺任务顺序。
2. 定义任务顺序和依赖关系
每个任务都有自己的逻辑顺序。"设计"在"需求"敲定之前没法开始。把这些关系梳理清楚，能避免排期冲突和意外。
3. 估算工时
估算每个任务要多久。这一步最容易出错——也常常是延期的根源。常见的估算方法：
- 类比估算：基于过往类似项目
- 参数估算：单位时间 × 数量（比如 1 小时/页 × 20 页）
- 三点估算：乐观值、悲观值和最可能值的加权平均
留出缓冲——单靠乐观主义保护不了你。
4. 把进度可视化（比如用甘特图）
任务、工期、依赖关系都梳理好之后，用甘特图把计划可视化。这能让你看清开始/结束日期、并行的工作，以及关键路径——也就是决定整个项目时长的那条任务链。
5. 设置里程碑
识别关键检查点——评审、审批、阶段性交付。里程碑既能让干系人对进展有把握，也能为汇报赋予结构。
怎么做出一份现实的进度计划
- 预留缓冲：给意外留点空间
- 考虑非工作日：周末、节假日、休假
- 用并行：能并行的任务就并行，缩短总工期
- 立足现实：基于团队真实节奏，而不是理想速度
不要追求"完美"的进度计划——追求一份能适应变化的计划。
常见的坑
- 过分乐观的估算：只往好处想，不为意外做准备
- 遗漏依赖关系：一个延期级联引发后面一连串延期
- 静态规划：计划做完就再没人更新或使用
怎么让进度计划"活"起来
计划做完并不等于"完成"。它要被每天用起来，才算真正发挥作用——用于监控和决策。
每周更新它，跟踪每个任务的状态（完成/延期/进行中），把它当作团队节奏和对外汇报的"事实之源"。
结语：设计时间，就是设计未来
制定进度计划，是在今天塑造未来的时间。它的本质是用细致的规划和前瞻性，把不确定变成结构。
没有任何项目会完全按原计划走。这正是为什么一份兼具灵活和前瞻的进度计划，是高效项目团队的基础。
在 AB 中是这样的
在 AB Project Management 里，进度计划不是一份独立的文档——它是从任务本身长出来的。每个任务都有起始日期、截止日期和工时估算；子任务汇总到父任务，给出准确的进度；项目日历会按周显示工作扎堆的位置，让你在确认前就能看见瓶颈。里程碑作为 "Milestone" 类型的任务存在，没有工时估算但有固定的截止日期。进度计划自动保持鲜活：有人挪了截止日期，日历会同步反映；通过 MCP 接入的 AI 助手关闭了一个任务，进度百分比也会跟着变。你不需要在旁边再单独维护一张甘特图——项目状态本身就是进度计划。
→ 接下来：3.3 资源分配