浅析项目工作量估算方法

                                                               浅析项目工作量估算方法

       马克思主义的认识论和实践观告诉我们，认识源于实践；总结实践经验、深化认识，进而指导实践，通过实践检验、修正认识（理论），螺旋式上升地提高认识。

       项目管理作为一个实践性很强的学科，特别需要理论实践相结合。在实际的项目管理工作中，每个管理者都有自己的一套办法，有的不看理论，纯粹自己摸索的（称之为“野路子”）；有的是纯靠理论的；有的是理论与实践相结合的。纯靠理论的那种，如果是用来教学，那还是合适的，如果真用到项目管理中，通常不会获得成功。对于不看理论，自己探索的，也不乏出色的管理者。我们走近这些人，去研究他们的管理模式后就会发现，虽不看理论，但管理方式却与理论如出一辙。对于理论与实践相结合的，无疑是最好的，也是最适宜绝大多数项目管理者的。我们也建议从事项目管理工作的同仁能边做、边总结、边学习、边分享，取得更大的成绩与进步。

       本文从理论和实践两方面出发，带大家再次温习一下工作量评估。

第一部分，理论学习。

      项目工作量估算是对项目全生命周期各阶段活动所需投入的人力资源成本进行度量量化、统计的行为活动，产出的成果应成为项目工期估算、计划制定、资源需求估算、风险管理的依据。

       常用的工作量估算方法有：Delphi头脑风暴(DWB)法、类比估算法、功能点分析（FPA）法和三点估算法。

       类比估算法，根据以前类似项目的实际工作量，凭经验来推测当前项目的工作量。例如，以前新增过一个重要空白凭证，实际工作量大概是15人天。参照历史经验，我们推测当前的新增网银Key重要空白凭证的项目为20人天（多出的5人天为网银端改造）。

      Delphi头脑风暴(DWB)法（德尔菲估算法），也是一种比较典型的专家判断法，是由许多专家运用结构化的方法来做出主观判断。简单来说就是背对背评估、偏差不超过一定数值（比如10%）有效。德尔菲估算法一般进行4~6轮，使大家的意见逐渐趋于一致。

      功能点估算法，是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。该算法用的最多的是功能点技术（Function Point，FP），该技术是Albrecht在1979年首先提出来的一种比较流行的估算方法，它将估算的关注点集中于程序的“功能性”和“实用性”上，而不是LOC的计数上。

       这种方法的计算公式是：

      功能点=信息处理规模X技术复杂度。

      信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等;技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。

       三点估算法，是指估算三种可能的工期，然后加权平均，得出活动的平均工期和标准偏差。常用公式包括：

                      期望工期 = （乐观估计+ 4 X 一般估计  + 悲观估计）/6

                      标准偏差 = （悲观估计 – 乐观估计）/6

                      方差 = [（悲观估计 – 乐观估计）/6]2

     公式中，期望工期是指有50%的可能性在该工期内完工；乐观估计是指在各种条件都很好的情况下，活动所需要的最短工期；悲观估计指在各种条件都很差的情况下，活动所需要的最长工期；标准偏差指悲观与乐观估计之间的离散程度，表示活动的风险的大小；方差指标准偏差的平方，用于计算整条路径的总工期的标准偏差。

 第二部分，实践经验。

      功能点估算法。通常，项目经理在接到项目后，评估完可行性后，就要做一个WBS分解，将项目先按大的模块拆分、再逐层细分。理论上，拆分的粒度越小越好，但考虑到工期问题，通常我们能拆分到某支具备独立功能的交易就可以了。基于WBS，我们评估通过定义每个功能的输入有多少字段、输出有多少字段、用到多少张数据表、用到什么文件等，定义项目的复杂系数，然后可以自动计算出项目的最少工作量、推荐工作量和最多工作量。

       最后项目经理采用的工作量只要在区间范围内即可。

       该方法操作起来较为简单，也方便高层领导验证，防止虚报；方法基于组织的历史经验数据建模，可持续改进优化。

       要用好功能点估算法，需要做到以下几点：

1、项目类型划分。通常可分为新建类、升级改造类，不同类型也对应不同的复杂系数。

2、功能拆分尽可能细。可下探到交易、函数、数据表、文件。从这个角度讲，有点像自下而上估算法。

3、功能分类，初始化复杂系数。将功能分为查询交易、维护类交易、新增类交易、删除类交易、新增数据表、修改数据表、文件上传、文件下载等等，并为每类功能定义初始的复杂系数（这个靠专家判断了）。

4、建立与需求跟踪矩阵的关联。防止为了凑工作量瞎编功能。

      德尔菲估算法。项目经理在拿到需求后，首先做需求分析，列出需求涉及到的功能，其实也是框定范围、做WBS分解的过程。理论上，这一步也是越细越好（每个需求条目最好不要超过80人时，即10人天）。第二，评估每一个需求条目的工作量。这一步用到了专家判断和德尔菲估算法，首先每位评估人背靠背根据自己的经验判断完成每个需求条目所需的工作量，并提交到系统；然后系统针对每个需求条目对应的工作量加总取平均，然后将每位评估人评估的工作量与平均值比较，任一需求条目的偏差超过阈值（比如10%），则视为不通过，需要重新评估；如此反复，直到偏差在10%以内。

德尔菲法有三个特点：
（1）反馈性：表现在多次作业，即在偏差超过阈值时反复修订与评定。
（2）独立性：参与评估的专家之间独立评估，不商量、不讨论，只通过他们头脑中的数据资料和经验，经过分析，判断和计算，确定出理想的结果。
（3）统计性：对各位专家提出的意见进行统计，再取平均数或是中位数统计出量化结果。

 

   第三部分，个人总结。

    在外包模式下，工作量估算结果经过计算后即为开发该功能所需花费的成本，所以企业必须重视。企业需要根据实际情况选择适合自己企业特色的估算方法，做到客观、公正。

   从个人角度，我认为“功能点估算+德尔菲方法”。首先，企业收集历史经验数据搭建功能点估算的数据模型，设定关注参数，比如项目类型、功能点复杂度、功能点是否重（chong）用、功能点影响范围等；然后采用德尔菲方法，交由3名专家以上的评估团进行评估，评估团背靠背设定关注参数；最后，每名评估人提交评估结果，系统检查评估偏差是否超过阈值，若超过，则重新开始，直至在阈值范围内。

   无论采用哪一种评估方法，最后的评估结果都要进行正式评审。