[職場系列] 漫談績效評鑑

最近整理了一下部落格，為自己的文章分類一下，有興趣看我之前關於職場的評論，可以看一下「漫談領導力」。

在職場上常常都會聽到一個問題，那就是「我的努力為什麼上面好像都沒有看見」?一般人所謂的看見與否，主要是圍繞著薪資的增長和陞遷上，也因此我們必須檢視公司決定薪資與陞遷的平台，也就是績效評鑑制度。

Google有個非常特殊的評鑑制度，就是「自評、互評和議評」。Google要求員工詳實紀錄自己的工作內容，並且需要評鑑同儕的績效，最後由經理綜合整理的內容以及建議的績效會在一個合議的環境下被審理和確認。相對一般公司而言，這大大增加了評鑑的複雜性，也因此每年到Google績效評鑑的時候，可說是哀鴻遍野，又有人戲稱一年一度的作文比賽又開始了。(其實這樣的形容當然有點誇張，Google確實也致力於降低員工花在績效評鑑的時間，不過這就留待後面討論)乍看之下，很難看出Google做法的好處，甚至會覺得傳統由經理決定一切的續效和陞遷是更簡單的方法。要瞭解Google的設計，就要先知道理解評鑑制度究竟是什麼，為什麼困難?

評鑑制度從本質上來說是一個將高維度空間(人的貢獻)映射到線性維度(總薪資)的過程。這裡假定薪資與職等是絕對正相關的，所以不算兩個維度。為了使這個映射最小程度地「失真」(不失真是不可能的)，Google採取的策略有二，一是採用多元的映射方式，二是提取關鍵的映射維度(有興趣的可參見Pricipal Component Analysis)。多元的映射方式就是建立自評、互評和議評的方式；而提取關鍵的映射維度則分兩層運算，一層是先將軟體工程師的貢獻映射到「成效、問題困難度、領導力」的三維空間，最後再憑藉各職等的工作內容，能夠把三維的空間映射到一維的績效分數。

講這麼多看起來很學術的名詞，但我要表達的，其實是這些評鑑制度會很大程度引導員工工作的方向。在Google的設計下，做任何軟體的案子之前一定要考慮能夠量化的成效，也要考慮問題的難度，最後就是依照案子大致的級別，去判斷領導力的需求。很明顯「努力」並不是評鑑的內容，但案子完成的速度會被考慮。常見的錯誤大致如下

1. 無法或錯誤地量化成效：做案子的時候沒有考慮到成效如何量化，或說量化錯誤的指標，導致結果與案子背後更大的目標對不上。如果一個自動化的案子的目標是減少需要手動處理的次數，那結果就不能用新增多少個系統來評價(有可能增加了十個系統，反而使系統容易出錯，導致手動處理的次數反而變高了)。

2. 無法精確敘述問題難度：許多案子的難度並不容易描述。有時候是單統的系統複雜度，有時候是外部的要求與原始系統的相容性。大部份的時候，必須要瞭解系統的人才能夠明白問題的難度。如果無法適當地展現難度讓他人瞭解，在績效評鑑上將會吃大虧。事實上我的經驗是很多人用講的都可以描述地很好，但在寫自我評鑑報告時，都無法順利將難度顯現。

3. 無法展現該有的領導力：在某些等級的要求裡，需要證明工程師有足夠能力影響其他的員工。也因此若是不懂得適度切分工作給較低等級的人來執行，或是在與其他組的合作中適度帶領案子的走向，就很容易在陞遷的時候慘遭滑鐵盧。

結論來說，好的公司透過陞遷制度的設計，要鼓勵員工作對的事。若是相信公司設計出來的制度對公司的發展是好的，那麼員工努力的方向應該就是照著陞遷制度的設計走。多瞭解公司制度設計背後的想法，你的努力就會被人看見。