创建工作分解结构

友情提示：释放双手，戴上耳机，听听看~

Vol.023 创建工作分解结构|主播：萌萌

管理小学问，每日微课堂。

这里是光环微课堂，每天七点半，一起聊聊项目管理的修行之道。

今天我想和你分享的内容是“创建工作分解结构”。

如果你也喜欢今天的文章，欢迎拉到文末给我们点个在看。

在定义项目范围之后，需要做的一个很重要的事情是创建工作分解结构。

定义范围是把这个项目要做的产品描述清楚，而创建工作分解结构要做的是讲清楚为了完成项目产品，我们需要干哪些活儿。

工作分解结构其实不只能用于项目管理，很多工作中都可以用。

很多时候，我们感觉一件事情很难干，或者想不清楚一件事情要怎么做的时候，往往是因为这件事情是杂乱无章的。

当你没有理清工作之间的逻辑和顺序的时候，想要把工作推动下去是很困难的。

所以，如果我们想把一个工作很好的推动下去的时候，理清思路是非常重要的。

WBS工作分解结构就是帮助我们理清工作思路的一种很好的工具。

使用WBS可以对一件工作进行逐级分解，让工作内容越来越清楚。

当工作分解到一定程度的时候，我们才有可能把具体的工作落实到某个关键的人身上，这样才有人去承担相应的工作的职责。

所以WBS工作分解结构是一个非常实用的工具。

而且在项目管理的过程中，一定会用到这样的工作方式，把一个整体的项目工作拆分到不同的层面、不同的颗粒度，这样才能真正的把项目工作分配下来。

当我们把工作分解到足够小的时候，才有可能把它真正的管起来。

对我们来说，使用WBS工作分解结构通常有这么几个好处。

首先就是我们可以通过WBS进行面向可交付成果的对项目工作的层次化分解。

其实就是按照一定的逻辑和工作把工作进行展开，能够让我们更清晰的了解工作内容。

第二个作用就是他能帮助我们更好的定义项目范围。

我们最开始定义的范围，如果缺少逻辑的话，那么就很难把为了完成这个产品需要做哪些工作给描述清楚。

最好的方式就是我们把它给拆解开，拆分成更细致的工作之后，我们就能更准确的描述产品范围。

我们都知道项目管理过程中会出现范围变更，但很多时候，可能同样的工作，业务部门不觉得有变化，IT部门就会认为是范围变更。

比如业务部门给IT部门提出需求上线一个新系统，因为业务部门不会对自己的要求进行拆分，所以就会认为不管实现这个需求要做多少工作，实际上做的是一件事，都是在范围以内的。

而IT部门就不一样了，他们会把接到的需求进行很详细的拆分，有10个功能点还是20个功能点，范围可是完全不一样的。

如果在一开始的时候，就把项目范围定的很宽，而且比较笼统，这样后面越容易产生分歧。

这就要求我们在一开始的时候，把要做的产品拆分成一个一个的功能点。

拆分的越细，越能够与客户和醒目经理对项目范围达成共识，避免因为范围界定不清晰而出现分歧。

工作分解结构的另一个作用，就是它能把项目工作分解成较小的，易于管理的多项工作。

我们都知道，管理的难度其实取决于工作的复杂程度，工作越复杂、包含的内容越多，管理起来就会越困难。拆分的越精细，管控起来就会越容易。

工作分解结构还有一个很重要的作用就是，每分解到下一层就代表对对项目有更详细的定义。

在分解工作的过程中，你会发现，分解的越细对项目的认识也会更加深刻。

还拿刚才说的上线新系统为例。

当业务部门说想要上线一个新系统时，这个系统中到底要包含哪些功能，业务部门心中可能也不是特别的清楚，只是在心里有比较模糊的一部分概念，有很多东西可能他都没有想到。

而当我们进行逐层分解，当分解到某一层面的时候，就会发现他之前有很多没有想到的地方。

所以很多时候，我们使用WBS工作分解结构可以帮助业务部门的人，去定义他们想要的产品要实现哪些功能，需要完成哪些动作，我们分解的越细，业务部门的人对自己的要求也就会越清楚。

可见WBS工作分解结构很重要的一个作用就是帮助业务部门更加清晰的完善项目的需求和定义。

WBS有两种比较常见的分解维度，其中一个维度是按照阶段划分。

这种分解方式通常是把我们的工作按照项目生命周期划分成不同的阶段，然后再分解每一个阶段内要做的工作。

比如像图23-1，是教室小助手这样一个软件产品的开发过程示例。

这个过程就是按照项目生命周期划分成不同的阶段，包括软件分析、软件设计、软件实现等。

在每一个阶段下面，我们会把这个阶段需要完成的工作进一步分解。

我们还会把项目管理的过程单独拎出来，形成一条单独的工作线。

这种分解方式就属于按照阶段去对工作进行分解。

图23-1 按照阶段分解工作结构

第二种方式就是按照成果进行分解，这种方式和按照阶段分解的区别在于，第一层分解出来的不是阶段的名称，而是不同的可交付成果。

图23-2 按照成果分解工作结构

在图23-2所示的飞行系统这个项目中，我们就是先把项目的可交付成果按照不同的类型定义出来，然后我们再对可交付成果进一步分解，看为了完成可交付成果需要在下一层完成哪些可交付成果。

所以，在示例中，为了完成支持设备，需要完成组织层面的支持设备，中间层面的支持设备，还有更加细化的站务层的支持设备等。

可以看出来，这两种工作分解方式确实是有很大区别的，在实际的项目管理过程中，这两种方式都是可以使用的。

项目经理可以根据具体的项目类型和自己的习惯选择不同的方式。

如果选择按照阶段进行工作分解，就会很清晰的看到哪些是阶段性的可交付成果，哪些是最终的可交付成果，这对项目阶段管控是很有帮助的。

而选择按照成果进行划分，最大的好处就是它能保证不会有可交付成果被遗漏，而且我们一开始就把最终的可交付成果列出来了，它一定会被项目成员所记住的。

所以，这两种工作分解方式各有利弊，大家可以根据项目类型和自己的习惯选中合适的方法。

当我们用WBS把工作分解到最底层的时候，就会产生工作包，也叫做“工作细目”，相当于WBS最底层的可交付成果。

当我们能够把一部分工作打包，进行进度安排、成本估算和控制的时候，就已经形成了工作包，我们可以为它找到一个合适的责任，把这部分工作承担起来。

定义工作包是为了找到一个合适的人，去承担完成这个工作的职责，这是工作包存在的重要意义。

好了，以上就是今天的全部内容，通过今天的内容你可以知道——

（1）为了讲清楚要完成项目的产品要做哪些工作，需要在定i范围之后创建工作分解结构。

（2）WBS工作分解结构有几个作用：

首先是可以对工作进行层次化分解，更清晰的了解工作内容后；

其次是能帮助我们更详细的描述产品范围；

第三个作用是能把醒目分解成更小的、易于管理的多项工作；

还有一个很重要的作用是，帮助客户和业务部门更加清晰的完善项目定义和需求

（3）有两种维度可以对工作结构进行分解，分别是按照阶段分解和按照成果分解。

按照阶段分解工作结构，能够很清晰的看到哪些是阶段性成果，哪些是最终的项目可交付成果；

按照成果分解工作结构，可以保证不会有可交付成果被遗漏

希望通过今天的内容，能帮助对工作分解结构有比较清晰的认识和了解，我们下期见！

今日BGM

点击聆听

今天我们使用的BGM是日本著名作曲家久石让的作品《The Rain》，也是电影《菊次郎的夏天》的配乐。

《The Rain》是典型的先抑后扬的音乐，开始的一段钢琴把人带入一个雨夜的世界，随后忧伤的小提琴声响起，如同一个思绪重重的人陷在哀伤的记忆中……

短暂的雨声后，有着相同旋律的大提琴声渐渐响起，似乎是被前者感染唤起了相同的感情一般，只是声音更加低沉，最后也渐消于无，世界似乎陷入了无边的雨夜中……

然而也并不是真的无边，随着音调的走高，一段欢快的旋律出现了，像是主人公经过昨夜的洗礼，收拾好了心情，重新振奋精神，迈着轻松坚定的步子重新上路了……