独家揭秘Airbnb的产品开发理念和工程师团队文化
英文原文：Engineering Culture at Airbnb
创见干货：
是时候来涨一波姿势了！这一次，Airbnb 在公司文化以及制度架构上给我们做了很好的示范，告诉我们一个真正符合互联网精神的科技公司应该是什么样儿？或者更加具体点儿说，一群埋头搞技术的工程师团队应该拥有怎样的团队文化？
从这篇文章中，你能懂得如何搭建一个纯技术的团队架构，如何设计部门之间的协作，真的可以算得上一次全面细致的分享了。也只有在创见，幸运的读者才能看得到「干货」与「有趣」久别重逢。
如果你曾经访问过 Airbnb 的办公场所，你很难不被一件事情吸引，那就是「鼓掌」。参观的人也许会一时一头雾水，但不要担心自己是不是走错了门儿，进到了某个传销团伙的据点。
不知道什么时候，你会发现身边一个小团队开始为一次小小的胜利鼓掌，然后周围越来越多的人也开始加入到鼓掌的队伍中，最后在整个产品研发和工程办公区，汇聚成为了滔天的声浪。说起来好笑，大部分人都不知道为什么自己在鼓掌，他们只是想在此时加入到欢呼庆祝的队伍当中，表示自己对他人的鼓励。这是在 Airbnb 经常看到的一个现象。
这本身就是一种优秀企业文化的具体体现。
每一家公司其实有着各自的公司文化。有一些很精心的设计打造，非常用心地关注和调整它一点一滴的发展，而另外的一些公司只是让文化自行在公司内部发展，期望最好的结果出现。无论哪种情况都改变不了这样一个标准：优秀的企业文化能够让身处其中的员工以最投入的态度去工作，而坏的企业文化则会腐蚀破坏人们的灵魂。.
笔者曾经有幸在 Airbnb 工作了 1 年多的时间。之前笔者曾经在其他若干公司担任工程师和产品经理，包括了 非死book 以及 Yahoo。这么多年的职场经验让笔者明白了一些道理，怎么样才能打造出最优秀的工程师团队文化。
工程师团队文化首要原则：工程师有着各自的影响力
工程师团队文化的核心就是：工程师都拥有各自的影响力。每一个工程师都在为客户以及公司创造价值上面承担着非常巨大的责任。
工程师本身就是出于「解决问题」的需要而招聘进来的。如果你的团队是由一群「解决问题能手」所组建而成的，那么最快推动公司向前发展的最有效办法就是让所有的决策落实在每一个工程师头上。工程师团队的文化、工具、流程，所有的一切都围绕着尽可能给这些工程师以最准确、最及时的信息，方便他们在第一时间做出最合理、最有效的决策。这能够帮助团队更快的进行产品的迭代更新，实验、以及更快的学习。
让这样的工作氛围得以实现是需要几个前提条件的：工程师需要在所有的项 目开发过程中，参与到制定目标、计划、头脑风暴中来，同时他们还需要具有对项目的自由选择权，更要有如何平衡短期工作和长期工作之间的灵活性，在不断应付 技术层面带来挑战的同时，还能创造出商业价值。但这是不是说工程师就是由着他们的性子想做什么就做什么呢？其实也不是这样的。他们需要跟团队其他成员一起 商量，不断地确认当下实质性的工作是什么，并且将这些工作按照优先级排序。在这里其他成员指的是项目开发经理、设计师、数据分析师以及其他人员。
更重要的是，工程师拥有的是无限透明的信息知情权。关于信息分享这件事，Airbnb 工程师团队是将其置于最高准则上的。工程师知道的信息越多，那么他们工作的自主性和自主能力也就越强。除非有一个非常明确，非常站得住脚的原因摆在那里让大家不要分享信息，否则大家是会做到信息同一时间，同一层面上的分享的。这里信息包括但不限于：分析用的数据库、周项目进展报告、CEO 所召开的会议纪要等内容。
这样的环境其实是会给人带来压力的，尤其是对于那些刚刚进入这个环境的新工程师来说更是如此。没有人会告诉你怎样去发挥自己的作用。而这就引入了工程师团队文化的第二个要点：帮助其他人寻找到当下的工作重点。
在 Airbnb 的团队，没有人会忙碌到抽不出时间来伸出援手的。往往刚刚进入 Airbnb 团队的新人，他的背后都站着一个团队的人，随之帮助他解决困难。不管这个困难是来自技术层面，又或者是工作计划层面，工程师们永远能够及时地给出最正确的答案。
结构化的团队，流动性的责任
在由公司所作出的清晰的战略规划下，让每个人都知道自己当下的工作内容应该是什么，并且在过程中不断推动决策的产生，这是可能的。因为 Airbnb 的发展战略一直以「可以量化」和「足够简洁」为两个主要特点。它足够简洁到所有的东西都能体现到一张白纸上，每一个在 Airbnb 的员工都很清楚自己肩上的职责，自己所负责的工作内容将会对这个更加宏大完整的图像产生怎样的影响。
知道了你的团队目标之后，你就能够清楚合理的规划自己的时间，尽可能地把曾经会浪费在争论上的时间拿来去做实质性的工作。因为 Airbnb 的各个大目标下都有着具体的数字目标，所以工程师们能够很快地评估出来每个项目的有效性，无论结果成败与否，都能够很快地从中学习，并且调整方向。
不仅如此，公司团队的结构也能够很好地体现出来公司的发展战略。事实上，Airbnb 的团队结构都是由大概 10 个人组成的小团队所组成的，成员包括了工程师、产品经理、设计师以及数据分析师。有一些团队成员还会兼任好几个小团队的岗位角色。同时，在不同的功能板块之间，Airbnb 是有着很强的协作性的。支付板块中会有来自财务的人，内部工具板块中会有来自客户体验的人。工程师与设计师经常会成双出现，实时地去解决当下的某个问题。最好的想法，往往就是来自于这种紧密的协作过程中。
在 2015 年，Airbnb 有 10 个团队面向产品开发，还有 4 个团队是面向技术的底层架构。每一个团队都将 Airbnb 的某个板块视为一个独立的产品来做，并且将这个产品不断拆分细化，使其成为以季度为分割的种种目标，而公司所做的整体战略规划是他们手中的指南针。
尽管每一个团队所负责的内容都是相对独立，不会产生重叠的，但是团队之间的频繁协作却又是经常发生，而且是被公司鼓励的。
举个例子，Airbnb 中分了两个不同的小组：「房东」和「租客」。因为从产品逻辑上来说，房东和租客是两个完全不同的群体，他们各自的诉求点是完全不一样的，但是正是因为房东 和租客之间的互动，才使得 Airbnb 在世界上那么得不同，所以这两个团队之间的协作沟通频繁程度，紧密程度完全超乎了一般人的想象。他们彼此分享经验，帮助对方来绘制「路线图」，分享目标， 合作开发项目，而另一方面，他们还能够拿出足够的专注程度投入到各自不同性质的工作中，满足拥有不同诉求的两种人群的各种需要。
言而总之，跨团队的协作帮助 Airbnb 弥合了产品板块与板块（部门与部门）之间的鸿沟
在 Airbnb，工程师突然换了团队，又或者做一些超出当下团队范畴的事情是很普遍的情况。举个例子，专注于产品的团队往往都需要在项目的工作流程中不断去 提升底层架构，而如果这个团队中的某个成员忽然发现自己的工作也许会在其他团队带来更加明显的效果，又或者是别的团队所做的事情更能引起他的兴趣，那么工 程师转团队是完全可以实现的，他们有这方面的自由。经理们会帮助他们理顺这一切。
其实说到底，一切都取决于工程师认为调整后的岗位角色会给整个产品团队带来更大的动力，只要满足这个条件，一切变动都不在话下。
在开发进程中的文化标准
Airbnb 在开发进程，从设计上来说是灵活的。它不希望在很多方向上都有所突破进展，但是也不希望变得非常标准化、模板化，这样会错失更好的工具和开发理念。Airbnb 为了解决这个两难问题，不强行在团队内推行某种规则，而是让每一个个体都能在产品开发中形成更加准确的判断。
如果项目开发上做了某些调整，往往是因为团队内部成员自发做出的决定。「代码审查」就是一个非常好的例子。
曾经，Airbnb 多年来都有一系列的方法来做到「拉拽请求」，但是从来不会说强制员工来这样应用。其实，很多工程师都没有将它们纳入到自己的工作流程中。在 Airbnb 刚刚建立不久的时候，一般来说工程师都能够将自己的变动直接应用到网站上。这就有点儿像是蒙着眼睛拿着电锯玩儿杂耍，看起来很酷，但是稍有不慎就会失掉自己的一根手指。
后来，有一些有想法的工程师们开始在每周工程师周报会议上面不断地强调「代码检查」的重要性，并且举出了在过去一周中所见过的最具帮助性，也是 最为深思熟虑的「代码审查」案例。很快，越来越多的工程师都开始应用「拉拽请求」，甚至于到最后如果你不要求「代码审查」的话，都会觉得你是如此的格格不 入。而如今，它已经成为了 Airbnb 项目开发过程中的一个不可或缺的环节。
同时，这种观念上的转换也体现在了工具的进步上面。之前有一个工程师小团队自己开发了一个能够持续整合的底层系统，让任何工程师团队能在几分钟内把一整套测试套件放到上面运行。利用工具，降低了高效率行为实现的门槛，并且不断推动公司的文化向前发展。
上述的例子只是冰山一角而已，与之类似的例子还有项目管理工具以及「Bug 追踪工具」上面。当 Airbnb 发现了一种更加优秀的开发方式的时候，它会让所有人都注意到它，让它基于特有的优势而存在，让人们来选择用或者不用。这样做会保证一定的灵活性，也不会错过任何一种能够提升开发效率的机会。
任何的工程师都能对代码库做出贡献，所有的软件库都是面向所有工程师开放的。别觉得这是不可能的事。因为 Airbnb 奉行的文化中包含了「自动化测试」、「代码审查」并且也有能力通过具体的产品监测发现代码异常。
这样的理念其实就是来自于如今的开源世界。团队中的某个人维护着这个代码库，而如今你想要染指这个代码库的话，首先要审查你所做的各种变动。
这样一来，每个工程师的主动性都得到了充分地释放。与其想办法把自己的问题放到别人团队的「工作重点清单」，然后等着他们来完成，还不如自己着手来做，然后请他们进行审查就好了。「代码审查」就是这样非常频繁地进行着，产品开发进程效率大大提升，每一个人都获益良多。
一旦代码融合了，工程师开始带来自己的变化。在任何一天，Airbnb 的网站所发生的变动会有 10 次甚至更多。整个的「开发-测试」流程只需要不到 10 分钟来运行，完成整个产品应用只需要花 8 分钟的时间。这 一切都太快速高效了，以至于一旦代码融合，公司会叫工程师立刻开始应用改变。各种细小的改变的快速应用，降低了发生技术冲突的概率，即便哪里出现了错误， 也方便人们更容易的「debug」。当你开始应用改变的时候，工程师通常都会在工程团队聊天室里待着。从系统宣布「配置」现在开始，到最后工程师们宣布他 们确认产品所做的变化是可行的。而在这个过程中，工程师还会紧密盯着一系列的数字，保证中间不会出什么差池。
当然，差池、失误、在所难免。往往 Airbnb 会选择把网站倒退到某个时点，又或者是立刻着手修复它。当问题解决的时候，工程师会出一份不针对任何人的「事故检查报告」。Airbnb 专门内部开发了一款「事故汇报工具」，专门用来保存这些报告。这些报告能够起到非常好的提示作用，帮助 Airbnb 在未来的工作中做到防患于未然，让系统底层架构更加可靠稳定。
职业发展
在科技圈子里面，作为工程师，你有两个选择，一方面你可以朝着自己的专业领域纵深发展，另一方面你可以朝着更高更宽的职位演进，比如产品经理。而 Airbnb 相信，前者能够取得如后者一般的成就。无论是哪个方向，他们的薪资是平行来制定的，所以如果在 Airbnb 升入了工程管理岗位，是没有什么所谓的「补偿性优势」一说的。
事实上，成为了一名经理并不意味着你是升职了，只是把你的工作角色，工作重心给做了一下调换而已。经理很多时候扮演的是居中协调的角色，他们是 不断将工程师前进路上的绊脚石移除的那个人。这个绊脚石有可能是职业发展上的某个瓶颈，工作内容优先度上的混乱，又或者是单纯技术上的不足。他们的功能体 现在「辅助」以及「指导」上面。
同时，Airbnb 还非常重视这些经理的技术强弱。每一个星期，每一个经理都会参加十几个有关技术层面的决策。如果他们任何一个人技术上不过关，那么很可能就不断让 Airbnb 深陷糟糕的泥潭之中。所以，所有的经理一开始都是从独立的工程技术人员做起来的。随着他们不断地熟悉代码，应用实践，还有更重要的是将 Airbnb 的文化纳入到下意识的行为当中，他们才一点点的符合「经理」这个角色。Airbnb 的经理绝不空降。
而作为独立的贡献者来说，他们主要的职责就是技术层面的执行，确保能够给整个产品带来更多的价值。他们负责找出当下哪些工作内容是最能达到这个 结果。除此之外，还对他们有另外一个要求，让开发进程在未来实践的过程中变得更加优秀高效。每一个小项目都应该提升公司团队的技术基础。这样的责任落实到 了每个人的头上，也使得工程师对彼此有了更高标准的要求，工程师们也会在产品研发的时间底线和功能上面做出取舍，为了带来更高质量的工程开发，必须多争取 一些时间。
Airbnb 还会在公司之外帮助工程师建立他们的技术档案，传播他们的名气。在专门建立的博客上，又或者是某些开源项目上，Airbnb 一点儿也不吝啬于公开目前的技术成功以及相关的工程师的名字。因为 Airbnb 相信，只要不是跟自己行业有关的最核心的技术，这些都应该拿来贡献给开源事业。Airbnb 一直想做一些回馈于技术社群，以至于社会的事情。它鼓励越来越多的人注意到工程师的劳动成果，并且非常骄傲地向外界展示自己的工程师又取得了怎样的进展成 就。
最后的总结
在接下来的几年时间，Airbnb 还将秉承着上述的开发理念和价值观不断向前。如今看上去那些不起眼的小事情所带来的深远影响，将在明天乘以十倍。届时 Airbnb 将成为一个更加庞大的团队，当然会有更大的压力，但能看到一路上不断在做试验，那些好的结果纳入到了 Airbnb 成为了它其中的一部分，哪些被摒弃在眼前，这本身就是很有趣的一件事，不是吗？
当你在快速成长的过程中，需要时刻保证这个创业环境是富有创新精神，并且有趣，这一点非常重要。工程师团队每个星期五都会展开长达一个小时的与技术研讨展示有关的会，上面会有各种 GIF 动画、欢呼喝彩、以及感谢的声音。Aribnb 还会在一年时间里展开两次长达数天的黑客马拉松活动。
让 Airbnb 变得如此特殊的是它的工程师文化，这种文化让工程人员比其他公司更加紧密联系在一起，如果总结一下就是：每个工程师都各负其责，拥有绝对的话语权和影响力，以互帮互助为工作重点，信息的共享是默认选项，持续不断地提升代码质量。这种文化让每个工程师都能带来最优秀的工作成果，每一天早上都能充满欣喜期待地投入到全新的工作当中。