谈谈绩效考核

考核是非常重要的事情，坚持什么样的价值导向，实施什么样的考核标准，就会得到一群什么样的员工。 企业发展到一定规模，大多数会通过一系列KPI考核来量化员工的工作，而软件开发这一行业KPI考核难以量化，更多时候迫于考核压力我们不得不通过制定一些标准来对员工工作进行量化。以下我们就谈谈如何制定考核标准。

我就按照我的团队考核标准和大家谈谈。假如我们采取100分值，完成日常工作可以打60分，而另外的40分则通过其他方式来确定。当然加分的权重可以视项目和公司文化的需要调整不同的权重比例。

第一， 工作态度

 一个人平时的工作表现，除了日常工作的输出，有很大一部分体现在他工作的态度上。

1 对工作是否有热情，在和其他人沟通的过程中是否起到积极主动的作用。如果满足这一项，加分。

2 是否针对现状和问题提出改良性建议，优化团队的工作方式或方法。加分

3 是否热衷于使用工具，提高工作效率，一个热爱打磨工具的人一定爱工作，不然他打磨工具为了什么？可以加分

4 是否热爱学习，引入新技术。如果简单引入新技术，仅会安装、配置、使用，不加分。引入新技术，了解其优缺点及使用场景，深入了解实现原理，能排查BUG和优化性能。加分。

5 热爱分享。在自己学习了新技术或者学会了新技能的时候，能通过博客或者论坛的方式沉淀下来并在团队内分享的。可以加分。

第二，与领导关系

和领导相处是一门艺术，更是情商的表现。优秀的下属甚至可以反向领导。

1 和领导是否熟悉，经常一起吸烟/喝酒/打麻将。考核不应加分。

2 有一类技术人员，沉默寡言，不能和邻导、同事谈笑风生，但是有技术追求，能扎进去解决非常难的问题。加分。

3 杠精型，落实工作安排不积极，做事阳奉阴违。减分。

4 非常听话，完全服从领导安排，自己不加思考，没有提出自己专业见解，也不敢指出领导的错误。减分或持平。

第三，加班相关

我们拒接无意义的加班，也接受一些必须要的加班。

1 如果项目需要积极主动加班的，加分；如果项目需要，又不肯主动加班的，减分。

2 正常工作时间没有高效输出，为了加班而加班的，减分。

3 加班时间长却磨洋工, 降低工作效率或者降低代码质量。减分

第四，工作难度(专家的价值的体现)

大多数情况下工作所遇到的问题都是普通问题，无法体现专家价值。专家水平的要求不能仅要看实现了多少功能，还要看实现难度高低。助理工程师或许会用很复杂的办法解决很简单的问题，资深工程师能用看起来很简单的办法解决很复杂的问题。从而在我们的工作过程中，我们还鼓励和培训专家。

1 能解决项目实现过程中遇到的难题，攻克技术难关的。加分

2 能对于系统架构或者系统提出优化和实施方案的。加分

第五，工作效率和质量并重(专业技能经常被忽略)

　　有的开发人员实现功能的速度很快，但是有很多BUG;富有经验的开发人员，初期进度可能有些慢，但是他提前考虑了各种异常流程，提前解决了性能问题，安全问题，兼容性问题，代码的可读性，可扩展性。通过前期少量的工作避免了后期大量的修改BUG/兼容/重构的工作。以兼容性为例： 前期考虑到兼容性问题，后期就不会花费巨大的成本去做兼容。所以，我们鼓励工作质量，代码质量高，可读性强，易于扩展或兼容的加分。

　　但是，在某些企业，却有写垃圾代码的程序员更有可能得到领导的赏识升职加薪。有些人开发速度快，代码很乱，留下很多bug。然后在之后的工作维护中，疲于去解决BUG，之后带来的是不停的加班去补这些坑。然而，这种现象反馈在某些领导眼里，就成了该同事工作积极，工作热情高，态度端正。而这种能力不强的人，往往很听话，易受领导喜欢。典型现象是：在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场扑救的人倒成了英雄，好心用户甚至还寄来感谢信。老板还给"救火队员"升职加薪。

　　现实中很多领导根本就不去看代码，更不懂软件质量，根本无法区分好代码坏代码。所以要确定一个人的输出，必须得从效率和质量双方面去综合考虑。对于效率高、质量好的同事，应该加分。

第六，勇于任事(长期重要但短期有过无功的事情)

同样的工作，不一样的做法，有的事情做了出力不讨好，但是为了项目的稳定和长期的可维护性，也是不得不去做。

1 创建坚实的基础架构是要花时间和成本的，短时间看不出来效果，不像实现华丽的UI界面，或者开发新功能，或者优化性能那样立竿见影。做基础功能的同学比业务的难以出成绩，应适合加分。开发具体功能的同事业绩很明显，开发低层SDK基础库的业绩则不明显。注意平衡。

2 维护工作：实现新功能和维护旧代码之间的考核。维护旧代码是很难的，比开发新功能更难，并且不出BUG就不会看到成绩，出了BUG又会被批评。对于勇于处理和维护旧功能的同事，适当的加分。

3 重构：能提高质量， 不出BUG则业绩不为领导所知，引入BUG则必被责骂。所以这种勇于重构提升代码质量的应加分

4 重用：不重复造轮子，能合理重用已有功能，提高开发效率的，应加分。

第七，过程与结果

市场只看结果，很多公司领导也按照结果来定义开发的产出，但是，这种不应该一概而论。

如果开发人员按要求开发功能因市场或方向原因未上线，不应减分；如果做的事情是有意义的，虽然短期内很难有成果，也应该相对应的加分。

第八，定量与定性

绩效考核，很多人都希望说能够定量的去考核，但是软件开发本来就是意见难以量化的工作，所以就应该在定量和定性之间取一个平衡点去综合考虑。比如定量的只占总体考核60%，定性的占40%，这个平衡要结合项目情况去做定夺。

后记

每年金三银四都是员工跳槽的高峰期，能力优秀的技术人员如果觉得考核不公平，通常不愿费口舌去申诉报怨，而是悄悄刷简历、找下家。长期以来会劣胜优汰，组织留下的就是能力很普通的。绩效考核很难做到真正的公平公正，我们也一直在自己能够涉及的范围内做到相对的公平公正。绩效考核是一种调节的利器，希望手握这一利器的人都能用得好。