WBS的概念分解策略、作用、用途、分解原则、分解方法及其他

1.引言

渐进明细是项目的特点，但这并不意味着不需要计划。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。在软件高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法，即根据总体阶段划分的总体WBS和专门针对系统设计或编码阶段的二次WBS。这其中部分的原因是需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在需求分析完成以后才能准确地得到系统设计或编码阶段的二次WBS，根据代码模块的合理划分而得出的二次WBS才能在系统设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。

2.基本概念 

WorkBreakdownStructure（WBS）工作分解结构：对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。WBS将项目的整个范围组织在一起并加以明确。每向下分解一个层次，就意味着项目工作的定义深入了一步。WBS最终分解为工作细目。WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。（2004年版PMBOK指南）

WorkPackage（工作细目，也翻译为工作任务包），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。（2004年版PMBOK指南）

ControlAcｃｏｕｎｔ（控制账目，CA），是综合范围、预算、实际费用和进度，并对绩效进行测量的管理控制点，控制账目设置在工作分解结构（在选定水平上的具体组成部分）的事先选定的管理点上。每一个控制账目都可以包含一个或多个的工作细目，但是每一个工作细目只可以在同一个控制账目相联系。（2004年版PMBOK指南）

3.对WBS的理解

从以上解释，我们得出如下结论，WBS是将项目加以定义，明确项目工作任务的。由此可见，WBS在项目管理的重要地位，所以“没有WBS，就没有项目管理”。

对于WBS定义的理解，我个人认为应在以下两方面重点加以理解：

第一方面，就是WBS的单元，即WBS层次结构的对象，它是以“Deliverables（可交付成果）”为分解导向，而不是以“ScheduleActivity（计划活动）”为分解导向。

WBS的最底层次为WorkPackage（工作细目），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。

为什么WBS的最底层次不是ScheduleActivity（计划活动）而是WorkPackage（工作细目）呢？

首先WBS是作为项目范围管理的工具、技术，项目范围管理关注点是项目的组成部分，它面向的是可交付成果，而不是过程。

其次WBS定义的是项目及其组成部分，是ScheduleActivity（计划活动）定义的依据，而不是去定义ScheduleActivity（计划活动）；

第三ScheduleActivity（计划活动）是项目进度表的单个组成部分，不是WBS的组成部分。对于这一点，很多人理解上可能有困难。因为，习惯说法是活动是由各项具体工作构成的，而上面的定义我们从字面上看的习惯说法与PMBOK的定义正好相反，但是从本质上去理解两者应该是相同的，只是说法不同。因为在项目管理尚未引进中国以前，我们把活动等同于项目。 

第二方面，就是WBS的结构，WBS的结构包含了科学的逻辑结构，而不是单个的、离散的、在时间顺序上不连续的成果的描述结构。

WBS的结构是由逻辑推演而成的，通过层层的包含关系，非常严谨。结构化是WBS的一大重要特性，WBS的逻辑结构错误会直接导致项目实施过程发生错误，严重的会带来项目的失败。

“做正确的事，正确地做事”是我们从事项目管理的一句格言，WBS首先解决的就是“做正确的事”问题，只有明确了“做正确的事”，“正确地做事”才有基础，所以我们说WBS是现代项目管理的重要基石。

4.WBS的主要用途 

WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。

WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。

WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。

WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。

5.WBS的作用 

防止遗漏项目的可交付成果。

帮助项目经理关注项目目标和澄清职责。

建立可视化的项目可交付成果，以便估算工作量和分配工作。

帮助改进时间、成本和资源估计的准确度。

帮助项目团队的建立和获得项目人员的承诺。

为绩效测量和项目控制定义一个基准。

辅助沟通清晰的工作责任。

为其他项目计划的制定建立框架。

帮助分析项目的最初风险。

6.WBS的主要分解原则 

一个单位工作任务只能在WBS中出现一次。

一个WBS项的工作内容是其对应下级各项工作之和。

WBS中的每一项都只有一个人负责，即使这项工作要多人来做，也是如此。

WBS必须与工作任务的实际执行过程一致。

WBS应服务于项目资源，项目成员必须参与WBS的制定过程，以确保一致性和全员参与。

每项WBS都必须归档，以确保准确理解项目包括和不包括的工作范围。

在根据范围说明书对项目的工作内容进行适当控制的同时，WBS必须具有一定的灵活性，以适应无法避免的变更需要。

工作包的定义应考虑80小时法则(80-HourRule)或两周法则(TwoWeekRule)，即任何工作包的完成时间应当不超过80小时。

WBS一般不超过5层，如超过即外包。

7.WBS的表示方式 

WBS可以由树形的层次结构图或者行首缩进的表格表示。

在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。

8.WBS分解方法 

类比法

类比法就是以一个类似项目的WBS为基础，制定本项目的工作分解结构。例如，ABC飞机制造公司，曾设计制造多种类型的大型客机，当他们计划投入设计生产某种新型战斗机时，就可以使用以往制造大型客机而设计的子系统。以从前的子系统为基础，开始新项目的WBS的编制。比如，该WBS的第一层中有飞机机身顶，该项又包括了飞机前身、飞机中部、飞机后身和机翼等第二层的多个子项。这种一般性的产品导向的WBS就成为新飞机项目的范围定义和新型战斗机成本估算等工作的起点。即参考类似项目的WBS创建新项目的WBS。

自上而下法

自上而下法常常被视为构建WBS的常规方法，即从项目最大的单位开始，逐步将它们分解成下一级的多个子项。这个过程就是要不断增加级数，细化工作任务。这种方法对项目经理来说，可以说是最佳方法，因为他们具备广泛的技术知识和对项目的整体视角。

自下而上法

自下而上法，是要让项目团队成员从一开始就尽可能的确定项目有关的各项具体任务，然后将各项具体任务进行整合，并归总到一个整体活动或WBS的上一级内容当中去。仍以ABC飞机制造公司设计制造新型战斗机为例，用这种方法，则不是开始就考察WBS制定的指导方针或是参考其他类似项目的WBS，而是尽可能详细的列出那些项目团队成员认为完成项目需要做的任务。在列出详细的任务清单后，就开始对所有工作进行分类，以便于将这些详细的工作归入上一级的大项中。比如说，项目团队某小组中的商业分析人员会知道他们必须确定用户对项目的要求以及该项目的内容要求；工程师们也会知道他们必须确定对系统的要求和对发动机的要求。于是，该小组可能会将这四项任务都归入到战斗机制造项目的概念设计这个总项中去。自下而上法一般都很费时，但这种方法对于WBS的创建来说，效果特别好。项目经理经常对那些全新系统或方法的项目采用这种方法，或者用该法来促进全员参与或项目团队的协作。

使用指导方针

如果存在WBS的指导方针，那就必须遵循这些方针。许多DOD（国防部）项目都要求承包商按照国防部提供的WBS模板提交他们的项目建议书。这些建议书必须包括针对WBS中每一项任务的成本估算，既有明细估算项，也有归总估算项。项目整体的成本估算必须是通过归总WBS底层各项任务成本而得到的。当国防部有关人员对成本计划进行评审时，他们必须将承包商的成本估算与国防部的成本估算进行对比，如果某项WBS任务成本有很大的出入，那一般就意味着对要做的工作任务还没搞清楚。

9.确定WBS是否已分解到足够详细的一层 

是否需要改善WBS工作包的成本估算和时间进度估算的精确度？

WBS工作包的负责人是否超过一人？

WBS的工作包是否包含了多个交付成果或实施过程？

是否需要分别定义工作过程的成本或WBS内的交付成果？

是否需要更精确地了解WBS内的工作过程的时间进度？

不同WBS工作包内的交付成果是否相互依赖？

WBS内过程中的工作实施是否有明显的时间间隔？

某一要素对资源的需求一段时间内会变化吗？

衡量WBS某一工作包进度的明确的目标标准存在吗？

这些验收标准在WBS的工作包全部完成前还适用吗？

WBS中的一些工作包是否存在一些风险需要特别的注意？

WBS工作包中的某一部分是否可作为单独的单元来做时间进度计划？

项目经理，项目团队，以及其他利害关系者包括客户对WBS的工作包有清晰和完全的理解吗？

是否有利害关系者有兴趣WBS某一工作包的现状和业绩？