只要招到大牛就能不死在创业路上？图样！图森破！

很多公司(尤其是创业公司)都发愁如何组建一个理想的团队，但是他们却往往没搞清楚团队的本质到底在于什么，本文作者以一个程序猿的角度来探讨他对于团队的理解。

过去，关于理想的开发团队似乎是一个热门的话题，所以我也来凑凑热闹。人们想要理想的开发团队，只是因为在传递知识的时候很痛苦。人们总在说，这个地球多你一个不多，少你一个不少。假如有一天你们团队中的主力走了，那么你们的团队会怎样?

有人会说：塞翁失马，焉知非福，也许上个月团队里走了个汉子，却新来了一个萌妹子;也许下个月会走个老人，那必然也会来个新人……对于个人来说，这是件好事。

但是对于团队来说就不一定了。

　　 最初的团队

　　有时，我会认为最理想的团队莫过于一些创业团队了—— 分工明确。很多创业公司在过去都有着较为理想的团队，然而随着业务与团队人数的增长，恐怕距离理想就会越来越远。

比如，刚才说到的“分工明确”这一优点，就恐怕会慢慢消失。我认识一些创业公司的前端人员，他们中的大多数可能还同时充当着后台API、App开发的角色。而这些人身兼多职的原因大致可归类为：

　 招不到人;

没有钱;

不知道招什么人(他们自己并没有意识到自己不知道)。

那些存活下来的团队(也包含没有存活下来的团队)里，一个人可能身兼多职，数个人的工作内容会有小部分的重叠，但是不会太多。在这一个时期，主导团队往往是Idea的所有者，Owner找来一个技术人员，这个技术人员再依照短处去寻找需要的人才，比如下图这样(别笑)：

随着公司业务的发展，出于个人、家庭、团队等等各种因素，总有些人会离职，公司总需要迎进新人。而通常，这些团队只有在真正受不了的时候才去招人，如果同大公司一样漫无目的地进行撒网式招聘，那么早晚会死在这条路上。

　 有序的团队

如果最初整个宇宙是混乱的、整个系统是混乱的、整个组织是混乱的，那么后边便是通过不断地分门别类，使整个系统看上去似乎有序。

所谓“有序”，即是说在这样的团队里，A做着A应该去做的事，B做着B应该去做的事。

如果A和B很熟悉，可能产生出ab —— 可能是一个新的系统，也可能是一个新的事物;

如果A和B不熟悉，那么通过公司的各种各样活动会帮他们产生ab;

如果A和B不得已熟悉，那么我想这个ab可能是API。

在最初的团队里，A和B的座位可能只隔着10cm，后来他们越来越远……

职能分明的团队是一个解耦后的系统(解耦就是用数学方法将两种运动分离开来处理问题)，他们之间的沟通需要比原来花费更大的开销，在传统IT公司及大部分的互联网公司都有这样的问题。

举例来说：传统软件开发流程中，知识传递的方式主要在于文档，而大部分程序员既讨厌看文档，又讨厌写文档(网上不难找到可以证明这一说法的证据)。

而无论是在系统集成环节，又或者是在交接环节，人们所做的事只有一件，那就是知识传递。因为职责所在的缘故，团队中每个单独的成员不可能接触太多的东西。

理想团队的核心问题

　　团队类似于人类的文明，更多地在于文化与知识的传承。而人们总是希望有一个理想的团队，但是他们往往并不知道，他们真正的问题不在于团队的成员本身—— 而在于团队是如何协作的。

　 理想型A

多数公司总是认为，理想团队的组成方式类似于这样：

那么想象一下：如果有一天大牛(图中那个红色圆点)出车祸了，中牛(橙色圆点)roll off了，那么整个团队就剩下一堆绿帽子了..……(囧oz)

在这样的团队里，只有大牛和中牛比较厉害，下面都是一帮菜鸟，让菜鸟之间传递知识基本是白费力气。那么我们通常会用下面的方式来培养、教授团队的成员：

老师(大牛或中牛)说：

你今天去把《Thinking Java》看一遍;

你今天去把《设计模式》看一下;

你今天……

在这时候，那些领悟力比较好的成员就可以走在NB的路上了，不过每堆人里也只会有那么1、2个人……╮(╯_╰)╭

　 理想型B

在另外一个理想型的团队里，成员的组成可以是这样的结构：

在这样的团队里，传递知识相当容易，因为大家很容易就懂得别人说的内容(人人都是大牛或中牛)。这样的团队并非不可构建，虽然让团队中的每一个人都是全栈程序员的难度很大。

　 构建理想团队

人类以前(现在基本也是)是通过师徒制来保证师徒间的知识可以传递下来。而在多数的软件开发团队里并不存在这样的制度，换句话说，在这样的环境成长时，你没有老师，要学什么、怎么学只能依靠你自己。

试着想一想：当团队里来了一个新人，你会怎么做?

再试着反过来想一想：如果你是一个新人，你来到这样一个团队：

A教你如何使用各种快捷键;

B教你使用一些特定语言的技巧;

C教你一些基本的DevOps技能;

D教你怎么追妹子;

……

说实话，我很怀疑新人是否真的会考虑加入这样一个团队。

　 结对编程

结对编程是指两位程序员坐在同一工作台前开发软件。与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码。不过也许出于对公司制度和文化的考虑，也许是出于对自己的不明确认知，多数市场主导的公司并不会采用这样的方式来工作。

这种团队的组成和协作方式，倾向于下图(请别问我从哪找的图，我只是比喻一下)：

在这样的协作里(也是知识传递的过程)，两个人并非每人的技能属性和强度都需要一致，两人的技能会出现重叠，但各有所强，并且很可能有一个人的某一个技能点数是满点。

随着项目的不断开发，随着老人离职新人进来，在这个结对编程的过程中，知识都在不断地传递，两个人的各项能力也会越来越强。

在这种结对编程的团队协作中会存在至少三种模式：

Coach模式：在我现有的经验里，这个模式对新人的帮助会比较大。通常来说，我们是要分解任务，然后带领新人一步步完成任务。虽然在这个过程中，新人可以很快了解工作中每一步的情况，但依旧没摆脱授课模式。

导航模式：在个过程中，有经验的人更多的是充当观察者。当能力差一些的那个人不知道往哪个方向走时，另一方就给予提示。但在这个模式中，往往要等新人犯错之后才能给出提示。

Pair模式：理想的结对编程是在这样的模式之中，两人之间有很好的默契，以及在某方面相接近的能力，要达成共同目标。在个过程中，需要注意的是平衡好两人的步骤。

采用结对编程的团队协作模式不仅可以提高菜鸟的水平，大牛的能力也可以有很大输出，对于程序员这一行业的人来说必然会有很大的提高。