该帖子同步发自圈子:IT项目管理圈 (访问该圈子)
一个软件工程师好不好?怎么判断?记件制?看看代码写得多不多?稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长,本来调用一个公共库中的函数就好了,现在我就拷贝过来;本来有一个状态变量可以重用,我再加一个;……程序员的法子多了。 高手们全不干了,有的Bug,查要一个星期,而且每天晚上都得查到凌晨两点,改起来就一行,这老兄一定跳起来了。所以记件制不行。记时制?每天八小时上班,太容易了。比加班,谁比得过毛头小伙子啊!而且,你知道我加班干什么?白天我可以天天上网,晚上干点活。或者我加班就打you戏,老板反正不在。时间长了,就变成了大锅饭。这也不行。 做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了:KPI嘛! KPI全称是Key Performance Index,就是大家每年每季度或每个月要填的表格。 作技术的组长和经理们,虽然一头雾水:这根本就没解决我的问题吗!不过,至少我知道该怎么干了。上去三下五除二给它填完了。加班多的,工作量打满分;打you戏的,工作态度全扣了…… 这法子实施容易,而且总的来说,至少组长经理们觉得是公平了。老板看他们同意了,也乐得消停。但是,这种方法也有很大的问题。最大的问题是把人看死了:好人永远是好人,落后永远是落后。时间一长,论资排辈,老人把权,企业失去动力。这种方法是以组织结构为中心的考核:组长给组员打分,经理给组长和打分,总经理给经理打分。大概是绝大多数有考评的单位的主要方式。 改变这种情况有什么方法吗?较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说,就是在每个项目中考核每个成员的评分,此评分是根据技术指标来衡量的;每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说,这种评分方式,适用于所有经理以下的人员的考评。而经理的考评,则可以按照MBO的方式,即Manage by Objective来管理。这种考评方式,能够极大激发基层员工的动力。因为考评结果是在各个项目中得分的总和,他们会乐意参加更多的项目。考评分用技术指标决定,如工作量用完成的功能点来衡量,工作质量用每千行代码Bug数衡量,技术人员会认为这很公平,从而有动力更努力。这种考评方法,也要求管理层有一种开放的管理态度:从“我要管”到“我来评”的转变。
|