程序員的績效之謎
前不久看到個新聞，Amazon 美國的一個中國 IT 工程師在西雅圖辦公室跳樓自殺，原因是收到了 PIP。那 PIP 是什么?就是 Performance Improvement Plan 的簡寫，表達的意思大概就是，再給你點時間改進工作績效，否則就請走人。但實際收到 PIP 95% 的情況都是走人，這樣實際的意思就變成了，再給你點時間趕快找下家吧。
但這哥們在美國工作，拿的是工作簽證。如果失業了，就意味著工作簽證失效，在美國也就待不下去了。各種壓力一起涌來，一時想不開就跳樓了。這個故事里面有個關鍵詞：績效，而且是程序員的績效。關于程序員的績效，像是一個彌久的歷史謎題，長期困擾著大量的程序員與他們的領導們。
工具與方法
KPI(Key Performance Indicators 關鍵績效指標)是企業***用的績效考核工具，但 KPI 通常只能定一些更寬泛的指標，且一般也只能分解到團隊經理的頭上，而很難分解到具體每個程序員的身上。
在我工作的歷史上，換過幾家公司，每家公司都使用一種粗放且獨特的方式來考核程序員。***家公司，工作完一年后我才知道什么叫績效考核。因為它們采用的是年度考核，一年過去到了年末經理跑來告訴你說你今年的績效還不錯，然后也不知道不錯是個什么水平。
總之是不錯了，但***也沒有加薪獎金什么的。努力回顧一年的工作，發現記憶非常模糊，除了少數幾件印象深刻的事。而那幾件少數事件，都是我搞砸了的事情，而且還捅了不小的窟窿，獲得了血淚換來的寶貴經驗。這么一想可能覺得「不錯」大概就是「有點差」的一個稍微溫和的表達了。
說起按事件來評判績效，就想起后來的另一個公司，他們就使用這樣的關鍵事件法來評估全年的績效。回想一下這一年自己做了什么特別的事情，有讓身邊的同事或領導都覺得很棒的事件么?有印象深刻的正向事件，那么就是優秀，如果是負向事件就是還需改進提升，其他就是一般了。表面看有那么一點合理性，但結合程序員的工作性質一想就不是那么合理了。
上面的方法要么只是模糊要么只是沒考慮工作性質的差異，那么下面的這個公司的評估方法就完全扯淡了。當時公司采用強制分布績效的方式，比如一個部門有 10% 的人得優秀，有 10% 的人得差，其他屬于一般。這樣的評估方式每月一次，直接和當月工資中的績效獎金掛鉤。
上面這么一強制分布下來，部門再分布到小組，小組長一看大家都是兄弟伙，一年有十個月出差于全國各地，天天加班不說，還要給人績效評個差，于心不忍。大家一商量，那就輪流來吧，這次得了差的，過幾個月就會得個優秀，這樣的績效評估基本也就流于形式，毫無意義了。
近年，像 Google 這樣的明星公司大規模應用起了一種叫 OKR 的工具。OKR 就是 Objectives and Key Results 的縮寫，表示目標和關鍵結果。這聽起來和 KPI 很類似，但它們有個本質的區別是方向性的，KPI 一般是分解下來，要你去做的。而 OKR 是我要去做的，KPI 是考核工具，而 OKR 實際是管理工具，跟蹤做事的目標和方向性。所以 OKR 也不是解決績效評估難題的銀彈。
綜上，通用的這些績效評估工具和方法，似乎面對程序員的績效評估都不太有用，這是為什么呢?這也許要從程序員的工作實質說起。
工作與評估
管理學上有位大師叫彼得·德魯克，他最早提出了知識工作者(Knowledge Worker)的概念，德魯克生于 1909 年，所以他經歷了從工業時代到信息時代的革命性變化。早期的工業時代只有工人和管理者的概念，那時的行業多是重資本推動的制造業，工人的特點是流水線的體力勞動，簡單重復，過程很容易監控，產出結果的數量和品質也容易檢測，所以個人的 KPI 很容易量化。
而德魯克定義的知識工作者是：
那些掌握和運用符號與概念，利用知識或信息工作的人。
顯然，程序員就是典型的知識工作者。知識工作者不僅利用知識，他們還會創造新的知識，從知識中獲得洞見，進而產生智慧。
程序員的主要產出是：代碼或交付的軟件系統。但軟件系統的代碼通常都是由多個程序員合作一起完成的，所以你就沒法精確的測量每個程序員的貢獻。也不要想當然的用一些簡單粗暴的指標來考核程序員，比如像：代碼行數。這樣的指標容易定義，容易測量，所以這樣的考核容易實施，而容易實施的考核總是首先被采用。但前提和出發點是錯的，只會南轅北轍，離目標越來越遠。
幸好應該大家都認識到這樣簡單的指標無法考評程序員個體的產出，但如果真得采用代碼行數來評價的話，倒是能解決程序界的另一個亙古已久的爭論：花括號 { 到底是寫在一行程序的末尾還是另起一行:)。
硅谷創業之父 Paul Graham 在《黑客與畫家》一書中寫到：
程序員就是知識時代的手藝人，也是目前還存在的***的手工藝人群體。
最***的 5% 的程序員寫出了全世界 99% 的優秀軟件。
可見，程序員的個體差異導致的貢獻度差異之大。但很遺憾的是我們至今沒有任何可行的具體測量方法能精確的評估程序員個體的貢獻度。所以 Paul Graham 繼續說：
大公司會使得每個員工的貢獻平均化。
大公司***的困擾就是無法準確測量每個員工的貢獻，大多數時候它只是在瞎猜。
我依稀記得看過一個來自英特爾的例子，原文記不住，大概簡單重述下。是說有個負責芯片設計的工程師提出并改進了一種芯片設計和生產方法，應用到一條年產值 10 億美元的生產線，提高了 1% 的產值。那么他的直接貢獻很容易計算出來就是一年為公司多增加了 1000 萬美金產值。但問題是我們該怎么獎勵他的這次卓越貢獻?
這個例子中還提到，他所在的芯片設計部門有一百多人，所以平均下來整個部門的人均額外貢獻就不到 10 萬美金了。所以，當年公司能給予他的獎勵實際是遠小于計算出來的實際增加值的，這就是一個大公司平均化的典型例子。但這個例子中，也不必感覺太不公平，實際離開了英特爾這樣的大公司，那個芯片工程師很可能是無法做出這樣的貢獻的。大公司一方面平均化了個人貢獻度，另一方面也為個人降低了風險同時提供了貢獻的放大器。
反過來，如果是在小的創業型公司，它依然是平均化計算個人貢獻度的。但人少了，被平均掉的就少了。對于小創業公司 Graham 的建議是：
你***找出色的人合作，因為他們的工作和你的一起平均計算。
結果與影響
按 SMART 原則來評定你的目標和達成情況：
- Specific(明確)
- Measurable(可測量)
- Achievable(可達成)
- Relevant(相關)
- Time-bound(時限)
其中只有「可測量」這一項在程序員個體上比較難實施，所以恐怕只能放棄精確的測量而轉為目標導向。而所謂目標或 KPI 無非就是上級對下屬的期望，然后再以此來判斷下屬的績效是否合乎期望。如果上級沒有明確對下屬的期望，如果我們不知道到底要什么，最可能的結果是什么也得不到。
那評估的結果是否能以達成目標為依據呢?表面一聽似乎很合理，但仔細一深入想想就有問題。如果上級只用目標管理來決定下屬的升遷賞罰，以至于下屬只專注于制定“好的”目標，即容易達成的 KPI，就會錯失了其他可能。
哥倫布的故事證明了這一點，哥倫布設定了一個尋找到亞洲(東印度群島)的新航線，但他最終卻找到了美洲，并開辟了后來延續幾個世紀的歐洲探險和殖民海外領地的大時代，因此：
即使一個下屬沒能達成所設定的目標，他的績效仍有可能被評為卓越。
哥倫布當初定的目標和***達成的結果存在差距，但并不能以此說他做的不好。過于綁定目標則限制死了路徑并控制了風險，但激勵創新意味著冒險，如果沒有風險，就幾乎等于沒有可放大性。
但就個體而言，你需要分清楚評估個人績效和提供機會讓個人獲得成長與提升的區別。所以，不妨把這兩種效果分為：
- 產出績效
- 成長績效
前者是組織更關心的，后者是個人更應關心的。當然現在的組織都說很關心員工成長并提供相應培訓，但更多時候組織是更傾向于在市場購買已經成熟的大樹。所以你不應該等著組織想起來給你澆灌才去成長，成長績效通常只能自己去評估，而且這點在很多組織也直接影響你的升級。
...
《程序員修煉之道》一書中寫道：
注重實效的程序員不僅要完成工作，而且要完成得漂亮。
所以，請：“Care about your craft. Think! About your work.(關心你的技藝，思考!你的工作)。” 畢竟你還是個手藝人，還要靠手藝吃飯不是。
此刻瞬間
有時會面臨這樣一種尷尬局面：一群程序員里，你想提拔一個經理，難道不是應該提拔績效更好的么?在你把超級程序員提拔為經理的同時，你也失去了你的超級程序員，并創造了一個差勁的經理。反過來，你去提拔一個差勁的程序員當經理，則更糟：一樣創造了一個差勁的經理，而且可能會失去一群從超級到優秀的程序員。
從這個周五到周日一直在出差途中，有個讀者(目前還是大學生)留言咨詢了一些問題，由于過了 48 小時已無法回復，就在這里簡單說說吧。他的問題很有代表性：喜歡自己的專業(工商管理專業，原話是感興趣有熱情，理解為喜歡應該沒問題吧)，卻感覺將來找工作很難對口。又想學一門硬技術傍身，想問下目前 IT 技術的各技術分枝，也就是學什么將來能做什么。
我的看法是***先想清楚一件事，到底以后要靠本專業還是學編程為生?至于梳理各技術分枝，這個問題的提法于我就屬于上一篇文章關于提問的毛病，太大而難以簡單回答。另外自己回答得了這個問題可能是你能以編程為生的一個前提。
【本文是51CTO專欄作者胡峰的原創文章，轉載請聯系作者本人獲取授權】
