程序员绩效考核.docx
- 文档编号:29493355
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:6
- 大小:102.29KB
程序员绩效考核.docx
《程序员绩效考核.docx》由会员分享,可在线阅读,更多相关《程序员绩效考核.docx(6页珍藏版)》请在冰豆网上搜索。
程序员绩效考核
程序员绩效考核
LT
就不可避免。
但是,主观的考核应该尽量少,避免出现团队中任人唯亲之类的影响团队整体的现象。
2. 合理量化
对于研发过程中的可以度量的数据,应该尽量合理的量化。
度量的过粗,大家都差不多,效果不明显;度量的过细,对收集指标数据要求比较高,甚至对研发本身会产生一定的影响。
所以,指标的量化应该结合实际的研发流程,做出比较经济的选择。
3. 双向和多向评价
对于上级对下级可以直接给予评价的行为,下级应该也能集体给上级打分。
对于主观考核部分,应该做到360度测评,对某个开发人员的评价,可以先由开发人员自己给自己的主观评价部分打分,再由主管、团队内同事review评价,综合确定最终评价。
4. 要研发过程还是业务结果?
考核程序员的侧重点应该放在过程上,而不是业务的结果上。
业务的结果应该由管理业务的人负责。
简单的说,谁拍板谁负责(或谁受益谁负责)。
所以,我一直觉得苦逼的程序员应该对自己的劳动本身负责。
程序员在自己的一亩三分地做好工作,写得好代码,改得快bug,产出多,质量高,就是一个好程序员。
当然对技术leader、architect的要求要放高一些。
当然,业务的好坏一般关联到公司和部门的performance,这可是奖金和绩效的来源,理所当然跟程序员有关系,但不应该是考核的核心。
对一个好的马龙(一般程序员,不上升到某种所谓的高度)来说,研发的本职工作才是作为一个程序员的核心价值。
这也正是前面说到的不同的职位不同序列应该有不同的要求和考核方式。
5. 发展阶段与侧重点
当然,公司或团队本身的发展阶段,也决定了对程序员考核的侧重点不同。
对于一个能力一般偏下、经常延期、积累差、不规范、处以还没有实现温饱的团队,考核的重点应该是提升团队研发能力,按时完成任务。
对于一个马马虎虎按时完成任务,但是不规范、没合作精神、没动力的团队,考核的重点应该是引导其行为,走向规范化,实现团队协作性的整体提升。
对于一个有一定的积累,相对能力还不错,已经能很好的完成工作任何的团队,考核的重点应该是如何进一步的提高研发水平和质量,实现标准化和流程化…….
指标的制定
具体怎么制定考核指标,我就只说说思路吧。
1、 研发过程
参与了多少项目,写了多少代码和文档,多少测试代码,完成多少模块和用例,解决了多少问题,bug率多少,reopen的bug率多少,多少次工作交付延期,多少次工作失误,内部做了多少次技术交流分享。
。
。
等等在研发过程中的工作度量
2、 业务结果
参与的项目给公司带来多少收益,个人工作部分分别占总任务量的比重,计算出来个人给公司带来多少收入。
。
。
参考部门的绩效和平均每人的绩效水平
3、 制度考勤
迟到早退啦,请假旷工啦,等等
4、 主观评价
同级的同事对其评价,上级领导的评价,工作态度,团队精神,技术水平,创新精神,主动性,责任心等等。
类似这些,结合你们的实际情况看哪些数据可以作为考核的指标。
然后再分别量化到一定的粒度。
接着确定每个指标的比重,怎么统计汇总。
最后做一个考核制度文档。
考核的执行
有了考核标准和方式以后,就剩下执行了。
执行的力度决定了考核制度是不是能起到作用。
如果执行得好的话,可以边执行,边收集数据,改进考核方式。
没有强有力的推动,不断的收集数据、check&&review,考核就会仅仅流于形式了。
前提是公司项目经理需要指定出一套代码标准和项目进度及需求说明的文档,分发给对应的程序员!
分几个方面吧
1、是否按照文档的要求书写代码。
如果一个程序员不能很好的按照领导的要求办事,这样的程序员能力再强,我想开除也并不可惜!
2、根据个人的能力水平分配不同的开发任务。
当然,项目经理是最清楚自己手下人员的个人能力以及能承担多大的开发任务。
有时候项目中遇到事先没有想象到的困难也是正常的,这个时候对于员工加班是正常的,就看这个程序员是否通过其他途径或者求助并且能准时的完成任务!
4、个人的解决问题的逻辑思维能力。
我带团队的时候就遇到过几个程序员,逻辑思维能力真的很弱很弱,给他提供很多解决问题的思路,就差把答案告诉他的,但是结果一样,还是抛给我一句话:
不会!
这样的早一天走,公司早一天减少损失!
3、个人的学习能力。
这点本人觉得非常重要,如果一个程序员没有很强的学习能力的话,一个团队就得不到进步,一个团队得不到进步,结局显而易见!
程序员绩效考核
关于程序员的绩效考核问题,相信是很多软件公司致力追求却一直无法做到量化的目标。
很多考核标准都只是一个框架,但却无法具体细致下去,从而引发了很多劳资方面的纠纷,到最后都是无果而终,无法坚持下去。
但还是有很多人,特别是不懂得技术之人,乐此不疲,希望以此种方法来作为程序员报酬的衡量标准。
最突出的就是“任务量”问题。
软件编程行业的任务,懂点编程的人都知道,这个行业是一个创造性、思维性的行业。
一个任务的工作量多与少是没有一个衡量标准的,原因就是软件功能的实现结果,根本就没有一个最好的标准。
有的人就以工作时数来进行衡量。
真的可以吗?
举个例子:
相同的任务且相同实力的程序员,有的程序员花了一天就完成。
也有的程序员花了两天完成,还有的花了三天,四天,五天完成的。
花一天完成的程序员做了功能上的实现,它是完成的,针对绩效考核来说,是满分的。
但是,比他花多得多时间的程序员呢?
他们除了花在功能实现上,还花了很多时间在代码优化以及界面操作设计上。
那么,从绩效考核来讲,也仅仅是满分。
花一天与花几天的程序员的工作量真的可以相等吗?
谁都知道不可能的。
再打个比方,两个工作任务,有可能在任务量上它真的就一样。
但是,在任务安排上,一个项目组由于技术力量及时间限制上较为宽裕,在一个月内宽松地完成了,而另一个项目组由于在人力资源以及时间限制上,加班加点,用了十天就完成。
以此相比,是哪个项目组的任务量更大一点呢?
所以,绩效考核的框架是死的,而程序员的任务是活的,用一个死的框架套住一个活的思想,程序员只为绩效的要求而实现,久而久之,一个软件项目根本就毫无创造性可言,就是一个生产线生产出来的一个标准化产品而已。
所以,我觉得,程序员的生产,就是个研发,而研发就是创造,不是生产工具,不能以简简单单的任务量来衡量,更不能成为技术层面之外的人简简单单的薪酬衡量标准。
用简单思想框架来束缚程序员的思维创造性,这是拖累研究,极易打击程序员的研究主动性。
但真正没有办法为程序员计算劳动所得吗?
我觉得,既然,程序员的工作是研发创造性的,那么,程序员就应当有个感性的前提,那就是视自身的劳功项目体现出的市场价值作为其劳动所得的标准。
所以,我觉得,在这方面上,项目奖比起冷冰冰的绩效考核温暖得多,它直接反映的是程序员的创造性结果。
在项目组内部的评比,则需要靠他们的直接带领人来衡量贡献的突出性,一是针对项目的技术贡献以及任务完成的质量贡献。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 程序员 绩效考核