转载

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

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

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

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

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

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

  最初的团队

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

  比如,刚才说到的“分工明确”这一优点,就恐怕会慢慢消失。我认识一些创业公司的前端人员,他们中的大多数可能还同时充当着后台 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

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

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

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

  构建理想团队

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

  •   试着想一想:当团队里来了一个新人,你会怎么做?

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

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

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

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

  4. D教你怎么追妹子;

  5. ……

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

  结对编程

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

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

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

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

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

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

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

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

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

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

  作者介绍  

我是黄峰达,1991 年出生于闽南,双子座,毕业于西安文理学院(电子信息工程专业),目前就职于 ThoughtWorks (西安)。 农村长大,热爱大自然,热爱生活。和哈比特人一样喜欢土地里长出来的东西。 是一个文艺控。喜欢读书,喜欢纸的质感,喜欢用笔铭刻记忆和思想。 是一个设计控,一个 DIY 爱好者。喜欢自行设计一些小东西,相比理论而言更喜欢动手实践,比如拆装自己的手机、电脑等。 最喜欢折腾与计算机相关的东西:SEO、前端开发、硬件相关(如:Raspberry Pi,51,Arduino,OpenWRT,uCOS...)、搜索引擎。

正文到此结束
Loading...