如何对程序员绩效考核？

因为自己是php的，所以尤其想听听php程序员管理的经验。

回复内容：

如果用代码量来衡量工作量的话，弊远大于利，员工位增加代码量不顾质量，废代码非常多，可以说惨不忍睹。 我干过这事儿，来抛砖引玉吧。

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

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

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

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

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

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

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

我后来的思路变化了，表格照样填，但实质策略变了。

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

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

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

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

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

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

而你真正要做的，只是尽量为他们向公司争取激励就可以了。 在极端情况下，
——譬如敏捷开发理论下过了磨合期的团队——
可以把一个需求拆成N多个足够细节的模块，并且分别提供每个模块的标准工时。
按标准工时计算绩效即可。

然而大部分情况下，是达不到这种情景的。
而按代码量来计算，特别不靠谱！特别不靠谱！特别不靠谱！ 把程序员提交的代码十天(甚至一个月)左右随机抽查一次看看质量，然后看看他每个月大致提交的代码总量。然后综合评定。

而且会在程序员入职时把这种方式告知他们。我在杭州一家公司兼职他们公司就这样干的，老板也是技术出身，偶尔也参与到审查代码当中来。大家也都很喜欢这种方式，有时一个多星期状态不好啥也不干也没关系。

非常牛逼的方法！！

当然了，程序员要是劳累命那就没办法了，我六点左右开睡，现在就醒了。因为我忍不住要起来修改我们宿舍另两货写的代码…… 绩效考核的先决条件是工作可测量。
从这个角度讲，有两种方式可以综合使用：
1.代码量。每天下班进行工作提交时，统计今日修改，新增的代码行数，业界基本水平大约是200行。

2.进行任务细化分割和管理。MantisBT可以实现这个功能。开发的整个流程，都可以在mantis上加以体现。分析人员逐级分割任务，并将最终可实现的子任务分割给程序员，程序员可以通过统计其任务完成量来估算其工作量。

其实，我觉得BOSS的焦虑在于无法“可视化”的观察项目的进度，这个任务可以通过使用MantisBT，合理设置里程碑来实现。当BOSS看到里程碑相关的任务完成度不断上升的时候，他的焦虑感就会显著降低了。
代码量可以作为基础绩效
但合格的代码必须要有一份KPI指标：有效解决问题、尽可能节省资源、易懂。 代码量和trac中完成任务情况，这是量化的部分，只有这些是不够的。我的经验，还需补充两个非量化指标：1，上游（产品经理或业务部门）评分，有利于摆正供需关系；2，同事互评，提高团队意识。