先提一下，這篇同樣充滿對職場上的臆測。一個不想面對論文的學生通常會開始思考一些奇怪而且還不會碰到的議題。
我想寫一點對公司考績制度的疑惑，疑惑開始於在噗浪上看到 @avhacker 的公司(後來知道是鼎鼎有名的...(消音XD))有所謂的「依程式行數」之類的評比制度，和在PTT programming版看到的「有BUG就扣考績」這兩件事。
然後ddavid@PTT提到 Joel 的三篇文章：
Ch21 激勵是有害的(2000)
Ch28 測量(2002)
Ch32 兩則故事(2000)
（我開始懶得幫文章上連結了，原諒我...）
先抄幾句來當大意，混個篇幅
第一篇，Joel講了一個他認為是污辱人的獎勵制度（在微軟），然後說，有些人的貢獻不一定會被看出來，所以有負面考績，導致士氣下降。有趣的是，就算給某人正面評價，但是如果不如那個人的預期，一樣還是士氣下降。更有趣的是，就算有一個公正的考績系統（而且這很難做到），大部分的人還是會失望，因為每個人都覺得自己應該有更好的考績。總之都會讓士氣低落、憂鬱、離職、嫉妒...甚至導致所謂的團隊自殺。他建議軟體經理在考績上做做樣子就好，如果沒有其他選擇的話。
第二篇，大意就是當管理的人想要測量知識工作者的績效時，總是下有對策。下面總是有辦法變出花樣來迎合測量系統就對了，而實質的工作品質可能還因此變得更糟。這裡有好幾個例子不只是軟體領域的。
第三篇說了兩個故事，描述管理良好的科技公司和一團亂的公司的差別。微軟在這裡是好的，「在微軟這家公司裡，如果你是Excel巨集策略的專案經理，即使來公司還不到半年也不要緊，你就是Excel巨集策略之神，連員工代碼六號的老員工也不能擋你的路。事情就是這樣。」另一家風格是「不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊...」Joel認為「最終的差異在於相信員工並讓他們把事情做好，還是把他們視為作業員對待，必須不停監視控制以免偏離主題並造成破壞。」
ddavid說：
「簡單的結論是，不要想用某種死板固定的規則來打程式人員的考績並做獎懲，只
會造成上有政策下有對策的反效果。你該做的事是一開始就選到對的人（在其它篇章
中有清楚的說明），然後讓他們有真正能做好事情的環境（同樣在其它篇章中有清楚
的說明），而不是用他們寫了多幾行程式或改了幾個Bug就獎勵他，反之就處罰。」
我自己看完三篇的感覺是，我認同Joel說的，但還是不禁冒出一堆疑問，所以不用打考績了嗎？主管只要「找對的人+能做好事的環境」就夠了？那台灣的軟體管理大多是什麼方式？我想，對於這些問題我實在是素材不足無法思考，還是要等真正進了業界才會有更進一步的想法吧？有什麼想法歡迎討論 :p
