谈“绩效考核”

Mon, 23 Apr 2012 00:00:00 +0800

前言

在工作以来就职的几家公司中，目前就职的这家公司有非常完善的“绩效考核”制度。绩效工资大概占工资的百分之二十左右，绩效的最高系数为2，就是说如果你的工资的20%为2000，绩效最高可以拿到4000 ，当然很难达到最高的系数。公司推行“绩效考核”的这种制度出发点是刺激员工的积极性，同时也让表现好的员工能有好的回报，但我却发现了其中的一些“弊端”。

我们的绩效分为两个维度：业绩考核和行为态度考核。行为态度主要是实际工作中的一些突出事迹，成就客户之类的东西，如果不是和客户直接打交道的比如实施类的岗位，在行为态度上要想有所表现比较困难，所以本文将围绕业绩考核来谈，并且只针对开发岗。

业绩考核又分为很多的指标，每个指标根据完成的情况得到不同的分数（0、2、3、5），再根据每个指标占的不同比例算出业绩考核的总分，业绩考核的指标有：工作量，bug量和关键节点达成率。下面分别来说下这几个指标。

工作量

任务系统的任务都会评估出一个工作量，以天为单位。计算方法为在季度末算出整个季度中完成的工作量和总出勤天数的一个比例。表明上看这个指标非常好，公司不用怕员工偷懒，相反员工还会主动去找事情做，因为担心工作量不够。看上去挺好，但实际操作中却存在很多问题，有些时候两个工作之间不能很好的衔接，造成工作量的流失；有些时候由于需求不明确等问题需要反复沟通造成严重的内耗；有时候。这样就会造成这样一种现象，平时会发现公司里的人貌似都非常的忙，但到了季度末统计工作量时却发现还不够。

bug量

bug量的计算方法是一个季度所做的任务的有效bug量和所做任务的共走量的一个比例，最终算出每天的平均bug量是多少，再根据这个bug量来打分。设置bug量这个指标的初衷是为了提高开发人员的开发质量，减少测试与开发之间往返的消耗。但这个指标至少会带来两个弊端：

1 开发人员和测试人员的对立

因为测试岗也有bug量的质量，他们是平均每日找到多少个bug，所以很多时候开发人员都在和测试人员纠结bug有效性的问题，其实开发和测试的目标应该是一致的，都是为了软件能够高质量的交付。

2 事不关己，高高挂起

经常会在项目中发现一些不合理的代码，如果是在以前的公司，如果是出现在我负责的模块，我会进行重构，但现在我可能不会去碰那些代码，因为可能会带来更多的缺陷，而这些缺陷最终会记在我的头上，即便重构不会带来任何的风险，也没有人会关心这个，人们更多关心的是软件能不能正常的运行。正是由于这个指标的存在，随着时间的增长，项目中的坏味道会越来越多。

关键节点达成率

基本上任务系统中的每个任务都会设置关键节点，对于开发来说关键节点就是某个任务提交测试的时间点。计算方法是未超时的任务数和总任务数的比例。这项指标的初衷是保证开发的效率，但也带来了一些问题：

1 互帮互助少了

虽然公司一直都强调同事之间要多沟通，多互相帮助，但正是有了这个指标当你的任务已经快到关键时间点的时候，你就没有多余的时间去顾及其他的事情了。

2 多任务的处理

当你正在处理设置了关键节点的任务的时候，突然来了一个紧急任务，可能是一个比较紧急的bug任务，如果是在以前的公司，肯定不会有什么顾虑，优先响应紧急的任务，手头正在做的事情就自然往后顺延了。但有了这个指标后就会担心我优先响应bug任务了，那手头正在做的超时了怎么办。

总结

很多公司没有绩效考核制度一样可以管理的很好，我个人也不是很喜欢这个绩效制度，我认为这个公司对员工的一种不信任。当然绩效制度如果使用合理也可以起到良性的作用，而且不同的公司应该制定适合自己公司的制度。制度就是一种约束，约束太多了总会让人感觉不爽，我认为最好的方式是领导能够利用自身的个人魅力感染员工，提升员工的责任感，很有幸我曾遇到过这样的领导，当时提倡的公司理念是“快乐工作，健康生活”，那段时间每天都很有激情，每天早上起来都很想去公司上班，但这样的公司和领导也是可遇不可求的。

绩效 on 冯威的博客