(一): 如何构建理想的开发团队
最后更新于:2022-04-01 03:37:58
> 原文出处:https://www.phodal.com/blog/rethink-one-build-dream-team/
> 作者: [Phodal Huang](https://www.phodal.com/blog/author/root/)
## ReThought (一): 如何构建理想的开发团队
**引言**: 过去,关于理想的开发团队似乎是一个热门的话题,所以我也来凑凑热闹。人们想要理想的开发团队,只是因为在传递知识的时候很痛苦。人们总在说,这个地球多你一个不多,少你一个不少。假想有一天你们团队中的主力走了,那么你们的团队会怎样?塞翁失马,焉知非福。
也许上个月我们团队里走了个汉子,来了一个萌妹子。也许下个月会走个老人,那必然也会来个新人。对于个人来说,这是件好事。但是对于团队来说,则有待商榷。于是,也将过去的一系列思考整理成一些文章,方便和以后的想法进行一些对比——有时候会发现最初的想法都挺好的,只是没有记录下来。
## 最初的团队
![document/2015-09-25/5604dd1c91eca](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd1c91eca.png)
有时,我在想最理想的团队莫过于一些创业团队了—— 分工明确。那些还存活着的公司在过去都有着那样理想的团队,然而随着公司业务与团队人数的增长,离这一些越来越远。
在我认识的那些创业公司的前端人员中,多数可能还充当着后台 API、App的开发,原因可归类为:
1. 招不到人
2. 没有钱
3. 不知道招什么人 (他们自己并没有意识到自己不知道)
如《REWORK》一书中所说的那样,只有在你真正受不了时才招人。如果同那些大公司一样,漫无目的地进行撒网,那么早晚会死在这条路上。通常在那些存活下来的团队(也包含没有存活下来的团队)里,一个人可能身兼多职,会有小部分的重叠,但是不会太多。
在这一个时期主导团队往往是Idea的所有者,Owner找来一个技术人员,这个技术人员再依照短处去寻找需要的人才。
![document/2015-09-25/5604dd2e45779](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd2e45779.png)
随着公司业务的发展,出于个人、家庭、团队因素,总有些人会离职(人总是有需求的,WiFi应该是最底层的吧),总需要迎进新人。
## 有序的团队
最初整个宇宙是混乱的、整个系统是混乱的、整个组织是混乱的。通过不断地分门别类,整个系统看上去似乎有序了。
![document/2015-09-25/5604dd42aa87c](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd42aa87c.png)
在这样的团队里,A做着A应该去做的事,B做着B应该去做的事。
1. 如果A和B很熟悉,可能产生出ab —— 可能是一个新的系统,也可能是一个新的生物。
2. 如果A和B不熟悉,那么通过公司的各种各样活动会帮ta们产生ab。
3. 如果A和B不得已熟悉,那么我想这个ab可能是API。
在最初的团队里,A和B可能只隔着10cm,后来他们越来越远。
职能分明的团队是一个解耦后的系统,他们间的沟通需要比原来花费更大的开销。在传统IT公司及大部分的互联网公司都有这样的"最后一公里"问题。引自之前的文章[《知识论(一): 知识传递》](https://www.phodal.com/static/media/uploads/rethink/https://www.phodal.com/blog/knowledge-transfer-part-1/) :
> 传统软件开发流程中,知识传递的方式主要在于文档,而我相信在网上已经有足够的证据可以表明,程序员既讨厌看文档,又讨厌写文档。
无论是在系统集成环节,又或者是在交接环节,人们所做的一件事只是知识传递。因为职责让你不可能接触太多的东西,就好比原来你可以每天吃一点的药,突然要你在短期内吃完。
## 理想团队
团队类似于人物文明,更多地在于文化与知识的传承。人们想要一个理想的团队,但是他们往往并不知道他们真正的问题不在于团队本身——而在于团队是如何协作的。
### 理想型A
在多数的公司里,团队的组成方式类似于下图:
![document/2015-09-25/5604dd517f559](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd517f559.png)
如果有一天大牛出车祸了,中牛roll off了,团队就剩下一堆绿帽子了...
在这样的团队里,我们可能会用下面的方式来教授团队的成员:
![document/2015-09-25/5604dd59cbf5d](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd59cbf5d.png)
即类似于传统的授课制:
1. 你今天去把《Thinking Java》看一遍
2. 你今天去把《设计模式》看一下
3. ...
在这时候,那些领悟力比较好的就在NB的路上了,但是每次只会有那么一两个人。
### 理想型B
在另外一个理想型的团队里,人们想要的是这样的结构。
![document/2015-09-25/5604dd649376a](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd649376a.png)
我想不到这样的团队还有怎样的知识可以传递。在这样的团队里,传递知识是相当于容易,因为大家很容易就懂得别人说的内容。
让团队中的每一个人都是全栈程序员的难度很大,然而这并不意味着这样的团队不可构建。
## 构建理想团队
在过去我们有师徒制,这样可以保证师徒间知识可以传递下来。而在多数的软件开发团队里,并不存在这样的制度,换句话说在这样的环境成长时,你只能依靠你自己。
> *在一个团队里,当来了一个新人时你们会怎么做?*
如果你是一个新人,你来到这样的一个团队:
1. A 教你如何使用各种快捷键。
2. B 教你使用一些特定语言的技巧。
3. C 教你一些基本的DevOps技能。
4. D 教你怎么追妹子。
5. ......
你会考虑加入这样的团队吗?
### 结对编程
或出于公司文化,或出于对自己的不明确认知,多数市场主导的公司并不会采用这样的方式来工作。这也导致了人们一直在追逐理想的开发团队时,一直找不到合适的时机。
![document/2015-09-25/5604dd708a632](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd708a632.png)
这时,也许会有人提醒你,你多了个分号。我曾经在看别人的面试作业时因为多了分号,reject了一个人——因为语言是Python。
而这时候团队的组成,倾向于下图(图是盗的,上面的图也都是盗的 :) ):
![document/2015-09-25/5604dd7ae921c](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd7ae921c.png)
在这样的团队里,并非每个人的技能都需要是一样的。会出现重叠,一个比一个强,可能有一个的技能点数是最强的。项目在不断开发地过程中,总会有人离职,有新人进来。
然而,在这个结对编程的过程中,知识都在不断地传递。
(ps: 上面只是提到了结对编程会构成理想团队,更多内容请期待下文《ReThink2: 如何照顾团队中的新人》(9月10号))