程序員的績效之謎

前不久看到個新聞，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.（關心你的技藝，思考！你的工作）。」 畢竟你還是個手藝人，還要靠手藝吃飯不是。

寫點文字，畫點畫兒，記錄成長瞬間。

微信公眾號「瞬息之間」，既然遇見，不如一起成長。