SC-02-05-外包软件WBS分解

抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。

 

对于大型项目来说化解风险最根本的一条是将大的项目分解成为很多个相对独立的部分，而后分别完成每一部分，将风险控制在一定范围内。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。

 

WBS具有4个主要用途：

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

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

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

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

 

 

WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被分解为WBS，是因为较好的工作分解可以：

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

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

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

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

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

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

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

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

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

 

WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点：

    * 工作包可以分配给另一位项目经理进行计划和执行。

    * 工作包可以通过子项目的方式进一步分解为子项目的WBS。

    * 工作包可以在制定项目进度计划时，进一步分解为活动。

    * 工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。

    * 工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。

 

1. 创建WBS的方法

创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：

（1）使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。

（2）类比方法。参考类似项目的WBS创建新项目的WBS。

（3）自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。

（4）自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。

 

2．创建WBS的基本要求

（1）某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。

（2）WBS中某项任务的内容是其下所有WBS项的总和。

（3）一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。

（4）WBS必须与实际工作中的执行方式一致。

（5）应让项目团队成员积极参与创建WBS，以确保WBS的一致性。

（6）每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。

（7）WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。

 

3．WBS的表示方式

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

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

 

4．WBS的分解方式

WBS的分解可以采用多种方式进行，包括：

（1）按产品的物理结构分解。

（2）按产品或项目的功能分解。

（3）按照实施过程分解。

（4）按照项目的地域分布分解。

（5）按照项目的各个目标分解。

（6）按部门分解。

（7）按职能分解。

 

5．创建WBS的过程

创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：

（1）得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。

（2）召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。

（3）分解项目工作。如果有现成的模板，应该尽量利用。

（4）画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。

（5）将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。

（6）验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。

（7）如果有必要，建立一个编号系统。

（8）随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。

检验WBS是否定义完全、项目的所有任务是否都被完全分解可以参考以下标准：

（9）每个任务的状态和完成情况是可以量化的。

（10）明确定义了每个任务的开始和结束。

（11）每个任务都有一个可交付成果。

（12）工期易于估算且在可接受期限内。

（13）容易估算成本。

（14）各项任务是独立的。

 

6．WBS的使用

对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。

当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。

WBS、OBS、RBS、职责分配矩阵比较：

WBS 是工作分解结构，下面都是工作包，都是成果，不包括具体人员、具体资源信息；

OBS 是组织分解结构，里面是部门、单位或团队, 不包括具体工作内容、工作职责，工作职责通常在职责说明书里面；

RBS 是资源分解结构，包括人的信息，因为人也是资源，不过不包括工作内容和所属部门。

职责分配矩阵，是把WBS和OBS结合起来，显示工作包和团队成员之间的关系。

 

7．WBS的实践经验

WBS字典：超大型项目需要，WBS字典有助于追踪所有的概要和详细的活动，包括一个简短的说明、WBS数字标识符（1.1、1.1.1、1.1.2等）和预计的努力。如果你把WBS字典输入到一个专门的工具中，这个工具还有助于追踪WBS的变化。

让最后的详细活动以行动为导向：WBS中的详细活动（不能进一步分解的活动）最终会转移到你的进度表中；因此，如果WBS中的详细活动以行动为导向会更加方便。

 

典型的WBS实践流程：

1. 制定工作产品清单（PL）。

工作产品（Working Product）是项目需要产出的工作结果，可以是项目最终交付成果的组成部分，也可以是项目中间过程的产出结果。以软件开发为例，软件中的用户管理模块是最中软件产品的一部分，软件的需求分析文档是软床过程中的文件，都是软件开发这个项目的工作产品。工作产品有大有小，有的相互关联，有隶属的关系。列出工作产品清单的过程，可以是头脑风暴的方法，项目组共同完成。

 

2. 制定工作产品分解结构（PBS）。

工作产品大大小小列出了很多，大型项目有几百项，几千项。工作这些工作产品的属性和关系，用结构化的方法组织这些工作产品，形成一个自顶向下的逐级细分的工作产品分解结构（PBS：Product Breakdown Structure）。这就是制造业内的产品物料表（BOM），说明一个产品有多少个零件组成。

 

3. 制定工作任务分解结构（WBS）。

有了PBS，只要把获得工作产品的任务明确，就可用根据PBS的结构，得到WBS了。注意同样的PBS，可用有不同的WBS，因为获得同样工作产品的任务可以是不同的。例如软件开发中的用户管理模块，是PBS中的工作产品，对于到WBS中，可以是不同的任务，一种是采购一个用户管理模块，另一种可以是项目小组开发一个用户管理模块。

 

4. 制定组织分解结构（OBS）。

WBS中的任务确定了，完成任务的责任人也就可以明确了。因此由WBS则可以形成整个项目的组织分解结构，由那些人来完成项目的任务，得到工作产品，并完成项目。

其中的关键是分解的结构，PBS、WBS和OBS是同一个结构，只是从不同的角度来阐述这个结构。关于这个结构的分解方法，常用的有组件分解方法和过程分解方法。典型的组件方法就是制造业中把一个完整的产品，逐级分解到零件。典型的过程分解方法可以是软件开发从需求到设计、编码、测试的一个过程。项目分解中，这两种方法往往交替使用，其最终是把项目分解到一个个具体和细小的工作任务。