如何对研发人员进行考核？

无忧保职场指南早报：绩效考核是评判员工贡献和所得的最直接有效的标准，但HR对研发人员的考核畏手畏脚，因为害怕绩效考核会遏制研发人员的创新，况且研发的时间长，月度季度的绩效考核并不合适。但实际上，完全可以对研发人员进行阶段性的考核，你至少要让大家看到你的进步，你的工作成绩。

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

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

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

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

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

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

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

　　你有没有发现，OKR这东西其实挺诡异的。

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

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

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

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

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

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

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

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

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

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

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

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

　　三大门派进行指标设计

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

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

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

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

　　业务需求响度

　　系统可用性

　　开发关键流程完成度

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

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

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

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

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

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

　　这类指标大致可分为：

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

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

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

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

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

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

　　研发类职位考核最大坑

　　强行量化！

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

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

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

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

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

　　第一类，很难量化，人力资源专家认为不要去量化，一旦量化内部撕逼会很严重，这一项可以只作为努力提高的方向和主观考核依据。

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

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

　　总之，经验就一句话：宁肯用主观评价，也不要引入错误的量化指标。

买房，摇号，落户，孩子入学都受社保影响，无忧保作为业界领先的个体社保自助缴纳平台推出全国社保代缴服务，保你社保不断缴。

小编有话说：谢谢这么优秀的你来看文章，有什么想对小编说的尽管来吧，大家的支持就是我们的动力，欢迎大家踊跃发表疑问，欢迎吐槽，社保生态圈群：248069515