# 二十一、重金激勵害多利少
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對策
- 四十五、請問,我可以使用連接程序嗎