[原创]WBS分解策略 - 栖息谷-管理人的网上家园

1. 引言
渐进明细是项目的特点，但这并不意味着不需要计划。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。在软件高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法，即根据总体阶段划分的总体WBS和专门针对系统设计或编码阶段的二次WBS。这其中部分的原因是需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在需求分析完成以后才能准确地得到系统设计或编码阶段的二次WBS，根据代码模块的合理划分而得出的二次WBS才能在系统设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。

Work Breakdown Structure （WBS）工作分解结构：对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。WBS将项目的整个范围组织在一起并加以明确。每向下分解一个层次，就意味着项目工作的定义深入了一步。WBS最终分解为工作细目。WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。（2004年版PMBOK指南）
Work Package（工作细目，也翻译为工作任务包），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。（2004年版PMBOK指南）
Control Acｃｏｕｎｔ（控制账目，CA ），是综合范围、预算、实际费用和进度，并对绩效进行测量的管理控制点，控制账目设置在工作分解结构（在选定水平上的具体组成部分）的事先选定的管理点上。每一个控制账目都可以包含一个或多个的工作细目，但是每一个工作细目只可以在同一个控制账目相联系。（2004年版PMBOK指南）

            WBS的最底层次为Work Package（工作细目），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。
                为什么WBS的最底层次不是Schedule Activity（计划活动）而是Work Package（工作细目）呢？
            首先WBS是作为项目范围管理的工具、技术，项目范围管理关注点是项目的组成部分，它面向的是可交付成果，而不是过程。
            其次WBS定义的是项目及其组成部分，是Schedule Activity（计划活动）定义的依据，而不是去定义Schedule Activity（计划活动）；
            第三 Schedule Activity（计划活动）是项目进度表的单个组成部分，不是WBS的组成部分。对于这一点，很多人理解上可能有困难。因为，习惯说法是活动是由各项具体工作构成的，而上面的定义我们从字面上看的习惯说法与PMBOK的定义正好相反，但是从本质上去理解两者应该是相同的，只是说法不同。因为在项目管理尚未引进中国以前，我们把活动等同于项目。

WBS的结构是由逻辑推演而成的，通过层层的包含关系，非常严谨。结构化是WBS的一大重要特性，WBS的逻辑结构错误会直接导致项目实施过程发生错误，严重的会带来项目的失败。
“做正确的事，正确地做事”是我们从事项目管理的一句格言，WBS首先解决的就是“做正确的事”问题，只有明确了“做正确的事”，“正确地做事”才有基础，所以我们说WBS是现代项目管理的重要基石。

正在写THE PURPOSE OF WBS 的论文，中文都不是很明白，真难写啊。

我一直以来都是PDCA，现在和做正确的事并正确地做事结合，对我的启发更大了，感谢LZ的总结归纳。

分析得非常的清晰，活动和可交付成果的差异，活动是一个动作过程，实现可交付成果的动作流程，可交付成果是活动的结果

WBS分解方法中的自下而上法，还没有用过，以后有机会试试，谢谢。

另外，除了“确定WBS是否已分解到足够详细的一层”，搂主能不能也总结一下“如何确定WBS是否分解得过细”？谢谢。