如何打造一个好氛围的技术团队
在创业团队里，由于自身名气不响，聘用到合适的员工是非常困难的。我就曾经遇上过无数约好面试不来的，几个发完offer后不报道也不主动回复的，甚至还有面试过程中接到BAT电话提供offer于是立马拔脚走人的。本文尝试记录一下某创业公司里，从零开始打造一个好氛围的技术团队的一些心得。
组建团队
招聘难，并不意味着就要降低标准。与其为了眼前利益而将就着聘用一个不太合适的人，并可能在未来使你自己还要耗费精力紧盯他的工作，让大家都痛苦，倒不如一开始就不要入这个坑。实际上招聘员工还是有一些技巧的。最靠谱的，就是自己认识，或者是同事内部推荐的人。这样的人有自己或者同事的背书，相比简历pk加海选，一般还是靠谱得多的。设置一个还不错的推荐费，更能增加一些推荐的动力。猎头们手上也会有一些不错的资源，就是会比较贵一些。选对合适的招聘时机也很重要。过年之后有不少领了年终奖后由于各种原因要跳槽的人，对于公司来说，可以选择的余地多了不少。当然弊端是这时候的竞争对手也会有很多。不过如果你的公司有足够吸引力的话（要不然你为什么会在那里？），关系也不大。提供差异化的岗位也是一个办法。有时候招聘时会觉得这人挺不错的，但就是不太适合这个职位，这时如果有条件的话，可以把眼光放长远些，留得好萝卜，不怕没有坑。有些工作还可以考虑以外包、合作甚至兼职的方式完成，不一定非得通过招聘来解决。
团队的规模不要太大，不然管理起来又麻烦又累，效率也不高。也不要求每个人都非常资深，工作经验能够均匀地哈希开就可以了。团队成员的性格和技能上最好能够互补。性格上，可以参考《人际风格与有效沟通实战》这篇文章，配备各种性格的队员。技能上，最好每个队员都各有所长，这样才能相互学习，促进团队整体的健康发展。
维护团队
根
有了团队之后，就需要让队员在团队里有家一般安心的感觉，这样才能集中精力，发挥出团队的战斗力。新招聘的人，由于对这个团队所知不多，根据各自的性格，可能会不敢表达，或者是急于表现。这就首先需要有一个能让新人感觉可靠的人物。虽然不至于时时嘘寒问暖，但是也要针对不同性格适时鼓励或是交代更多的背景知识。每当我去到一个新团队的时候，我就会把认识的人视为“根”，工作或是政策上有问题都会优先找他，就算他解决不了，也会告诉我应该找谁。有的公司会有类似的政策，称之为buddy或者是sponsor，以帮助新人迅速融入环境。所以为每位新人找到一个合适的“根”，让其从“根”上发芽并迅速成长为参天大树，就是团队领袖的任务之一。
连接
团队成员如果只是通过工作维系在一起，这样的连接就不是那么的可靠。所以我们需要团队建设（team building）来增加工作之外的连接。我记得新团队的第一次团队建设，是参加一个密室逃脱。在游戏中，不仅能看到每个人的特点和配合能力，还能给未来增加不少谈资，从而加强团队成员间的连接。相比起来，如果只是吃顿饭……效果就比较有限了，但总是比没有强。所以许多公司会有针对新人的拓展训练。如果公司层面能够组织旅游那就更理想了，除了提振团队士气，甚至找到自己的另一半也不无可能。团队发展好了，就会自发产生各种活动，甚至邀请团队成员去自己家里玩，从而将同事变成了朋友，在这样的团队里工作相信一定是令人愉悦的享受，而不仅仅是为了养家糊口而工作。
目标
团队是指一种为了实现某一目标而由相互协作的个体所组成的正式群体，所以明确团队的目标是非常重要的，可以说没有目标就没有团队存在的必要。这个目标需要让所有的团队成员都心中有数。曾经有一段时间完成一期的开发工作之后，第二天团队突然发现没有活儿了，于是有人开始焦虑，有人开始懒散，还有人浑浑噩噩，不知道整天都做了些什么。直到PM组织大家开了一个小会，说明了接下来的目标之后，团队才找到了存在的价值，重新振奋士气走下去。实现团队目标的同时，也可以兼顾团队成员个体的目标，尽量使之也能协同实现。
会议
工作上，新人可能对别人都干了些什么不那么了解，会有一种“不那么透明”的感觉。每天早上团队站会（stand-up meeting）是解决这个问题的良方之一。大家轮着说昨天都做了什么，今天要做些什么，遇到了哪些问题，有心的人自然能从中获取到有用的信息。结对编程（pair programming）也有助于在团队成员之间共享信息，但是它的成本比较高，可以在创业公司中将其作为非常规手段，只在必要的时候结对即可。一个迭代或项目完成之后的回顾会议（retrospective）也对改进团队效率、增加团队透明度很有帮助。大致做法如下：
- 如果团队成员之间不很熟悉，或者氛围非常不好，需要做安全度检查，大家匿名打分，如果分数偏低，需要请在场人士中级别最高的人员离场，之后重复打分直至分数较高为止。如果一直都是很低，那团队肯定有问题。这个会也没有必要开了，领导需要在线下解决。这个是担心开会的时候，大家真话说得少，光说套话等。不说真话的会，不如不开，省的浪费大家时间。
- 主持人组织大家写一些便利贴，一般包含好的（well）、不好的（less well）和不确定的（puzzle）三类，然后将其贴在白板上并进行归类。一个well的例子可能是我们有XXX新人加入，一个less well的例子可能是好久没有团建了，一个puzzle的例子可能是我们好久没有code review了。主持人应该尽量客观，通常尽量少发表自己的看法。他还要负责时间上的控制，不要太发散了，导致问题都聊不完，或者聊太high了。建议主持人轮岗。
- 让大家都明白白板上的便利贴说的到底都是什么事。
- 让大家投票选出最想聊的几件事，然后讨论并记下可以做的行动（action）以及负责人。
- 主持人记录回顾内容并发给大家（wiki或邮件），这样可以在下次回顾会议的时候看看上次的行动进展如何了。
分权
如果管理得太过精细，管理者难免会心力交瘁（有些人除外）。适当地放手，让团队成员自己负责某一块领域，不仅有助于管理者集中精力处理自己的任务，也更能促进团队成员的成长。即使管理者有事不在的时候，也能迅速找到后备者顶上，解决一些迫在眉睫的问题。每个团队成员都不一样，有些人不喜欢总是做一样的事情，这种时候就可以考虑轮岗，增加其技术广度。而有些人可能由于家庭或别的原因，希望稳定一段时间，这种时候就可以让其深入成为某一领域上的专家。所以一对一地聊一聊，确认对方的喜好，以及公司层面可以提供的支持，可以作为领导者的事前功课。
提高效率
团队的开发效率非常重要，可以说是关系到团队的存亡。这方面可以采用痛点驱动的办法来提高团队效率。例如，如果程序员写的代码，要部署上某个环境非常费劲，那就会迫使程序员尽量少去部署。这时候团队就需要有人站出来，解决部署慢的问题。有许多时候这其实就是个对某原则的妥协，或是对某个工具不太熟悉罢了。例如，当时团队开发app的h5端的时候，部署测试环境需要五分钟，导致调试效率低下。后来通过分析为什么慢，并打出一系列组合拳来解决那些原因，我们将部署时间缩短到了10秒，大家的工作热情很容易就起来了。还有一次由于包引用的关系，导致部署并调试本地环境需要耗时三分钟。分析原因之后，我们放弃了DRY原则，将比较类似的代码分散到了不同的代码库里，极大地提高了本地的调试效率。而被放弃的DRY原则在这种场景下其实并不是那么的适用。
许多程序员倾向于复制/粘贴代码来作为自己的模板。所以如果技术领导者想要大家写出什么样的代码，首先需要让自己的代码成为理想代码的模板。例如，如果我希望大家编写单元测试，那我的代码就需要有单元测试，这样当其他人复制的时候，就需要考虑单元测试怎么写的问题。但如果只是口头说说，很快就会流于形式。而模板当然不可能一口气就写得那么完美，所以当代码审查的时候，需要识别并不断改进烂代码，还要把思想传达给其他人，最终成为团队共同的财富。
学习
仅有工作的热情还不够，程序员其实并不是吃青春饭的职业，而是终身不断学习提高的职业。团队应该能够提供集体学习的环境，例如大家每周三晚上共同学习某一个课程（例如某个特定技术或是在线课程），共同成长。一个人学，学得快；一群人学，学得深。集体学习因为可以相互分享和讨论，学习效果要比个体学习更加突出。
分享
要想打造一个技术氛围浓厚的团队，适时地举办技术分享会是一个很不错的办法。一开始可能由于各种原因没人响应，这就需要团队领袖走出第一步并持续鼓励大家分享。如果团队成员不太自信，一开始的分享内容可以是非技术的，也可以是较短时间的。只要走出了第一步，后面总会越来越好的。分享除了让团队成员获取知识，更直接的其实是让分享者自身成长，还有助于将自己塑造成此领域的技术专家形象。分享可能会带来一些工作时间上的消耗（准备分享以及大家聚集在一起的时间），但是从长远来看是非常有益于团队成长和技术氛围构筑的。我所在的上一个团队就成功地推出了两档分享品牌，一个是每周五下午一个小时左右的技术主题分享，以及不定期的午间半小时非技术或是小技术分享。除了session形式的分享以外，还可以有workshop类型的分享，大家一起动手完成某个任务，效果更佳。
