什么是WBS

当你发现一个项目很难完成时，不妨把它分割成一块一块的，将所分的小块交给相应的人去开发去管理，各个突破，项目就会简单多了。

在项目管理中，有一个专业名词—WBS ( Work Breakdown Structure ) ，即工作分解结构。在做 WBS 拆分时，有以下几个原则：

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

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

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

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

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

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

如何做好WBS

WBS分解可以根据可交付成果进行分解、可以根据工作过程分解、也可以采用混合模式进行分解。将一个大项目分解成一个个可以完成的小目标，最后将分解过的工作落实到个人。管理者可以通过脉络图功能对每个事项进行拆解，每项被拆解出来的任务都可以进一步设定开始、结束时间，每个被分解后的任务状态和完成情况都是是可以量化的，而且都有具体的开始和结束时间的要求。

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

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

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