关于量化考核绩效

用数据、量化来考核绩效是一种管理者无能的表现。

这可以说是最简单的考绩方法，单位时间生产多少件，次品率多少。

管理者希望用数据来衡量其团队的工作效果，其实是一种汇报的思路，依赖这些数据向他们的上级报告自己的功劳。

如何让不接触或少接触自己团队的上级知道自己的功劳、苦劳？于是，计算功能点，缺陷密度，全都来了。

他们用这些量化的数据来考核团队成员，看着各种各样的图表，得意于自己的制表制图技能。

他们只关心自己的工作，不关心团队和成员的成长。

他们不去带领团队寻找问题的根源，只会使团队向着数据挂帅的歪路上越走越远，对项目，对公司的影响也是越来越坏，越来越大。

统计数据、量化本身并没有问题，我也一直在统计（用行话说叫做度量），但是我只把结果用来发现团队、个人存在的问题，寻找原因，及改善的方法。不作为绩效考核的参考。

有网友说“CMMI L4要求度量”，我没研究过，我猜测其要求度量并没说建议用来考核绩效吧。

想起了以前的甲A联赛12分钟跑。运动员的体能测试，国外比国内先进许多，人家用来评估运动员的身体状况，保持运动状态，等等等等做好多事，但就没拿来作为能否参加职业联赛的标准线。我们把体能测试这个方法拿来了，拿来让成耀东痛苦地补考以求有球踢，让姚夏向着带球从不拐弯的路越走越远。足球水平提高了吗？

那么绩效怎么考核？我倾向于用目标达成来考核。

制定一个阶段目标，这个目标需要是可这个的，可那个的，这个那个大家都已熟知，不再赘述，制定目标需要用到度量的数据，通过数据发现问题，寻找原因，寻找方法，确定目标，考察达成情况。

对于团队和个人都是适用的。

譬如，同样是手里握有缺陷密度的度量结果，A是10，B是5，单纯以这个来考绩是没有任何好处的，加上各种权值也是一样。针对每个个人，和他一起分析当前状况，找到改善的空间，和方法，制定一个阶段目标，届时，考察阶段目标的达成情况，以及方法的执行度，综合考察。

这只是考核绩效的一个方面，但是个很重要的方面。

关于用度量结果量化考核绩效的坏处，在James Shore & Shane Warden的《敏捷开发的艺术》一书中看到如下段落：

软件开发生产率是出了名地难以衡量。……在软件领域，我们没有一种客观的方法来衡量产量。一项特性的尺寸是多少？

我们可以通过统计函数点或代码行来度量软件的大小，但这无异于使用立方英寸来度量蜂窝电话的特性。

源代码行数（SLOC）及其语言相关的表兄弟：函数点（function point），是度量软件尺寸的常用方法。不幸的是，它们也常被用于度量生产率。然而，正如外形花哨的手机，软件的大小也并不一定跟特性或价值有关联。

设计良好的代码是模块化的；它支持多项特性而没有重复。设计越好，重复越少，代码行数也越少。这种精心的设计需奥付出时间和精力，但带来的结果是更少的bug和更容易修改的软件。

汇报源代码行数或函数点会鼓励团队每天都产出更多行代码。团队的生产率没有增加，却很可能花费更少的时间在设计质量上。SLOC产量将会提高，确实会，但设计质量却会下降。研究表明，一个程序拥有的代码行数越多，可能拥有的缺陷就越多，开发成本也越高。

总的来说，SLOC和函数点是有问题的生产率度量方法。