春节将至,又到了评绩效拿年终奖的时候!程序员绩效KPI 这个弥久历史谜题该怎么算呢?

关于程序员的绩效,像是一个弥久的历史谜题,长期困扰着大量的程序员与他们的领导们。

KPI(Key Performance Indicators 关键绩效指标)是企业最爱用的绩效考核工具,但 KPI 通常只能定一些更宽泛的指标,且一般也只能分解到团队经理的头上,而很难分解到具体每个程序员的身上。

前不久看到个新闻,Amazon 美国的一个中国 IT 工程师在西雅图办公室跳楼自杀,原因是收到了 PIP。那 PIP 是什么?就是 Performance Improvement Plan 的简写,表达的意思大概就是,再给你点时间改进工作绩效,否则就请走人。但实际收到 PIP 95% 的情况都是走人,这样实际的意思就变成了,再给你点时间赶快找下家吧。

但这哥们在美国工作,拿的是工作签证。如果失业了,就意味着工作签证失效,在美国也就待不下去了。各种压力一起涌来,一时想不开就跳楼了。这个故事里面有个关键词:绩效,而且是程序员的绩效。

工具与方法

在我工作的历史上,换过几家公司,每家公司都使用一种粗放且独特的方式来考核程序员。第一家公司,工作完一年后我才知道什么叫绩效考核。因为它们采用的是年度考核,一年过去到了年末经理跑来告诉你说你今年的绩效还不错,然后也不知道不错是个什么水平。

总之是不错了,但最后也没有加薪奖金什么的。努力回顾一年的工作,发现记忆非常模糊,除了少数几件印象深刻的事。而那几件少数事件,都是我搞砸了的事情,而且还捅了不小的窟窿,获得了血泪换来的宝贵经验。这么一想可能觉得「不错」大概就是「有点差」的一个稍微温和的表达了。

说起按事件来评判绩效,就想起后来的另一个公司,他们就使用这样的关键事件法来评估全年的绩效。回想一下这一年自己做了什么特别的事情,有让身边的同事或领导都觉得很棒的事件么?有印象深刻的正向事件,那么就是优秀,如果是负向事件就是还需改进提升,其他就是一般了。表面看有那么一点合理性,但结合程序员的工作性质一想就不是那么合理了。

上面的方法要么只是模糊要么只是没考虑工作性质的差异,那么下面的这个公司的评估方法就完全扯淡了。当时公司采用强制分布绩效的方式,比如一个部门有 10% 的人得优秀,有 10% 的人得差,其他属于一般。这样的评估方式每月一次,直接和当月工资中的绩效奖金挂钩。

上面这么一强制分布下来,部门再分布到小组,小组长一看大家都是兄弟伙,一年有十个月出差于全国各地,天天加班不说,还要给人绩效评个差,于心不忍。大家一商量,那就轮流来吧,这次得了差的,过几个月就会得个优秀,这样的绩效评估基本也就流于形式,毫无意义了。

近年,像 Google 这样的明星公司大规模应用起了一种叫 OKR 的工具。OKR 就是 Objectives and Key Results 的缩写,表示目标和关键结果。这听起来和 KPI 很类似,但它们有个本质的区别是方向性的,KPI 一般是分解下来,要你去做的。而 OKR 是我要去做的,KPI 是考核工具,而 OKR 实际是管理工具,跟踪做事的目标和方向性。所以 OKR 也不是解决绩效评估难题的银弹。

综上,通用的这些绩效评估工具和方法,似乎面对程序员的绩效评估都不太有用,这是为什么呢?这也许要从程序员的工作实质说起。

工作与评估

管理学上有位大师叫彼得·德鲁克,他最早提出了知识工作者(Knowledge Worker)的概念,德鲁克生于 1909 年,所以他经历了从工业时代到信息时代的革命性变化。早期的工业时代只有工人和管理者的概念,那时的行业多是重资本推动的制造业,工人的特点是流水线的体力劳动,简单重复,过程很容易监控,产出结果的数量和品质也容易检测,所以个人的 KPI 很容易量化。

而德鲁克定义的知识工作者是:

那些掌握和运用符号与概念,利用知识或信息工作的人。

显然,程序员就是典型的知识工作者。知识工作者不仅利用知识,他们还会创造新的知识,从知识中获得洞见,进而产生智慧。

程序员的主要产出是:代码或交付的软件系统。但软件系统的代码通常都是由多个程序员合作一起完成的,所以你就没法精确的测量每个程序员的贡献。也不要想当然的用一些简单粗暴的指标来考核程序员,比如像:代码行数。这样的指标容易定义,容易测量,所以这样的考核容易实施,而容易实施的考核总是首先被采用。但前提和出发点是错的,只会南辕北辙,离目标越来越远。

幸好应该大家都认识到这样简单的指标无法考评程序员个体的产出,但如果真得采用代码行数来评价的话,倒是能解决程序界的另一个亘古已久的争论:花括号 { 到底是写在一行程序的末尾还是另起一行:)。

硅谷创业之父 Paul Graham 在《黑客与画家》一书中写到:

程序员就是知识时代的手艺人,也是目前还存在的最大的手工艺人群体。

最顶尖的 5% 的程序员写出了全世界 99% 的优秀软件。

可见,程序员的个体差异导致的贡献度差异之大。但很遗憾的是我们至今没有任何可行的具体测量方法能精确的评估程序员个体的贡献度。所以 Paul Graham 继续说:

大公司会使得每个员工的贡献平均化。

大公司最大的困扰就是无法准确测量每个员工的贡献,大多数时候它只是在瞎猜。

我依稀记得看过一个来自英特尔的例子,原文记不住,大概简单重述下。是说有个负责芯片设计的工程师提出并改进了一种芯片设计和生产方法,应用到一条年产值 10 亿美元的生产线,提高了 1% 的产值。那么他的直接贡献很容易计算出来就是一年为公司多增加了 1000 万美金产值。但问题是我们该怎么奖励他的这次卓越贡献?

这个例子中还提到,他所在的芯片设计部门有一百多人,所以平均下来整个部门的人均额外贡献就不到 10 万美金了。所以,当年公司能给予他的奖励实际是远小于计算出来的实际增加值的,这就是一个大公司平均化的典型例子。但这个例子中,也不必感觉太不公平,实际离开了英特尔这样的大公司,那个芯片工程师很可能是无法做出这样的贡献的。大公司一方面平均化了个人贡献度,另一方面也为个人降低了风险同时提供了贡献的放大器。

反过来,如果是在小的创业型公司,它依然是平均化计算个人贡献度的。但人少了,被平均掉的就少了。对于小创业公司 Graham 的建议是:

你最好找出色的人合作,因为他们的工作和你的一起平均计算。

结果与影响

SMART 原则来评定你的目标和达成情况:

  • Specific(明确)
  • Measurable(可测量)
  • Achievable(可达成)
  • Relevant(相关)
  • Time-bound(时限)

其中只有「可测量」这一项在程序员个体上比较难实施,所以恐怕只能放弃精确的测量而转为目标导向。而所谓目标或 KPI 无非就是上级对下属的期望,然后再以此来判断下属的绩效是否合乎期望。如果上级没有明确对下属的期望,如果我们不知道到底要什么,最可能的结果是什么也得不到。

那评估的结果是否能以达成目标为依据呢?表面一听似乎很合理,但仔细一深入想想就有问题。如果上级只用目标管理来决定下属的升迁赏罚,以至于下属只专注于制定“好的”目标,即容易达成的 KPI,就会错失了其他可能。

哥伦布的故事证明了这一点,哥伦布设定了一个寻找到亚洲(东印度群岛)的新航线,但他最终却找到了美洲,并开辟了后来延续几个世纪的欧洲探险和殖民海外领地的大时代,因此:

即使一个下属没能达成所设定的目标,他的绩效仍有可能被评为卓越。

哥伦布当初定的目标和最后达成的结果存在差距,但并不能以此说他做的不好。过于绑定目标则限制死了路径并控制了风险,但激励创新意味着冒险,如果没有风险,就几乎等于没有可放大性。

但就个体而言,你需要分清楚评估个人绩效和提供机会让个人获得成长与提升的区别。所以,不妨把这两种效果分为:

  • 产出绩效
  • 成长绩效

前者是组织更关心的,后者是个人更应关心的。当然现在的组织都说很关心员工成长并提供相应培训,但更多时候组织是更倾向于在市场购买已经成熟的大树。所以你不应该等着组织想起来给你浇灌才去成长,成长绩效通常只能自己去评估,而且这点在很多组织也直接影响你的升级。

...

程序员修炼之道》一书中写道:

注重实效的程序员不仅要完成工作,而且要完成得漂亮。

所以,请:“Care about your craft. Think! About your work.(关心你的技艺,思考!你的工作)。” 毕竟你还是个手艺人,还要靠手艺吃饭不是。

此刻瞬间

有时会面临这样一种尴尬局面:一群程序员里,你想提拔一个经理,难道不是应该提拔绩效更好的么?在你把超级程序员提拔为经理的同时,你也失去了你的超级程序员,并创造了一个差劲的经理。反过来,你去提拔一个差劲的程序员当经理,则更糟:一样创造了一个差劲的经理,而且可能会失去一群从超级到优秀的程序员。

写在最后FOR Freedom 看看外边的世界,以及IT这一行,少不了去Google查资料,最后,安利一个V——PN代理。一枝红杏 VPN,去Google查资料是绝对首选,连接速度快,使用也方便。我买的是99¥一年的,通过这个链接(http://my.yizhihongxing.com/aff.php?aff=2509)注册后输上会员中心得优惠码,平摊下来,每月才7块钱,特实惠。

本文标签 程序员 KPI SMART 绩效考核工具

转自 SUN‘S BLOG - 专注互联网知识,分享互联网精神!

原文地址 :春节将至,又到了评绩效拿年终奖的时候!程序员绩效KPI 这个弥久历史谜题该怎么算呢?

相关阅读:Aaron Swartz – 互联网天才开挂的人生历程:每时每刻都问自己,现在这世界有什么最重要的事是我能参与去做的?
相关阅读:网站环境apache + php + mysql 的XAMPP,如何实现一个服务器上配置多个网站?

相关阅读:什么是工程师文化?各位工程师是为什么活的?作为一个IT或互联网公司为什么要工程师文化?

相关阅读: 对程序员有用:2017最新能上Google的hosts文件下载及总结网友遇到的各种hosts问题解决方法及配置详解

相关阅读:win10永久激活教程以及如何查看windows系统是不是永久激活?

相关BLOG:SUN’S BLOG - 专注互联网知识,分享互联网精神!去看看:www.whosmall.com

时间: 2024-10-13 01:02:26

春节将至,又到了评绩效拿年终奖的时候!程序员绩效KPI 这个弥久历史谜题该怎么算呢?的相关文章

绩效/加薪/年终奖,虐你如初恋

年底了,经理们忙着做绩效评价,忙着为年底调薪做准备,心里忐忐忑忑,反复思量,左三圈,右三圈,此情无解可消除,才下眉头又上心头,辗转反侧,夜夜梦回,衣带渐宽终不悔,为伊消得人憔悴,最后呢-- 亲爱的程序员,你对经理们这么努力这么费心熬制出来的年终绩效大汤还满意吗? 绩效评估与调薪,有多少不得不说的事儿?有多少欲说还休的事儿?有多少欲盖弥彰的问题?来来来,看看我们的18个问题,有几个能砸中你. 注:本文将绩效评价结果分为A.B.C.D四档.A为优秀,能出色完成工作,超预期:B为可以胜任工作,能够及时

聊聊程序员绩效那点事【转】

原文地址:http://www.cnblogs.com/cc011/p/5861244.html 刚入职场的时候,对于绩效的概念理解朦朦胧胧,到后面自己做PM,自己开始带团队,带团队以后开始接受公司相对正规的团队管理的培训,到阅读德鲁克的<卓有成效的管理者>,对绩效这个概念有了相对较为清晰的认识,所以在这篇随笔里,我会以自己的亲身体验来讲一讲我对绩效的认识. 1.TOP 1有意思的问题作为程序员怎么拿到高绩效?这个话题就好像问做什么赚钱的一样, 没有一个非常精准的答案但是有一些普适的道理.  

聊聊程序员绩效那点事

刚入职场的时候,对于绩效的概念理解朦朦胧胧,到后面自己做PM,自己开始带团队,带团队以后开始接受公司相对正规的团队管理的培训,到阅读德鲁克的<卓有成效的管理者>,对绩效这个概念有了相对较为清晰的认识,所以在这篇随笔里,我会以自己的亲身体验来讲一讲我对绩效的认识. 1.TOP 1有意思是作为程序员怎么拿到高绩效?这个话题就好像问做什么赚钱的一样, 没有一个非常精准的答案但是有一些普适的道理.  a)超出预期: 所谓高绩效一般情况下是要超出期望才有可能,那么这个期望就是给你考评的老板或者主管的期望

拿代码量算绩效考核?别毁了程序员

原文链接 虽然程序员都说自己是搬砖的,但很显然,搬砖是很好考核的,一天搬多少块砖是一目了然可以量化的,一天搬1000块砖肯定比一天搬800块砖的要厉害:而程序员却很难以这样的方式来考核,一天1000行代码比一天800行代码要厉害?很有可能会反过来,800行代码会更厉害.做过程序员的都知道,bug 数.代码行.版本数等等的这类指标都是不可行的.然而,对于公司来说,必须考核每个人的绩效和表现,否则加薪升职就没有标准了,这里就出现了一个矛盾:程序员的工作比较难考核,而公司又必须考核! 在这样的背景下,

程序员诉苦:“绩效考核”成了优秀员工的标签,绩效满分=成功?

前些天,有几个网友找我谈绩效考核的事,都是在绩效上被差评的朋友.在大致了解情况后,我发现他们感到沮丧和郁闷的原因,不全是自己没有做好事情,他们对于自己没有做好公司交给的事,一方面,持一些疑义,因为我很明显地感到他们和公司对一件是否做好的标准定义有误差,另一方面,他们对于自己的工作上的问题也承认.不过,让他们更多感到沮丧的原因则是,公司.经理或HR和他们的谈话,让他们感觉整个人都被完全否定了,甚至有一种被批斗的感觉.这个感觉实在是太糟糕了. 因为我也有相似的经历,所以,我想在这里写下一篇文章,谈谈

《人,绩效和职业道德》和《一个程序员的生命周期》读后感

作为一名计算机专业的学生,以后的工作也就是与电脑与代码紧紧的连接在了一起.作为一名程序员,在软件的开发设计上很难以一个人的力量去完成,团队合作是当今的主流.在团队合作中,会出现许许多多的问题,比如整个任务如何合理的分配给每个人,每个人是否又会尽心去完成等等. 在看完<人,绩效和职业道德>后,还有一点让我印象深刻.分工的重要性,说道分工那就不得不提组长这个职位,一个团队中必须选出一个决策者,这样在遇到大的事情时才会有人做决定,组长在团队中起到了领头羊的作用,组长必须根据每个成员的特点对其进行分工

漫谈程序员系列:任性,春节前辞职

有些公司会在春节前释放岗位出来,不过说实在的,春节前招人有一些困难,你会发现大部分人的答复都是说要春节后再考虑.这也可以理解,辛辛苦苦干了一年了,拿到年终奖再说吧,年底加薪结果出来再说吧.大部分程序员是这种心思,不过也有一些哥们儿会很任性,春节前就辞职.你说这是为什么呢? 改变,从今天开始 "拖延症"是指自我调节失败,在能够预料后果有害的情况下,仍然把计划要做的事情往后推迟的一种行为. 年会还没开.年终奖还没发.年前招人的公司少--这些托辞会让相当一部分人把找工作的事儿往后拖,拖过年再

程序员的工作、学习与绩效

工作中,碰到一些这样的例子,总有人提出疑问,为什么一个同事工作勤勉,完成了很多事情,季度绩效评定很高,但晋升却碰壁了.之前已经写过一篇<技术晋升的评定与博弈>,基本就能解答这个问题.但隐藏在背后的更深层次的本质却是:工作.学习与绩效的关系. 工作 程序员的主要工作是:编程,产出代码,完成需求,交付软件系统. 程序员按其工作技能和经验,大体又分为三个阶段:初.中.高级.三个级别的程序员的主要工作都是编程与产出代码,产出代码的数量也许相差不大,但产出代码的属性可能有明显差别. 在曾经的文章中提出过

人,绩效,职业道德,一个程序员的生命周期,读后感。

人,绩效,职业道德.不像是讲述,更像是在教导.让我们在更高的角度来看待自己的团队,就算是自己只是一个团队一个小角色也会清楚自己的定位.同时也是在告诉我们团队的运行原理,对于这个我持怀疑态度,这个并不是一本书的短短几页可以定下结论的.具体的实施会因为各种琐碎的事情产生不一样的变化.个人认为这一章会带给个人对团队的憧憬,它告诉了团队的问题及问题的解决办法,就像是团队的运行只有这样.但是事实上一个团队的运行磨合需要经历很多事情,运营者需要操很多的心. 程序员的生命周期更像是一个小人物的奋斗史,但是根据