WBS任务分解指南

变更记录
目录
1.目的 (4)
2.任务分解定义 (4)
3.任务分解的类型 (5)
3.1.清单类型 (5)
3.2.图表类型 (6)
4.任务分解的过程 (7)
4.1.基本步骤 (8)
4.2.分解的标准 (9)
4.3.分解结果的检验 (9)
5.任务分解的注意事项 (10)
6.任务分解的意义 (11)
1.目的
项目管理者经常会面临项目失控的一些问题，例如进度严重落后、资源不足、资金紧缺等。

项目失控和超出控制范围的问题，常常使项目经理处于被动。

因此。

采取积极的应对措施，做好计划和控制好计划是项目成功的必要条件，但不是充分条件。

如果没有计划和控制是很难获得项目的成功的。

2.任务分解定义
当要解决的问题过于复杂时，可以将问题分解，直到分解后的子问题容易解决；
然后分别解决这些子问题。

规划项目时，也应该从任务分解开始，将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。

目的是提高估算成本、时间和资源的准确性，使工作变得更易操作，责任分工更加明确。

任务分解是对需求的进一步细化，是最后确定项目所有任务范围的过程。

任务分解的结果是任务分解结构（WBS）。

任务分解结构（WBS）是面向可交付成果的对项目元素的分组，它组织并定义了整个项目的范围。

不包括在WBS工作就不是该项目的工作。

任务分解结构（WBS）是一个分级的树型结构，是对项目由粗到细的分解过程。

任务分解结构每细分一个层次表示对项目元素更细致的描述。

其中，任务分解结构的工作包是WBS的最低层次的可交付成果，项目完成时，应该完成这些交付成果，这些交付成果也可以分配给另外一位项目经理进行计划和执行，也可以通过子项目的方式完成，这时工作包可进一步分解为子项目的WBS或各个活动，这种工作包应当由唯一一个部门（组织或者个人）或承包商负责。

任务分解是项目评估的前提和自下而上评估算法的基础。

例如对于软件项目A进行任务分解的过程如下图所示。

一般说，进行任务分解时，可以采用清单或者图表的形式表达任务分解的结果。

3.1.清单类型
采用清单类型的任务分解方式，就是将任务分解的结果以清单的表述形式进行层层分解的方式。

现在以一个项目为例进行说明，这个项目的名字定义为“变化计数器”，它是统计程序大小的软件工具，当修改一个程序的时候，这个工具可以统计各个版本之间有多少代码行被增加、删除或修改。

这个项目的任务分解可以按照不同的标准进行分解，采用清单方式进行任务分解如下：
1. 变化计数器
. 比较两个版本的程序
1.1.1. 预处理
1.1.
2. 文件比较
1.1.3. 结果处理
. 找出修改后的程序中增加和删除的代码行
1.2.1. 找出增加的代码行
1.2.2. 找出删除的代码行
. 统计修改后的程序中增加和删除的代码行数
1.3.1. 统计增加的代码行
1.3.
2. 统计删除的代码行
. 统计总的代码行数
. 设定标记以指示修改的次数
. 在程序的头部增加修改记录
3.2.图表类型
采用图表类型的任务分解过程就是进行任务分解时采用图表的形式进行层层分解的方式。

例如，对于上面的“变化计数器”这个项目，采用图表类型的分解结果如图2所示。

4.任务分解的过程
进行任务分解应该采取一定的步骤，并且分解过程中保持唯一的分解标准。

任务分解的基本过程如图2所示。

图2 任务分解的基本过程
任务分解应该根据需求分析的结果和项目相关的要求，同时参照以往的项目分解结果进行。

最终任务分解的结果是WBS。

在分解过程中可以参照分解模板，进行
一步一步详细的分解。

虽然每个项目是唯一的，但是WBS经常能被“重复使用”，有些项目在某种程度上是具有相似性的。

例如从每个阶段看，许多项目具有相同或相似的周期和因此而形成的相同或相似的工作细目要求。

许多应用领域都有标准或半标准的可以当作样板用的WBS。

例如，图3中是有些软件企业进行项目分解的WBS模板，当然，本图仅作为参照示例，不代表任何特定项目的具体分解标准，而且也不是唯一的参照模板。

图3 一个WBS模板
4.1.基本步骤
分解意味着分割主要工作细目，使它们变成更小、更易操作的要素，直到工作
细目被明确详细的界定，以有助于未来项目的具体活动（规划、评估、控制和选择）的开展，一般说，进行任务分解的基本步骤是：
（1）确认并分解项目的主要组成要素。

通常，项目的主要要素是这个项目的工作细组。

项目目标作为第一级的最整体的要素。

项目的组成要素应该是有形的、
可证实的结果来描述，目的是为了绩效易检测。

当我们知道了主要构成要素
后，这些要素就应该用项目工作怎样开展，在实际中怎样完成的形式来定义。

有形的、可证实的结果既包括服务，也包括产品。

（2）确定分解标准，按照项目管理的方法分解，可以参照任何分解结构(WBS)模板进行任务分解，而且分解的时候标准要统一。

分解要素是根据项目的实际管
理二定义的。

不同的要素有不同的分解层次。

例如，项目生存期的阶段可以
当作第一层次的划分，把第一层次中的项目细目在第二个阶段继续进行划分。

（3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。

工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没
有了确定性。

（4）确定项目交付成果，交付成果是有衡量标准的，以此检查交付结果。

（5）验证分解正确性，验证分解正确后，建立一套标号系统。

4.2.分解的标准
进行任务分解的标准应该统一，不能有双重标准。

选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱，导致任务的重叠。

可以采用生存期为标准；或者以功能（产品）组成为标准；或者以项目的组织单位为标准，或者采用其他的方法。

4.3.分解结果的检验
任务分解后，核实分解的正确性：
更低层次的细目是否必要和充分如果不必要或者不充分，这个组成要素就必须
重新修正（增加细目、减少细目或修改细目）。

最底层要素是否有重复如果存在重复现象就应该重新分解。

每个细目都有明确的、完整的定义吗如果不是，这种描述需修正或扩充。

是否每个细目可以进行适当的估算谁能担负起满意地完成这个项目的任务如
果没有，修正是有必要的，目的是提供一个充分的管理控制。

成功完成的任务分解结构（WBS）是对项目总范围的组织和界定。

作为范围阐述，这个WBS通常是用来开发或巩固一个达成共识的项目范围。

项目的划分每降低一个层次阐述，就要增加一个项目要素的详细描述。

任务分解结构（WBS）可以与组织分解结构（OBS）综合使用，建立一个任务职责的对应关系。

5.任务分解的注意事项
进行任务分解时应注意如下事项：
任务分解的规模和数量因项目而异。

注意收集与项目相关的所有信息
注意参看类似项目的任务分解结果，与相关人员讨论。

可以参照模板进行分解。

先分大块任务，然后再细分小的任务，最底层是可控的和可管理的，避免不必
要的过细，最好不要超过7层。

按照软件项目的平均规模来说，推荐任务分解时至少拆分到一周的工作量（40
小时）。

每个工作包至少有一个提交物。

定义任务完成的标准。

任务分解结果必须有利于责任分配。

可以准备WBS的字典。

最后与相关人员进行评审。

根据情况，任务分解中可以包括诸如管理、质量等任务的分解。

当然也可以在后续的活动分解的时候，分解出相应的管理、质量等活动。

WBS中的每一个具体细目通常都指定唯一的代码，具体工作要素的阐述通常收集在WBS字典中。

一个典型的项目分析字典，既包括了对工作包的阐述，也包括了对其他规划资料（如进度表的日期、成本预算和员工分配等问题）的阐述。

例如，如表1便是一个WBS字典的例子。

表1 WBS的字典实例
6.任务分解的意义
任务分解结构（WBS）提供了项目范围基线，是范围变更的重要输入，而且有了任务分解，项目经理可以集中注意力到项目的目标上，不必为细枝末节伤脑筋。

同时，任务分解结构给开发项目提供了一个实施框架，其中明确了责任，为评估和分配任务提供具体的工作包，是进行估算和编制项目进度的基础，对整个项目成功的集成和控制起到非常重要的作用。