项目经理的重要工具工作分解结构，如何有效使用？

（一）创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。

主要用途：
WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。
1 WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
2 WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
3 WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
4 WBS防止遗漏项目的可交付成果。
5 WBS帮助项目经理关注项目目标和澄清职责。
6 WBS建立可视化的项目可交付成果，以便估算工作量和分配工作。
7 WBS帮助改进时间、成本和资源估计的准确度。
8 WBS帮助项目团队的建立和获得项目人员的承诺。
9 WBS为绩效测量和项目控制定义一个基准。
10 WBS辅助沟通清晰的工作责任。
11 WBS为其他项目计划的制定建立框架。
12 WBS帮助分析项目的最初风险。 

WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构（WBS）都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS是由3个关键元素构成的名词：工作（work)--可以产生有形结果的工作任务；分解（breakdown)--是一种逐步细分和分类的层级结构；结构（structure)--按照一定的模式组织各部分。根据这些概念，WBS有相应的构成因子与其对应：
⑴结构化编码
编码是最显著和最关键的WBS构成因子，首先编码用于将WBS彻底的结构化。通过编码体系，我们可以很容易识别WBS元素的层级关系、分组类别和特性。并且由于近代计算机技术的发展，编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。
⑵工作包
工作包（work package）是WBS的最底层元素，一般的工作包是最小的“可交付成果”，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如：管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动；包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本；过程中产生的报告/检验结果等等文档；以及被分配的工班组等责任包干信息等等。正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的基础。基于上述观点，一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。
⑶WBS元素
WBS元素实际上就是WBS结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关，必须面向最终产品或可交付成果的，因此WBS元素更适于描述输出产品的名词组成（effictive WBS，Gregory T. Haugan）。其中的道理很明显，不同组织、文化等为完成同一工作所使用的方法、程序和资源不同，但是他们的结果必须相同，必须满足规定的要求。只有抓住最核心的可交付结果才能最有效的控制和管理项目；另一方面，只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。工作包是最底层的WBS元素。
⑷WBS字典
管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与者（如承包商）接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。

WBS计划
项目计划是如何体现工作范围的呢？常用的方式是通过工作分解的方式，将工作范围细分为活动，然后对每项活动分配时间和资源，而活动结果的总和就是工作范围，我们将这种分解的计划称为WBS（Work Breakdown Structure，工作分解）计划。制定WBS计划是制定项目计划最主要的活动。    

制订WBS计划主要分为以下三个步骤：   
第一，分解工作任务。将一个总的工作范围（软件项目XXX）逐渐细分到合适的粒度，以便对任务计划、执行和控制。对于软件项目来说，分解工作任务不是一项单纯的计划活动，而是要根据项目的特点决定工作任务的分解结构。实际工作中更多地会考虑技术因素来确定工作分解结构的形式。  
第二，定义活动依赖关系。确定了项目中要完成哪些活动以后，需要对这些活动之间的依赖关系做出定义。活动之间的依赖关系取决于实际工作的要求，不同活动之间的依赖关系决定了活动的优先顺序及其重要性。活动依赖关系是确定项目关键路径和活动浮动时间的必要条件，定义活动间依赖关系的目的是确定每一项活动所需的输入、输出关系。  
第三，分配时间和资源。完成工作任务分解并定义了活动的依赖关系后，应该为每项活动分配相应的时间和资源。通常活动都会产生自己的交付物。为活动分配时间可以采用自下而上和自上而下两种不同的方法。自下而上是先估计最小粒度的活动所需要的时间，项目所需的时间则取决于所有项目活动的关键路径时间；自上而下则是确定完成项目所需要的总的时间，然后将时间分配给不同的活动。这两种方法在实际中都有应用，对于客户项目，很多情况下只能采取自上而下的方式，因为大多数项目都事先确定好了项目的交付时间。在软件项目计划中，资源分配主要指人员的分配，指定了时间资源以后，应该指定人力资源。一项工作任务是否能够完成，所需要的时间和人员是两个最主要的变量。在一定的范围内，时间和人员是可以互换的。即增加人员会缩短工作时间；延长时间会降低对人员的需求量（但这种观点的害处在于管理者往往会认为所有的活动都可以互换时间和人力资源）。如果已经确定了活动的完成时间，则指定相应的人员作为完成活动的责任人。

（二）工作分解结构作为项目经理的宝贵工具

对于那些之前没有参加过项目管理课程或内部培训的人来说，工作分解结构（WBS）可能听起来像是一个未知的领域。但实际上，它是一个面向可交付成果的层次分解工作，理想地由项目经理和分配的项目团队在实际软件开发开始之前起草。此外，它被认为是PM潘多拉盒子中最有效和最重要的工具之一。
工作分解结构
WBS是将项目拆分为相对较小的可管理单元或冲刺的简单方法。但与此同时，不应该将其与简单生动的任务列表混在一起。它并不意味着包括应该在项目开发框架内采取的所有各种行动，但它绝对关注于在一天结束时构成项目的结果和可交付成果。通常情况下，团队和PM应首先完成WBS。一旦完成并设计了整个项目地图，您就可以开始绘制sprint任务列表和甘特图。WBS的一个优点是在PM的武器库中使用它是非常有用的。同时，这个工具非常复杂，需要花费大量的时间和精力从头开始为每个独特的项目创建它。
您可能有一个问题，那么为什么工作分解结构如此有用？因为它甚至可以在您开始编写实际代码之前很久就为您提供对未来应用程序或网站的完整愿景。从这个角度来看，您将能够探索项目迷宫中最黑暗的角落。在现实世界中，项目被分解为关键的可交付成果，然后进一步细分为可交付成果，直到团队中的每个软件开发工程师都有自己的工作任务。WBS实际上可视化团队的全面工作流程，直到最终发布日期，任务之间的依赖关系，要完成的详细任务列表。有了WBS，你永远不会疯狂地为开发分配预算，并创建更多或更少的现实时间表，以确保事情顺利进行。 

此外，WBS与风险管理计划可以帮助项目经理识别众多潜在风险并有效地处理这些风险。如果项目开发出现任何问题，WBS将立即向PM发出信号，显示它将影响整个事情的方式，并提供相应调整的可能性。
当PM创建工作分解结构时，他应该邀请所有参与者，以确保不会错过任何一项任务。此外，WBS应该有一个词汇表来捕获与项目相关的任何特定术语或缩写。该词汇表可以为团队成员提供有关范围的更多详细信息，并防止可能导致责任混淆的元素之间的重叠以及可交付成果的预算。无论在主题方面的经验如何，对于任何人来说，完善的词汇表应该是同等且完全可理解的。
需要记住的是，WBS对于任何类型的项目都很有帮助，从简单的登陆页面或移动应用程序到具有庞大数据库和大量集成的复杂SaaS。即使对于有一个开发人员的项目，WBS甚至也很有用。但对于大型项目而言，WBS可能会成为一种昂贵且耗时的工具，这里的项目管理软件应该会出现。
创建WBS的最简单方法是拿一张纸和一支笔。但是如果你有其他队友在远程办公室怎么办？使用在线工具更好。项目管理软件允许远程团队在线进行WBS头脑风暴。将项目分解为可交付项后，项目管理软件会让您有机会自动创建任务列表，同时考虑任务和子任务之间的所有依赖关系。您还可以列出甘特图来管理时间表，截止日期，日程安排等。
通常，项目管理软件是基于云的，因此每个人都可以在各种设备上使用它。同时进行评论和编辑，确保所有更改都会自动显示给团队中的每个人。此外，任何持续时间的变化或一个任务的截止日期都会立即导致最终项目时间表的更改。一次创建的WBS文件可以进一步用于下一个即将到来的项目。真棒模板，哈？
我真诚地希望您在阅读本文后能够更好地理解WBS作为项目管理的有效工具的利弊。现在尝试在开发管道中的下一个项目时使用它。信不信由你，这将是一次全新的体验。

（三）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的方式来工作和学习，二来是希望大家也能从中得到一些启发，对今后的工作和生活有帮助。