【研发管理】开发团队产能度量



大部分互联网公司的技术团队,都会经历一个水深火热的发展阶段,直接表现就是有做不完的项目,还有应接不暇的需求变更。业务部门恨不得今天晚上提的一个想法,第二天就能够在生产环境看到。如果看不到,可能就会心生怨念,觉得技术没效率。

那么到底有没有效率呢?这个问题的答案是,别人觉得你有效率就是有效率,别人觉得你没效率就是没效率。你看,我们扯起淡了。

其实关键是,我们自己知不知道效率如何?你的回答会不会是,当然知道,这个月我们的项目个数是10个,上个月才8个,所以这个月比上个月产出高?或者,当然知道,这个月我们加班时间比上个月还要长,所以产出高。作这样的回答,先不谈能否说服别人,我们自己都各种心虚了吧,心都虚了,有效率也是没效率的卖相。

要想心不虚,还是得数据说话,要把产能量化出来。有些人心里犯嘀咕了,这怎么可能,我们是技术团队耶,我们是创造性劳动耶,一名优秀的程序员可以顶百十个程序员耶。得,咱自己人就先不扯这些劳什子,扯三天三夜也扯不完,太费口水。

量化思路


我们的做法是,是用项目绩效分来界定每个项目的工作量。

在项目初始的时候,我们先会针对每一个项目,评定一个绩效基数出来,这个基数的意义就是做这个项目,一人天的投入代表多少项目绩效分。这个基数的影响因素有两个,一个是难易度,另外一个是复杂度,难易度是指技术上的挑战,比如新技术尝试,比如算法改进,比如.Net转JAVA。而复杂度是指逻辑上的挑战,比如业务分支特别多,比如差错零容忍,比如公共项目集成,比如重构大段大段的看着就想吐的老代码。

这两个因素最终大概会以这样的方式影响基数:A+X*B+Y*C,A、B、C都是常数,公司可以根据自己的情况敲定一个值,我们用的是100、20、20,X、Y是难易度、复杂度等级,我们分为四级,对应的常数是3、2、1、0。

举例,
某项目难度系数1级,复杂度系数3级,那么绩效基数就是100+3*20+1*20=140。
那么假设这个项目的工期是10人天的话,这个项目如果顺利完成就是1400绩效分。

然后我们还可以根据情况,对项目质量和进度情况作一些减分策略。
最终就可以得出一个项目的项目绩效分。

如此,每个月我们只要将部门里完成验收的项目列一列,将所有绩效分加一加,就得出了总产出,再除以部门的总人数,就得出了一个重要的指标:人均项目绩效分,也即人均项目产出,也即这个部门的产能。

写到这里,我突然想到,这项目绩效分有点类似于敏捷方法论中的故事点数。敏捷团队的产能,也是基于点数来度量的。


量化操作演变


以上,我们算是定义了一个绩效分的量化规则,这是一个静态的标准,其实更有意思的是执行过程的演变。

最早的时候,我们还没有项目绩效分的提法,那时候整个开发团队也就十几二十个人,项目也没那么多,所以都是由总监看方案,然后直接拍出一定额度的项目奖金,我们直接用项目奖金来判断产能。

后来,受各种因素的影响,我们每个月的项目奖金的发放标准开始频繁变化,这导致用项目奖金来判断产能的方法失效,于是我们将项目奖金与项目绩效分离,总监同学不再直接拍项目奖金,而是拍成项目绩效分,然后再根据预算状况,换算出项目奖金,其实就是通过汇率将变化因素抽象了出来。这才让月度之间的项目绩效分有了可比性。

项目奖金和项目绩效分的作用和意义要分开看。在野蛮生长时期,项目奖金制度的正面效用非常突出,对于项目的及时交付很有益。然而我们也不能忽略其负面效用,比如时间久了,有些人会下意识认为做项目等于拿奖金,那么持这样的心态,没有奖金的项目还能不能做好呢?道理大概就跟吃药一样,用猛药可以立竿见影,但时间久了就会产生依赖,药性越猛依赖越强,药效却是越来越弱的。

项目奖金的利弊先放下,改天再谈,继续谈我们的产能度量历史。再往后,团队越来越大,项目也越来越多,月均完成的项目两百以上,而总监的事情也越来越多,没有精力来打分。为了把总监解放出来,我们成立了一个评分委会员,来代替总监工作,同时定下了几条规矩。

1、评分委员由每个项目组的第二负责人担任。第二负责人就是除项目经理之外综合能力最好的人。这么做的初衷是一方面是评分委员要了解项目,所以要从项目一线出人。二是没有安排项目经理,是怕占用项目经理太多时间。

2、每一个项目由项目经理自评之后,两位评分委员分别校正后取均值。

3、评分委员不能够校正自己所在组的项目。

4、评分委员在上岗之前,进行集中培训以统一标准。还从以前的老项目中抽取一些测试样本,让评分委员试打,以验证大家的评分标准与总监脑袋里的那个标准是否接近。验证下来的结论是,正负误差10%,还算可以,于是大家就上岗了。

5、为了确保评审委员的最后打分,每月还会随机抽选几个项目,让总监再打一遍,然后比对一下。


于是,总监解放了,工作也照常进行下去了。
这个制度,从2011年年初开始试行,走了三个月,各方反应良好。

出问题了


然而,问题总在不经意间出现,部门经理跟我反馈,说四月份我们核算了一个总的数字出来,感觉不太对劲,于是我们决定进行一次突击审计。审计规则很简单,把总分超过1000分的,或者综合系数达到3的项目全部拉出来。然后纠结几个部门头,逐个过项目,前后花了四个小时,确实有所发现。

1、大家都觉得自己做的项目复杂,技术难度大,所以综合系数都想往高里打。

2、项目排期基本符合现实情况,但有部分项目组分解颗粒太大。

3、第二负责人担任评分委员,面对比自己高一级的的项目经理时,底气不足,初评校而不正。


基于以上审计发现,我们出台了改革方案,要点有:

1、评分委员由项目经理担任,解决话语权不足问题。同时评分委员结对工作,尽量互补结对。比如技术好一点的和业务熟悉的人搭配。

2、且任务分解的最大颗粒是3人天,超出3人天一定要再次分解。控制颗粒够小,才容易判断工期合理性。

3、项目经理自评时不评综合系数,综合系数由评分委员给出,然后交由部门经理审核。超出一定级别,部门经理还要邮件到部门总监处说明情况。目的是要从整个部门的平面,去评定难度和复杂度。说到底,难度和复杂度是比较出来的,至少需要在部门内部进行比较。

4、为校正两个部门之间的评价标准,部门交叉审计。每个月,由部门总监随机抽取项目,由不同部门的部门经理就工期、难度、复杂度进行审计,动态校正几个部门经理脑子里的参照系。前面,我们历时四个小时的审计过程,到中后期大家打出来的分数越来越默契,其实也是因为随着审计的进行,大家的参照系越来越接近。

5、提供申诉渠道,如果觉得工期和综合系数评定不符合事实情况,可以向总监申诉,进行仲裁。

至此,问题算是解决了,而我的注意力也转移到项目奖金制度的变革上了,这需要慢慢斟酌斟酌。

还是有问题


上面的方案,某种程度上是可以实现相对公平,然而管理成本很高,高的原因是太多人参与了执行过程,于是我们又进行了一次调整。

不管怎么调整,秉持的原则是不变的:以适当的管理成本,把大家的实际工作反映出来,同时力求整体的公平性

这次调整,有两个主要的变化:

1,取消了项目经理参与初评的环节,转变成由部门经理评定

经过前期的几次审计活动,我们发现,
项目经理们对人天的估算是很有把握的,都比较准,
差异比较大的是综合系数,各有各的标准或本能的想往高里打(利益最大化是一种本能),
所以把综合系数单独拿出来,交给几位部门经理进行判断,
判断的方式是每一两周专门拿时间出来,逐个的Review大家的项目,
然后现场评定,同时也稍带着看看任务分解和工期编排。


2,配合协调投入的核算
原先我们搞的有点复杂,配合度、配合人天、协调度、协调人天,
这么多影响因素,让操作变得很困难,争议较多。
所以直接简化为辅助人天,与编码没关系的项目投入,都可计为辅助人天,
每个辅助人天的绩效分标准也统一为多少天一天,会比编码人天少一些。

这里要注意的时,辅助投入是很琐碎的,比如帮助测试人员搭环境,配合上线等等,所以进行估算,比如每天投入1小时,协调了三四天,估算出来可能是0.5人天左右的辅助人天。


至此,整个绩效分的评定过程就变成了:
1,项目经理根据项目范围,确定项目工期,然后在项目验收之后,对工期进行一次修正,给出两个数据:编码人天,辅助人天

2,部门经理集中对符合结算条件(产品验收报告)的项目进行Review,酌情对项目的难易度、复杂度进行升级。

PS:难易度是指技术上(智力上)的挑战,比如新技术尝试,比如算法改进,比如.Net转JAVA。而复杂度是指逻辑(体力上)的挑战,比如业务分支特别多,比如差错零容忍,比如公共项目集成,比如重构大段大段的看着就想吐的老代码,比如涉及多个系统的集成工作。

3,项目经理对项目Review的结果进行申诉,规避部门经理操作上的误伤。


一点体会


这么一次折腾下来,还有一些体会。

1,没有监督的权力滋生腐败,没有节制的信任滋生投机,因为利益最大化是一种本能。

2,有缺陷的制度,是试金石,不是八仙过海,就是群魔乱舞。

3,有什么样的制度就有什么样的人,制度会以一种滴水穿石的精神去影响人。

4,有什么样的制度就有什么样的人,终究是作为制度设计者的智慧不够,修炼不够。



 进一步交流: 扣扣,是用来扣的    

[本日志由 余波 编辑过]
上一篇: 【研发管理】绩效考核,从快慢鱼到大小鱼
下一篇: 【传帮带】管理人才的培养
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags: 绩效管理 研发管理 量化
相关日志:
评论: 0 | 引用: 0 | 查看次数: -
发表评论
昵 称:
邮 箱: 支持Gravatar头像.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.