本文主要讲团队长阶段工作量估算（一般在一个月以上），它和很多因素有很密切的关系，我通常将它划分为以前几点：

1、所采用的过程。

在瀑布式过程下，风险会不断积累，应对变化的能力较弱，往往按计划发布了第一个版本，但是之后又由于需求或设计变更的幅度出现了大量工作量。相当多的团队在这时失去了对工作量的控制。

在迭代式过程下，风险会较早的暴露以便针对性的解决，应对变化的能力较强，工作量投入相对比较平均，根据需求或设计变更的情况需要考虑部分甚至整体重构的工作量。

需求或设计变更幅度越大，则瀑布式比迭代式耗费的工作量越多。

需求或设计变更的幅度越小， 则瀑布式比迭代式耗费的工作量越少。

2、团队成员的个人能力。

将代码完善、测试的因素、可维护性等一并考虑在内，则一个的开发人员的工作效率很可能是一个一般性的开发人员的工作效率的十倍。

3、项目的计划以及任务的分配在团队成员保持稳定的前提下，合理的人员结构、有节奏的计划、合理的任务分配将大大提升单位时间内的有效工作量，从而加快项目进度。

4、有效工作比率。

即在单位时间内的有效工作量，和人员士气、任务安排、工作的复杂度和难度等密切相关。

好的团队的有效工作量可以达到60-70%甚至再多一些，但是根据一个项目管理培训老师的说法，如果一个团队的有效工作量长期超过80%，那要小心了。

5、风险预防。

包括需求变更、设计变更、人员变更等都会影响到实际的工作量，尤其是人员变更，往往无法由团队本身加以控制。

工作量估算模型：该模型本质上是一个经验模型，主要针对业务复杂型且已有较成熟框架的项目，不知道是否适用于技术复杂型或者协调复杂型。

基于如下假设：

1、宏观上以迭代式（或阶段式）为主，每个迭代（或阶段）包含一个比较完整的需求、设计、开发、测试、发布的流程，各个迭代（或阶段）之间有交叉。总的来说是类似于rup的一个过程。

2、项目团队的结构、个人能力、参与度是一个典型的业务复杂型团队。其人员呈较为合理的纺锤型结构，允许部分人员较为薄弱。

项目管理：需求分析：设计：开发：测试：实施支持=0.5：1：1：2：1：0.5注意：以上比例仅代表工作量比例，不代表团队成员比例，团队成员可以兼不同角色。

3、在每个阶段中，又分为以下几类工作：

1）初始细化。其主要目的是针对性的解决或预防风险，也包括技术架构甚至部分公共模块的开发。该部分工作量取决于风险的高低，通常占一个阶段的10-30%.

2）构造开发。以功能模块（或功能点）为基准单位，按比例分配需求、设计、开发、测试的工作量，参考比例为1：1：2：1.如果该模块包括数据迁移，则额外增加1份工作量。

3）实施支持培训。占一个阶段的5-10% 4）管理沟通协调成本，占一个阶段的10%左右。

4、功能模块（或功能点）工作量估算。

1个基准功能模块通常包含1-2个业务对象，每个业务对象中带业务逻辑的属性大约10个不到，包括该业务对象的简单行为：增、删、改、查。但不包括该业务对象的复杂行为。

在采用成熟框架的情况下下，该基准模块的工作量估算为15人天（取有一定经验的人员），包含初次开发及后续完善的工作量。此时有效工作比率为60%.复杂行为视为简单行为的4倍。

特别复杂的功能点（包含有特定算法的）需要单独估算，在早期以5-10倍估算。

5、风险预防。此部分完全取决于对项目的评估，并综合各方面因素由各估算成员凭借经验得出。（德尔塔法）

其模型如下：T=[（N×P）/S]×（1+X）

T：总工作量，单位为人天N：基准功能模块数目，根据需求按经验评估，可按功能模块细化估算。

P：基准功能模块的工作量，通常取15人天。

S：构造开发工作量占整个阶段的百分比，在50%-75%之间X：项目风险预防，根据经验取值，低的为10%，高的可以超过注意：此工作量和进度并没有必然的联系，破坏项目结构的人员追加并不能带来进度上的利益。

备注：开发技术稳定以及人员稳定的情况下，估个大概，还是有可能的，但实际情况很难。

在前期制定项目时间表，我们不得不评估时间，这是一个基础。

另外常常出现的问题，是我们对风险的估计不足，不知如何给风险留出合适的时间。风险如何控制也是对风险有效评估的前提。

在这其中所使用的评估公式，经常要在项目过程中不断修正，因为这个公式毕竟是个经验公式，你经验积累的过程，也是个校正的过程。

常常遇到的情况，是在项目开始的时候估一下之后，对工作的估算的原理和模型不管不顾了，而是陷入解决项目的细节问题当中。