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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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