醉创业
首发于醉创业
专题 | Mike Curtis:Airbnb 的工程师文化

专题 | Mike Curtis:Airbnb 的工程师文化

导语:

继续我们假期里关于「公司文化」的小专题。昨天推荐了 Airbnb 的创始人之一 Brian Chesky 的内部邮件,今天我们来看看Airbnb真正的公司文化是什么样的。

我听过 Airbnb 很多有趣的故事,尤其是当去年他们做了re-branding(还记得那个被玩儿坏的新logo吗?),且估值又蹿升到100亿美金之后,这家公司的很多细节开始被世人关心了。人们都在想,这么一个曾经被所有人嫌弃的创业项目是怎么走到今天的?

不过我们不打算过多宣扬他们那些看起来很像是「优秀企业文化」的部分,比如极尽细节的办公室装修(比如Airbnb每间会议室都是一个真实出租房屋的复制,那个非洲房屋的家具是等了几个月才到的);硅谷科技公司最好的伙食之一(尤其早餐嗯);以及他们甚至有一个专门负责文化的部门叫做"Ground Control"...这些当然很重要,但在十几年前Sergey Brin把大厨 Charlie Ayers 请到 Google 开始,这些已经逐渐变成了硅谷明星创业公司的标配。当然,「公司文化」不止于此。文化不仅是免费伙食和带薪假期,文化还是,你鼓励什么、限制什么、奖赏什么、惩罚什么;如何招聘、怎样对待你的客户、邮件的风格是什么...等等等等。我们推荐过 Ben Horowitz 两篇挺受欢迎的文章《如何尽可能地减少公司政治》和《如果你做不了别的什么,就做一家「好」公司吧》。我想,这也是公司文化的一部分。

这篇文章讲的则是Airbnb的工程师文化。工程师在这个时代有多重要已毋须多言,但真正能塑造良好工程师文化的创业公司却并不多见。很多时候,他们仍被当成「实现一个idea的工具」,而不是企业的主人。但历史告诉我们,有一个正确的工程师文化能够让公司变得多么强大。不过读完这篇 Airbnb 分享在自己博客上的文章后,我很强的一个感受是,如果能做到文中说的那样,那么公司整体的招聘流程、打造方式等等都要围绕着那些最核心的价值进行。所以,文化从来不是孤立的,而且浸染在一个公司的方方面面。

Engineering Culture at Airbnb

作者:Mike Curtis

翻译:想读好多好多书的@李学芳、一回家就失联的@DDC

原文链接:Engineering Culture at Airbnb

如果你昨天正好在Airbnb的办公室可能会发现一个现象:掌声。我不清楚为什么,但有时候团队会为了一些小成就而鼓掌,然后越来越多的人开始加入其中,突然间整个产品开发部沉浸在一片掌声和欢呼中。很多人并不知道庆祝的原因,他们只是想表示支持顺便开心一下。也许这就是好的文化吧:自觉支持并祝贺他人的成功。每个公司都有特定的文化,有些小心翼翼地保持着,而另一些只是随性发展并期望得到好结果。但不管怎样都存在一个事实:人们在良好的文化环境下工作表现很出色,而在糟糕的文化下工作就会自暴自弃。我来Airbnb已经一年多了,之前我在Facebook,Yahoo!和很多其他公司担任过工程师和经理,我想分享一些我们在塑造工程师文化上所做的努力。

工程师拥有自己的影响力

我们的核心思想是:工程师拥有自己的影响力。每个工程师都单独负责为客户以及公司创造尽可能多的价值。我们招人最看重解决问题的能力。当你有一个有强大的解决问题能力的团队时,使公司前进的最好方法就是把决策权给到每个工程师手中。我们的文化、工具以及流程都围绕着给个体贡献者及时提供准确的信息以帮助他们作出正确的决策,这也利于我们迭代、实验、以及学得更快。

创造出这样的环境需要几个条件,工程师要参与每个项目的目标设定、计划和头脑风暴,他们也可以自由地选择想要做哪个项目。他们可以灵活地平衡长期和短期工作,在管理技术问题的同时创造商业影响力。这表示工程师可以做任何他们想做的吗? 不。他们会和团队其他成员,包括产品经理、设计人员、数据分析师等一起定义并优先选出有影响力的工作。同样重要的是,工程师可以访问所有的信息。我们默认信息共享。工程师们得到的信息越多,工作自主性就越高。除非有特殊理由(几乎很少),一切都是共享的,包括访问分析数据信息库,每周项目实时更新,CEO会议摘要,以及很多其他信息。这种环境会让人提心吊胆,尤其是对新来的工程师来说。这也是为什么我们的核心价值观之一就是优先帮助别人。在我们的团队中,没有人会因为很忙而拒绝向他人提供帮助。尤其是对于我们新招募的毕业生,往往会被分派到可以帮助他们发现问题的团队。不管是技术还是战略上的问题,工程师总是优先帮助他人。

Airbnb三位创始人



结构化的团队和流动的责任制

如果有一个清晰的公司战略来指导决策流程,就可以帮助人们判断什么才是有影响力的,这就是为什么我们的战略设计得简单且可定量分析。它简单到可以在一张纸上列出来,Airbnb的每一位员工都清楚自己的工作和公司整体大局是如何关联的。明白你团队的目标可以帮助你合理地安排时间,这样就能少费时间讨论有争议的事情。因为我们每一个主要目标都会被量化,所以就可以评判每个项目的效率,快速地从成功或失败中学习。

我们的团队结构也反映了公司的策略:我们的工作小组都很紧凑,一般不会超过十个人,这样可以使沟通更高效。团队主要由工程师、产品经理、设计师、数据分析师组成,有一些团队也会和公司其他部门合作。不同职能部门间的合作很紧密。支付部门有财务部门的人,内部工具部门有客户体验部门的人。工程师和设计师一起找出如何实现某件事。最好的想法往往是由紧密合作而来的。今年,我们有十个团队负责产品开发,四个团队负责基础技术设施建设。每个团队都关注一个Aribnb业务的特定方面,并以季度为单位按照公司的整体战略制定自己的项目和子目标。虽然每个团队都负责业务中并不重合的部分,但跨领域合作很常见也受到鼓励。比如我们有独立的分别负责房东和房客的团队,因为我们倾向于将房东和房客看做不同的用户群,他们各自有特定的需求。但正是房东和房客的互动使得Aribnb变得特别,这两个团队为各自的发展蓝图出主意、共享目标、在项目中搭配合作,同时又保留足够的独立性,并积累特定客户群的使用案例和专业经验。促进跨团队合作可以帮助我们弥补缺陷。对工程师来说转换团队或者做超出他本来团队范围的工作很常见。举个例子,面向产品的团队在他们项目的工作流程中为改善基础设施建设做出贡献是很常见的事情。当工程师发现另外一个团队的工作更符合自己的兴趣也更容易让他们发挥影响时,他们可以自由地选择团队。而且事实上,这样做是被提倡的。经理可以促进这样的过程,但这要取决于工程师个人是不是找到了使自己创造最大价值的团队并愿意动一动。

开发流程中的文化导向

Airbnb的开发流程设计地非常灵活,我们不想过于发散,但是我们也不想太标准化以至于错失新兴的优秀工具和方法。我们推崇的是,培养个体的判断力而不是在团队中强制推行规则。流程的改变往往是自团队内部发生的。代码审查(code review)是常常被提起的一个体现这种改变的典型例子。多年来我们一直有抽查的机制,但这并不是强制的,在过去许多工程师也没有把这纳入到他们的工作流程中。事实上,早期的普遍做法是将自己的更改直接加入到源代码里并配置网站,这有点像蒙着眼睛玩儿电锯——开动电锯的时候看着很酷,但最后你肯定会失去一根手指。不知从什么时候开始,几个积极的工程师开始在我们的全体工程师周会上指出那些非常好的代码审查,他们指出的都是过去一周他们看到的最有帮助或有想法的代码审查,很快,越来越多的工程师开始申请代码审查,当过了那个临界点,不申请代码审查反而会变得怪怪的。现在这已经是我们开发流程的一环了。

同时,这种文化的转变在我们的工具改进上也体现了出来,一个小工程师团队自发建立了我们的持续集成基础框架,所有的工程师团队随时添加的新的分支程序都可以在几分钟之内运行整个测试包。使用工具降低养成良好习惯的门槛也催化了团队的文化转变,这只是一个例子,此外还有数不清的其他例子,包括我们是如何采用项目管理工具和bug tracker的。当我们发现做某事的更佳方式时,我们会促进大家对这种新想法的认识,然后任其自由发展,直到它被整个团队采用(或被淘汰)。这样每个团队在如何完成工作上就有很多灵活发挥的空间,也给新想法新创意创造了机会。

每一位工程师都可以对代码库的任意部分作出贡献,所有的知识库都向每一位工程师开放,使这一切成为可能的是我们的自动化测试、代码审查文化以及通过细节监测检测产品异常现象的能力。我们的规矩借鉴来自开源世界:团队里负责维护代码库的人要先审阅你的更改才能将其合并进代码库,这种模式使得工程师们更容易解放自己。他们不用等别的团队找出时间来优先处理自己的申请,而是自己做完再请别人审查。这种代码审查是非常快的,因为我们总是优先帮助他人。代码合并后,工程师会部署自己的更改。一天里我们会重新配置网站十好几次。我们的建模-测试过程只需要不到10分钟就能运行完,而且我们8分钟左右就可以完成一次全面的产品配置,因为这个过程是如此快捷,我们要求工程师将自己的代码合并进代码库后立即部署他们的变更。产品的改动越小意味着产生冲突的可能性也更小,出错时排除漏洞也更容易。部署自己的更动时要列席工程师聊天室也是我们不成文的规定。部署开始和结束时我们的程序都会通知,工程师也会宣布他们已经验证了自己对产品做的变更。在此期间,工程师也要负责关注各项指标,确保不要出错。当然,有时候出错是不可避免的,这时我们就会恢复系统或者解决问题、继续前进。当问题解决后,工程师要和负责网站稳定运行的团队一起写一份事件分析报告,这不是为了指责哪个人,我们将所有的事件分析报告都存在我们内部开发的一个事件报告工具里,从这些报告中我们汲取信息,做出一些保证基础框架更加稳定可靠的前瞻性工作。

Airbnb Office



职业发展、路径、和影响力

我们还认为工程师不论是作为管理者还是个体贡献者都可以取得同样的发展。工程师的职业生涯中有两条发展轨道:管理和个体贡献,这两者的收入水平是相当的,所以在 Airbnb 进入工程师管理层并不会有薪酬上的优势。事实上,成为一名经理的意义不在于升职,而在于改变工作重心。经理人是协调员,他们的存在是为了清理工程师面前的障碍,有可能是职业发展障碍、优先级排序障碍或者技术支持,基本上是包罗万象。他们最主要的工作职责是支持他们周围人的工作。我们也很看中经理人的技术能力。每一位经理人每周都要参与很多技术决策,如果没有强大的技术背景,他们在这个决策过程中的影响可能导致不好的结果。有鉴于此,所有的经理都应该从个体贡献者做起,当他们熟悉了代码和开发实践后,最重要的是,当他们感到自然而然地要走出这一步的时候,他们可以转型为管理者。我们不会空降经理人。一个个体贡献者的主要职责是执行能给公司业务带来影响的技术,他们要负责找到并作出有高度影响力的工作。

在此过程中的另一条价值观是让一切经手事物更好。每一个项目都要能提升我们的技术基础。这种责任在于个人贡献者,这意味着工程师要驱动技术决策并督促彼此保持高标准的技术工作,也意味着工程师要协调各种功能的取舍和截止日期,保证有足够的时间来做高质量的技术产出。我们帮助工程师进步的另一个方法是帮助他们在公司外建立个人档案。我们通过在我们的书呆子博客和开源世界发博文实现这一点。我们认为不属于我们独特业务核心的东西都可以开放到开源世界,我们一直想要给社区贡献有用的科技,我们鼓励此种行为,因为这能提升人们对我们在做的编程工作的认识,也可以展示我们工程师的一些优秀作品。

总结一下

目前,我们还在建立能在未来几年带领我们前进的基础和最佳实践(best practice),当我们发展成一个更大的团队时,今天看来很小的一些决定将会被放大10倍。这让人压力山大,但是看着这些尝试取得成功并慢慢变成公司文化的一部分或者失败后亲眼看着它们被抛弃也挺有意思的。

别把企业文化玩儿坏了是最最重要的。当你快速扩张的时候,保持一个富有创造性和有趣的环境是很重要的。我们的工程师团队每周五都要欢聚一小时进行技术展示、GIF动图分享,鼓掌、赞美和欢呼。我们每两年还会组织为期几天的编程马拉松,每一届都像我们的博文报道的那样有价值。 每周我都会跟工程师小团队见面问些问题,听听有什么可以帮助我们改进的想法。我们有一个书呆子山洞,工程师可以在工作的时候进去休息听歌。关于我们的团队是怎么保持凝聚力、怎么玩儿得开心的可能可以专门写一整篇博文,但是这个我们改天再谈。让Airbnb与众不同的是我们的文化将工程师和企业愿景以及彼此紧紧地联系在一起,我在别的地方都没有看到过这种联接。在这里,工程师们有影响力、优先帮助他人、默认分享信息并总是让经手过的代码更好,我们的企业文化使得工程师能够呈现最出色的工作,并令他们每天来工作时都兴致勃勃。


另外,PingWest也写过关于Airbnb文化的一篇充满好玩细节的文章,补充阅读在此:

Airbnb创始人说别搞砸了公司文化,他们的公司的文化是什么?


题图来自Airbnb官网

编辑于 2015-02-22

文章被以下专栏收录