人员考评问题

实施绩效考核总是很困难：
1、工作量难以度量，不能经代码行来度量，有时几行代码胜过千行代码；如果用功能点计算，有些功能复杂，有些则简单，也有所欠缺。如果加上技术复杂度系数，则考证的工作量加大了。
2、考评工作量大，特别是考评的周期越短、考评的系数越多、考班次的人员越多，则工作量就越大。有时会觉得投入这么多工作量进行考评，是否值得。
3、难以做到客观。许多公司考评结果，3分客观、7分主观，难于公平；
4、考评人员的选择问题。如果让团队自评，则可能出现小帮派，导致结果不公正；如果让人事参让考评，因为人事不懂技术，难以保证公平；如果让部门领导考评，又缺乏深入。……
总之，不考评不行，考评不公平、公正也不行。
建议多使用公开技术评审，效果可能好些，浪费少些。

老板考虑Leader，Leader考虑developer。Leader需要考虑每个人的贡献度，以及工作态度，要看长期效果。

我在想，考评的目的是什么？

软件公司的考评要靠直接人事，就是和员工直接接触的人，但是也要考虑主管是否是喜欢被拍马屁的人，这个很重要，因为考评一定要客观，实际，一定不能主观！！

呵呵就凭这句话，我要是老板，你就是我的人事总监了

Bug率+难度系数可以进行人员素质的考核，当然Bug率需要有单元测试来配合，尤其是在总体构建时看看今天的增量对以往已完成构建的影响，如果今天的成果给已完成部分带来了很多的Bug那么就说明今天的开发缺乏整体感，这里的Bug率很能反应队员的水平，一个好的队员一般都比较有整体观念，在开发新功能的时候会顾及老的功能，所以在新开发的过程中，出现影响旧成果的Bug就比较少，反之就多，所以配合单元测试的Bug率很能反应队员的水平。

当然，还有一点比较重要，有个难度系数的问题，难度系数比较高的工作容易出现较高的Bug率，所以给任务评测一个难度系数，最终让难度系数和Bug率进行一个合理的系数运算，就能比较直观的反应队员的真实水平。

软件的量比较难考核，但是水平比较容易考核，最终的利益分配可以根据水平进行分配，这样一方面可以是水平高的队员得到合理的回报，同时还可以激励后来的队员奋进学习，勇于承担难度系数高的工作。

考评当然只能靠直接的领导做。不过客观总是一种希望而已，主管不可能是完全客观的，任何人都会有一些主观思想的。关键是制度允许这种主观到什么程度。同样能力和成绩的两个人，主管就是不喜欢其中一个，制度不让这两个人评的差太远就OK了。

针对项目做考评，其实真正考评的只是项目经理或项目负责技术的人员，和项目成员关系不是很大。方向性错误，为什么要成员来买单呢？

我们公司曾经试行过1个bug罚款5元的做法

嘿嘿

那样子复杂模块就没人喜欢作了。

和考试的目的基本上是一样的
资源就那么多，总有人想多占，那就得找个规则出来考呀