摘要:随着IT产业的发展，国内软件项目越来越贴近客户的现实需求，项目工程涉及多方面的集成，包括网络、硬件、软件平台、行业软件等的集成越来越紧密，软件开发细节上涉及专业软件包的整合。同时客户对定制化的需求及工期的需求也越来越高。

作为项目经理，如何在满足客户需求，并在人力资源不足（员工成熟度不够、队伍不稳定、工程师工作积极性不高）、工期紧的情况下，有效的制定和执行项目计划，是项目经理一个重要的能力，而要完成这一进度人员的组织非常重要。

本文作者通过项目经理培训，并结合多年软件行业从业之经验，来研究和探讨项目执行过程中任务的分解和执行中人员组织方面的思路，希望与正从事软件项目管理的同行分享与共勉，力图对后续的工作提供一些指导。

一个软件项目必须满足：目标、时间进度和预算的要求。要完成这个项目而建立的软件开发组织是一个复杂系统。表面上看起来目标、时间进度和预算，三者好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，特别是在实际工作中团队的行动会变得越来越慢，往往可能导致项目进度的不可控制，使成本上升，甚至导致项目的失败。

在项目经理培训中，涉及的内容很广泛。本文试图仅仅从项目的任务分解和执行中人员的组织来进行一些讨论。主要有下面几个方面来谈我的理解。

1. 问题的提出：项目的进度度量

1.1进度不可控的原因

在实际的项目执行过程中 ，缺乏合理的时间进度是造成项目滞后的主要原因，原因是什么呢？

首先，对估算技术缺乏有效的研究，很多项目经理对项目进度过分乐观的估计，它反映了不真实的假设——一切都将运作良好。

第二，采用的估算技术隐含地假设人力和工作量可以互换，错误地将进度与工作量相互混淆。

第三，对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。

第四，对进度缺少跟踪和监督。跟踪技术和常规监督程序。

第五，当意识到进度的偏移时，下意识的反应是增加人力。只会使事情更糟。

对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。在估计和进度安排中，某个任务可以分解给参与人员，他们之间需要相互的交流。子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。

沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。因此工作量随人员的数量呈线性变化：按照n(n-1)/2递增。

1.2进度的经验性安排

项目进度和工作量的不同：工作量只是子任务的数量的简单分解。项目进度依赖于顺序上的限制，以及资源制约、培训时间、管理成本等。

这里有一个基于经验的时间安排尺度。假设以一个项目的总体执行项目周期为1。对于软件任务的进度安排的经验法则：

    1/3计划
    1/6编码
    1/4构件测试和早期系统测试
    1/4系统测试，所有的构件已完成

除了系统测试，进度基本能保证。不为系统测试安排足够的时间简直是一场灾难。因为延迟发生在项目快完成的时候，问题才出现在客户和项目经理面前。延误发布，将付出相当高的商业代价。上述的二次成本远远高于其他开销。

因此，在早期进度策划时，允许充分的系统测试时间是非常重要的。开发并推行生产率图表、缺陷率、估算规则等等，而整个组织终会从这些数据的共享上获益。项目经理需要挺直腰杆，坚持他们的估计。

当一个软件项目落后于进度时，加派人手可能产生的进度灾难。

    要及时聘请到多么能干的新员工；
    新员工需要接受培训。有经验的职员将投入到原有进度安排以外的工作中；
    原先划分为三个部分的工作，会重新分解成五个部分；
    更多的交流成本、管理的工作；
    某些已经完成的工作必定会丢失，系统测试必须被延长。

2. 团队的组织

大型项目的每一个部分由一个团队解决，而并非一拥而上。由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

2.1协作成本

需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。所以并不是人越多越好，系统应该由尽可能少的人员来开发。

2.2成员差异

程序员好的和差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异。