如何利用 ONES 甘特图制定和追踪项目进度计划？

一、瀑布开发生命周期

1、瀑布模型的定义

我们先来回顾一下瀑布模型的一些定义：

瀑布模型是将软件项目划分为不同阶段，从一个阶段流动到下一阶段，每个阶段输出一个或多个评审通过的文档，后续阶段在上一阶段结束前不应该开始，每一个阶段的输出是下一个阶段工作的输入，典型的计划驱动软件过程。

2、在什么情况下适合用瀑布开发模型呢？

项目或产品的目标不变。比如项目一开始就敲定好了需求和项目范围，而且需求也基本不会变化，还有固定交付日期。那用瀑布模型再合适不过。
工作过程不需要检视和调整。在小阶段完成后，不需要检查和决策，因为项目一开始的目标就固定好了。
在质量需求高于成本需求和进度需求的时候。如果没有完善的质量建设机制，还是瀑布模型更能保证质量要求。
当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。

3、瀑布模型的优缺点都具体是什么呢？

缺点

开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险
通过过多的强制完成日期和里程碑来跟踪各个项目阶段
不适应用户需求的变化
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量

优点

纯瀑布模型能够降低管理费用,因为你可以预先完成所有计划
更好地达到质量预期
当前一阶段完成后，只需要去关注后续阶段
为项目提供了按阶段划分的检查点

二、WBS拆分的原则

1、基本分解原则

100%划分原则

也就是说我们需要把项目涉及到的所有工作，包括项目管理工作，都用 WBS 进行分解。

一定不能出现 WBS 分解完成之后，发现有些项目工作没有在 WBS 中体现出来的情况。因为我们整个项目的范围是按照 WBS 分解后的要素来界定的。

如果有某一部分工作没在其中体现出来，相当于这部分工作在项目范围之外了。这说明项目的 WBS 分解本身是有问题的。

百分百原则还有一个体现呢就是每一个父层级要完成，需要刚好完成它的子层级的所有工作，不能多也不能少。也就是百分百原则既要包含所有的工作，同时工作还需要属于正确的位置。

每项工作由一个人负责

工作包和任务很重要的意义就是要找到一个合适的人，把这部分工作承担起来。ONES 工作项，有且只有一个负责人。

要素不能只有一个

第三个基本原则是，要素不能只有一个。每一层分解出来的要素不能只有一个。既然我们把它叫做分解，那在分解时一定是一个变两个、三个、四个甚至更多。

描述合格的、可交付成果的状态

我们要在 WBS 工作结构分解中，描述合格的、可交付成果的状态，尤其是工作包的状态。

也就是说，当我们分解到工作包的时候，需要对工作包有相应的描述，讲清楚工作包是由哪些内容组成的，它的验收标准是什么，质量标准是什么，否则的话工作包就成了一堆毫无意义的代号。这些信息可以在 ONES 工作项的详情区域利用描述、属性字段等信息定义清楚。

项目经理负责、项目成员参与WBS的制定过程

项目经理对 WBS 有最终解释权，但在制定计划的过程中，需要项目成员参与，避免遗漏工作或者资源冲突。

2、最佳实践原则

当然，在做 WBS 分解时，除了以上这些必须要遵守的基本原则之外，还有最佳实践原则也很重要。最佳实践是经过多次项目实战总结出来的一些比较好的方式，那么在 WBS 分解中常见的最佳实践有哪些呢？

第一层比较重要

一般来说，在做 WBS 分解的时候，我们会认为第一层是比较重要的，如果第一层分解的维度没有选好的话，后面的分解都会非常混乱。

通常从两个维度进行第一层的分解是比较好的：「基于可交付成果」和「基于工作过程」。

「基于可交付成果」就是根据项目最后要交付的产品先做第一层的分解，然后逐层往下分解；「基于工作过程」就是按照阶段划分进行分解，比如说开发、测试、上线等都属于根据项目不同阶段的状态进行的分解。分解方式我下面会再展开一下给大家介绍。

重点描述可交付成果

第二个最佳实践就是，在描述 WBS 分解出来的不同要素的时候，要重点描述可交付成果而不是行为动作。

关于产出你可以这样理解，WBS 分解出来的每个要素最好是像「软件、硬件、说明书」这样的可交付成果，而不是一个动作。

有很多项目经理在做 WBS 分解的时候，会分解出来大量的动作，比如分析需求、开发功能等，结果去检查 WBS 的时候，会发现所有的动作都有，却把很多的可交付成果落下了。

而我们做项目最终需要的是可交付成果，动作只是完成可交付成果的过程，这不是我们所需要的。

每层的要素分解不超过9个

第三个最佳实践原则是，WBS 每层的要素分解一般不超过9个，否则就会难以控制，最好是分解到3-7个，这样可以保证分解清晰又便于管理。

指定一个负责人

第四个最佳实践原则，就是每个分解出来的要素，只能指定一个负责人，不能出现好几个人同时负责一件事的情况。

一件事情有好几个人在做，那就跟没人负责一样，因为一旦项目出现问题，可能这几个人就会互相推卸责任。而如果只有一个人在负责这件事，那么出现问题直接找这个人就可以了。

如果一个工作确实需要几个人共同完成，那么可以由一个人来负责，其他几个人作为他的资源，这个人要对另外几个人的工作负责。

先把一层100%的分解

第五个最佳实践是，尽量先把一层100%的分解，然后再把某个要素的下一级别要素，进行更加细致的划分，这是贯彻百分百原则的好方法。

三、WBS 分解的方法有两种最常见

1、第一种基于可交付成果进行分解。

这种分解方法的上层一般以可交付成果为导向，下层一般为可交付成果的工作内容。例如，对购物软件开发项目工作进行分解，采用「基于可交付成果划分方法」。分解过程为：第一层将软件分解为不同的功能模块，如登录、搜索商品、购物车、支付等等；第二层以支付为例，将支付细分为微信支付、支付宝支付、信用卡支付等等；第三层对信用卡支付进一步分解，比如招行信用卡支付、建行信用卡支付等。