如何评价个人在团队中的绩效

来道数学题先

已知a,b>0, (a+b)/2, sqrt(ab) 和 2/(1/a+1/b) 谁大？

现实中的人就像上面的a和b一样，虽然个体都一样，但组成的团队却可以有各种生产力。一个积极的评价方式能很有效地减少内耗，提高生产力。这篇博客能为你制定一个积极的评价方式提供参考。

世界团队千奇百怪，找到一种通用的评价方式是，不靠谱的。一群人在搬砖头，您可以通过他们的搬运量来评价他们的绩效。但是如果服务业，比如一群老师 在教计算机系列课程，没有砖头就不好评论了。这时让学生自己来评价是一种很好的选择。但是如果医生和护士在合作手术，让病人来评价就不太合适了。也许病人 睡了或者永远睡了。这时，相互评价是一种很好的选择。有时合作者之间是信息不对称的，比如

一群码农合作开发软件。只有码农自己知道偷了多少菜。这时我们如何评价个人在团队中的绩效呢？

我们调查了现行的一些评价方法，评价的主要参考有

• 工作时间

这已经是一种灰常灰常古老的评价方式了。但是这却无疑是最广泛使用的评价方式。因为在任何行业这都是个杀手级的评价方式。而且有一套很成熟的操作方 法，进监狱的时候刷一次卡，出监狱的时候刷一次卡。期间，用摄像头，或者很土地，用肉眼监视囚犯的活动。我跟很多上班族讨论过这个问题，他们觉得世上最痛 苦的事莫过于此。

在很多行业，这已经是一种很有效的一评价方式了。因为 时间 == 投入 == 绩效。但在IT行业，情况不太妙。因为这个行业太神奇了。首先，码农们面对的是一台电脑，不是普通的机器。电脑不仅是生产工具，更是一款全能的娱乐平 台。"不准看小说，不准看视频，封QQ端口"却永远堵不住码农们勇敢的心。另外一方面，在这个行业，重复做同一件事的情况太常见了。如果没有很好的软件工 程思想，Bug能吞噬所有时间。《人月神话》第8章值得一读。即使不做重复工作，时间投入也很少正比于绩效。因为每个人的效率很不一样，如果仅仅用时间来 评价的话，很容易打击码农的积极性。所以工作时间不是一个很和谐的评价方式。

• 代码量 （== 砖头块数？）

很自然的，码农的产品就是代码。用代码量来评价码农的表现是很直接很方便。但是，实际上，用户关心的不是软件多大，而是软件的实用性。人们在争论卸 载360还是QQ时，很少有把程序大小列入比较对象。但是很多开发公司却把代码量作为评估参考。这让人很费解。在IT这个神奇的行业，用代码量来评价码农 会有很多漏洞。首先，用行数作为衡量单位的话，空行可能会大量产生。如果空行不被允许的话，不必要的注释会很常见。或者你能想到更多的衡量单位，但是我觉 得漏洞是不可避免的。更重要的是，像我们前面提到的，代码量并不是我们的最张目标。所以用代码量来评价码农的工作是一件很愚蠢的事情。

• 任务量

这是我了解的一些业界知名企业采用评价方式，算法如下

1. 码农向地主请求任务
2. 地主分配任务给码农
3. 码农完成任务
4. 码农提交任务
5. 地主确认
6. 跳到1

如果一切都很顺利的话，这是一种很完美的算法。因为这种面向任务的评价方式像改革开放的春风一样，很能煽动码农的积极性。

绩效 = 码头块数 = 任务量   =》   完成更多任务== 赚更多的钱

但这需要两个断言成立

i  地主是神，能很精准地衡量每个任务的绩效

ii 地主是神，能很精准地衡量每个任务的完成情况

虽然这这两个断言很难成立，但是较前两种评价方式已经有了巨大的提高。

如果任务的完成情况不能得到正确地评估的话，任务量的评估方法和代码量评估方法没有任何差别。但是实际中可以把一个开发团队划分成项目经理、开发员 和测试员。按照微软标准（《BUG“指挥棒”》 ，孙小翔），开发员和测试员比例是1：1，并相互独立。于是我们可以改进前面的算法

1. 开发员向项目经理请求任务
2. 项目经理分配任务给开发员
3. 开发员完成任务
4. 开发员把任务提交给测试员
5. 测试员把测试结果提交给项目经理
6. 开发员.绩效 += Function1（Task， Bug#）
7. 测试员.绩效 += Function2（Task， Bug#）
8. 跳到1

这样就完美解决了前面的第二个断言，有了反馈机制。

对于第一个断言，我们提供两个解决方案

第一种方案是，项目经理把所有任务标好绩效，由开发员来选择任务。

第二种方案是，项目经理仅把任务划分，由开发员之间”竞价“来获得任务。

于是，我们有了最终算法

1. 项目经理划分任务
2. 开发员选择一个任务
3. 开发员完成任务
4. 开发员把任务提交给测试员
5. 测试员把测试结果提交给项目经理
6. 开发员.绩效 += Function1（Task， Bug#）
7. 测试员.绩效 += Function2（Task， Bug#）
8. 跳到2

这样，就无需项目经理自己来衡量每个任务的绩效了。另一方面，每个开发员都有自己的偏好，让开发人员来选择任务能有效的提高生产力。

这样我们就得到一种相对满意的，通过任务量来评估个人在团队中绩效的一种方法。

但是，开发员的任务量不完全等同于绩效，就像篮球运动员在一场比赛的绩效不能完全用进球来衡量一样。还有助攻、篮板球、封盖。。。我们提供的方法仅仅是对客观事实的评价。在其它方面，我们觉得组内互评是一种很好的评价方法。

更好的评价方式需要我们的共同探讨和分享，希望本博客能对你有帮助

MicroTeam