# 二十一、重金激励害多利少
Mike Murray是一位非常衰的微软人事经理,他做了不少蠢事,不过最经典的还是他上任后 不久推出的「出货」奖,也就是在你负责的产品上市时送你一块压克力做的大墓碑。这应该 算是某种驱使你工作的激励,因为如果你不好好做事就拿不到那块墓碑!真让人奇怪这个墓 碑出来之前微软是怎么推出产品的。
「出货」项目在一场大型的公司聚餐中大张旗鼓地宣布。在活动举行前数星期,公司园区就 布满了宣传海报,上面有比尔盖茨的照片还有一句「这个人为何在微笑?」。我不确定那是 什么意思。是说因为现在有了能让软件出货的激励方案,比尔觉得高兴而微笑吗?不过在那 场聚餐活动上,雇员们显然觉得自己被当成小朋友。到处都是不满的墟声。Excel的程序团 队还举起一个大告示板,上面写者「Excel团队为什么在打哈欠?」这个出货奖被极其鄙视, 结果连Douglas Coupland的经典作品Microserfs里甚至还有一章,里面有一群程序员尝试 用一根吹管把它破坏掉。这是真有其事,不是我乱盖的。
把你的科学家雇员当作幼儿园小朋友来对待,并不是很少见的特殊现象。几乎每家公司都有 同类型既侮辱又贬低人的奖励方案。
在我工作过的两家公司里面,压力最大的时间就是每年两次的绩效评估期。不知怎么回事, Juno和微软的人事部门的的绩效评估系统一定是从同一本呆伯特式管理书籍上抄的,因为两 边的作法完全一样。首先你要「匿名」地向上评估你的直属经理(假装这样就能很诚实的进 行)。然后再填好一个可有可无的「自我评估」表格,让你的经理在评估你的绩效时可以「参 考」。最后你会在多个不可量化的项目(如团队合作)得到一个1到5的分数(不过实际上只会 出现3分或4分)。经理会把建议奖励名单往上送,接下来名单会被完全忽视,然后每个人都 会拿到完全随机的奖金。这样的系统从未考虑一个事实,就是人各有不同而独特的天赋,需 要各种天赋才能让一个团队好好运作。
有几个原因使得绩效评估令人紧张。我有许多朋友的才华都不是传统尺度可以呈现的,他们 通常都拿不到好考绩。举例来说,某位朋友是个欢乐触媒和快活的总监,可以在艰苦状况下 激励大家,而且还是结合团队的黏着剂。不过由于经理不了解他的贡献,所以常会得到负面 考绩。另一个朋友非常的有洞见;别人会因为跟他讨论事情而把工作做得更好。他会花高于 平均的时间去尝试新技术;就这方面来说,他对团队其他人的帮助是无法衡量的。不过他写 的程序行数也低于平均水平,而他的经理也实在太蠢没注意到其他贡献,所以通常考绩也不 好。而负面的评价显然对士气有致命的作用。事实上即使给某人正面的评价,只要评价不如 本人预期的好,对士气一样有负面的作用。 绩效评估对士气的作用并不是对称的:负面评价对士气伤害很大,可是正面评价并不会改善 士气或生产力。拿到正面评价的人都己经做得很好了。对这些人而言,正面评价会让他们觉 得自己是为了拿到好成绩才好好工作的,就像巴伐洛夫制约实验中的狗为奖赏而工作,并非 真心在意自己工作质量的专业人仕。
其中的困难在于大多数人都认为自己把事情做得很好(即使事实上不是)。这其实是我们心里 为了让生活不那么难受,而对自己玩的一个小把戏。所以说如果每个人都觉得自己表现良好, 而评估结果正好是公正不阿(这并不太容易做到)时,那么大多数人都会对评估结果感到失望。 而这种结果所牺牲的士气成本很难被低估。在团队中诚实地实施绩效评估通常会导致士气低 落或忧郁,甚至会有部份人员离职,影响长达一星期左右。团队成员间会产生间隙,通常是 因为考绩差的人嫉妒考绩好的,发生如同DeMarco和Liste「称之为团队自杀(teamicide)的 过程:己冻结的团队不自觉的毁灭。
Alfie Kohn在哈佛商业评论中一篇己成为经典的文章中写道:
过去三十年间至少有两打以上的研究明确地指出,为了报酬而工作的人,表现不如完全 不期望有报酬的人。HBR Sept/Oct 93 他的结论是「激励(或者说贿赂)在职场上是行不通的」。DeMarco和Liste「更进一步明白地 表示,任何型式的职场竞争及奖惩方案,包括以前流行那种「在某人做对事时马上奖励」的 把戏,所带来的伤害都大过好处。给某些人正面激励(比如愚蠢的公开颁奖仪式)暗示他们 其实只是为了拿那个压克力奖牌才有表现;也暗示他们在工作上不够独立,要有甜头才会努 力;这实在是既侮辱又贬低人格。
大多数的软件经理都没有选择余地,只能依循现有的绩效评估系统。如果你身在这个位 置,要防止团队自杀的唯一办法,就是对每个人都只给些装装样子的考绩。不过如果你在这 件事上有其他选择,我会建议避开各种的绩效评估和奖励方案,或是愚蠢的本月最佳员工计 划。
- 第一部分 位与字节:编程实践点滴
- 一、语言的选择
- 二、深入底层
- 三、joel测试:改进代码的12个步骤
- 四、每一位软件开发人员必须、绝对要至少具备UNICODE 与字符集知识(没有任何例外!)
- 五、轻松写就功能规格说明书 - 第1节:为什么烦心?
- 六、轻松写就功能规格说明书 - 第2节:什么是规格说明书?
- 七、轻松写就功能规格说明书 - 第3节:但是……如何?
- 八、轻松写就功能规格说明书 - 第4节:技巧
- 九、轻松制订软件进度表
- 十、每日连编是朋友
- 十一、难伺候的故障修复
- 十二、软件开发中的5个世界
- 十三、稿纸原型开发
- 十四、不要被太空架构师所吓倒
- 十五、开火与运动
- 十六、人员技能
- 十七、源于计算机学科的三个错误思想
- 十八、二元文化
- 十九、自动获取用户故障报表
- 第二部分 开发人员的管理
- 二十、面试游击指南
- 二十一、重金激励害多利少
- 二十、二不配备测试人员的五个首要(错误)原因
- 二十三、任务换人有害无益
- 二十四、绝不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序设计界的LordPalmerston
- 二十八、评测
- 第三部分 Joel对常态问题的遐想
- 二十九、RickChapman解读愚昧
- 三十、在这个国家狗是干什么的? 我们有多么天真?
- 三十一、作为哼哈二将,只管去做事
- 三十二、两个故事
- 三十三、巨无霸麦当劳与天才厨师JamieOliver
- 三十四、没有什么像IT看起来那么简单
- 三十五、提防非自主开发综合症
- 三十六、策略I:BEN&JERRY公司与AMAZON
- 三十七、策略II:鸡与蛋问题
- 三十八、策略III:让我回去!
- 三十九、策略IV:大件与80/20神话
- 四十、策略V:公开源代码的经济因素
- 四十一、墨菲法则肆掠的礼拜
- 四十二、微软公司是如何败北API之战的
- 第四部分 对.NET稍多的评说
- 四十三、微软精神失常了
- 四十四、我们的.NET对策
- 四十五、请问,我可以使用连接程序吗