研发类岗位考核的错误观点
错误观点一：高科技行业不适合绩效考核！
有人会认为，高科技行业就没法考核，绩效考核会扼杀创新；那我就问一句：你就算去到美国当教授，你也得拿出能反映出你水平的教学成果和科研成绩吧，难道这不是绩效考核么？
错误观点二：研发的开发周期太长，不适合绩效考核
还有人认为：研发是一条长线，可能需要半年或者一年才做才的出来，所以月度季度的绩效考核并不合适。
那我问你：就不能搞点里程?的成果出来？就不能分解出 一些阶段性的成果出来？就算你做的东西实在难度太大，但总得有个东西能让大家看到你在进步是不是？如果公司一点都不考核，就坐那等着几个人在那里毫无进展的憋大招，这种公司你敢进？
观点三：绩效考核是上司挤兑人的工具
有人评价说，绩效考核就是你的领导：说你行你就行，说你不行行也不行。
确实，这是一个弊端，但这个问题貌似在领导本身评价不客观，而并不是绩效考核本身的问题啊。如果一位中层干部，管理能力业务能力都强的话，他的手下一定是愿意跟随的，我也没哪家正常的企业，天天喊着要取消绩效考核的。
没有规矩，不成方圆。让辛?工作的贡献大的员工获得更多的回报，让组织有机制去剔除破坏团队战斗力的不合适的人员，这就是我们说的绩效考核价值。
相比于无法精确量化工作而造成的一些困扰；一个无序的管理环境，一个你今天干了活都不知道明天会不会被认可的失控的状态，才是真正可怕的东西。
研发类职位的考核，江湖上盛传的3大流派
关于研发人员的绩效考核，经过那么多企业的试验、试错、打脸、实践、完善，基本可以分为了3大流派，这3大流派并非孤立存在，他们经常交叉与合作，只是3大流派一直在争夺江湖第一霸主的位置。
一、业绩导向派：
这一派人多势众，是研发江湖第一大门派。
他们认为研发的产出就是业务结果，业务结果衡量的主要标准就是规模和收入（产品占有率，产品销售额），这个流派优点是只看结果，比较受投资人/公司高管的认可。
2、过程导向派：
这一派最近几年也是发展迅速，他们很大一部分成员是从业绩导向派投靠而来。
他们认为研发的产出是一个个小小的里程碑组成的，比方说在新浪微博，什么UV啦、PV啦、转化率、在线时长什么的都是可以视为阶段性过程导向的考核。
3、产品至上派：
这一派供奉乔布斯为祖师爷，目前在三大派中人数最少，但大多都有情怀。
这一派的产出这块的判断往往凭借主观感受，但也因为有着强烈个人审美和产品感觉，一旦方向走对了，就甩前两大帮派一条街，这个门派里的长老就变得至关重要。
3大流派各有优劣，江湖人士纷争不休。
不管怎么争论，3种流派都有一个致命的缺陷，也是研发考核的致命缺陷是：一旦完全严格量化考核，聪明的开发人员都会找到各种方法来规避指标体系本身的漏洞。
所以说，没有一个考核流派是完美的，我们只能取当中最适合自己的。
3大门派进行指标设计，容易遗忘哪些重要指标
谈到研发类指标设计，很多人都是一脸的愁容，常规的研发人员绩效考核的指标大家都懂。
小编来总结一下那些不怎么被重视，却很重要的指标：
一：要保证有质量地产出，去支撑业务需求的指标
研发部门要响应业务的需求，在响应的过程中，响应的质量是至关重要的，如果响应后做出来的是辣鸡，那响应有个P用！？
快速保证质量地支撑业务需求，研发质量指标就很关键，比如：
业务需求响度
系统可用性
开发关键流程完成度
需求影响度：结合月度计划与月度计划的完成度，看研发的产出是否与业务是直行对齐的（或是落后的）。
系统可用性：挑选业务流程的关键路径，涉及影响这里的故障的都算作影响系统可用性。
开发关键流程完成度：通过数据度量来反推关键流程的执行质量， 例如：转测试，发布回退这些；
有了这三点，才能说研发人员的的产出是支撑了业务的发展，否则研发部门就等于是关上门自己自嗨。
二：要有预见及应付变化的指标项
在考核过程中，很多企业都选择依据过往经验判断所设定的，结果性指标。
但实际随着业务快速发展，团队成员也需要成长，所以每年都需要一些有预见性能够应付未来变化的考核项。这样以便于团队成员更快更好的成长。
这类指标大致可分为：
1、新技术研究引用：主要通过业务需求多少使用新技术占比度量
2、突破创新型优化，主要通过产品功能的突破与创新，来节省公司成本
3、模块重构，性能优化形项目、可以通过单机压测值来度量
三：大型跨部门项目的完成度
大型项目需要跨组联调的很多，但如果不在各自KPI项目里面，其实有时候会比较难推动，所以在设计指标的时候，需要增加这么一项。
对于大型项目，Review的过程也可以发现KPI目标的制定是否有可度量的方式，如果不行，那需要再次细化KPI，避免出现最后核算的时候，确认不了是否能完成。
所以说，在给研发团队做指标的时候，千万不要只是跟着产品走，还要看响应、看品质、看发展、看合作。
研发类职位考核最大坑：强行量化！
研发人员量化难度大，所以很多小伙伴会选择强行去量化，这样做其实对研发人员非常不友好，研发人员会认为你故意找茬。
研发人员的质量考核分为以下三部分：
代码质量：代码本身的质量决定了对后续开发的友好程度
研发质量：研发阶段产生的bug
运维质量：产品上线以后的故障情况和资源消耗情况
第一类，很难量化，小编的建议是不要去量化，一旦量化内部撕逼会很严重，这一项可以只作为努力提高的方向和主观考核依据。
第二类，做研发的小伙都知道，很难用bug数量来衡量研发质量，建议让研发人员给HR列一张Bug等级表，严重Bug当然要扣分，无关紧要的Bug你扣分就过分了。
第三类，这是可以完全量化的，通过线上服务器消耗、故障恢复时长等来做考核，这种考核的优点同样是投资人和老板看得见，不需要担心指定的KPI偏离了大方向。
总之，小编给研发人员做过考核的经验就一句话：宁肯用主观评价，也不要引入错误的量化指标。
