程序員的工作、學習與績效
工作中，碰到一些這樣的例子，總有人提出疑問，為什么一個同事工作勤勉，完成了很多事情，季度績效評定很高，但晉升卻碰壁了。但隱藏在背后的更深層次的本質卻是：工作、學習與績效的關系。
工作
程序員的主要工作是：編程，產出代碼，完成需求，交付軟件系統。
程序員按其工作技能和經驗，大體又分為三個階段：初、中、高級。三個級別的程序員的主要工作都是編程與產出代碼，產出代碼的數量也許相差不大，但產出代碼的屬性可能有明顯差別。
在曾經的文章中提出過一個代碼屬性：資產與負債。由大量初級程序員產出的代碼并以此構建的軟件系統，如果最終能完成交付，那么很可能資產和負債性基本持平。這是很多早期創業公司的特點，因為缺乏資金和足夠的知名度，難以吸引到又多又好的中高級程序員加入。這樣的系統多屬于勉強滿足業務需要，看不出明顯的 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 大的技術能力更好。
當然，這是一個簡化的理想模型，但現實中程序員的考核恐怕比這個模型更簡單粗暴。但它也指出了一個事實：晉升技術能力更好的人，他們解決更難的問題因而創造壁壘，產出更多的資產和更少的負債。而對于僅僅單一高績效的人，不適合用晉升來激勵，而應該用獎金來獎勵。
...
為什么業界喜歡三到五年的程序員?按一萬小時理論，三到五年接近或滿足了這個量的編程訓練，這個階段就是產出代碼的黃金時段，量大質優，而且各公司的“坑”(職位)也多。
【本文是51CTO專欄作者胡峰的原創文章，轉載請聯系作者本人獲取授權】
