软件人员绩效考核新思路

-从以组织为中心到以项目为中心
软件人员管理,一向被认为是一件难题。尤其是年中年底的评价问题,涉及到加工资,发奖金,稍有差池,就会民怨沸腾,来年是该走的不走,不该走的全走了。

一个软件工程师好不好?怎么判断?

记件制?看看代码写得多不多?稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长,本来调用一个公共库中的函数就好了,现在我就拷贝过来;本来有一个状态变量可以重用,我再加一个;……程序员的法子多了。高手们全不干了,有的Bug,查要一个星期,而且每天晚上都得查到凌晨两点,改起来就一行,这老兄一定跳起来了。所以记件制不行。

记时制?每天八小时上班,太容易了。比加班,谁比得过毛头小伙子啊!而且,你知道我加班干什么?白天我可以天天上网,晚上干点活。或者我加班就打游戏,老板反正不在。时间长了,就变成了大锅饭。这也不行。

做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了:KPI嘛!

KPI全称是Key Performance Index,就是大家每年每季度或每个月要填的表格:

考核项 权重 得分
工作量 30%
工作质量 30%
工作态度 10%
沟通能力 10%
…… ……
合计

作技术的组长和经理们,虽然一头雾水:这根本就没解决我的问题吗!不过,至少我知道该怎么干了。上去三下五除二给它填完了。加班多的,工作量打满分;打游戏的,工作态度全扣了…… 这法子实施容易,而且总的来说,至少组长经理们觉得是公平了。老板看他们同意了,也乐得消停。
但是,这种方法也有很大的问题。最大的问题是把人看死了:好人永远是好人,落后永远是落后。时间一长,论资排辈,老人把权,企业失去动力。
这种方法是以组织结构为中心的考核:组长给组员打分,经理给组长和打分,总经理给经理打分。大概是绝大多数有考评的单位的主要方式。

改变这种情况有什么方法吗?较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说,就是在每个项目中考核每个成员的评分,此评分是根据技术指标来衡量的;每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说,这种评分方式,适用于所有经理以下的人员的考评。而经理的考评,则可以按照MBO的方式,即Manage by Objective来管理。

这种考评方式,能够极大激发基层员工的动力。因为考评结果是在各个项目中得分的总和,他们会乐意参加更多的项目。考评分用技术指标决定,如工作量用完成的功能点来衡量,工作质量用每千行代码Bug数衡量,技术人员会认为这很公平,从而有动力更努力。

这种考评方法,也要求管理层有一种开放的管理态度:从“我要管”到“我来评”的转变。开放,第一,体现在允许员工内部自由流动。很多基层或中层组织和经理都有一种不愿意放人的倾向,从而使得一些内部员工不能到他喜欢和胜任的岗位上去,最后选择离开公司。与其这样,不如让他们自己在公司里寻找机会,同时也承担转岗的后果。第二,相信被充分信任,授权而责任明确的员工会努力完成自己的工作。这比保姆式管理要好的多。以前遇到一个能力很强的组长,经常比喻他做项目是就像两手护着一圈鸡蛋,稍不留心,鸡蛋就漏了,以示他的手下多么不济;后来这个组长走了,项目的后续版本却还是正常发布,没见那个鸡蛋打掉了。

当然,这种管理方法最大的要求是具备良好的信息化管理。比如,代码应该有统一的代码库管理,而不是只保存在程序员个人手里;Bug也要存在缺陷管理库中,不是只是去跟程序员讲一下。每个项目结束时,每项统计指标的计算也是烦琐的工作,需要人力和耐心。

除了信息化管理外,各级组织结构上的经理和组长的认可也是很重要的。因为他们在员工的评价的主导权上有所削弱,甚至这种评价方法出来的结果和他们的“影响”不一致。只是需要和他们讨论:也许要改变的是个人的成见,而不是评分。

Contributors: FHL