[探索]互联网技术团队的绩效管理实践3-项目线绩效考核



  上一节,我们介绍过项目组的分裂过程,它是一种基于项目类型的同质分裂,分裂出来的项目组的工作内容大同小异。与此同时,随着团队规模的不断扩大,分工越来越精细,不断有新的工种出现,新工种会专注于某一细分模块的工作,这是一种异质分裂,典型的新工种是架构师。团队规模很小的时候,设置专职架构师是件满奢侈的事情,项目经理往往是以一当十的用的,如果有一件事情不知道该给谁做,通常都是由项目经理兼的。当系统规模越来越大的时候,着眼于全局的架构设计,再由项目经理兼做几乎是不可能胜任的,这个时候就必须依赖专职的架构人才,成立架构师团队。架构师团队和项目团队的关注点是有很大不同的,前者我们称为创新线,更多关注创造力,后者称为项目线,关注项目吞吐。针对这两条线,我们设置不同的绩效管理办法,用不同的指标进行绩效跟踪。本篇我们将介绍项目线的管理办法

项目绩效的量化


  项目组的绩效构成的主要因素为项目绩效,我们用项目绩效分来量化项目贡献度。每一个项目在启动之前,都将分配一定的绩效分,这个绩效分由四个方面的因素构成:实施工作量、协调工作量、技术难度、上线风险实施工作量,很容易理解,就是我们要投入多少人天的开发工作量;协调工作量,是我们后面提出来的,因为当项目组多的时候,一定会有一些公共项目涉及多个项目组,这样的项目开发工作量并不大,协调工作量却大的惊人。技术难度,也容易理解,技术难点比较多的项目,自然要分配多一点绩效分,注意,难度是相对难度,比如让一个.net工程师做Java的项目,这难度也是大的,为了鼓励新技术的尝试,就应该多分配绩效分。上线风险,这个也是比较特殊的因子,我们是做电子商务的,线上故障是我们最怕的东西,因为这可能直接导致损失,一个小小的错误在巨大的交易流量下都会被放得很大,线上故障出现后,相关项目人员是要承担责任的。所以对于一些上线风险较大的项目(例如:资金相关),我们都会分配较多的绩效分,以便更好的权责对等

  那么一个项目做下来,最后能够拿到多少分呢?最终得分由三个因素构成:基础分、质量分、进度分基础分,就是只要你的项目做完了,拿到测试报告了,就可以获得基础分。质量分,由QC团队发出来的测试质量等级决定,我们的测试质量等级有A、B、C三级,A级拿满分,B级和C级分别扣一定比例的绩效分。进度分,也类似,没有Delay得满分,如果有Delay,根据Delay级别,分别扣除一定比例的绩效分。

  基础分、质量分、进度分的比例为:50%,40%,10%,这个比例的用意是,只要项目做掉了,就可以取得一半的分值,然后我们在质量和进度之间,侧重于质量。因为系统规模越来越大,我们慢慢从以前的追求进度转移到追求质量上。实际上,很多项目早一天上晚一天上,已经没有什么不得了的影响。然而,质量一旦出现问题,后果就是相当严重的。

  那么测试质量等级是怎么定出来的呢?我们也有三个主要的关联指标:bug分值、重复问题提交率、致命bug及时修复率。这里要分别解释一下,bug分值,不是bug数目,是一个换算出来的分值,单纯的数量统计是没有可比性的,所以我们将bug按照严重程度分为:A致命、B严重、C主要、D轻微,然后他们的bug分值配比是:A:B:C:D=7:5:2:1,即一个致命bug抵7个轻微bug,最后将bug分值除以实施人天,我们便可以知道每一个人天的投入产生了多少bug分;重复bug,是指QC报出来bug没有有效修复,以个数计;致命bug及时修复率,是指开发人员有没有在指定的时间区间内完成阻断bug的修复,以便QC可以继续推进测试工作。这三个因素共同决定了一个项目的测试质量等级。

  我们的项目绩效分,每个月汇总一次,以项目组为单位进行比对,反应在技术部的月报当中。我们最关注的指标是人均绩效分,即整个项目组拿到的绩效分除以项目组成员数。这个指标很大程度上可以反应一个项目组的人均产能。不过这里,也有一个问题,即项目组的项目量不足的问题,这会导致项目组内的工作量不饱和。这种情况下表现出来的产能问题,应该要特殊对待。我们给大家的建议是自己去开创项目,发起内部立项。我们的系统跑了这么久了,一个项目组负责的系统也基本上是固定的,我想只要我们愿意做,我们一定可以发起不少重构性质的项目的。此外,我们也建议他们跟架构组联络,承担他们发起的一些项目。

  项目绩效分,通过一个奖金系数,与项目奖金挂勾,多劳多得,一个月结算一次。这个奖金系数一般情况下是1,但也会波动,影响因素有两个主要方面,一是整个公司的业绩状况,二是整个技团队的表现。奖金系数也是我们后来引入的概念,将奖金的变化抽象出来,这样项目绩效分就是稳定指标的了,在一定的时间区间内可以进行对比分析。

  大家注意到,我们月度是以项目组为单位进行绩效比对的,这是因为我们认为对于公司级别的考核,项目组已经是一个最小的考核单元了,再往下量化已经是非常困难的事情了。另外,对于项目奖金的分配,我们也有一些认识,首先项目奖金是项目实施的资源之一,所以项目奖金的分配权限是完全下放给项目经理的;二,项目奖金的分配要以能够激励整个项目组的绩效持续增长为目标。如果某个项目组的项目绩效越来越差,我们就会去分析他以前的分配策略是不是有问题,必要时进行干预。

季度考评之项目经理(项目组)


  我们的绩效考核周期是一个季度一次,季度绩效考评的结果将影响季度奖。

  项目组的季度绩效,就是项目经理的绩效。由两部分构成:项目绩效分、行为&附加贡献。前者就是项目绩效,由三个月的人均项目绩效分排名换算得到,占80分;后者,是团队建设方面,主要是为团队的中长期目标服务的,占20分,这20分如何给,也是有满多讲究的,因为这部分是比较难以量化的,为了降低拍脑袋的盲区,我们将这部分又切为两块,10分给直接上司拍脑袋(根据经验,这部分通常各项目组之间差异不会太大)。另外10分作一些界定,能够明确下来的得分点就明确下来,比如内部培训,当一次讲师就可以得一分。对于不能够明确的部分,月度由项目组自行总结,按条给分,相当于由各个组自己界定自己能够得多少分,并提供事实依据(不用很复杂的报告,能说明清楚事件即可,反正自己做过什么做到什么程度都很清楚)。这样,项目组的季度绩效考评,便可以比较容易的呈现出来了。

季度考评之工程师


  工程师的季度考核,分为三个部分:项目绩效分(由项目经理分配的),所在项目组的绩效排名、直接上司打分。分别占的比例为:60%,30%,10%。项目绩效分,是由项目经理综合分配后得出的,这个绩效分的分配原则我们前面讲过,比如有的工程师没有做项目,但去当讲师给组里作了贡献,也是会得到绩效分的。项目组的绩效占了30%的比例,传达的一个信息就是项目组整体绩效的重要性,作为项目团队中的每一个人,只有形成合力,才能够在这一部分取得好成绩,强调的是团队合作。在项目组内部,工程师之间的得分区间50-60(组内差异小),在项目组之间得分区间是10-30(组间差异大),也就是说最优秀组中最好的工程师和最差组最差的工程师季度绩效可以最大可以达到30分。另外的给项目经理拍脑袋的10分,也是为了进行项目组建设用的,一般情况下不会差异太大,所以工程师的绩效,关键还是取决于整个项目组的项目绩效

关联阅读


互联网技术团队的绩效管理实践1-我们是谁
互联网技术团队的绩效管理实践2-寻找绩效
互联网技术团队的绩效管理实践3-项目线绩效考核
互联网技术团队的绩效管理实践4-创新线绩效管理
互联网技术团队的绩效管理实践5-非项目绩效





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

[本日志由 余波 编辑过]
上一篇: [探索]互联网技术团队的绩效管理实践2-寻找绩效
下一篇: [项目管理]租房搬家也是做项目
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags: 绩效 项目
相关日志:
评论: 1 | 引用: 0 | 查看次数: -
Hannibal
回复回复Hannibal[2010-04-29 02:08 AM | | | del]
目前有这么一个问题 ,就是关于项目质量的.从我们的实际情况看,在不考虑代码结构(可读性,可维护性),执行效率,对服务器资源的损耗的基础上,快速开发出可以通过QC测试的项目是很容易的.这导致了可能有些人为了提高开发效率(通俗的讲就是为了多做项目多拿钱)而放弃对项目质量的追求(事实上据我观察,这种现象已经出现了).而项目在今后的维护成本将大大增加,运维的硬件成本也将增加.我们目前所陷入的急需重构和重构困难的问题,与这点不无关系.
我们的架构组构思且实施了很多优化性能的项目,但从上述地方损耗的性能却无法得到截至,而且其损耗是个不小的数目.
当然,我们是一个处于发展中的团队,我也听说QC已经着手要上马白盒测试,但在这个阶段,我们是否有其他方法能够最大限度的规避此问题?
我知道有些项目经理会在项目开始时就整体设计思路与工程师进行沟通,如发现问题则进行指导,在项目完工时对项目进行逐行走查,这个做法显然是有效的,可它的致命缺点是时间的损耗,我们的项目开发时间并没有计算这一块.
目前我们有一些代码走查机制,但其走查目的也是从是否会出现致命bug的角度进行的,而非设计是否不合理,效率损耗是否过大,编码是否不易于维护,这也与代码走查和项目开发并没有分配足够时间有关系.
如果项目上线时间并非十分紧急,我们是否能够想出办法在这一块做的更好?

以上言论为临时想起的事情,并没有经过深入思考,也知道这个地方要得到改善在目前情况下存在许多困难,一点拙见只为抛砖引玉.

回复来自 余波 的评论 余波 于 2010-04-29 08:50 AM 回复

你提出了一个非常好的问题,非常感谢。接下来,我们要花点时间想想办法,如果你有了什么新想法,欢迎随时能够给我留言。

发表评论
昵 称:
邮 箱: 支持Gravatar头像.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.