很多项目经理对于项目评估、管理、控制的能力基本上是来自于项目经理本身的从业经验，由于各种各样的原因，项目经理更多的是一个全才，这是在当前环境下，保证项目还能正常运行的必然结果。在实际情况中，项目不但耗时长，而且成功率也很低，其中一个很重要的原因是对于需求的工作量评估没有一个具体的依据，很多时候都是想当然的估算一个数字，当项目开发过程中来自于需求变更后对新需求的工作量估计不足导致产生连锁反应，后失去对项目的控制。
本文的目的在于提出一种对项目总体工作量估算的模型，用于项目经理在面对原始合同进行概要设计，项目进行过程中面对需求变更时计算工作量的一种参考依据。这个模型的目的是要有效的减少工作量，这并不意味着会少做事，而是希望引导多做正确的事情。特别是这个模型也能为提高工作效率指明方向。
要设计一个模型，首先要对日常工作进行全面的分析，抽象出工作的每一个步骤，对每个步骤中所需要用到的知识进行归纳，还需要对每个步骤中的复杂度进行评估。
在一个项目的开发过程中，在面对一个业务功能时首先做的是从需求中设计表结构，然后为表结构定义各种各样的关联，定义完关联后基本上在大脑内形成界面的大致样子，然后开始写代码。
从上面的过程中，大致可以分成下面的两个步骤：
1. 数据结构设计阶段
2. 根据数据结构编写代码阶段
接下来分析下每个步骤所用到的知识。
1. 在数据结构设计阶段所使用的知识分为以下几个部分
1) 数据库设计知识
2) 业务知识
2. 在根据数据结构编写代码阶段所使用的知识分为以下几个部分
1) 数据库操作知识
2) 后台编程语言知识
3) 前台编程语言知识
4) 业务知识
通过以上的分析可以看到，在第一个阶段所需知识单一，更多的源自于经验。由于所使用知识比少，当需求产生变化时，为变化所花费的时间也比较少。因此可以得出一个简单的结论，当某一个步骤所需知识比较单一时，对该步骤的变更和编码所需时间都比较少。
那么可以看到在第二个阶段，所用知识复杂，所以必须要对第二阶段进行细分
在第二阶段，通常的做法是，根据业务功能，首先编写关于这个业务表的增删改的代码，再根据表之间的关系写出数据关系代码，后根据设计的界面样式，编写界面代码
在这个阶段也分成以下几个步骤
1. 编写单表的维护代码
2. 编写该表与其他表的业务关系代码
3. 编写界面代码
同样的，再来分析下每个步骤所使用的知识
1. 在编写单表的维护代码所使用的知识分为以下几个部分
1) 数据库单表操作知识
2) 后台编程语言知识，仅需要知道如何操作数据库
3) 业务知识
2. 在编写该表与其他表的业务关系代码所使用的知识分为以下几个部分
1) 数据库多表查询知识
2) 后台编程语言，这里是根据业务的复杂度来决定所使用的知识范围。
3) 业务知识
3。在编写界面代码所使用的知识分为以下几个部分
1) html知识
2) javascript知识
3) css知识
4) 后台编程语言，仅使用到与前台界面编写相关的部分知识。
5) 业务知识
通过以上分析可以看到，在编写单表的维护代码阶段是使用知识少的一个步骤，同样的当业务产生变更时，为该处的变化所用的编码时间也比较少，而变化所花费的时间与表结构的调整所花费的时间是正比关系。这个关系将在复杂度分析时进一步说明。接下来看编写该表与其他表的业务关系代码和编写界面代码部分，这个2个阶段所使用的知识繁多，并且涉及的知识面也很广，是项目中花费时间多的地方。但是在实际项目开发中并没有再对这两个步骤进行更细的分解的过程。
现在可以得出一个这样的结论，工作量是与所使用的知识相关的。一个业务所使用的知识点越少，所涵盖的知识面越少，那么所耗费的工作量也会越少。由此，当需要提高工作效率时，尽量少的使用知识是一种有效的手段。但是在实际情况中，并不能有效的减少知识使用种类，只能在使用知识的熟练度上下工夫，一个开发者所掌握的知识熟练度越高，那么相对的工作量也会越少，一个知识点的入门门槛越低，那么工作量也会越少。因此，设置工作量为G，知识点入门门槛为B，B1为交给新手人员开发的知识点，知识点总数为C，P1为高级开发人数的，P2为新手人数，那么G = ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 。
对知识点分析完后，再对业务的复杂度进行分析，知识点的应用可以看作是开发中的横切方向的话，那业务的复杂度是开发中的纵切方向，业务的复杂度贯穿了所有的开发步骤。
在本文中，从数据的应用着手，来分析业务的复杂度。
在项目开发中，经常要遇到"类型"这样的业务点，例如职务。对于这一类业务，其主要开发时间花费在"对于单表的增删改查"上。另一种类型的业务，其复杂度高一点，主要应用于该表需要与另一个表进行组合，然后产生一种"所属"的关系，例如权限，角色等，其主要开发时间花费在"对于多个表的所属关系的增删改查"上。还有一种类型的业务，主要是将多个表的数据进行组合转换后输出，例如报表，CMS的模板解析等，其主要开发时间花费在"对于多个表数据的监测和重组上"，后一种类型的业务，主要是为数据附加上状态，例如工作流等，其主要开发时间花费在"对于数据的不同状态的处理上"。
以上4点基本涵盖了做项目时所面对的业务。接下来，我们为这4种业务定一个权值
1.对于单表的增删改查"权值为1
2.对于多个表的所属关系的增删改查"权值为4
3.对于多个表数据的监测和重组上"权值为8
4.对于数据的不同状态的处理上"权值为16
这个权值的比值基本来自于数据的维度，1类业务是单一纬度。2类业务除了要处理多个1类业务外，还需要处理多个1类业务之间的关系。3类业务除了要处理2类业务中包含的，还需要对数据本身进行转换处理，4类业务除了要处理3类业务的，还需要处理数据的状态。后一种业务要比前一种业务多处理一种逻辑结构。
根据这个权值，来看看在项目中经常遇到的情况，以职务为例，开始的需求是1类业务，这个时候客户的需求变更可能如果制在1类业务的需求范围内，那么如果完成职务的业务开发时间为1的话，那么修改的时间应该在<=1的开发时间内。但是，这个时候客户提出一种需求变更，他要求，职务是有从属关系的，例如A部门有属于A部门的职务，B部门有属于B部门的职务，当这类需求出现时，那么开发完成的时间必须提高到4了，从这一种变化可以看出，当需求变更在某一个级别的分类业务内进行变化时，其所完成的单位时间是与权值成正比关系。但是如果需求变更导致该业务的分类级别被提升，那么修改所花费的时间将直接提高到对应业务分类的权值所对应的时间比。
假设工作量为G，权值为D那么G=D(D=1，4，8，16)。再结合前面关于知识点的分析结果，G = D_*( ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 ) ( D = 1 ， 4 ， 8 ， 16 )
公式的完全说明如下:
G = D_*( ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 ) ( D = 1 ， 4 ， 8 ， 16 )
G : 工作量
D : 业务复杂度( D = 1 ， 4 ， 8 ， 16 )
C : 知识点总量
B : 入门知识点总量
B1 : 交给新手人员做的入门知识点总量
P1 : 高级开发人员数量
P2 : 新手开发人员数量
( C - B ) / P1 : 意思是只能由高级开发人员做的事情
( B - B1 ) / P1 : 意思是由高级开发人员做的只需要入门门槛知识能做的事情
B1 / P2 : 意思是由新手人员做的需要入门门槛知识做的事情
从这个公式可以看出D值越小，C值越小，B值趋向于C值，B1值趋向于B值时，工作量是小的。要想D值小，那么在做需求和需求变更时要引导客户避免高权值的需求产生。要想C值小，让开发者只面对少量知识点，是分层开发，每一层的知识点将足够的小。要想B值趋向于C值，必须使用框架来进行开发，要想B1趋向于B值，应该避免让仅需入门门槛知识能应付的需求让高级开发人员来做。
希望这个模型能为项目经理在面对需求和需求变更时提供指导意义，使得在对工作量估算时有据可循。
