谈谈对码农们的绩效考核
发布时间:2017-04-21, 11:27:08 分类:默认分类 | 编辑 off 网址 | 辅助
正文 2063字数 827,637阅读
谈谈程序员的绩效考核今天一个朋友问我程序员应该怎么考核。我想了想,总结了下我理解中一般开发人员的绩效考核。
考核的意义
首先一个前提是,考核是手段不是目的。我一直觉得对一个团队来讲,有两个基本目标:一个是完成自己承担的工作任务,一个是提升整个团队的能力。这两个目标相互促进,进而实现螺旋式的上升发展。考核只是为了更好的了解工作情况和团队情况、更清晰更准确的认识剖析自我,为改进和提升做准备的技术手段。
所以开发人员的考核对团队来说,有两层意义:既是团队成员的绩效奖金荣誉的一个数据支持,也是团队整体建设进一步发展的依据。
对个人来说,也有两个意义:横向可以与团队内其他成员做对比看到差距继续努力,纵向也可以跟自己的不同时间段做对比看到进步的足迹。
从设计上讲,考核应该跟公司的职级职位序列和绩效奖金等制度挂钩,不同的层次、不同的岗位,应该有一些不同的要求和考核方式,最终把考核的结果通过某些奖惩形式实施下来。没有奖惩激励的考核,只是纸上谈兵的空洞形式。
考核的原则
程序员的考核一般可以从研发管理过程、项目与部门效益、公司考勤制度、主观考核评价指标等组成。因为程序员经常无偿加班(没办法,难道不是事实么?),公司考勤之类的制度应该不怎么用得到程序员的头上,剩下的主要也就是过程、效益和评价了。
考核的原则我觉得有如下几个:
1. 主客观相结合
一般来说,我们希望可靠本身越客观越好。但是制定指标收集客观数据,分析整理,对于IT研发过程来说,都是很复杂的事情。特别是研发本身不规范,技术能力差,不成熟的团队,变数大、流程不标准,很多事情难以度量。主观的一些东西就不可避免。但是,主观的考核应该尽量少,避免出现团队中任人唯亲之类的影响团队整体的现象。
2. 合理量化
对于研发过程中的可以度量的数据,应该尽量合理的量化。度量的过粗,大家都差不多,效果不明显;度量的过细,对收集指标数据要求比较高,甚至对研发本身会产生一定的影响。所以,指标的量化应该结合实际的研发流程,做出比较经济的选择。
3. 双向和多向评价
对于上级对下级可以直接给予评价的行为,下级应该也能集体给上级打分。对于主观考核部分,应该做到360度测评,对某个开发人员的评价,可以先由开发人员自己给自己的主观评价部分打分,再由主管、团队内同事review评价,综合确定最终评价。
4. 要研发过程还是业务结果?
考核程序员的侧重点应该放在过程上,而不是业务的结果上。业务的结果应该由管理业务的人负责。简单的说,谁拍板谁负责(或谁受益谁负责)。所以,我一直觉得苦逼的程序员应该对自己的劳动本身负责。程序员在自己的一亩三分地做好工作,写得好代码,改得快bug,产出多,质量高,就是一个好程序员。当然对技术leader、architect的要求要放高一些。当然,业务的好坏一般关联到公司和部门的performance,这可是奖金和绩效的来源,理所当然跟程序员有关系,但不应该是考核的核心。对一个好的马龙(一般程序员,不上升到某种所谓的高度)来说,研发的本职工作才是作为一个程序员的核心价值。这也正是前面说到的不同的职位不同序列应该有不同的要求和考核方式。
5. 发展阶段与侧重点
当然,公司或团队本身的发展阶段,也决定了对程序员考核的侧重点不同。
对于一个能力一般偏下、经常延期、积累差、不规范、处以还没有实现温饱的团队,考核的重点应该是提升团队研发能力,按时完成任务。
对于一个马马虎虎按时完成任务,但是不规范、没合作精神、没动力的团队,考核的重点应该是引导其行为,走向规范化,实现团队协作性的整体提升。
对于一个有一定的积累,相对能力还不错,已经能很好的完成工作任何的团队,考核的重点应该是如何进一步的提高研发水平和质量,实现标准化和流程化…….
指标的制定
具体怎么制定考核指标,我就只说说思路吧。
1、 研发过程
参与了多少项目,写了多少代码和文档,多少测试代码,完成多少模块和用例,解决了多少问题,bug率多少,reopen的bug率多少,多少次工作交付延期,多少次工作失误,内部做了多少次技术交流分享。。。等等在研发过程中的工作度量
2、 业务结果
参与的项目给公司带来多少收益,个人工作部分分别占总任务量的比重,计算出来个人给公司带来多少收入。。。参考部门的绩效和平均每人的绩效水平
3、 制度考勤
迟到早退啦,请假旷工啦,等等
4、 主观评价
同级的同事对其评价,上级领导的评价,工作态度,团队精神,技术水平,创新精神,主动性,责任心等等。
类似这些,结合你们的实际情况看哪些数据可以作为考核的指标。然后再分别量化到一定的粒度。接着确定每个指标的比重,怎么统计汇总。最后做一个考核制度文档。
考核的执行
有了考核标准和方式以后,就剩下执行了。执行的力度决定了考核制度是不是能起到作用。如果执行得好的话,可以边执行,边收集数据,改进考核方式。没有强有力的推动,不断的收集数据、check && review,考核就会仅仅流于形式了。
(支付宝)给作者钱财以资鼓励 (微信)→
有过 15 条评论 »
考核的内容,必然谈及量化,量化是什么?
量化是人的主观意见,2个不同的“项目主管”会得出2个不同量化标准。至于楼主说的多人量化,那是不现实的。
“项目主管”的水准也是影响“程序员”绩效的一个参数。
一个nice的主管,能有效的管理一支团队高效且符合队员的价值期望。
一个差劲的主管,或者说非技术出身的主管,才是“程序员”的噩梦。这种主管才是希望看到数据的人,才是喜欢拿数据说事的人。
技术出身的主管,不需要拿数据,只要看程序员的工作内容和工作态度,即可判定该程序员的价值所在。因为这类主管明白程序员的产出付出了多少代价,因为这些产出作为主管都曾经历过或类似经历过。
因此,我认为,考核程序员的人必须有一定水准,如果没有水准,任何考核规范都是没有意义的。
我假设存在一种“机器M”,M可以对程序员开发的代码进行客观公正的度量,以测算程序员的绩效值。
一种反例:一名负责内核开发的程序员A,编写了1万行关于线程的代码,A为此参考了大量的操作系统开发资料,包括windows、linux等等。
程序员B负责开发搜索引擎实现算法,编写了1万行关于优化搜索的代码,B为此的设计了数学模型,并将模型通过大量数据加以验证模型的正确度,通过多次失败后才最终修正模型。
M在对程序员A、B进行测算绩效时,将无法有效核准他们的差异,因为M缺少经验,M不可能知道所有领域的开发难度,以及开发时的时间损耗,有些开发并非总是成功。故此反证:M不存在。
由此可知,考核程序员的标准需要什么?需要“领域经验”,领域外的主管无法评估领域内的程序员,这是一个客观存在的事实。
这些就是目前最大的问题所在。
不能用制度保证,而是用人治来保证的,都是虚的。。。如我天朝。