浅谈程序员的绩效考核

左手的ㄟ右手 2022-05-28 12:46 141阅读 0赞

今天一个朋友问我程序员应该怎么考核。我想了想，总结了下我理解中一般开发人员的绩效考核。

考核的意义

首先一个前提是，考核是手段不是目的。我一直觉得对一个团队来讲，有两个基本目标：一个是完成自己承担的工作任务，一个是提升整个团队的能力。这两个目标相互促进，进而实现螺旋式的上升发展。考核只是为了更好的了解工作情况和团队情况、更清晰更准确的认识剖析自我，为改进和提升做准备的技术手段。

所以开发人员的考核对团队来说，有两层意义：既是团队成员的绩效奖金荣誉的一个数据支持，也是团队整体建设进一步发展的依据。

对个人来说，也有两个意义：横向可以与团队内其他成员做对比看到差距继续努力，纵向也可以跟自己的不同时间段做对比看到进步的足迹。

从设计上讲，考核应该跟公司的职级职位序列和绩效奖金等制度挂钩，不同的层次、不同的岗位，应该有一些不同的要求和考核方式，最终把考核的结果通过某些奖惩形式实施下来。没有奖惩激励的考核，只是纸上谈兵的空洞形式。

考核的原则

程序员的考核一般可以从研发管理过程、项目与部门效益、公司考勤制度、主观考核评价指标等组成。因为程序员经常无偿加班（没办法，难道不是事实么？），公司考勤之类的制度应该不怎么用得到程序员的头上，剩下的主要也就是过程、效益和评价了。

考核的原则我觉得有如下几个：

1.    主客观相结合

一般来说，我们希望可靠本身越客观越好。但是制定指标收集客观数据，分析整理，对于IT研发过程来说，都是很复杂的事情。特别是研发本身不规范，技术能力差，不成熟的团队，变数大、流程不标准，很多事情难以度量。主观的一些东西就不可避免。但是，主观的考核应该尽量少，避免出现团队中任人唯亲之类的影响团队整体的现象。

2.    合理量化

对于研发过程中的可以度量的数据，应该尽量合理的量化。度量的过粗，大家都差不多，效果不明显；度量的过细，对收集指标数据要求比较高，甚至对研发本身会产生一定的影响。所以，指标的量化应该结合实际的研发流程，做出比较经济的选择。

3.    双向和多向评价

对于上级对下级可以直接给予评价的行为，下级应该也能集体给上级打分。对于主观考核部分，应该做到360度测评，对某个开发人员的评价，可以先由开发人员自己给自己的主观评价部分打分，再由主管、团队内同事review评价，综合确定最终评价。

4.    要研发过程还是业务结果？

考核程序员的侧重点应该放在过程上，而不是业务的结果上。业务的结果应该由管理业务的人负责。简单的说，谁拍板谁负责（或谁受益谁负责）。所以，我一直觉得苦逼的程序员应该对自己的劳动本身负责。程序员在自己的一亩三分地做好工作，写得好代码，改得快bug，产出多，质量高，就是一个好程序员。当然对技术leader、architect的要求要放高一些。当然，业务的好坏一般关联到公司和部门的performance，这可是奖金和绩效的来源，理所当然跟程序员有关系，但不应该是考核的核心。对一个好的马龙（一般程序员，不上升到某种所谓的高度）来说，研发的本职工作才是作为一个程序员的核心价值。这也正是前面说到的不同的职位不同序列应该有不同的要求和考核方式。

5.    发展阶段与侧重点

当然，公司或团队本身的发展阶段，也决定了对程序员考核的侧重点不同。

对于一个能力一般偏下、经常延期、积累差、不规范、处以还没有实现温饱的团队，考核的重点应该是提升团队研发能力，按时完成任务。

对于一个马马虎虎按时完成任务，但是不规范、没合作精神、没动力的团队，考核的重点应该是引导其行为，走向规范化，实现团队协作性的整体提升。

对于一个有一定的积累，相对能力还不错，已经能很好的完成工作任何的团队，考核的重点应该是如何进一步的提高研发水平和质量，实现标准化和流程化…….

指标的制定

具体怎么制定考核指标，我就只说说思路吧。

1、       研发过程

参与了多少项目，写了多少代码和文档，多少测试代码，完成多少模块和用例，解决了多少问题，bug率多少，reopen的bug率多少，多少次工作交付延期，多少次工作失误，内部做了多少次技术交流分享。。。等等在研发过程中的工作度量

2、       业务结果

参与的项目给公司带来多少收益，个人工作部分分别占总任务量的比重，计算出来个人给公司带来多少收入。。。参考部门的绩效和平均每人的绩效水平

3、       制度考勤