程序员绩效考核

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