WBS是Work Breakdown Structure的缩写，是按照可交付成果为导向对项目要素进行分组的方式。根据不同的应用，WBS可以分为行业标准、设备采购和研发管理三大类。我们今天要讨论的是研发管理类别的WBS。

产品研发需要进行研发流程管理，而研发流程管理则需要工作分解结构的支持。

研发管理的WBS旨在积累以往项目的经验，将典型项目的WBS整理为基础WBS，然后通过实例化形成项目WBS，作为项目管理的基础。

WBS按照系统研发过程中需要完成的工作逐级分解形成层次体系，完全规定了研发项目的工作内容，并展示了各项工作之间以及工作与最终产品之间的关系。有了WBS，就可以确定关键路径和关键资源，并为资源需求、成本预算和风险评估等工作提供基础。

WBS分解可以根据可交付成果进行、也可以根据工作过程进行，还可以采用混合模式。在《NASA系统工程手册》中，WBS包括实现产品分解结构（PBS）所需的工作、项目管理、系统工程、集成和验证以及全生命周期的保障。企业通常以可交付成果为主导，以研制过程为依据，综合运用项目管理技术和工具来开展项目工作的分解。

虽然WBS分解的方式有多种多样，但其分解原则是共性的：

第一，完整性：WBS要包含项目总范畴100%的内外部交付物。每一层分解的子任务也要100%覆盖其父级任务范畴。在同一个层次上列出所有的分支，例如在软件开发项目的第一层级列出需求评估、设计、开发、测试、交付、项目管理等模块。

第二，合理性：把控分解的颗粒度。太细容易丢失重点，太粗则不利于项目控制，这需要进行灵活的权衡。比如说项目团队都是由经验丰富的成员组成的，那么就可以采用比较大的工作包，同时工作包的大小也要和沟通管理的频度相配合。如果每日要开会，工作报告大小最好让成员能够在一个工作日内完成，这样每天进行沟通时，不至于没有什么可以讲的东西。如果每周进行沟通，成员的工作包就可以划分得适当大一些，但是工作包至少也要能够明确到具体的负责人，而且所有的任务都是要围绕着项目的交付物。如果项目包划得太大，有好几个负责人，那么这个项目包就还要继续进行拆解。

第三，唯一性：一项任务只能出现一次，任务之间不能相互包含。比如说要盖一个房子，列了其中一个子任务是购买建筑材料，在列另外一个分支的时候，又列了一个要购买水泥，那么这两个之间实际上就存在着相互包含的一个关系。

第四，责任性：每个节点只能有一个负责人/部门。

第五，可行性：节点目标在付出努力的情况下可以实现，避免设立过高或过低的目标。

第六，灵活性：有一句话叫计划就是用来变更的。要能够适应实际情况的变化，对WBS进行灵活调整。

WBS实际上很多的规律是和SMART原则是相符合的，所以建议大家做完WBS之后，最好要用SMART原则再复核一下。

WBS的基本单元是工作包WPD，即Work Package Definition，它是分解结果的最最小部分。每个工作包的定义通常包括以下内容：

1. 工作范围：工作包要完成的任务和数量。

2. 质量要求：根据相关规范和质量标准来明确各工作包的质量要求。

3. 费用预算：一般按照精益成本分解到工作包中。

4. 时间安排：根据研发流程确定工作包的活动顺序，形成工作包活动间的逻辑关系。

5. 资源要求：根据各个工作包的要求进行资源分析，尽可能实行资源的优化配置。

6. 责任承担：每个工作包应有一个明确的负责人，做到责权明确，便于实施、控制和考核。

制定WBS时，一定要与团队成员充分沟通，成员一起参与制定的计划，理解为什么要这么做，执行起来就会更有动力，也可以将抱怨减少到最小。

随着软件系统越来越庞大和复杂，有时候从一开始就去做一个很彻底的WBS是没办法实现的，所以现在更多的是把敏捷和WBS结合起来，这其实是更为明智的一种做法。

需要推荐靠谱PMP/软考/NPDP/CSPM机构的同学可以关注我后台回复【推荐机构】

备考资料分享如下：