其实，这要看你在什么层面，从什么角度去使用WBS；以及你的项目所具有的一些特征。这些将决定你如何有效地使用WBS工具去管理你的项目。

下面谈谈我对这个问题的看法：

在这里用这个表格可能更直观地表达我的认识

面向活动的分解方式非常适合于服务类项目的工作分解，而且这类项目的工作结构本身应该不复杂，例如网上流传很广的结婚WBS案例。当然，这不是说面向活动的WBS就一定结构简单，但是WBS的本质并不是“穷举”所有的工作细节，而是科学合理的管理项目工作。你可以参考关于80Hrs规则的文章，来了解WBS的分解精细度问题的答案。

（暂且放下面向成果分解方式的评价）

面向活动的分解方式最大的问题就是对变更的控制力不够，因为就任务本身而言也许他在项目实施过程中不会改变，但是它产生的结果很有可能是会发生变化的。比如：采购任务按照设计图纸要求采购设备。无论你将活动分解得多么详细，你都无法跟踪最终采购设备和图纸标明设备是否存在差异。另外，当你管理的项目是由很多参与方共同完成的（例如AEC工程领域），那么针对任务的分解方式是非常脆弱的，因为你很难规定一个独立承包商的所有任务（即便你有合同约束他们），这有悖于另一个被普遍接受的WBS设计原则100%规则。

面向活动的分解方式同时也容易导致WBS演变为schedule工具，或者WBS容易沦为项目进度计划的工具而不是基本的项目管理工具。这一点在我看到的wbs中甚至成为了一种趋势。[Lax老兄，我可不想与你开展新的论战] 但是我们不得不承认，至少在有限的范围内，有很多人忽略了WBS作为范围管理工具的作用，而更多地将它用于schedul计划和管理。

面向活动的分界方式的重要基础就是任务的成果简单明了，不存在任何可变因素。例如获得“某某部门或领导的批准”，相反如果活动定义为“确定区域供电方案”就有可能包含大量的可变因素。对付这一问题的方法有两个：

1. 将活动继续分解，直到它不再有任何可变因素；
2. 定义活动的可交付成果（还是需要基于成果的分解和定义）。

[这里我要提醒sam: 当WBS含有很多不确定因素的时候，维护WBS结构绝对是件非常繁冗的工作]不同的方案有可能导致不同的工作任务模式。

小结

上述论调似乎在刻意“贬低”面向活动的分解方式，如果你这样认为就大错特错了！事实上面向活动的分解方式特别适合个人对于项目的管理，至少我是这样的。毕竟，个人看待项目管理不能避免的会面向活动。另外，如果项目是完全属于组织内部的，那么面向活动的分解方式可以提高组织的协同效率。

而PMI则倾向于面向成果分解方式，并且在其出版的《Practice Standard for Work Breakdown Structures》 有详尽的阐述。据个人的实践，在AEC领域，面向成果分解的方式是唯一的选择。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)