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的高度。

最后一个级别的人非常难找，也很难培养。其实多数企业的基层技术实力差别很小，主要差别在于这一级别及以上人员的差异。

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》