[讨论]WBS应该多细致？... ...

marsoon

问题的引出

项目分解不宜太细
作者： WEBYY

我们经常遇到人们问我们“我们这个项目有多少任务”或“我在做项目计划时应该做多详细”这样的问题。这种情况不只是刚做项目的项目经理会问，有些经常做项目经理也会感到困惑。对于在项目分解时遇到的这些问题，我想谈一些自己的看法。
项目经理经常容易犯的一个错误就采用太细的清单任务列表法，也就是把项目分成了太多的任务，他们把项目分解到了一个小时就能完成的琐碎的任务。当然认为项目计划应该详细到项目中的每一个人应该做的每一件事这样的思路是可以理解的。但是如果认为一个项目经理的工作就是一天拿着一个写好了的、有许多任务的单子，然后把已经完成的任务一个一个销掉，这就有些不对了。也就是说，项目计划应该是为了做好项目上的每一件事的一步一步的程序，这样做的目的是为了防止同样的事被重复地做。如果项目经理没有这种理念的话，那么就提高了我们重复做这个项目中有些相同的事的可能性。

有许多人认为在项目中，项目经理应该尽力去想每一件事。如果是一个小项目，项目经理可能还有这个能力和精力，如果是比较大的项目，特别是当一个项目经理同时管理着几个性质相同或相近的项目时，如果让项目经理去考虑每一件事，这种可能性是很小的。因此在现实的项目管理中，我们必须依靠专家的力量，即使这样一个项目经理和它的智囊团要想管理项目中每一个小任务，也是不太现实的。

这种太细的清单任务列表方法使项目管理经理在做项目计划时增加了成百或者上千的任务。这些任务大多数仅需要几个小时或者几天的时间。这样的项目分解能够使得项目经理更好地控制和导致项目成功吗？从我们的观点看，一个太细的清单任务列表方法不能使我们很好的控制，可能更易增加项目不成功的可能性。

首先，详细的任务列表方法导致甚至是鼓励了项目经理在项目上采用微观管理。当一个项目里有不认真工作的人时，可以采用微观的管理方法。但事实上很少有一个项目团队里大部分人员都是不认真工作的人。我们相信你的项目团队中大部分人在微观管理方式下不能取得成功。这种方式其实是对那些本应对任务结果负责的人过分依靠项目经理，而不是独立处理问题提供了方便。

第二，项目经理是采用通过考查下属取得的成绩来管理下属，还是采用看下属是否完成了某项任务来管理他们，哪一种方式会更有效呢?我们相信前者会更有效。如果采用后一种方式管理下属，可能会出现下属虽然把任务完成了但没有取得应有的成果的情况。

第三，这种详细的任务列表的方法要维持起来是比较困难的。因为如果这样的话，人们在许多任务上都必须做出汇报，其实这样做可能使那些本来重要的、对进度影响比较大的情况的汇报的机会就相对地减少了。另外不管有没有助手，在这种情况下，一个项目经理每天都要听很多汇报，由于精力有限，他可能就不能正确处理那些实际上十分重要的事情，如果这种情况一旦发生，就会影响项目的进展，或者增加项目的成本。这听起来好象在现实中不太可能发生，其实在现实的项目管理中经常会有这种现象出现，甚至在大项目和重要的项目上也有时出现。我的观点是，既然没有一个人的精力是有限的，那我们在考虑项目计划分解时，为什么还花这么多时间去把项目分解成那么细小的任务呢？

一般来说，我们喜欢在做项目细分时，大多数的任务在1—8周，是比较好的。

问题
1 WBS应当在什么时候拟定最为恰当？
2 分解程度需要多细致为最佳？
3 WBS的更改和维护怎样进行比较合适？

rabing

在进行WBS前，首先要进行梳理EPS及OBS，这样基本就形成了WBS的雏形了，

marsoon

谢谢扬子兄，呵呵。
但是如果具体的环境和形势要求必须对WBS更改，事实上，国内项目这一点也很普遍。
那么WBS的更改和相关的举措、影响会怎样呢？

请大家赐教。

扬子

任务分解太粗或太细, 都会不便于工作分配, 不利于成本/进度控制, 并且会给项目成员间带来额外的沟通负担, 这个问题几句话还真难说清.

个人浅见:

1. 在界定工作范围时WBS应该成形了, 而在 项目启动会议上进行工作包的分配时结合沟通计划再次进行确认;

2. 分解程度不必拘泥 80 hours 原则, 以适合项目工作内部逻辑为宜, 并且我觉得划分清晰比细致程度更重要 ----- 可以参考金字塔写作原理的 MECE 原理进行分解 ?

3. WBS 的更改和维护越少越好, 呵呵 !