随着商业社会的发展，现代企业的愿景和商业目标越来越宏大。无论是整体的战略规划，还是传统KPI 、最近几年大受欢迎的 OKR……都离不开“分解”的艺术。本篇文章，笔者将简要介绍项目管理中的工作分解结构（WBS），以及3个实践中的问题与解决思路，一起来看看吧。
一、什么是工作分解结构？
根据 PMI 的定义，创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件过程。对于工作分解结构（WBS）的概念，我们认为应该在以下两方面重点理解：
WBS 以可交付成果（Deliverables）为对象，而不是以计划活动（Schedule Activity）为对象；WBS 的结构，包含了一套科学的逻辑结构和分类 ，而非单个的、离散的、在时间顺序上不连续的成果的描述结构，通过层层的包含关系，非常严谨。二、WBS 分解 与常见问题
关于 WBS 的分解 ，许多项目管理的书籍都有介绍，常见的方式包括按照产品的物理结构、产品或项目的功能用途、项目的实施阶段和过程、项目组织的地域分布、各个子目标、部门或者职能角色等等。
但由于每个项目的独特性，这些经验性的理论 在实际应用中仍然会遇到很多问题，结合团队的服务实践，我们梳理归纳了3个痛点问题和对应的解决思路。
1. WBS 分解的颗粒度
由于项目管理的自身特点，在项目规划阶段，我们很难穷尽项目涉及的全部事项，对一些远期才能完成的成果，项目初期可能无法分解。即使是在一个理想环境下，工作分解过细，也会带来管理成本的无效耗费，资源使用效率低下，同时 WBS 各层级数据汇总困难。
分细不容易，分粗一点呢？比如每个 WBS 设计三层，前两层概要、后一层是最终的成果，又很可能导致范围蔓延、权责分工不清晰，也是不合理的。
解决思路：
WBS 的实质思想之一，是要体现在项目过程中项目职责的落实和明确划分。
「责任到人」是项目管理的核心，实际工作中最糟糕的情况是事情出了，没人认账，没人负责，要避免这个问题的出现，就需要在每一层次 WBS 分解过程中都考虑到项目责任划分和归属，尽可能每一个更底层的节点都有唯一责任人（或部门）相对应。
因此，分解的粒度是”可以分配,可以交付”。
2. 不同分解 之间的矛盾
在实际的管理实践中，一个项目往往有多种分解 ，可以按照工作的流程、可交付成果分解，也可以在不同层级使用不同的 ，在一些大型复杂项目中，常常还涉及诸多的对外采购活动，合同中清单分解项目依赖具体的场景需求，有时候还会受到独立的行业标准和惯例约束。
不同的分解方式侧重点不同、相互之间难以统一，造成了 WBS 在理论上容易理解但在具体场景下操作实施的难度。
解决思路：
解决这一矛盾，首先要理解 WBS 的另一作用，是实现项目进度/成本控制的基础，如果没有这个功能，WBS 在具体活动中没有任何特殊意义，只是一个工作备忘录。
结合这一作用，我们可以考虑在应用 WBS 的时候，将其分为两个部分：
上层部分为大项工作分解结构，可以参考项目的高层级目标，将整个项目按级别划分若干大项和单项。大项分解可以参考项目的生命周期、各个阶段、各个里程碑控制点等原则划分；
底层部分划分也不一定严格遵循80小时等传统原则，尽可能有一个相对完整等交付成果即可，如果涉及对外合同，尽量让底层部分的分解层次位于合同清单项之上，避免混乱、也利于工作量和成本衡量。
3. WBS 在项目各阶段的地位作用
WBS 不是一个大而全、覆盖整个项目的分解结构，很多项目关键信息都不能在 WBS 中完整表现。由于主要呈现项目「可交付成果」，我们实际执行往往陷于细节，没有把它放到项目中系统看待其关联，远不如项目活动、进度类文件用得多，常常被束之高阁，沦为工作的备忘录。
解决思路：
WBS 并不是孤立存在的，它可与其他编码体系配合，体现不同的配置关系，比如 WBS 和 OBS（组织分解结构）结合，就可以进行职责配置，把项目工作分解结构 WBS 看作纵轴，组织分解结构 OBS 为横轴，通过两者的整合确定部门或个人的工作任务和责任。
另外，WBS 在不同阶段也有不同的侧重作用：
项目规划阶段——明确项目范围，是项目进度/成本估算的基础项目执行阶段——检查项目质量，可以项目进度/成本联合控制项目结束时——项目绩效衡量以上就是我们本期分享。关于 WBS 更多详细信息，可以参考PMI《工作分解结构实践标准》,这一标准列举了一些具体行业的 WBS 模板，可以在裁剪后应用于特定领域的具体项目。
本文由 @ONES 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
