软件人员绩效考核新思路.doc

软件人员绩效考核新思路从以组织为中心到以项目为中心软件人员管理，一向被认为是一件难题。尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。一个软件工程师好不好？怎么判断？记件制？看看代码写得多不多？稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长，本来调用一个公共库中的函数就好了，现在我就拷贝过来；本来有一个状态变量可以重用，我再加一个；程序员的法子多了。高手们全不干了，有的Bug，查要一个星期，而且每天晚上都得查到凌晨两点，改起来就一行，这老兄一定跳起来了。所以记件制不行。记时制？每天八小时上班，太容易了。比加班，谁比得过毛头小伙子啊！而且，你知道我加班干什么？白天我可以天天上网，晚上干点活。或者我加班就打游戏，老板反正不在。时间长了，就变成了大锅饭。这也不行。做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了：KPI嘛！KPI全称是Key Performance Index，就是大家每年每季度或每个月要填的表格：考核项权重得分考核项权重得分工作量30%工作质量30%工作态度10%沟通能力10%. .合计作技术的组长和经理们，虽然一头雾水：这根本就没解决我的问题吗！不过，至少我知道该怎么干了。上去三下五除二给它填完了。加班多的，工作量打满分；打游戏的，工作态度全扣了这法子实施容易，而且总的来说，至少组长经理们觉得是公平了。老板看他们同意了，也乐得消停。但是，这种方法也有很大的问题。最大的问题是把人看死了：好人永远是好人，落后永远是落后。时间一长，论资排辈，老人把权，企业失去动力。这种方法是以组织结构为中心的考核：组长给组员打分，经理给组长和打分，总经理给经理打分。大概是绝大多数有考评的单位的主要方式。改变这种情况有什么方法吗？较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说，就是在每个项目中考核每个成员的评分，此评分是根据技术指标来衡量的；每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说，这种评分方式，适用于所有经理以下的人员的考评。而经理的考评，则可以按照MBO的方式，即Manage by Objective来管理。这种考评方式，能够极大激发基层员工的动力。因为考评结果是在各个项目中得分的总和，他们会乐意参加更多的项目。考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。这种考评方法，也要求管理层有一种开放的管理态度：从“我要管”到“我来评”的转变。开放，第一，体现在允许员工内部自由流动。很多基层或中层组织和经理都有一种不愿意放人的倾向，从而使得一些内部员工不能到他喜欢和胜任的岗位上去，最后选择离开公司。与其这样，不如让他们自己在公司里寻找机会，同时也承担转岗的后果。第二，相信被充分信任，授权而责任明确的员工会努力完成自己的工作。这比保姆式管理要好的多。以前遇到一个能力很强的组长，经常比喻他做项目是就像两手护着一圈鸡蛋，稍不留心，鸡蛋就漏了，以示他的手下多么不济；后来这个组长走了，项目的后续版本却还是正常发布，没见那个鸡蛋打掉了。当然，这种管理方法最大的要求是具备良好的信息化管理。比如，代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。除了信息化管理外，各级组织结构上的经理和组长的认可也是很重