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