瀑布项目计划怎么做？用 ONES 完成 WBS、依赖关系与关键路径

很多瀑布项目都有一张完整的项目计划表：任务、负责人、开始时间、结束时间一应俱全，但执行起来仍然频繁延期。上游晚了几天会影响哪些任务？哪些工作真正决定最终交付日期？资源冲突后计划还能不能成立？这些问题往往说不清。要让计划真正可执行，关键是从范围出发做好 WBS 分解，再建立任务依赖、识别关键路径，并结合资源和计划基线持续校验进度。

要点速览：瀑布项目计划到底怎么做？

核心答案：瀑布项目计划可以按“范围基线 WBS 活动与工期 依赖关系 关键路径 资源校验 计划基线”的顺序制定。

其中，WBS 解决范围完整性，依赖关系解决任务先后逻辑，关键路径帮助项目经理找到真正决定项目工期的任务链。PMI 将 WBS 定义为面向可交付成果、对项目总范围进行层级分解的结构；WBS 本身并不等同于进度计划，后续还需要补充活动、工期和依赖关系。

落到系统中，以 ONES 研发管理平台为例，可以在项目计划中建立 WBS、设置里程碑和前后置依赖，再由系统识别关键路径；结合资源日历检查人员负载，并通过计划基线持续比较原计划与实际执行偏差。 ONES 当前瀑布项目管理方案也将 WBS、任务依赖、里程碑、计划基线和工时资源管理作为核心场景。一套完整的计划逻辑可以概括为：

一、很多瀑布计划为什么“有日期，却不可执行”？

原因在于：一张任务排期表只有时间信息，没有完整的任务逻辑，就很难承担项目控制作用。

瀑布项目常见的进度问题，并不是项目经理没有做计划。实际情况往往是：每个任务都有开始日期和结束日期，但任务之间没有依赖关系，里程碑没有明确交付要求，计划与真实资源也没有校验。

为了避免这种情况的发生，可以先检查自己的项目计划是否存在下面几种情况：

因此，制定计划时首先要解决计划结构，再处理日期。

二、从 WBS 到关键路径，一份瀑布计划可以这样做

一份可执行的瀑布项目计划，不是先给所有任务填上日期，而是按照范围 WBS 活动与工期 依赖关系 关键路径 资源 基线逐步建立计划逻辑。

第一步：先锁定交付范围，再拆 WBS

WBS 应覆盖项目完整范围，并逐层拆到可以估算、分配和跟踪的工作包。

PMI 将 WBS 定义为围绕项目交付成果、对项目总范围进行层级分解的结构。它首先回答“项目需要交付什么”，再为后续活动定义、排期和资源安排提供基础。

研发项目可以按照「项目目标 项目阶段 工作包 可执行任务」逐层展开。以一个智能硬件新品项目为例：

需求与方案：需求确认、系统方案评审

硬件开发：原理图设计、PCB 设计、样机制作

软件开发：固件设计、功能开发

集成验证：软硬件联调、系统测试

发布准备：验收、量产/发布准备

WBS 不需要追求“越细越专业”。判断是否已经拆到合适粒度，可以看三个问题：负责人是否明确？工期能否估算？完成标准能否判断？

三个问题都能回答，通常就已经达到可以进入排期的粒度。ONES 的瀑布研发管理方案也强调，WBS 的重点是让范围完整、责任清晰、时间可以估算，并支持从业务目标、阶段继续向子任务和执行项逐层分解。

第二步：把 WBS 转换成活动和工期

WBS 解决“要做什么”，进度计划还需要进一步明确每项工作的负责人、工期和完成条件。

进入排期前，建议至少给底层工作补齐四类信息：

负责人：谁对结果负责；

预计工期：完成工作需要多长时间；

开始条件：什么条件满足后才能启动；

完成标准：做到什么程度才算真正完成。

工期最好由实际承担工作的成员共同估算。项目经理可以协调整体节奏，但如果几十项专业任务的时间都由一个人直接填写，计划很容易在执行后快速失真。这一步先把工期估准，不必急着手工固定所有开始和结束日期。后面的任务依赖建立起来以后，很多日期本身就应该随着计划逻辑联动调整。

第三步：建立任务依赖，把清单连成执行网络

只有建立依赖关系，项目计划才能判断一个任务延期后会影响哪些后续工作。例如智能硬件项目中：

PCB 设计完成后，才能进入打样；

样机完成后，才能开始部分整机验证；

硬件和固件都达到条件后，才能进入软硬件联调。

这类关系决定了项目真正的执行顺序。

实际排计划时，一个常见误区是为了让甘特图看起来整齐，把任务机械地首尾相连。依赖关系描述的应该是真实的业务、技术或交付约束，而不是视觉上的先后顺序。

在 ONES 中，可以为任务设置工期、计划开始和结束时间以及前后置关系，并根据依赖变化调整排期。

第四步：识别关键路径，找到真正影响交付日期的任务

关键路径是一组连续的关键活动，它决定当前计划条件下项目能够完成的最短周期。

PMI 对关键路径的解释是：关键活动通常没有可用总时差，关键路径上的活动一旦延期，就会影响项目完成日期。例如一个简化项目：

可以得到两条主要路径：

A B D F G：17 天

A C E F G：18 天

第二条路径持续时间更长，因此在这个简化计划中，它决定了项目最早完成时间。

关键路径的价值也正在这里。一个项目可能有上百项任务，项目经理没有必要用同样的精力逐项跟踪。更值得重点关注的是：当前关键路径上的任务，以及正在持续消耗时差、可能转变为关键任务的工作。

ONES 在任务工期和前后置依赖建立后，可以识别并突出显示决定项目总周期的关键任务链。

第五步：检查资源，确认计划实际上做不做得到

逻辑上排得通，不代表资源上一定做得到。

例如两个任务可以并行，但实际负责人是同一位硬件工程师；或者测试团队同时支持三个项目，计划中的测试窗口实际上没有可用人力。这类问题不会直接体现在任务依赖里，却同样会让计划失效。因此，初步排期完成后还要重点检查：

关键任务负责人是否存在时间冲突；

同一时间段是否有人明显超负荷；

稀缺岗位是否同时被多个项目占用；

外部供应商、评审和节假日是否已经计入计划。

ONES 的资源日历可以查看成员在不同项目和任务上的排期及工时占用，帮助项目经理识别超负荷、空闲时段和跨项目资源冲突。实际操作可以概括为三步：先完成 WBS 和初排期，再检查资源可用性，发现冲突后调整负责人、时间或项目优先级。

第六步：设置里程碑，形成正式计划基线

计划经过团队和相关负责人确认后，需要把关键节点和批准版本固定下来，后续才能判断项目究竟偏离了多少。

里程碑适合对应明确的阶段成果，例如：

需求基线批准；

系统方案评审通过；

样机验证完成；

系统测试完成；

发布审批通过。

相比单纯写一个日期，更重要的是明确这个节点需要什么交付成果、满足什么条件才能通过。

正式计划批准后，还应建立计划基线。后续即使任务日期发生调整，也保留原来的批准版本，用于比较“原计划”和“当前计划”。否则项目经理每周都在修改甘特图，几个月以后只能看到现在准备什么时候完成，却很难回答：原本计划什么时候完成？从哪个节点开始偏离？哪些任务发生过调整？

ONES 的项目过程跟踪可以结合任务状态、完成比例、临期/逾期、工时和交付情况持续更新计划，并通过计划基线比较不同时点的范围和日期变化。

做到这里，一张项目计划才从静态任务表变成了真正可以跟踪的进度网络：WBS 保证范围完整，任务依赖建立执行逻辑，关键路径指出进度重点，资源校验保证计划可执行，计划基线则为后续偏差分析提供参照。

三、用 ONES 把 WBS、依赖和关键路径落到同一套计划里

在 ONES 中，可以按照“创建 WBS 设置任务排期和依赖 识别关键路径 校验资源 固化基线 持续跟踪偏差”的顺序管理瀑布项目计划。

1. 用项目计划建立 WBS

项目经理可以先定义企业常用的 WBS 分解方式，再按照项目目标、阶段、工作包和执行任务向下拆解，并把关键节点标记为里程碑。上传的方案明确给出了 WBS 层级展示、里程碑标记以及层级间进度联动等能力。

如果企业有大量同类型项目，还可以把成熟结构沉淀成模板，减少每个新项目重新搭建计划的工作量。

2. 设置工期和前后置依赖，识别关键路径

WBS 完成以后，为任务维护工期、起止日期和前后置依赖。依赖建立后，系统可以根据任务网络识别关键路径，把决定项目总周期的关键任务链突出显示。ONES 官方项目计划资料也显示，其项目计划支持 WBS、里程碑和前后置关系，并可以通过计划基线比较执行偏差。

这里有一个重要原则：工具可以计算关键路径，但任务之间究竟存在什么业务依赖，仍然需要项目经理和专业团队判断。

3. 用资源日历修正排期

初步关键路径形成后，再检查关键人员的工时占用和资源饱和度。如果关键任务负责人在同一时间段已经满负荷，就应该在计划批准前调整，而不是等执行阶段再靠加班解决。

4. 建立计划基线，跟踪真实偏差

项目计划批准后设置基线。执行过程中，任务状态、完成比例、工时、交付物和计划日期持续更新；管理者可以将当前计划和原基线比较，识别新增任务、日期变化和范围调整。

这使项目周会讨论从“大家感觉还能不能按时完成”，转向更具体的问题：关键路径有没有变化？哪一个节点开始出现偏差？偏差会不会传到最终里程碑？

四、计划发布前，可以用这张清单做一次检查

一份瀑布项目计划进入正式执行前，建议至少确认下面 10 项：

项目范围已经确认，并有明确交付版本

WBS 覆盖全部已批准范围

最底层工作可以明确责任人

关键任务已经完成工期估算

真正存在先后约束的任务已经建立依赖

关键里程碑有明确交付物或评审标准

已计算并检查关键路径

已检查关键人员和稀缺资源负载

项目团队已经共同评审计划

正式批准后已经建立计划基线

如果其中三四项仍然无法回答，建议先完善计划，再正式承诺交付日期。

项目执行以后，这张清单还可以进一步变成固定的周度检查机制：检查关键路径、即将进入关键路径的任务、资源冲突、下一里程碑和基线偏差。这样管理者关注的是项目真正可能影响交付的变化，而不是机械地逐条检查几百个任务。

五、做好瀑布项目计划的关键

一份有效的瀑布项目计划，最终应该能够回答几个非常具体的问题：

项目究竟要交付什么？为了交付需要完成哪些工作？这些工作按照什么顺序发生？哪几项任务决定最终日期？资源能否支持这个日期？计划改变以后，偏差从哪里开始？

WBS 让项目范围变得完整，依赖关系把分散任务连接成执行网络，关键路径让项目经理找到进度管理重点，资源校验提高排期的现实可行性，基线则让后续偏差有据可查。

当这些信息持续与真实任务进展联动，甘特图才真正成为项目控制工具。ONES 的作用也在这里：把 WBS、任务、依赖、关键路径、里程碑、资源和基线放到一套持续更新的项目数据中，让原本依靠项目经理人工维护的计划逐步形成可跟踪、可比较的管理闭环。

FAQ：瀑布项目计划常见问题

1. WBS 应该拆到多细？

拆到可以可靠估算、明确负责人和判断完成即可。复杂、高风险工作可以继续分解；简单、短周期工作没有必要为了层级而继续拆分。重点是范围完整和可管理，而不是任务数量越多越好。

2. WBS 和甘特图有什么区别？

WBS 描述项目为了完成目标需要包含哪些工作，重点是范围结构；甘特图进一步加入工期、时间和任务关系，重点是进度安排。通常先建立 WBS，再逐步形成进度计划。

3. 关键路径是不是“最重要的几个任务”？

不是同一个概念。关键路径关注的是时间逻辑：在当前计划条件下，决定项目总工期的一串连续活动。一个商业价值很高的任务未必位于关键路径，而一个看起来普通的集成任务可能恰恰决定交付日期。

4. 关键路径确定以后会一直不变吗？

不会。实际工期、任务依赖、范围和资源发生变化后，任务时差可能随之改变，关键路径也可能转移。因此关键路径需要随着项目实际数据持续重新检查，而不是在项目启动时计算一次就结束。

5. ONES 能自动算关键路径吗？

可以。在任务工期和前后置依赖已经设置的前提下，ONES 的瀑布项目计划支持识别并突出显示决定项目总周期的关键任务链。 但依赖关系是否符合真实业务、工期估算是否合理，仍然需要项目经理和团队确认。

6. AI 可以直接帮项目经理生成完整项目计划吗？

AI 更适合生成计划初稿。ONES 的瀑布项目管理方案显示，ONES 的 AI 助手可以读取项目背景、需求范围或阶段目标，辅助进行分层拆解、生成里程碑和阶段任务。最终的负责人、工期、依赖和交付承诺仍需要人工评审确认。 对复杂瀑布项目来说，这种方式可以减少初始整理工作，但不能替代专业判断。