2001年的時候，我們注意到程式員個體差異很大，尤其是品質差異很大，即使他們天天坐在一起。原因在與大家幾乎各自分工幹各自的活動，中間缺少交流（不是交流學習會那種，而是每時每刻發自内心的交流）。而對于一個軟體而言，品質最好的部分并不能導緻整個軟體品質好，但品質差的部分卻可以導緻整個軟體品質差（可以認為是一個串聯系統），是以建立一個學習型團隊成為當時的工作重點。
最初希望建立一個程式員的分級制度，讨論了很多元度，最終放棄了年限/“熟練程度”/語言種類等，而是鎖定在學習與交流上，因為我們發現“好程式員幾乎都是那些經常交流溝通的程式員”。當時部門有25人，設想劃分的等級包括：
1. 需要被指導的
2. 可獨立工作的
3. 可提供指導的
4. 可提供教育訓練的（後來在NEC看到他們的制度，前三個相同，這個則是“可獨擋一面的”也就是能帶領部門的）
下面是這幾個級别分别所需的人選條件和培養方向。
1. 需要被指導的
實際上接近誰都可以，但一般不選擇年齡很大而水準仍然不行的。年齡變大後，認知過程會受到局限，而年齡小的程式員學習能力和心态都要好得多。
指導活動委派給“可提供指導”的師傅，指導應該每時每刻都發生，而不是每天或每周開會或其它工作。1個3級師傅和1～3個1級新手組合成一個小組，以無障礙的方式坐在一起，随時溝通。師傅要随時與大家進行“松結對程式設計”（請參考139團隊那篇博文），新手們如果程式設計出現了品質/進度問題，師傅要承擔責任。
新人造缺陷的速度遠遠超過造代碼的速度，一般新人每人每天編碼大約是老手們的2倍（隻看行數），而缺陷可以達到5～10倍。對于超級新手，最好不讓他們的代碼進入最終産品，而是先做做原型等工作；之後可以看過代碼并修訂後再進代碼庫。看代碼包括兩個重要内容：第一是簡化代碼，因為新手的程式普遍臭長；第二個則是排除典型的錯誤和隐患，尤其是各種測試找不到但肉眼能看到的問題如潛在的空指針/野指針等。
以往曾有人提過讓兩個水準相當的人一起做一個任務（或進行代碼交叉互審），結果我們發現他們經常吵起來，因為水準相當是吵不出什麼最終結果的，最多是半斤八兩；還是一高配多低效率高。這種檢查不會花費高手太多力氣，一方面新手的程式高手一看就能看出問題；二方面是新手必須在下次避免重複犯錯，師傅是來幫助他提高水準的，不是擦屁股的，這一點在配置設定師傅的時候就要明确。
2. 可獨立工作的
這裡的獨立工作，指“可獨立工作”而非“應獨立工作”。獨立工作是件很危險的事情，我們後來也出現了幾次生産問題，一個被非常信賴的進階程式員的2個月的工作被完全抛棄，而重建新的代碼隻花費了2周。是以如果可以選擇，獨立工作主要應該在新技術研究/單獨而獨立的産品等方面，盡量不要混入大型産品的最終代碼中。而且即使獨立工作，也應該有更高水準的程式員提供代碼審查，或隸屬于某“可提供指導”的隊員管理。
有很多程式員很喜歡沉迷技術，如果他們技術很高但卻不喜歡帶徒弟，也可以扔到這裡來。不過，“可獨立工作的”級别的價值遠遠低于“可提供指導的”，隻适合獨立公關特定狹窄的領域或産品，不适合做大規模主體開發，那是必須由團隊來承擔的工作。
3. 可提供指導的
從這個級别開始，開始有很強的業務方面的要求，而不再限于技術，因為他們要經常參加對外的交流活動；此外，所做出的決策往往不是基于技術，而是也要基于業務。要找到既懂業務又懂技術的人很難，是以可以選擇技術高手，但要要求他學習業務。其實工作了5～6年後的程式員都會隐隐地意識到，領域的經驗已經開始勝過技術經驗。
在另外一家公司我曾觀察到6人小組的組長天天程式設計而不進行管理，後來他說：他大緻數了一下，60%的代碼都是他編寫的，是以他就把其他人一扔，自己幹活去了。是以在給他們招聘下屬時，他們必須參加招聘活動，并詢問他們：你是否認為這個人可以在你們組幫助你幹活？把答案當作是否招聘的重要因素，同時也促使他思考自己需要什麼人，怎樣使用這些人。
4. 可獨當一面的
這個級别絕對是要對業務的重視超過技術的人來擔當，否則整個部門都可能以光速南轅北轍。此外如果團隊成立足夠長，他應該是從“可提供指導”級别提拔過來的。前面的各個級别可以認為是大壩上的一塊塊石頭，隻是大小差異的問題，而這個級别的人必須是水泥，而不是最大的一塊石頭，否則團隊很快就會陷入上司過多沉迷技術，産品像無舵之船一樣飄蕩。
這個級别基本上就是産品經理/部門經理的高度，同時也是靈活中提到的PO的高度。
最後一個級别的人非常難找，也很難培養。其實多數企業的基層技術實力差别很小，主要差别在于這一級别及以上人員的差異。
點選下載下傳免費的靈活開發教材：《火星人靈活開發手冊》
