2007-08-08

人员考评问题

经常看到这个问题，同时也没有什么好的参考答案。 人员考评大概是传统管理和现在的IT项目结合的一个难点。
人员不考是不行的 。 这个是传统观点，也是我 比较认同的观点。
IT项目团体性， 主观性，以及可考察的指标又不够明确。工作量？bug率？ 项目一年运营结果和计划预期对比？这些考察指标都有，但是都不全面。总有各种例子能够说出一个反面 情况。

但是对于一个团队，如果公司足够大， 以团队为考评对象。大概可行。 不过 众多小公司还是只能是针对个人。 总不能团队做坏了个项目，把整个团队都开除了吧。
针对个人，就要明确 责任是什么， 工作量有多少？ 最好的完成度又是如何的？ 这些检查点， 都是主观估算的，这个就是难点所在了。考评实在是 太过于主观了。
不过考评不能没有。只能设法选择一种来做了。实际是否合适，还得检验过才知道。

有种中庸的办法， 考评是针对项目整体的，奖惩也是针对团队整体的。 最终的奖惩结果，团队自己处理。不知道这样的办法，具体实行起来是否合适？
评论
celine 2007-11-19
偶们对测试人员奖果冻一个～

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

嘿嘿
celine 2007-11-19
pikachu 写道
我在想，考评的目的是什么？

和考试的目的基本上是一样的
资源就那么多，总有人想多占，那就得找个规则出来考呀
抛出异常的爱 2007-11-19
lsdayy 写道
我们公司曾经试行过1个bug罚款5元的做法

嘿嘿

那样子复杂模块就没人喜欢作了。
lsdayy 2007-11-19
我们公司曾经试行过1个bug罚款5元的做法

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


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

针对项目做考评，其实真正考评的只是项目经理或项目负责技术的人员，和项目成员关系不是很大。方向性错误，为什么要成员来买单呢？
w_y_g 2007-10-29
Bug率+难度系数可以进行人员素质的考核，当然Bug率需要有单元测试来配合，尤其是在总体构建时看看今天的增量对以往已完成构建的影响，如果今天的成果给已完成部分带来了很多的Bug那么就说明今天的开发缺乏整体感，这里的Bug率很能反应队员的水平，一个好的队员一般都比较有整体观念，在开发新功能的时候会顾及老的功能，所以在新开发的过程中，出现影响旧成果的Bug就比较少，反之就多，所以配合单元测试的Bug率很能反应队员的水平。

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

软件的量比较难考核，但是水平比较容易考核，最终的利益分配可以根据水平进行分配，这样一方面可以是水平高的队员得到合理的回报，同时还可以激励后来的队员奋进学习，勇于承担难度系数高的工作。
zagile 2007-10-06
pikachu 写道
我在想，考评的目的是什么？


呵呵就凭这句话，我要是老板，你就是我的人事总监了
InnocentBoy 2007-09-26
软件公司的考评要靠直接人事，就是和员工直接接触的人，但是也要考虑主管是否是喜欢被拍马屁的人，这个很重要，因为考评一定要客观，实际，一定不能主观！！
pikachu 2007-09-26
我在想，考评的目的是什么？
cnfree 2007-09-19
老板考虑Leader，Leader考虑developer。Leader需要考虑每个人的贡献度，以及工作态度，要看长期效果。
yawolf 2007-08-31
实施绩效考核总是很困难：
1、工作量难以度量，不能经代码行来度量，有时几行代码胜过千行代码；如果用功能点计算，有些功能复杂，有些则简单，也有所欠缺。如果加上技术复杂度系数，则考证的工作量加大了。
2、考评工作量大，特别是考评的周期越短、考评的系数越多、考班次的人员越多，则工作量就越大。有时会觉得投入这么多工作量进行考评，是否值得。
3、难以做到客观。许多公司考评结果，3分客观、7分主观，难于公平；
4、考评人员的选择问题。如果让团队自评，则可能出现小帮派，导致结果不公正；如果让人事参让考评，因为人事不懂技术，难以保证公平；如果让部门领导考评，又缺乏深入。……
总之，不考评不行，考评不公平、公正也不行。
建议多使用公开技术评审，效果可能好些，浪费少些。
likeblood 2007-08-14
bug率，呵呵，想想就郁闷，打给我的错误，90%不是我的问题，我在最底层，负责数据的提供，但是到表现层隔着好几层的调用，但是都算我头上了，要是真也当个考评参数。。。。嘿嘿
Lucas Lee 2007-08-14
jack 写道
做领导总想考，做手下的永远不愿意被考 。

考的不合理。
要考虑的因素很多，不能用简单粗暴的方式，比如写的代码行数之类。
允许水平一般的人的生存，允许水平高的人出头，允许水平较低的人有上升的机会。

人是不一样的，人在不同阶段心态也不同。
比如刚毕业的，可能想得得多就是多赚点钱、多学点技术，同时可能没有别的去处，所以愿意加班；
工作了3-5年左右的，该结识女朋友了，所以加班的意愿降低；
结婚生子的人，更在意平稳的生活，平衡家庭和工作，不愿意也没有精力加班了。

如果有考评制度，试试对上述几类人是否都能适合？
steve_gu 2007-08-10
jack 写道
做领导总想考，做手下的永远不愿意被考 。


那多半是考得不到位
gengjw 2007-08-10
《动物职场》中一语中的：
员工总是想花最少的精力挣最多的钱。
老板总是想花最少的钱让员工干最多的事。
双方都在试探对方的容忍极限，只要不越过那个无法容忍的临界点，就最大限度的忽悠对方。

对这种老板和员工我的评价是只有money，没有理想！

现实并不见得理想和money一定是对立的，对想挣钱又想实现理想的人肯定会有更好的解决办法。
对于只在乎钱的人上述的办法是最好的！
只要理想不要面包的人，我没见过！

绩效考核，想想老板和员工都是些什么人，就能模出一个大概思路来。
月影梧桐 2007-08-09
那也不一定吧
考评做的好，对成员是牵引，激励先进，促进落后者进步
否则又回到大锅饭时代了
jack 2007-08-09
做领导总想考，做手下的永远不愿意被考 。
月影梧桐 2007-08-09
考评，不管那个行业那种职位，都不可能象运动员比赛那样，秒表一卡，米尺一拉就清清楚楚地列出个一二三来，肯定会存在主观的成分，这件事情确实非常考验主管的智慧。

标准，应该针对每个人度身量制，不可能一个系统工程师和一个初级程序员都一样，而且应该主管和员工达成一致。可以从三个方面来考虑，一是结果，比如完成的任务量，按时交付的情况；二是过程，比如作为一个teamleader，你要主动积极去组织去计划；三是对团队的贡献，跨团队跨部门协作情况。对teamleader，pm这样的管理角色，要参考其团队的整体绩效。

作为主管，最终给出评价的时候肯定存在主观的成分，但是一个比较好的主管，会对成员的工作情况比较了解，同时主管在整个过程中有辅导的责任，不能是到最后评价的时候说你这没做好那没做好，在过程中就应该及时给予指导和支持，这样结果会相对有说服力并被团队成员认同。

个人不建议将一个团队的结果加在每个成员的身上，团队整体完成质量再好，也可能存在低绩效员工，反之亦然。

另，考评不可运用的太过，参考《绩效主义毁了索尼》

jack 写道
麻烦就在这里， 考核，或者考评，总的有个标准量。 但是在it项目中这样的标准量很难确定。标准量不准确，考评自然就是主观+主观了。
jack 2007-08-08
麻烦就在这里， 考核，或者考评，总的有个标准量。 但是在it项目中这样的标准量很难确定。标准量不准确，考评自然就是主观+主观了。
javavsnet 2007-08-08
我觉得针对项目考评更可行一些。毕竟对于公司，对于客户来说，项目做的好不好，是否让客户满意是个硬标准，也是最重要的标准。只要客户满意了，项目成员工作量再少也应该得到奖励。
有个问题，对个人如何衡量工作量？代码行数？工作时间？这些衡量标准都是鞭打快牛呀。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

jack
搜索本博客
我的相册
Ef77f3e6-c72c-4457-992b-6ca5d1d9263a-thumb
4
共 1 张
最近加入圈子
存档
最新评论