WBS工作分解结构
WBS：工作分解结构（Work Breakdown Structure）
创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
输入：
1.项目范围说明书
2.需求文件
3.组织过程资产
输出：
1.工作分解结构
2.工作分解结构词典
3.范围基准
4.项目文件(更新)
工具与技术
1.工作分解结构样板
2.分解
注意事项：
注意WBS与OBS，RBS[Risk]，RBS[Resource]，BOM的区别.
分解细则
WBS分解的原则：
横向到边即百分百原则指WBS分解不能出现漏项，也不能包含不在项目范围之内的任何产品或活动
纵向到底指WBS分解要足够细，以满足任务分配、检测及控制的目的
WBS分解的方法：
至上而下与至下而上的充分沟通
一对一个别交流
小组讨论
WBS分解的标准：
分解后的活动结构清晰
逻辑上形成一个大的活动
集成了所有的关键因素
包含临时的里程碑和监控点
所有活动全部定义清楚
学会分解任务，只有将任务分解得足够细，您才能心里有数，您才能有条不紊地工作，您才能统筹 安排您的时间表
工作分解结构
工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
无论在项目管理实践中，还是在PMP考试中，工作分解结构(WBS)都是最重要的内容。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS具有4个主要用途：
1.WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管
理项目的工作。
2.WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
3.WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
4.WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
WBS应包含的信息：
项目产品或服务结构，项目组织结构，项目的阶段划分。
WBS 是面向项目可交付成果的成组的项目元素，这些元素定义和组织该项目的总的工作范围，未在WBS中包括的工作就不属于该项目的范围。WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被分解为WBS，是因为较好的工作分解可以：
a.防止遗漏项目的可交付成果。
b.帮助项目经理关注项目目标和澄清职责。
c.建立可视化的项目可交付成果，以便估算工作量和分配工作。
d.帮助改进时间、成本和资源估计的准确度。
e.帮助项目团队的建立和获得项目人员的承诺。
f.为绩效测量和项目控制定义一个基准。
g.辅助沟通清晰的工作责任。
h.为其他项目计划的制定建立框架。
i.帮助分析项目的最初风险。
WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点： a.工作包可以分配给另一位项目经理进行计划和执行。
b.工作包可以通过子项目的方式进一步分解为子项目的WBS。
c.工作包可以在制定项目进度计划时，进一步分解为活动。
d.工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。
e.工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
1. 创建WBS的方法
创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：
a.使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。
b.类比方法。参考类似项目的WBS创建新项目的WBS。
c.自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。
d.自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。
2．创建WBS的基本要求
创建WBS时需要满足以下几点基本要求：
a.某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
b.WBS中某项任务的内容是其下所有WBS项的总和。
c.一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
d.WBS必须与实际工作中的执行方式一致。
e.应让项目团队成员积极参与创建WBS，以确保WBS的一致性。
f.每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。
g.WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。
3．WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。
其中美国国防机构使用WBS在MIL-STD中对WBS进行的描述为：“WBS是由硬件、软件、服务、数据和设备组成的面向产品的家族树。”
在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。
4．WBS的分解方式
WBS的分解可以采用多种方式进行，包括：
a.按产品的物理结构分解。
b.按产品或项目的功能分解。
c.按照实施过程分解。
d.按照项目的地域分布分解。
e.按照项目的各个目标分解。
f.按部门分解。
g.按职能分解。
5．创建WBS的过程
创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：
a.得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。 b.召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。 c.分解项目工作。如果有现成的模板，应该尽量利用。
d.画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
e.将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。 f.验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。 g.如果有必要，建立一个编号系统。
h.随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。 检验WBS是否定义完全、项目的所有任务是否都被完全分解可以参考以下标准： i.每个任务的状态和完成情况是可以量化的。
j.明确定义了每个任务的开始和结束。
k.每个任务都有一个可交付成果。
l.工期易于估算且在可接受期限内。
m.容易估算成本。
n.各项任务是独立的。
5．WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工
作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。
当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。
6．WBS的实践经验
最多使用20个层次，多于20层是过度的。对于一些较小的项目4－6层一般就足够了。 WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。
WBS，不止是工作分解结构，也能更好的管理个人时间，是一个很好的工作和做事的思路和习惯。
先看下WBS的官方定义吧，工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
讲下自己对WBS的理解和认识的过程。
最初安排各个模块后，大家各行其路，自己按照自己的思路开始进行。项目经理问了多久可以完成，自己扫了下需求，然后互相打量了下其他人的眼神。10天吧，大概。可想而知，15天后，我们仍然准备了很多解释工作延期的理由。
然后有了WBS。刚开始自己对WBS的认识很浅显，只是字面意义上的理解：合理分配任务，然后跟踪任务的完成情况。开始的时候，大家对工作的也比较盲目，根据各自模块进行模块功能划分，然后大概的对各个功能的难度和所需时间进行了时间的预估，再安排各个功能模块给个人。问题总是在我们不期望的时候和考虑不周的时候如期而至。这次虽然比上次进步了，但是仍然有很多的不足。
经过几次的摸爬滚打，自己总结了几点需要在WBS中注意的。
1，WBS一定要自上而下的分配任务。先从总的需求，再到模块功能，再细分到功能的每个实现。不要一开始就太关注某个细节，避免出现因为考虑不周到，对项目的某些功能进行遗漏。
2，WBS一定要有可操作性。何为可操作性？比如说，我要锻炼身体。就要问自己怎么锻炼，每天5分钟短跑，10个俯卧撑。这个每天5分钟短跑，10个俯卧撑就是可以操作的。只有具有可操作性，才能正确的预估时间。 这点也是本人感觉最难的，因为分解到可操作性就要能估计完成时间，如果分解不够详细，可能最后整个项目的时间估计会出现很大偏差，如果估计过于详细，会浪费太多时间，在合适的阶段估计到该阶段需要的详细程度。需要大家在实际的工作中不断的总结经验，不断的改进，才能越来越准确的WBS。
3，WBS最好分解到小时为单位，不要超过一天为宜。时间太长，就没有实际的操作性，而且时间长，也说明问题分解的不够明白。如果分解到12个小时一个任务，很有可能存在自己分解不够细致，导致在实际的开发过程中遇到自己没有考虑到问题，造成延期，带来项目风险。
从WBS中也得到了很多启发。比如，生活中遇到的很多问题，如果没有一定的思路，都很棘手。但是如果用WBS的方式来分析问题，首先从大的方向将问题分解，然后一点一点的将大问题分解成小问题，直至分解成可以操作的各个小步骤，然后这个时候就可以一步一步的完成各个小步骤，小目标。不但可以较快的找到解决问题的方法，而且可以作为估算
自己的时间成本和其他成本一个依据。
再者，生活中经常为自己定各种各样的目标。很多人习惯把目标定的比较远，但是实际的操作性差，而且不能很好的检查自己的完成情况。比如说，一个月读完某本书。其实是可以将任务分解，先粗略的看下各个章节的内容量和难易度，然后将各个章节分别击破。第一周看1，2，3，4章，第二周看，4，5章，等。这样不但具有很强的操作性，每周任务相对每天又有很大的灵活性，可以适当的调整每天的时间，而且，如果到了周五发现还有很多没有读完，又能很好的监督自己，加快进度。
分享这些，一来是自己可以整理下思路，以便在今后能更好的应用WBS的方式来工作和学习，二来是希望大家也能从中得到一些启发，对今后的工作和生活有帮助。
WBS工作分解结构
WBS：工作分解结构（Work Breakdown Structure）
创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
输入：
1.项目范围说明书
2.需求文件
3.组织过程资产
输出：
1.工作分解结构
2.工作分解结构词典
3.范围基准
4.项目文件(更新)
工具与技术
1.工作分解结构样板
2.分解
注意事项：
注意WBS与OBS，RBS[Risk]，RBS[Resource]，BOM的区别.
分解细则
WBS分解的原则：
横向到边即百分百原则指WBS分解不能出现漏项，也不能包含不在项目范围之内的任何产品或活动
纵向到底指WBS分解要足够细，以满足任务分配、检测及控制的目的
WBS分解的方法：
至上而下与至下而上的充分沟通
一对一个别交流
小组讨论
WBS分解的标准：
分解后的活动结构清晰
逻辑上形成一个大的活动
集成了所有的关键因素
包含临时的里程碑和监控点
所有活动全部定义清楚
学会分解任务，只有将任务分解得足够细，您才能心里有数，您才能有条不紊地工作，您才能统筹 安排您的时间表
工作分解结构
工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
无论在项目管理实践中，还是在PMP考试中，工作分解结构(WBS)都是最重要的内容。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS具有4个主要用途：
1.WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管
理项目的工作。
2.WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
3.WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
4.WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
WBS应包含的信息：
项目产品或服务结构，项目组织结构，项目的阶段划分。
WBS 是面向项目可交付成果的成组的项目元素，这些元素定义和组织该项目的总的工作范围，未在WBS中包括的工作就不属于该项目的范围。WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被分解为WBS，是因为较好的工作分解可以：
a.防止遗漏项目的可交付成果。
b.帮助项目经理关注项目目标和澄清职责。
c.建立可视化的项目可交付成果，以便估算工作量和分配工作。
d.帮助改进时间、成本和资源估计的准确度。
e.帮助项目团队的建立和获得项目人员的承诺。
f.为绩效测量和项目控制定义一个基准。
g.辅助沟通清晰的工作责任。
h.为其他项目计划的制定建立框架。
i.帮助分析项目的最初风险。
WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点： a.工作包可以分配给另一位项目经理进行计划和执行。
b.工作包可以通过子项目的方式进一步分解为子项目的WBS。
c.工作包可以在制定项目进度计划时，进一步分解为活动。
d.工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。
e.工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
1. 创建WBS的方法
创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：
a.使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。
b.类比方法。参考类似项目的WBS创建新项目的WBS。
c.自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。
d.自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。
2．创建WBS的基本要求
创建WBS时需要满足以下几点基本要求：
a.某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
b.WBS中某项任务的内容是其下所有WBS项的总和。
c.一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
d.WBS必须与实际工作中的执行方式一致。
e.应让项目团队成员积极参与创建WBS，以确保WBS的一致性。
f.每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。
g.WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。
3．WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。
其中美国国防机构使用WBS在MIL-STD中对WBS进行的描述为：“WBS是由硬件、软件、服务、数据和设备组成的面向产品的家族树。”
在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。
4．WBS的分解方式
WBS的分解可以采用多种方式进行，包括：
a.按产品的物理结构分解。
b.按产品或项目的功能分解。
c.按照实施过程分解。
d.按照项目的地域分布分解。
e.按照项目的各个目标分解。
f.按部门分解。
g.按职能分解。
5．创建WBS的过程
创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：
a.得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。 b.召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。 c.分解项目工作。如果有现成的模板，应该尽量利用。
d.画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
e.将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。 f.验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。 g.如果有必要，建立一个编号系统。
h.随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。 检验WBS是否定义完全、项目的所有任务是否都被完全分解可以参考以下标准： i.每个任务的状态和完成情况是可以量化的。
j.明确定义了每个任务的开始和结束。
k.每个任务都有一个可交付成果。
l.工期易于估算且在可接受期限内。
m.容易估算成本。
n.各项任务是独立的。
5．WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工
作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。
当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。
6．WBS的实践经验
最多使用20个层次，多于20层是过度的。对于一些较小的项目4－6层一般就足够了。 WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。
WBS，不止是工作分解结构，也能更好的管理个人时间，是一个很好的工作和做事的思路和习惯。
先看下WBS的官方定义吧，工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
讲下自己对WBS的理解和认识的过程。
最初安排各个模块后，大家各行其路，自己按照自己的思路开始进行。项目经理问了多久可以完成，自己扫了下需求，然后互相打量了下其他人的眼神。10天吧，大概。可想而知，15天后，我们仍然准备了很多解释工作延期的理由。
然后有了WBS。刚开始自己对WBS的认识很浅显，只是字面意义上的理解：合理分配任务，然后跟踪任务的完成情况。开始的时候，大家对工作的也比较盲目，根据各自模块进行模块功能划分，然后大概的对各个功能的难度和所需时间进行了时间的预估，再安排各个功能模块给个人。问题总是在我们不期望的时候和考虑不周的时候如期而至。这次虽然比上次进步了，但是仍然有很多的不足。
经过几次的摸爬滚打，自己总结了几点需要在WBS中注意的。
1，WBS一定要自上而下的分配任务。先从总的需求，再到模块功能，再细分到功能的每个实现。不要一开始就太关注某个细节，避免出现因为考虑不周到，对项目的某些功能进行遗漏。
2，WBS一定要有可操作性。何为可操作性？比如说，我要锻炼身体。就要问自己怎么锻炼，每天5分钟短跑，10个俯卧撑。这个每天5分钟短跑，10个俯卧撑就是可以操作的。只有具有可操作性，才能正确的预估时间。 这点也是本人感觉最难的，因为分解到可操作性就要能估计完成时间，如果分解不够详细，可能最后整个项目的时间估计会出现很大偏差，如果估计过于详细，会浪费太多时间，在合适的阶段估计到该阶段需要的详细程度。需要大家在实际的工作中不断的总结经验，不断的改进，才能越来越准确的WBS。
3，WBS最好分解到小时为单位，不要超过一天为宜。时间太长，就没有实际的操作性，而且时间长，也说明问题分解的不够明白。如果分解到12个小时一个任务，很有可能存在自己分解不够细致，导致在实际的开发过程中遇到自己没有考虑到问题，造成延期，带来项目风险。
从WBS中也得到了很多启发。比如，生活中遇到的很多问题，如果没有一定的思路，都很棘手。但是如果用WBS的方式来分析问题，首先从大的方向将问题分解，然后一点一点的将大问题分解成小问题，直至分解成可以操作的各个小步骤，然后这个时候就可以一步一步的完成各个小步骤，小目标。不但可以较快的找到解决问题的方法，而且可以作为估算
自己的时间成本和其他成本一个依据。
再者，生活中经常为自己定各种各样的目标。很多人习惯把目标定的比较远，但是实际的操作性差，而且不能很好的检查自己的完成情况。比如说，一个月读完某本书。其实是可以将任务分解，先粗略的看下各个章节的内容量和难易度，然后将各个章节分别击破。第一周看1，2，3，4章，第二周看，4，5章，等。这样不但具有很强的操作性，每周任务相对每天又有很大的灵活性，可以适当的调整每天的时间，而且，如果到了周五发现还有很多没有读完，又能很好的监督自己，加快进度。
分享这些，一来是自己可以整理下思路，以便在今后能更好的应用WBS的方式来工作和学习，二来是希望大家也能从中得到一些启发，对今后的工作和生活有帮助。