4.7.6　处理经验

既然工作分解如此重要并且在实际中有效，那么如何才能在项目的计划阶段就做出一个完善又可行的工作分解呢？

1.改变思考方法

常见的分解基本上是按时间的先后顺序，或工作实施顺序来分解的。但是，WBS分解中并没有要求分解的工作之间需要有一定的时间关系，主要的分解原则是：一是横向到边即百分百原则，指WBS分解不能出现漏项，也不能包含不在项目范围之内的任何产品或活动；二是纵向到底，指WBS分解要足够细，以满足任务分配、检测及控制的目的。

根据这两个原则，没必要一定按照时间顺序或项目实施顺序来分解项目，完全可以按照其他的标准来分解，比如按照项目的最终交付成果来分解就是一个不错的分解方式。

2.按目标分解

工作分解结构（WBS）：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。具体来说，就是在总体上按目标分解，局部可以按成熟的工作流程分解。这样就让项目管理者能够更多地从宏观的角度把握整个项目的进展情况，而不是注重局部的工作，最终忽略了部分细节，使项目开发成功。

一个WBS分解中的局部范围可按工作的时间顺序分解，但最好计划人与实施者都能对这个局部工作有丰富的实践经验，或已经形成了针对这部分工作的成熟模型。分解后应达到：活动结构清晰；逻辑上形成一个大的活动；集成了所有的关键因素；包含临时的里程碑和监控点；所有活动全部定义清楚。

没有计划的项目是一种无法控制的项目。在高技术行业，日新月异是主要特点，因此计划的制订需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如，对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法。即根据总体阶段划分的总体WBS和专门针对详细设计或编码阶段的二次WBS。学会分解任务，只有将任务分解得科学、合理，才能做到心中有数、有条不紊地工作，才能统筹安排好时间。统一的、标准化的WBS分解体系对解决软件工程项目管理中存在的问题，对快速提高项目管理水平具有重要意义。

在软件开发的整个过程中，从开发经理到系统分析员到高级程序员到普通程序员把任务层层分解，到最后，变成一堆纯敲代码的体力活，这个过程中存在许多不合理的过程。比如，一方面要高级程序员写大量简单的方法，很烦、很费时；另一方面，大量初入门或者还在校的程序员苦于找不到程序员工作不得不闲着，甚至改行。应该让合适的人做合适的事，让大公司不养闲人，让每个想做编程的人都有机会。要避免软件公司闲的时候养太多闲人，忙的时候又犹豫是否不招人。招人的花费挺多，且跳槽率高，不利于后期维护修改。

进行任务分割时应当注意任务之间关于知识和技术的耦合程度，以及任务内关于知识和技术的内聚程度，以减少项目内耗。尽量做到低耦合，以降低对成员之间交流的依赖程度，让大多数成员（需要把握全局的骨干成员除外）无须考虑太多繁杂的、不相干的东西；尽量做到高内聚，让成员可以尽量发挥他的能力并掌握已经获得的项目的相关信息。

对于划分好的任务，要仔细地分析它的难点和工作量，这些东西都是任务分配必需的约束条件。一定要结合技术含量、相关知识的学习难度来深入考虑，不可过分依赖表面数据（代码行/页数/功能点数）来评估。

任务分割完毕之后，就可以开始分配任务。分配任务的总则是减少对交流的依赖。

对于不同的人来说，同一个任务的难度是不相同的。因此，要调整任务分配方法，让合适的人做合适的工作，减少整体难度。

分配过程中，尽量把高耦合的任务分给同一个成员，避免把过多过琐碎的无关任务分给同一个成员。

此外，分配任务时，还应当把任务相应的知识/技术要点列表，连同其他任务资料一起提交给成员，以便成员能够提前做好准备，做到胸有成竹，以避免不必要的技术风险。如果工作量实在太大，或是工期要求太紧，不得不把高耦合任务甚至同一任务分给多个成员负责，这时候就要特别注意成员间工作相关知识的同步、信息的交流问题。选择几个比较友好的人，让这几个人坐在一起工作，就能使他们方便地交流。

如果由于成员调度、个人进度、需求变更、以前遗漏的任务或者某种不可抗力等原因，而不得不更改任务分配，这时候一定要考虑如何最大化地利用项目人员已经做过的工作、已经获得的项目相关信息，尽量减少任务更改而引起的交流、培训和再教育花费。