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

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

注意下面的例子为了便于理解使用的是代码行，但实际上这两个概念是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：“功能点好，比较容易给客户和领导交代”

B：“二期真烂。”

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

B：“怎么讲？”

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

B：“生产率降低，编码有效性提高……怎么做整体评价呢？”

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

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