一个令人震惊的事实是连生产率这样的常见度量数据都没有一个简单的定义。连我们日常经经常使用到的公式：生产率=工作产品/工作量（工作产品能够是代码行，功能点，也能够是不论什么能够计数的东西。比方文档页数）都是错误的。

假设你正常尝试使用生产率做度量，那么至少应该先分为以下两种度量数据。

注意以下的样例为了便于理解使用的是代码行，但实际上这两个概念是IFPUG（国际功能点用户组）对功能点计数时做的分类。

应用类数据 Application Type

以下这段对话将产生一个应用类度量数据：

A：“这个软件有多少代码行？”

B：“等我数一下……10000行”。

A：“多少人天开发出来的？”

B：“大约100人天吧”

A：“那么生产率=10000行/100人天=100行/人天”

这样的生产率是按一个应用（Application这个词汇的来历）的静态规模度量产生的生产率。过一段时间会发生戏剧性的变化：

三个月后……

B：“我们又改动了一些代码，添加了一些代码，可是也删除了一些代码”

A：“哦？”

B：“多投入了100人天，只是如今还是10000行。”

A：“那么如今的总生产率是：10000行/200人天=50行/人天；假设仅仅算二期么……0。我也帮不了你了”

B：“好吧……二期算是白忙一场”

开发类数据 Development Type

A：“这个软件有多少代码行？”

B：“一共同拥有两期……等我数一下……第一期100人天开发了10000行……第二期也是100人天，添加2500行，删除2500行，改动5000行”。

A：“那么一期生产率=10000行/100人天=100行/人天”

B：“二期呢？”

A：“二期生产率=（添加2500+删除2500+改动5000）/100人天=10000行/100人天=100行/人天”

B：“yeah!“

A：”只是。也有的体系说二期生产率=（添加2500+删除2500/2+改动5000）/100人天=8750行/100人天=87.5行/人天

B：”啊？“

A：”等下……还有体系说二期生产率=（添加2500+删除2500/4+改动5000/2）/100人天=……这个，你自己算吧。

“

B：”好吧。总算比白忙一场好。

“

怎样使用？

场景一：计划与绩效考核=开发类数据

由于增删改都要花费工作量，所以用开发类数据做计划和考核更加公平一些。

只是，一般採用功能点更加合理一些。比方在重构中极有可能删除大段的代码（我们以前在15分钟左右把4000行代码重构为55行，功能不变）。而实际上应用的变化并不大。假设用这样的外界（客户。高层）难以感受到的“变化”来做度量元，非常难得到认同。

三种体系（增删改权值同样，或/2。或/2/4）选择哪个好呢？

我也不知道，由于这三种体系都有人在用。我的建议是：

1. 假设刚刚開始做度量

随便选择一个方法就好了，可是请记录下原始数据。

也就是说。要记住有多少新增，多少删除，多少改动。

2. 数据积累比較多了

请按三种方法都计算一次，然后对照一下计算结果和实际工作量的相关系数（相关系数日后会科普一下。Excel表里变有这个函数CORREL(B1:G1,B2:G2），相关系数越高表明用这样的方法做估算更接近事实。

度量分析没有“理论上哪个最好”，仅仅有数据本人才有发言权。

或者说。度量分析的本质就是消除各种理论的主观性、片面性、理想化，把发言权留给数据本身。

场景二：需求变更控制

只是，不论有多少理由，一个软件仅仅改动、删除功能而不添加功能。都不是一个正常的事情。

过多改动功能表明需求分析最初做的不好。而删除功能则表明做了过多的无用功能。

为了约束团队，防止他们把“改软件”当作工作，须要定期监控两者的比值：应用类/开发类。假设这个数据不断下降。表明大家都在改动之前的功能，非常久没有大量添加功能了。

在小而美的产品研发中，改动功能可能是一个常态，但这不能作为開始能够不深入思考“最佳功能”的理由。

在项目开发尤其是外包项目中。仅仅改动而不添加功能是一个灾难，由于客户多数时候不会为改动功能付费，他们觉得这是由于乙方未能深入分析需求造成的。

场景三：编码有效性

也就是用多少代码能实现多少功能的问题，编码有效性越高，则所需代码越少。（日后有具体文章描写叙述）

当然，这里的“功能”指国际标准功能点度量出来的功能，而不是我们平时所说的“个人理解不同规模也不同”的那种直觉功能。

在这样的场景中，应该使用：编码有效性=总代码行/总功能点数=总代码行/应用类功能点数。

比方在之前那个样例中，第二期代码行可能还是10000行，可是假设功能点添加了，那么编码有效性实际上增高了。

完整演示样例

以下是一个功能点、代码行、编码有效性、应用类、开发类数据的完整应用场景。

A：“这个软件有多少代码行和功能点？”

B：“一共同拥有两期……等我数一下……第一期100人天开发了10000行。200功能点……第二期也是100人天。添加2500行，删除2500行。改动5000行；添加50功能点，删除20功能点，改动30功能点”。

A：“那么一期代码行生产率=10000行/100人天=100行/人天，功能点生产率=200功能点/100人天=2功能点/人天”

B：“二期呢？”

A：“二期生产率=（添加2500+删除2500+改动5000）/100人天=10000行/100人天=100行/人天。功能点生产率=（增50+删20+改30）功能点/100人天=100功能点/100人天=1功能点/人天”（临时仅仅用第一种增删改权值算法）

B：“哪期项目做得快呢？“

A：“从代码行看，一样；从功能点看，一期项目快一倍。

”

B：“以哪个为准好呢？”

A：“功能点好，比較easy给客户和领导交代”

B：“二期真烂。

”

A：“也未必，你们的编码有效率提升了。

”

B：“怎么讲？”

A：“二期完毕后（不是二期开发本身），整个产品还是10000行。功能点却添加为300。你们如今的代码效率已经达到10000/300=33行/功能点了（越低越好。一期是10000/200=50）”

B：“生产率减少。编码有效性提高……怎么做总体评价呢？”

A：“生产率提高是终极目标。只是编码有效性的提升有利于未来的生产率和质量的提升。所以。如今总体评价是生产率下降了，未来要看你们以后能否真正发挥编码有效率的优势了。”

怎么样？假设是我，假设能写一个由数字组成的项目报告。我才不会写一大堆模棱两可的文字呢。