程式員的工作、學習與績效

工作中，碰到一些這樣的例子，總有人提出疑問，為什麼一個同僚工作勤勉，完成了很多事情，季度績效評定很高，但晉升卻碰壁了。之前已經寫過一篇《技術晉升的評定與博弈》，基本就能解答這個問題。但隐藏在背後的更深層次的本質卻是：工作、學習與績效的關系。

工作

程式員的主要工作是：程式設計，産出代碼，完成需求，傳遞軟體系統。

程式員按其工作技能和經驗，大體又分為三個階段：初、中、進階。三個級别的程式員的主要工作都是程式設計與産出代碼，産出代碼的數量也許相差不大，但産出代碼的屬性可能有明顯差别。

在曾經的文章中提出過一個代碼屬性：資産與負債。由大量初級程式員産出的代碼并以此建構的軟體系統，如果最終能完成傳遞，那麼很可能資産和負債性基本持平。這是很多早期創業公司的特點，因為缺乏資金和足夠的知名度，難以吸引到又多又好的中進階程式員加入。這樣的系統多屬于勉強滿足業務需要，看不出明顯的 bug，但一遇到特殊情況就容易當機。整個系統雖然勉強能支撐公司營運，但其中欠下了大量的技術債，先活下來，未來再來慢慢還。

若是完成了一個債務比資産還大的系統，會是個什麼樣的情況呢？那這就是一個還存在明顯 bug 的系統，是基本無法完成傳遞和上線的。是以，現在主流都是先完成一個資産和負債剛好過平衡點的系統，釋出上線，接受回報，再快速疊代，在疊代中不斷地提升其資産性，降低其負債性。在 facebook 的著名智語激勵下，奮力前行：done is better than perfect（比完美更重要的是先完成）。

而中進階相比初級程式員，就不僅僅是傳遞代碼，完成工作，還有後續的兩條：達成品質、優化效率。從初級向後兩級跨越的門檻就在于此，比較容易被卡在不斷地在完成工作，但卻沒有去反思，沉澱，疊代并改進，導緻一直停留在了不斷的重複中。

程式員的工作，以産出代碼為主，從初級到進階，代碼的負債屬性逐漸降低，資産屬性不斷提升，并成為高品質的個人貢獻者。在這個層面上，還是 facebook 的另一條智語足以說明問題：code wins arguments（代碼赢得争論）。

學習

學習，是唯一能讓你突破不斷循環怪圈的不二法門。

程式員在攀登職場階梯的道路上，走過了進階，後面會有好些分叉路線。比如，轉到脫離技術的純管理崗或者技術管理崗。我以前寫過，技術主管或架構師某種意義上都屬于技術管理崗，不懂技術是做不了這兩個角色的。或者繼續沿着深度領域走，成為細分領域專家。

這後面哪條路适合你呢？你是随大流，還是自己真得認真思考過？這是做選擇題。如果一生要工作三十多年，前十年你多在做解答題，解決一個又一個問題。那麼在大約走過三分之一後，你就會開始做越來越多的選擇題。為什麼呢？因為一開始可能都沒有太多選擇的機會。而做好選擇題，就需要大量的學習，還需要不斷的試錯。

面對怎麼選路的問題，我近年學習的收獲是這樣的：選擇走最适合實作個人價值的路。這就是我的基礎選擇價值觀。程式員的個人價值該怎麼實作？該如何最大化？程式員作為個人貢獻者，産出的增長随時間和經驗實際上連線性都不是，而是呈對數曲線的（《兩種增長曲線》）。到了一定時間必然面臨瓶頸，這就需要找到一個價值貢獻放大器。有人很幸運的編寫服務于數千萬或數億人的軟體服務，這是産品自帶的價值放大器。這樣同樣寫一份代碼，你的價值就是要比别人大很多。而轉管理者、主管或架構師，這些角色無非都是自帶杠杆因子的，是以也有價值放大作用。但個人能否适應得了這樣的角色轉換，又是另一回事了。

現在稍具規模的中大型公司内部的職場階梯模型，我看基本都源自拉姆·查蘭的那本書《上司梯隊》。書裡把人才潛能分成三種：熟練潛能、成長潛能、轉型潛能。原書文中對這三點做了詳細的特征描述（比較長），我簡單提煉下主要特點：

熟練潛能：關注目前專業領域且十分熟練，但沒有顯示出在開發新能力上的努力，竭力維持現有技能。

成長潛能：按需開發新能力，顯示出高于目前層級要求的其他技能（專業、管理、上司）。

轉型潛能：持續有規律的開發新能力，追求跨層級的挑戰和機會，展現雄心壯志。

人力資源管理中的高潛人才盤點，基本就來自這套模型，主要就是識别出這三類潛能人才。「熟練潛能」就是對學習的最低要求，在程式員這個技術日新月異的行業裡，維持現有技能确實已經讓不少人感覺很竭力了。

攀登的這條階梯，它從來不是筆直的。在每一個拐彎處，都應減速、思考、學習、進步。學習也常與錯誤相伴，查理·芒格說過：

世界上不存在不犯錯誤的學習或行事方式，隻是我們可以通過學習，比其他人少犯一些錯誤 —— 也能夠在犯了錯誤之後，更快地糾正錯誤。但既要過上富足的生活又不犯很多錯誤是不可能的。實際上，生活之是以如此，是為了讓你們能夠處理錯誤。

績效

績效，特别是程式員的績效，從來都是個謎（《程式員的績效之謎》）。

一談績效，管理者就會說誰誰績效很好，你看加了很多班，做了很多事。之前說了程式員傳遞的軟體系統，如果說代碼的資産和負債屬性相當，大家可能會沒有直覺感覺。做個大家熟悉的類比，如果隻是相當，這就像我們刷信用卡購買了一項産品或服務，滿足了當下的需求，赢得了時間，但将來這筆欠款是要還的，不還就會付出代價。但如果是資産遠大于負債，那就是刷了卡，後面卻不用還了的感覺，那應該是種暗爽的感覺。後者才叫績效好，但如何評估？謎。

最近看劉潤的文章講到 kpi 管理，提到了一個考核微軟技術支援的辦法。感覺挺有意思，如果把它換成程式員的場景可能就是這樣一些關鍵名額：

a：需求難度系數，需求評審時架構師和程式員共同分析确定，達成共識

b：需求花費時間，越短越好，由程式員自己記錄

c：完成需求送出的代碼行數，越少也好，需要定制工具支援代碼和需求關聯的統計

d：完成需求數，越多越好

e：e = a x b x c x d 表示有效工作産出

其中 a 難度系數基于團隊共識達成，因為大量的業務需求，其實很多難度近似。b 和 d 實際是兩個互相制衡的因素，本來用 1 小時完成的，你自己記錄成 10 分鐘，那麼完成的總的數量就會變少。c 展現了代碼技術能力，完成同樣功能的代碼，資産性不變，越少的代碼行數越少負債。這樣當衡量有效工作産出（e）時，同樣的 e，a 和 d 大的技術能力更好。

當然，這是一個簡化的理想模型，但現實中程式員的考核恐怕比這個模型更簡單粗暴。但它也指出了一個事實：晉升技術能力更好的人，他們解決更難的問題因而創造壁壘，産出更多的資産和更少的負債。而對于僅僅單一高績效的人，不适合用晉升來激勵，而應該用獎金來獎勵。

...

為什麼業界喜歡三到五年的程式員？按一萬小時理論，三到五年接近或滿足了這個量的程式設計訓練，這個階段就是産出代碼的黃金時段，量大質優，而且各公司的“坑”（職位）也多。