很多HR都比较头疼一个问题：研发部门的绩效考核该怎么搞定!?想要回答这个问题难度不小，而且一篇文章也解决不了所有公司的考核难题。

一、绩效考核不适用研发类职位?

每次一看到有人鼓吹干掉、罢免、取代绩效考核，我总想和他们坐下来好好聊(si)聊(bi)，能秉持这个观点的理由到底是啥?

换位思考一下：如果你去开家公司，就拍着脑袋给员工发奖金么?还是用人人平等大锅饭?抑或是你压根就不发?

说句难听的，拍脑袋弄的结果，那也是绩效考核，只是效果比你瞧不起的那些绩效方式方法更差而已;

错误观点一：高科技行业不适合绩效考核!

有人会认为，高科技行业就没法考核，绩效考核会扼杀创新;那我就问一句：你就算去到美国当教授，你也得拿出能反映出你水平的教学成果和科研成绩吧，难道这不是绩效考核么?

错误观点二：研发的开发周期太长，不适合绩效考核

还有人认为：研发是一条长线，可能需要半年或者一年才做才的出来，所以月度季度的绩效考核并不合适。

那我问你：就不能搞点里程碑的成果出来?就不能分解出 一些阶段性的成果出来?就算你做的东西实在难度太大，但总得有个东西能让大家看到你在进步是不是?如果公司一点都不考核，就坐那等着几个人在那里毫无进展的憋大招，这种公司你敢进?

错误观点三：绩效考核是上司挤兑人的工具

有人评价说，绩效考核就是你的领导：说你行你就行，说你不行行也不行。

确实，这是一个弊端，但这个问题貌似在领导本身评价不客观，而并不是绩效考核本身的问题啊。如果一位中层干部，管理能力业务能力都强的话，他的手下一定是愿意跟随的，我也没哪家正常的企业，天天喊着要取消绩效考核的。

没有规矩，不成方圆。让辛勤工作的贡献大的员工获得更多的回报，让组织有机制去剔除破坏团队战斗力的不合适的人员，这就是我们说的绩效考核价值。

相比于无法精确量化工作而造成的一些困扰;一个无序的管理环境，一个你今天干了活都不知道明天会不会被认可的失控的状态，才是真正可怕的东西。

二、OKR是研发人员的福音和解药?

大家仔细回忆一下，我们这几年身边的流行的管理工具，是不是都在经历：争相传送、大干快上、浅尝辄止、偃旗息鼓，这四个过程。

之前是KPI，现在轮到了OKR。

作为绩效管理界的新宠，OKR的名头却非常响亮，听起来似乎要勇夺绩效考核第一工具的桂冠，但作为HR，我们问一下自己，你所了解有哪些企业正在普及OKR?恐怕能说出3-5家已经非常难得了吧。

为何像BAT、华为、联想、海尔等优质的高科技公司都没有普及OKR呢，是他们不知道OKR么?答案显然并不是，我想那些优质的企业都没有普及OKR，有一重要的原因就是：OKR的评价结果不和个人利益直接挂钩啊。

谁都知道，衡量一家公司好不好，最重要的指标是业绩;衡量一个人的价值，最重要的指标是绩效考核的结果。这两者都和金钱有关，但现在OKR却告诉你不能和金钱相挂钩。业绩做的好不好与我们的的收入都没什么影响，那请问老板图啥?员工图啥?难道图一个老板画过的虚无缥缈的饼?

小儒不是想全盘推翻OKR，但是你有没有发现，OKR这东西其实挺诡异的。

比如说我说今年研发效率提升50%，看上去特别的可度量，但是实际统计口径最后是我自己出的。换句话说，在OKR考核下，我要做的事其实是“吹个牛逼让老板觉得牛逼，并且最后证明我做到了或者做不到”。

所以说，OKR适合是极为自律、自我驱动力极强的团队。但看看普遍的管理环境，我就TMD尴尬了。

三、研发类职位的考核，江湖上盛传的3大流派

关于研发人员的绩效考核，经过那么多企业的试验、试错、打脸、实践、完善，基本可以分为了3大流派，这3大流派并非孤立存在，他们经常交叉与合作，只是3大流派一直在争夺江湖第一霸主的位置。

1、业绩导向派：

这一派人多势众，是研发江湖第一大门派。

他们认为研发的产出就是业务结果，业务结果衡量的主要标准就是规模和收入(产品占有率，产品销售额)，这个流派优点是只看结果，比较受投资人/公司高管的认可。

2、过程导向派：

这一派最近几年也是发展迅速，他们很大一部分成员是从业绩导向派投靠而来。

他们认为研发的产出是一个个小小的里程碑组成的，比方说在新浪微博，什么UV啦、PV啦、转化率、在线时长什么的都是可以视为阶段性过程导向的考核。

3、产品至上派：

这一派供奉乔布斯为祖师爷，目前在三大派中人数最少，但大多都有情怀。

这一派的产出这块的判断往往凭借主观感受，但也因为有着强烈个人审美和产品感觉，一旦方向走对了，就甩前两大帮派一条街，这个门派里的长老就变得至关重要。

3大流派各有优劣，江湖人士纷争不休。

不管怎么争论，3种流派都有一个致命的缺陷，也是研发考核的致命缺陷是：一旦完全严格量化考核，聪明的开发人员都会找到各种方法来规避指标体系本身的漏洞。

所以说，没有一个考核流派是完美的，我们只能取当中最适合自己的。

四、3大门派进行指标设计容易遗忘哪些重要指标

谈到研发类指标设计，HR都是一脸的愁容，常规的研发人员绩效考核的指标HR都懂。

小儒来总结一下那些不怎么被重视，却很重要的指标：

1、要保证有质量地产出，去支撑业务需求的指标

研发部门要响应业务的需求，在响应的过程中，响应的质量是至关重要的，如果响应后做出来的是辣鸡，那响应有个P用!?

快速保证质量地支撑业务需求，研发质量指标就很关键，比如：

业务需求响度

系统可用性

开发关键流程完成度

需求影响度：结合月度计划与月度计划的完成度，看研发的产出是否与业务是直行对齐的(或是落后的)。

系统可用性：挑选业务流程的关键路径，涉及影响这里的故障的都算作影响系统可用性。

开发关键流程完成度：通过数据度量来反推关键流程的执行质量， 例如：转测试，发布回退这些;

有了这三点，才能说研发人员的的产出是支撑了业务的发展，否则研发部门就等于是关上门自己自嗨。

2、要有预见及应付变化的指标项

在考核过程中，很多企业都选择依据过往经验判断所设定的，结果性指标。

但实际随着业务快速发展，团队成员也需要成长，所以每年都需要一些有预见性能够应付未来变化的考核项。这样以便于团队成员更快更好的成长。

这类指标大致可分为：

①、新技术研究引用：主要通过业务需求多少使用新技术占比度量

②、突破创新型优化，主要通过产品功能的突破与创新，来节省公司成本

③、模块重构，性能优化形项目、可以通过单机压测值来度量

3、大型跨部门项目的完成度

大型项目需要跨组联调的很多，但如果不在各自KPI项目里面，其实有时候会比较难推动，所以HR在设计指标的时候，需要增加这么一向。

对于大型项目，Review的过程也可以发现KPI目标的制定是否有可度量的方式，如果不行，那需要再次细化KPI，避免出现最后核算的时候，确认不了是否能完成。

所以说，在给研发团队做指标的时候，千万不要只是跟着产品走，还要看响应、看品质、看发展、看合作。

研发类职位考核最大坑

强行量化!

研发人员量化难度大，所以很多小伙伴会选择强行去量化，这样做其实对研发人员非常不友好，研发人员会认为HR故意找茬。

研发人员的质量考核分为以下三部分：

代码质量：代码本身的质量决定了对后续开发的友好程度

研发质量：研发阶段产生的bug

运维质量：产品上线以后的故障情况和资源消耗情况

第一类，很难量化，小儒的建议是不要去量化，一旦量化内部撕逼会很严重，这一项可以只作为努力提高的方向和主观考核依据。

第二类，做研发的小伙都知道，很难用bug数量来衡量研发质量，建议让研发人员给HR列一张Bug等级表，严重Bug当然要扣分，无关紧要的Bug你扣分就过分了。

第三类，这是可以完全量化的，通过线上服务器消耗、故障恢复时长等来做考核，这种考核的优点同样是投资人和老板看得见，不需要担心指定的KPI偏离了大方向。

总之，小儒给研发人员做过考核的经验就一句话：宁肯用主观评价，也不要引入错误的量化指标。