关于考评的一些思考

又到年底了，项目组的成员都要进行年终考评，基于考评结果发年终奖。其实，每个成员，都认为自己做了很多事情，都应该获得好的考评结果。但是，对于管理者来说，必须要能分辨出真正做的好的，并给予相对公平的考评结果。否则，就会造成很多的不满，从而影响团队士气。

那么，重点是，管理者如何分清哪些人做的好，哪些人做的不好呢。尤其是软件研发团队，不像销售团队，看销售业绩就行了。关于这个问题，肯定有很多理论、很多方法，这里就不详细列出。学过项目管理的都应该比较清楚。我只就几个常见的点谈一下自己的看法。

第一，bug数量。有的成员总结，我今年修正bug数量xxx个。这个要从两个方面来看：1）这些bug是不是他引入的，如果是他自己引入的bug，绝对不能算工作量，而且还要问责，为什么那么多bug；2）如果是修正别人的bug，可以算工作量，但要弄清楚，这些bug是如何来的。当然，需求变更和bug要分清。对测试人员来说，找到的bug越多，尤其是比较隐蔽的bug越多，说明能力越高。

第二，代码量。有的成员总结，我今年写了xxx行代码。代码是实现功能的，代码的量和实现功能不是成正比的关系，这个和一个包子1元钱，十个包子10元钱完全不能类比的。代码应该至少分为两类，一类是核心代码，支撑产品的底层框架，必须要稳定、高效，而且要尽量简洁实用；一类是业务代码，实现业务流程，一般都是增删改查，逻辑不是很复杂。一行高质量的核心代码，并不比上千行的业务代码的价值低，这个管理者一定要有清晰的认识。还有一点，有些成员喜欢重复造轮子，自己开发的代码并不比现有的开源解决方案强多少(很多开源框架有很好的社区、很好的文档、很好的质量，为什么要再自己做一个？)，而且后续的维护又会增加很多工作量。我的经验是，把合适的开源框架用精，要比自己开发不知好多少倍。所以，用好别人的成果，就是不写一行代码，也会产生巨大的价值。

第三，加班量。有的成员总结，我今年加了xxx天班。搞IT的，一般都有加班，尤其是项目忙的时候。但是，有的管理者认为加班多就好，加班多就工作量大，这是非常错误的。这个问题的根本是，本末倒置啦。因为加班是实现工作量的途径，不是目的。管理者需要清楚的知道，成员完成的任务质量、难度、数量。这就需要管理的精细化，管理者要清楚任务的难度，以及最后完成的质量。每个人的一汇总，结果基本就清晰了。否则，一年下来，基本稀里糊涂，只有看成员平常的外在表现(比如经常加班，比如经常开会，比如经常找领导诉苦自己累。。。)了。

各位，看到后，有没有其他的想法，咱们也可以一起沟通。