工作中，碰到一些這樣的例子，總有人提出疑問，為什么一個同事工作勤勉，完成了很多事情，季度績效評定很高，但晉升卻碰壁了。之前已經(jīng)寫過一篇《技術(shù)晉升的評定與博弈》，基本就能解答這個問題。但隱藏在背后的更深層次的本質(zhì)卻是：工作、學(xué)習(xí)與績效的關(guān)系。
　　工作
　　程序員的主要工作是：編程，產(chǎn)出代碼，完成需求，交付軟件系統(tǒng)。
　　程序員按其工作技能和經(jīng)驗，大體又分為三個階段：初、中、高級。三個級別的程序員的主要工作都是編程與產(chǎn)出代碼，產(chǎn)出代碼的數(shù)量也許相差不大，但產(chǎn)出代碼的屬性可能有明顯差別。
　　在曾經(jīng)的文章中提出過一個代碼屬性：資產(chǎn)與負(fù)債。由大量初級程序員產(chǎn)出的代碼并以此構(gòu)建的軟件系統(tǒng)，如果最終能完成交付，那么很可能資產(chǎn)和負(fù)債性基本持平。這是很多早期創(chuàng)業(yè)公司的特點，因為缺乏資金和足夠的知名度，難以吸引到又多又好的中高級程序員加入。這樣的系統(tǒng)多屬于勉強(qiáng)滿足業(yè)務(wù)需要，看不出明顯的 bug，但一遇到特殊情況就容易宕機(jī)。整個系統(tǒng)雖然勉強(qiáng)能支撐公司運(yùn)營，但其中欠下了大量的技術(shù)債，先活下來，未來再來慢慢還。
　　若是完成了一個債務(wù)比資產(chǎn)還大的系統(tǒng)，會是個什么樣的情況呢？那這就是一個還存在明顯 bug 的系統(tǒng)，是基本無法完成交付和上線的。因此，現(xiàn)在主流都是先完成一個資產(chǎn)和負(fù)債剛好過平衡點的系統(tǒng)，發(fā)布上線，接受反饋，再快速迭代，在迭代中不斷地提升其資產(chǎn)性，降低其負(fù)債性。在 Facebook 的著名標(biāo)語激勵下，奮力前行：Done is better than perfect（比完美更重要的是先完成）。
　　而中高級相比初級程序員，就不僅僅是交付代碼，完成工作，還有后續(xù)的兩條：達(dá)成品質(zhì)、優(yōu)化效率。從初級向后兩級跨越的門檻就在于此，比較容易被卡在不斷地在完成工作，但卻沒有去反思，沉淀，迭代并改進(jìn)，導(dǎo)致一直停留在了不斷的重復(fù)中。
　　程序員的工作，以產(chǎn)出代碼為主，從初級到高級，代碼的負(fù)債屬性逐步降低，資產(chǎn)屬性不斷提升，并成為高品質(zhì)的個人貢獻(xiàn)者。在這個層面上，還是 Facebook 的另一條標(biāo)語足以說明問題：Code wins arguments（代碼贏得爭論）。
　　學(xué)習(xí)
　　學(xué)習(xí)，是唯一能讓你突破不斷循環(huán)怪圈的不二法門。
　　程序員在攀登職場階梯的道路上，走過了高級，后面會有好些分叉路線。比如，轉(zhuǎn)到脫離技術(shù)的純管理崗或者技術(shù)管理崗。我以前寫過，技術(shù)主管或架構(gòu)師某種意義上都屬于技術(shù)管理崗，不懂技術(shù)是做不了這兩個角色的。或者繼續(xù)沿著深度領(lǐng)域走，成為細(xì)分領(lǐng)域?qū)＜摇?br /> 　　這后面哪條路適合你呢？你是隨大流，還是自己真得認(rèn)真思考過？這是做選擇題。如果一生要工作三十多年，前十年你多在做解答題，解決一個又一個問題。那么在大約走過三分之一后，你就會開始做越來越多的選擇題。為什么呢？因為一開始可能都沒有太多選擇的機(jī)會。而做好選擇題，就需要大量的學(xué)習(xí)，還需要不斷的試錯。
　　面對怎么選路的問題，我近年學(xué)習(xí)的收獲是這樣的：選擇走最適合實現(xiàn)個人價值的路。這就是我的基礎(chǔ)選擇價值觀。程序員的個人價值該怎么實現(xiàn)？該如何最大化？程序員作為個人貢獻(xiàn)者，產(chǎn)出的增長隨時間和經(jīng)驗實際上連線性都不是，而是呈對數(shù)曲線的《兩種增長曲線》。到了一定時間必然面臨瓶頸，這就需要找到一個價值貢獻(xiàn)放大器。有人很幸運(yùn)的編寫服務(wù)于數(shù)千萬或數(shù)億人的軟件服務(wù)，這是產(chǎn)品自帶的價值放大器。這樣同樣寫一份代碼，你的價值就是要比別人大很多。而轉(zhuǎn)管理者、主管或架構(gòu)師，這些角色無非都是自帶杠桿因子的，所以也有價值放大作用。但個人能否適應(yīng)得了這樣的角色轉(zhuǎn)換，又是另一回事了。
　　現(xiàn)在稍具規(guī)模的中大型公司內(nèi)部的職場階梯模型，我看基本都源自拉姆·查蘭的那本書《領(lǐng)導(dǎo)梯隊》。書里把人才潛能分成三種：熟練潛能、成長潛能、轉(zhuǎn)型潛能。原書文中對這三點做了詳細(xì)的特征描述（比較長），我簡單提煉下主要特點：
熟練潛能：關(guān)注當(dāng)前專業(yè)領(lǐng)域且十分熟練，但沒有顯示出在開發(fā)新能力上的努力，竭力維持現(xiàn)有技能。
成長潛能：按需開發(fā)新能力，顯示出高于當(dāng)前層級要求的其他技能（專業(yè)、管理、領(lǐng)導(dǎo)）。
轉(zhuǎn)型潛能：持續(xù)有規(guī)律的開發(fā)新能力，追求跨層級的挑戰(zhàn)和機(jī)會，展現(xiàn)雄心壯志。
　　人力資源管理中的高潛人才盤點，基本就來自這套模型，主要就是識別出這三類潛能人才。「熟練潛能」就是對學(xué)習(xí)的最低要求，在程序員這個技術(shù)日新月異的行業(yè)里，維持現(xiàn)有技能確實已經(jīng)讓不少人感覺很竭力了。
　　攀登的這條階梯，它從來不是筆直的。在每一個拐彎處，都應(yīng)減速、思考、學(xué)習(xí)、進(jìn)步。學(xué)習(xí)也常與錯誤相伴，查理·芒格說過：
　　世界上不存在不犯錯誤的學(xué)習(xí)或行事方式，只是我們可以通過學(xué)習(xí)，比其他人少犯一些錯誤 —— 也能夠在犯了錯誤之后，更快地糾正錯誤。但既要過上富足的生活又不犯很多錯誤是不可能的。實際上，生活之所以如此，是為了讓你們能夠處理錯誤。
　　績效
　　績效，特別是程序員的績效，從來都是個謎《程序員的績效之謎》。
　　一談績效，管理者就會說誰誰績效很好，你看加了很多班，做了很多事。之前說了程序員交付的軟件系統(tǒng)，如果說代碼的資產(chǎn)和負(fù)債屬性相當(dāng)，大家可能會沒有直觀感覺。做個大家熟悉的類比，如果只是相當(dāng)，這就像我們刷信用卡購買了一項產(chǎn)品或服務(wù)，滿足了當(dāng)下的需求，贏得了時間，但將來這筆欠款是要還的，不還就會付出代價。但如果是資產(chǎn)遠(yuǎn)大于負(fù)債，那就是刷了卡，后面卻不用還了的感覺，那應(yīng)該是種暗爽的感覺。后者才叫績效好，但如何評估？謎。
　　最近看劉潤的文章講到 KPI 管理，提到了一個考核微軟技術(shù)支持的辦法。感覺挺有意思，如果把它換成程序員的場景可能就是這樣一些關(guān)鍵指標(biāo)：
A：需求難度系數(shù)，需求評審時架構(gòu)師和程序員共同分析確定，達(dá)成共識
B：需求花費時間，越短越好，由程序員自己記錄
C：完成需求提交的代碼行數(shù)，越少也好，需要定制工具支持代碼和需求關(guān)聯(lián)的統(tǒng)計
D：完成需求數(shù)，越多越好
E：E = A x B x C x D 表示有效工作產(chǎn)出
　　其中 A 難度系數(shù)基于團(tuán)隊共識達(dá)成，因為大量的業(yè)務(wù)需求，其實很多難度近似。B 和 D 實際是兩個互相制衡的因素，本來用 1 小時完成的，你自己記錄成 10 分鐘，那么完成的總的數(shù)量就會變少。C 展現(xiàn)了代碼技術(shù)能力，完成同樣功能的代碼，資產(chǎn)性不變，越少的代碼行數(shù)越少負(fù)債。這樣當(dāng)衡量有效工作產(chǎn)出（E）時，同樣的 E，A 和 D 大的技術(shù)能力更好。
　　當(dāng)然，這是一個簡化的理想模型，但現(xiàn)實中程序員的考核恐怕比這個模型更簡單粗暴。但它也指出了一個事實：晉升技術(shù)能力更好的人，他們解決更難的問題因而創(chuàng)造壁壘，產(chǎn)出更多的資產(chǎn)和更少的負(fù)債。而對于僅僅單一高績效的人，不適合用晉升來激勵，而應(yīng)該用獎金來獎勵。 ...
　　為什么業(yè)界喜歡三到五年的程序員？按一萬小時理論，三到五年接近或滿足了這個量的編程訓(xùn)練，這個階段就是產(chǎn)出代碼的黃金時段，量大質(zhì)優(yōu)，而且各公司的“坑”（職位）也多。
　　-----
　　寫點文字，畫點畫兒，記錄成長瞬間。 微信公眾號「瞬息之間」，既然遇見，不如一起成長。 

關(guān)鍵詞： 廣州網(wǎng)站制作、廣州網(wǎng)站制作公司、廣州網(wǎng)站建設(shè)、廣州網(wǎng)站建設(shè)公司、廣州網(wǎng)站設(shè)計、廣州網(wǎng)站設(shè)計公司、廣州做網(wǎng)站、廣州做網(wǎng)站公司、廣州品牌網(wǎng)站制作、廣州品牌網(wǎng)站制作公司,廣州微網(wǎng)站制作、廣州微網(wǎng)站制作公司、番禺網(wǎng)站建設(shè)、番禺網(wǎng)站制作