大家好，我是老原。

为什么很多人明明有了很多工具和方法，还是做不好工作？

有没有想过，什么样的人才是“会工作“ 的人？

罗振宇在启发俱乐部里，对“会工作”做了一个解释。

“会工作的人，就是在他的脑子里，能画出那个终极的图。”

这个终极的图，就是WBS，以终为始，往下细化成可执行的具体步骤。

从这句话里面，有两个关键词：“终极”+“画出”。一个是结果，一个是过程。

总结来说就是你的「目标感+分解能力」。

能从结果出发，一步一步拆解出具体的步骤并执行好它，达到预定的目标，这样的人，才算是一个“会工作“的人。

你是“会工作“的人吗？

虽然道理都懂，但大多数人都没做到。

在面对时间紧、经验少的项目或任务前面，难免手足无措，不少项目经理或负责人会担心做计划浪费大家的工作时间，不加思考就拍脑袋干起来，遇到问题再解决，结果总是差强人意。

WBS就是一个可以帮你理清头绪，根据目标做好计划的工具。

与其选择后期背锅，不如学会用WBS进行前期“拆雷”，尤其是对于这种没有成熟经验的项目，必须遵循WBS工作分解结构法对项目进行“拆解”。

一、先来个经典问题

先来说说那个古老的问题——我们都知道把大象装入冰箱需要三步：

虽说这是小时候的脑筋急转弯，大家都知道听个乐就好了，但很多人做计划也真是这么做的。

行动上讲，把大象装入冰箱需要几步是典型的工作分解结构，上述的三步也是必须的步骤，但只分解了表面的工作内容，实际内涵远远不止于此。

现实生活中，想要让你把大象放进冰箱，只有这3步明显做不到。

第一，我们需要弄清楚任务需求：是要冷冻还是冷藏？是要活着冷藏还是分割冷冻？还是……

第二，需要测量大象的尺寸，考虑定制冰箱还是满世界找合适的冰箱？还是……

第三，怎么把它装进去？是迷晕了抬进去，还是让它自己走进去，又或者你需要一把刀……

因此，对任何一种方法，一种工具，一种模板，都应该搞清楚它们背后的逻辑和本质，是要解决什么问题，有什么制作原则，适用于什么样的场景？

通过理解基本的逻辑和规则，实践消化后形成自己的标准方法。

只有这样，用工具解决问题时，才不会被工具解决。

二、那么，WBS有什么用？

WBS最大的用处就是帮你拆解任务，使其变得可实操。

还是那头大象，要如何吃掉一头大象呢？

答案当然是：一次吃一口。

完成一个大目标，就如同吃掉一头大象，需要一层一层、一级一级的逐步分解细化为一个个小的任务单元，从而把每一个小的任务单元完美的完成，大目标，自然也就完美地完成了。

更细致的好处和功能，总结起来大概是3点：

01 时间压力面前，WBS是你死扛和逃避之外的第3种选择

在时间紧任务重时，对一个大的工作包往往无法准确的进行评估，当对其进行细化分解后就能评估出相对准确的工作时间与人力资源。

为啥？

因为它可以可以理清整个项目结构，了解项目全貌，通过分析每个节点，帮你找到切入点，统筹整个项目所需的人力、时间、成本；

02 消痛疏堵？揭开项目细节，早发现、早解决

作为项目负责人，你肯定有过这样的经历：小细节没有关注，一两个字的关键细节没看清，结果酿成大麻烦，“小火”最后活活把你拉成了一个“救火队员”。

通过功能分解，完全方便你了解及控制项目进度，规避风险；运筹帷幄大概就是这种感觉。

任务看板可视化，把一些隐形的工作显性化，显性的工作结构化，结构的工作标准版，这不就是妥妥的高效组织吗。

03 划清责权，轻松应对需求新增

细分项目范围，为项目划清界线；当提出需求时，能清晰的分辨出所提出需求为新增需求，还是变更需求，便于项目管理者管理项目。

三、怎么搞定一个拿得出手的WBS

想玩好一个游戏，第一步就是了解规则，在规则清楚的前提下，如果你能“玩“好规则，加上技术辅助等等，你一定是个游戏高手。

01 “守规矩”——WBS的分解原则

WBS看起来只是一张图，但也有它的「游戏规则」：

1、100%原则

拆分的任务要100%包含所有交付物，每一层分解的子任务也要100%覆盖它的父级任务范畴。

例如开发项目，在任务拆解时必须覆盖所有内容模块，然后再对不同模块做更细致的拆解。

2、要有合理的工作包大小

工作包不是越细越好，而是可交付、可分配、责任到人。分解的最小工作包要保证一个人能在80小时内完成的范围，如果大于和这个范围，就需要继续分解，因为大的工作包会有暗藏风险。

3、元素互斥

互斥就是相互独立且完全穷尽。

「相互独立」就是不重复造轮子；「完全穷尽」才能做到无遗漏不误事。

比如你把采购水果和采购例子并存，就是不合理的拆分。

4、围绕产出

在列举WBS工作包时，要按照期望的产出物计划，而不能只是规划行动事件。说人话就是盯着目标做事。

就好比小孩玩泥巴，原材料也对，但每个人最终捏出来的结果是完全不一样的。

所以即使工作步骤都一样，但如果没有围绕产出来制定，很可能组合出来的结合和预想的相差甚远。

作为项目负责人，要避免这样的情况发生，必须从你要的产出结果出发去做计划，而不是仅仅规划了行动事件。

同一个起点开始跑步，方向没搞对，自然离终点越来越远。

02 “上辅助”

1-MECE原则 相互独立 完全穷尽

听上去很复杂的样子，其实很简单，MECE法则就像是拼图游戏，把所有的拼图碎片拼出一个完整的图片，如果拼的正确，最后一定是一块不多，一块不少，刚刚好构成完整的图片。

MECE用在项目WBS分解中，就是要做到不重叠，不遗漏——重叠了成本增加，遗漏了，风险巨大。

2-滚动式规划原则 颗粒度近细远粗

项目初期，很多信息都是需要随着时间的推移进行逐步确认，如果有些信息不明确的情况下，做出详细的分解就会造成管理时间的无效浪费，毫无意义。

03 WBS的分解方式

WBS常见的分解方式总共有7种：

① 按产品的物理结构分解② 按产品或项目的功能分解③ 按实施过程分解④ 按项目的地域分布分解⑤ 按项目的各个目标分解⑥ 按部门分解⑦ 按职能分解
04 WBS的编制步骤

以IT项目的WBS分解步骤为例：

05 WBS的检验标准

做完了计划，别忘了最重要的一步：检验。

怎么知道自己的WBS到底能不能拿得出手？主要有这几个标准：

一个人的核心竞争力取决于他的底层框架和可迁移能力。

学会一个工具或者方法，接触的多了，你会发现我们其实掌握的是底层逻辑，从一个点可以链接更多的领域和行业。

就拿WBS来说，它同样适用于产品管理，可以把产品调研、需求、设计等工作用同样的方法进行分解。

熟悉我的朋友应该知道，我经常强调一句话「万物皆可项目」，项目化思维可以用来解决任何事情。

小到回家炒个蛋炒饭，大到负责一个亿级千亿级的项目，掌握好项目管理的底层知识体系，这种项目管理能力可以升级应用到任何一个领域。

————

我是老原，欢迎关注我的公众号【项目经理老原】，每天都会有项目管理案例干货分享。