如何对程序员绩效考核？

我干过这事儿，来抛砖引玉吧。

不是我想做，是当时的公司有这制度，财年结束前要和部门里的每个人面谈一次，填一摞表格。

我们程序员都知道这工作不是工厂里拿计件工资的工人，比如今天你做八个工时，组装了五十台收音机，质检发现两台次品，为了质量管理的需要，你今天的绩效是四十八台收音机，如果每台收音机你挣五块钱，那么你今天挣了5*48=240元。如果你一个季度生产率排名考前，公司考虑给你每台加五毛钱。如此这般。

但程序员的真正绩效是他的competence，这不是一个容易量化的概念。competence可以是创造性的解决技术或业务问题，可以是紧张项目开发中爆发的个人效率，可以是长期和别的部门对接时候的影响力，可以是永远不成为bottleneck的自我管理能力，可以是因为个人实力带给项目团队的确定性，可以是在需要的时候提供某个特别具体的技术方案或者理念与实践，可以是在危机的时候愿意投入自己时间到非自己领域的团队精神，可以是写出的东西对开源社区的贡献以及因此给公司带来的无形效益，可以是带领新人大大加速他们的融入，也可以是一串充满灵感的优质代码 ...

笼统得说，就是用自己的技术和经验搞定事情的那种能力。

编程太复杂了，一个人可以贡献的方面太多了，如果用传统的绩效考核制度，就很容易给团队套上紧箍咒，制度不合适，不充分反映工作性质，就会产生副作用，制度和人，人和人之间就会产生桎梏，分散团队注意力，破坏团队和谐。做考核的人要小心翼翼，把一个人放进一个预设好的框框里，实际上这种工作一点意义也没有。

为什么有些公司要自寻烦恼？也许因为老板是从传统行业过来的，不熟悉IT团队的工作方式，下面的人也不敢告诉他。也许是因为公司需要这种政治，刻意给人一点压力，给管理层事做。也许因为HR觉得这是薪酬体系的必要部分。

无论处于哪种原因，这种考核方式通常既不提升团队和个人的生产力，只会动员起很多人，一起浪费很多时间；实际也不影响最终的薪酬审核，对每个个人的意义并不产生实质影响，一方面因为各种政治与非政治的考虑，评审总是会偏向中庸的路线，不能过分打击稍后进的，也不能对先进的奖励得太过分，尤其是加薪，大多数公司的职场就是这么回事，每种制度看上去条条框框，执行到关键步骤，都是雾里看花。
我后来的思路变化了，表格照样填，但实质策略变了。

第一是要想保持团队士气，不因为死板的绩效考核让自己和团队里的人陷入难堪的境地，我提高了招聘的标准。实际团队的成员水平是有层次的，初中高都应该有，有一段时间因为项目的关系，也招过不太满意的人，虽然是极少数，但还是觉得这个成本太大，找一个不像样的进来跟自己扯淡然后利用制度来开掉他，不如找一个标准高的，然后狠狠奖励他。我见过这样的公司，招聘放水，不对全局负责，看重短期性价比，结果成为中层的一块心病，把他们推向管理的下限，做过面试官的都知道，在程序员这个行业，平庸的人数都数不过来，标准稍微一降的结果，是任何绩效考核都应付不过来的。

这样一来，每半年或一年的考核，我的注意力就只需要放在可否激励，如何激励，激励多少，以及如何和HR争取预算这些更积极的问题上来了，同事们也配合。

所以与其招进来烂人用绩效制度制约之，不如招聘时确保进来的都至少是当职的人，有竞争力的人对所有制度都是比较友好的，对管理也是。以激励为目的的考核，谁不欢迎呢？

第二是强调个体责任，减少项目调度，尽量让每个程序员有一块自己的领域，是某一个业务或者技术部分的专家，比如A做mobile端的开发，就会尽量让他把mobile app做过瘾了为止，没有特殊情况，不轻易他随机调到别的部分。如果每个人的中长期权责是清楚的，那么绩效考核也会是清楚的，每个人能说出自己工作的纵向成果，比如A前六个月对mobile app完成了关键性的重构，使用了更新更快的技术，核心代码的效率有了大幅提升，用户体验有明显改善。这些东西他不说你也知道，因为分工的明确，你自己也很好跟踪，peer之间也对对方干了什么取得了什么成果十分清楚，这样就为考核系统的透明化提供了基础，透明意味着公平与效率。

从管理的角度，每个同事的工作成效都有长期的跟踪，其中涉及的难度大小都可以比较公正地评判，如果谁一个阶段的效率没有其他人高，你就可以把他所负责的部分的具体情况考虑进去，这能帮你作出更好的评价。更值得考虑的，是你可以把注意力放在每个人的具体成长上，很多时候横向比较本来就是没什么意义的。考核周期临近的时候，填不填表格，你心里都是有数的。

也许最重要的，是每个人都从专注的工作中学到了东西，对自己的部分有更大的责任感，并且他们知道，这些在公司的考核系统里，都是可见的。在需要的时候，他们应该为承担更大的责任，作好了准备。

而你真正要做的，只是尽量为他们向公司争取激励就可以了。