如何对程序员绩效考核？

心中u你

因为自己是php的，所以尤其想听听php程序员管理的经验。
原文地址：https://www.zhihu.com/question/20417273

继续前进

程序员的考核的确是个难题，很多不懂行的老板甚至采用代码数来考核，真的是贻笑大方了。
我做技术管理差不多7，8年了，虽然不能说是驾轻就熟，但也有一些心得吧，这里简单给几点建议：
1.工期是否delay
这点很重要，程序员也是职场人，职场人优秀与否的第一点应该是deadline，一个经常延期交付的人是不值得信任和给他搞绩效的。
工期不delay是一个基础要求，如果能提前完成那就更好了。
2.交付质量是否稳定可靠
比如后端的QPS、TPS这些，虽然大家都上线了，质量是千差万别的，再比如客户端的崩溃率，是做到了千分之几，还是万分之一，这就是交付质量。
程序员的交付质量非常重要，这意味着用户体验和公司品牌，试想下微信经常崩溃是个什么画面。
3.技术能力的提升度
比如高级工程师你就需要掌握高并发/高可用等技术，socket底层你要了解吧，多线程/多进程防死锁，科学调度等等要做到吧。


这一项要再平时的代码review中考核出来，同样一段代码，技术能力层次差别展现出来的结果是不一样的，哪怕工期差不多，交付质量差不多，但是否做到高内聚、低耦合了，是否能给其他框架复用，是否足够简洁优美等等。
这些也很重要，这决定了程序员的未来。
4.沟通和团队协作
和项目团队各个角色之间的沟通和协作能力。软件开发更多是一个团队合作的事情，尤其是现在复杂的功能软件，都需要通过多角色合作分工完成。如果没有良好的沟通能力和团队协作能力，一定是寸步难行的。

大力水手

或许专业的HR才能给到你正确的答案。
现在很多互联网企业开始学习Google使用OKR工具管理程序开发人员的绩效（注意：OKR是管理绩效，而非考核绩效），但是不免有很多老板或是人力资源部门想要用更加量化的指标来考核程序员。
不管是出于绩效结果应用（提成、奖金、期权等），还是出于压力驱动效率的角度，KPI确实更能被HR和管理层所看好。
但是，很多不专业的HR根本不熟悉程序员的工作流程和工作内容，也很难制定出合适的关键绩效指标，往往使得开发团队抱怨连天。
专业的HR往往会和研发部门讨论，设定出程序开发人员的KRA，再细分出KPIs进行试点。当然，后期必然有一个修改KRA和KPIs的过程。

KRA关键结果领域（Key Result Area）

KRA意为关键结果领域，它是为实现企业整体目标、不可或缺的、必须取得满意结果的领域，是企业关键成功要素的聚集地。它是对组织使命、愿景与战略目标的实现起着至关重要的影响和直接贡献领域，使关键要素的集合。

就软件开发人员而言，KRA可能是：

• 按照固定的规范开发软件
  
• 根据需要撰写技术文档
  
• 及时完成软件
  
• 测试阶段没有错误
  
• 后期实施阶段没有错误
  
• 由于软件错误而造成的时间损失
  

以下，结合上述的KRA，并参考阿里和华为的一些研发部门（部分团队用的是OKR和BSC）的KPIs，给出适合考核程序员的参考指标。
1、编码规范：1-5分
2、文档规范：1-5分
3、
新功能完成量：超过目标、达到要求目标、尚可、欠佳、落后
Bug修正量：超过目标、达到要求目标、尚可、欠佳、落后
设计完成质量：超过目标、达到要求目标、尚可、欠佳、落后
4、
测试阶段Bug数
测试阶段Bug修复数
测试阶段Bug修复率
5、
软件崩溃率
后期实施阶段用户反馈Bug数
后期实施阶段用户反馈Bug修复数
后期实施阶段用户因Bug而导致的损失评级
后期实施阶段Bug响应速度评分
6、
因Bug的存在而投入时间的长度
处理积压错误的速度

考虑到很多企业可能连代码规范都没有，也不需要开发撰写开发文档。那么下面还给出KPI的设计方法和提取原则，毕竟，授人以鱼不如授人以渔。
KPI设计方法

常用的方法是“鱼骨图”分析法和“九宫图”分析法。
依据公司级的KPI逐步分解到部门，进而分解到部门，再由部门分解到各个职位，依次采用层层分解，互为支持的方法，确定各部门、各职位的关键业绩指标，并用定量或定性的指标确定下来。
鱼骨图法是一个十分形象的方法，以“企业战略目标”为“鱼头”，层层分解出“鱼骨”。
主要步骤如下：

• 明确目标——明确鱼骨图的鱼头，必须有一个明确的目标，没有明确的目标，KPI都是空谈；
  
• 使用脑力激荡法——寻找影响因素，集思广益，寻找各个主要因素；
  
• 利用鱼骨图进行，按照结果、策略、短板、板块进行逻辑分析——剔除不合理的因素，将相同的因素归纳到一起；
  
• 利用鱼骨图，寻找衡量关键因素的KPI。
  

KPI提取原则

确定关键绩效指标有一个重要的SMART原则。
SMART 是 5 个英文单词首字母的缩写：

• S 代表具体（Specific）：指绩效考核要切中特定的工作指标，不能笼统；
  
• M 代表可度量（Measurable）：指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的；
  
• A 代表可实现（Attainable）：指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标；
  
• R 代表关联性（Relevant），指绩效指标是与上级目标具明确的关联性,最终与公司目标相结合；
  
• T 代表有时限（Time bound）：注重完成绩效指标的特定期限。
  

以上，不过确实更加建议程序员的绩效管理采用OKR方法，想要了解OKR你可以看看这篇：
UI 设计部门如何绩效？

长长的路

在极端情况下，
——譬如敏捷开发理论下过了磨合期的团队——
可以把一个需求拆成N多个足够细节的模块，并且分别提供每个模块的标准工时。
按标准工时计算绩效即可。
然而大部分情况下，是达不到这种情景的。
而按代码量来计算，特别不靠谱！特别不靠谱！特别不靠谱！

同花顺

我干过这事儿，来抛砖引玉吧。
不是我想做，是当时的公司有这制度，财年结束前要和部门里的每个人面谈一次，填一摞表格。
我们程序员都知道这工作不是工厂里拿计件工资的工人，比如今天你做八个工时，组装了五十台收音机，质检发现两台次品，为了质量管理的需要，你今天的绩效是四十八台收音机，如果每台收音机你挣五块钱，那么你今天挣了5*48=240元。如果你一个季度生产率排名考前，公司考虑给你每台加五毛钱。如此这般。
但程序员的真正绩效是他的competence，这不是一个容易量化的概念。competence可以是创造性的解决技术或业务问题，可以是紧张项目开发中爆发的个人效率，可以是长期和别的部门对接时候的影响力，可以是永远不成为bottleneck的自我管理能力，可以是因为个人实力带给项目团队的确定性，可以是在需要的时候提供某个特别具体的技术方案或者理念与实践，可以是在危机的时候愿意投入自己时间到非自己领域的团队精神，可以是写出的东西对开源社区的贡献以及因此给公司带来的无形效益，可以是带领新人大大加速他们的融入，也可以是一串充满灵感的优质代码 ...
笼统得说，就是用自己的技术和经验搞定事情的那种能力。
编程太复杂了，一个人可以贡献的方面太多了，如果用传统的绩效考核制度，就很容易给团队套上紧箍咒，制度不合适，不充分反映工作性质，就会产生副作用，制度和人，人和人之间就会产生桎梏，分散团队注意力，破坏团队和谐。做考核的人要小心翼翼，把一个人放进一个预设好的框框里，实际上这种工作一点意义也没有。
为什么有些公司要自寻烦恼？也许因为老板是从传统行业过来的，不熟悉IT团队的工作方式，下面的人也不敢告诉他。也许是因为公司需要这种政治，刻意给人一点压力，给管理层事做。也许因为HR觉得这是薪酬体系的必要部分。
无论处于哪种原因，这种考核方式通常既不提升团队和个人的生产力，只会动员起很多人，一起浪费很多时间；实际也不影响最终的薪酬审核，对每个个人的意义并不产生实质影响，一方面因为各种政治与非政治的考虑，评审总是会偏向中庸的路线，不能过分打击稍后进的，也不能对先进的奖励得太过分，尤其是加薪，大多数公司的职场就是这么回事，每种制度看上去条条框框，执行到关键步骤，都是雾里看花。
我后来的思路变化了，表格照样填，但实质策略变了。
第一是要想保持团队士气，不因为死板的绩效考核让自己和团队里的人陷入难堪的境地，我提高了招聘的标准。实际团队的成员水平是有层次的，初中高都应该有，有一段时间因为项目的关系，也招过不太满意的人，虽然是极少数，但还是觉得这个成本太大，找一个不像样的进来跟自己扯淡然后利用制度来开掉他，不如找一个标准高的，然后狠狠奖励他。我见过这样的公司，招聘放水，不对全局负责，看重短期性价比，结果成为中层的一块心病，把他们推向管理的下限，做过面试官的都知道，在程序员这个行业，平庸的人数都数不过来，标准稍微一降的结果，是任何绩效考核都应付不过来的。
这样一来，每半年或一年的考核，我的注意力就只需要放在可否激励，如何激励，激励多少，以及如何和HR争取预算这些更积极的问题上来了，同事们也配合。
所以与其招进来烂人用绩效制度制约之，不如招聘时确保进来的都至少是当职的人，有竞争力的人对所有制度都是比较友好的，对管理也是。以激励为目的的考核，谁不欢迎呢？
第二是强调个体责任，减少项目调度，尽量让每个程序员有一块自己的领域，是某一个业务或者技术部分的专家，比如A做mobile端的开发，就会尽量让他把mobile app做过瘾了为止，没有特殊情况，不轻易他随机调到别的部分。如果每个人的中长期权责是清楚的，那么绩效考核也会是清楚的，每个人能说出自己工作的纵向成果，比如A前六个月对mobile app完成了关键性的重构，使用了更新更快的技术，核心代码的效率有了大幅提升，用户体验有明显改善。这些东西他不说你也知道，因为分工的明确，你自己也很好跟踪，peer之间也对对方干了什么取得了什么成果十分清楚，这样就为考核系统的透明化提供了基础，透明意味着公平与效率。
从管理的角度，每个同事的工作成效都有长期的跟踪，其中涉及的难度大小都可以比较公正地评判，如果谁一个阶段的效率没有其他人高，你就可以把他所负责的部分的具体情况考虑进去，这能帮你作出更好的评价。更值得考虑的，是你可以把注意力放在每个人的具体成长上，很多时候横向比较本来就是没什么意义的。考核周期临近的时候，填不填表格，你心里都是有数的。
也许最重要的，是每个人都从专注的工作中学到了东西，对自己的部分有更大的责任感，并且他们知道，这些在公司的考核系统里，都是可见的。在需要的时候，他们应该为承担更大的责任，作好了准备。
而你真正要做的，只是尽量为他们向公司争取激励就可以了。

清风寡欲

把程序员提交的代码十天(甚至一个月)左右随机抽查一次看看质量，然后看看他每个月大致提交的代码总量。然后综合评定。
而且会在程序员入职时把这种方式告知他们。我在杭州一家公司兼职他们公司就这样干的，老板也是技术出身，偶尔也参与到审查代码当中来。大家也都很喜欢这种方式，有时一个多星期状态不好啥也不干也没关系。
非常牛逼的方法！！
当然了，程序员要是劳累命那就没办法了，我六点左右开睡，现在就醒了。因为我忍不住要起来修改我们宿舍另两货写的代码……