只要招到大牛,就能不死在创业路上?

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

只要招到大牛,就能不死在创业路上?的照片 - 1

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

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

只要招到大牛,就能不死在创业路上?的照片 - 2

最初的团队

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

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

招不到人;

没有钱;

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

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

只要招到大牛,就能不死在创业路上?的照片 - 3

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

有序的团队

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

只要招到大牛,就能不死在创业路上?的照片 - 4

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

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

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

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

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

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

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

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

理想团队的核心问题

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

  • 理想型A

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

只要招到大牛,就能不死在创业路上?的照片 - 5

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

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

只要招到大牛,就能不死在创业路上?的照片 - 6

老师(大牛或中牛)说:

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

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

你今天……

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

  • 理想型B

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

只要招到大牛,就能不死在创业路上?的照片 - 7

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

构建理想团队

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

  • 试着想一想:当团队里来了一个新人,你会怎么做?
  • 再试着反过来想一想:如果你是一个新人,你来到这样一个团队:
  1. A教你如何使用各种快捷键;
  2. B教你使用一些特定语言的技巧;
  3. C教你一些基本的DevOps技能;
  4. D教你怎么追妹子;
  5. ……

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

结对编程

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

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

只要招到大牛,就能不死在创业路上?的照片 - 8

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

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

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

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

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

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

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

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: