大家好，我是老原。
为什么很多人明明有了很多工具和方法，还是做不好工作？
有没有想过，什么样的人才是“会工作“ 的人？
罗振宇在启发俱乐部里，对“会工作”做了一个解释。
“会工作的人，就是在他的脑子里，能画出那个终极的图。”
这个终极的图，就是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来说，它同样适用于产品管理，可以把产品调研、需求、设计等工作用同样的方法进行分解。
熟悉我的朋友应该知道，我经常强调一句话「万物皆可项目」，项目化思维可以用来解决任何事情。
小到回家炒个蛋炒饭，大到负责一个亿级千亿级的项目，掌握好项目管理的底层知识体系，这种项目管理能力可以升级应用到任何一个领域。
————