專題 | 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 進入工程師管理層並不會有薪酬上的優勢。事實上，成為一名經理的意義不在於升職，而在於改變工作重心。經理人是協調員，他們的存在是為了清理工程師面前的障礙，有可能是職業發展障礙、優先順序排序障礙或者技術支持，基本上是包羅萬象。他們最主要的工作職責是支持他們周圍人的工作。我們也很看中經理人的技術能力。每一位經理人每周都要參與很多技術決策，如果沒有強大的技術背景，他們在這個決策過程中的影響可能導致不好的結果。有鑒於此，所有的經理都應該從個體貢獻者做起，當他們熟悉了代碼和開發實踐後，最重要的是，當他們感到自然而然地要走出這一步的時候，他們可以轉型為管理者。我們不會空降經理人。一個個體貢獻者的主要職責是執行能給公司業務帶來影響的技術，他們要負責找到並作出有高度影響力的工作。

在此過程中的另一條價值觀是讓一切經手事物更好。每一個項目都要能提升我們的技術基礎。這種責任在於個人貢獻者，這意味著工程師要驅動技術決策並督促彼此保持高標準的技術工作，也意味著工程師要協調各種功能的取捨和截止日期，保證有足夠的時間來做高質量的技術產出。我們幫助工程師進步的另一個方法是幫助他們在公司外建立個人檔案。我們通過在我們的書獃子博客和開源世界發博文實現這一點。我們認為不屬於我們獨特業務核心的東西都可以開放到開源世界，我們一直想要給社區貢獻有用的科技，我們鼓勵此種行為，因為這能提升人們對我們在做的編程工作的認識，也可以展示我們工程師的一些優秀作品。

總結一下

目前，我們還在建立能在未來幾年帶領我們前進的基礎和最佳實踐（best practice），當我們發展成一個更大的團隊時，今天看來很小的一些決定將會被放大10倍。這讓人壓力山大，但是看著這些嘗試取得成功並慢慢變成公司文化的一部分或者失敗後親眼看著它們被拋棄也挺有意思的。

別把企業文化玩兒壞了是最最重要的。當你快速擴張的時候，保持一個富有創造性和有趣的環境是很重要的。我們的工程師團隊每周五都要歡聚一小時進行技術展示、GIF動圖分享，鼓掌、讚美和歡呼。我們每兩年還會組織為期幾天的編程馬拉松，每一屆都像我們的博文報道的那樣有價值。 每周我都會跟工程師小團隊見面問些問題，聽聽有什麼可以幫助我們改進的想法。我們有一個書獃子山洞，工程師可以在工作的時候進去休息聽歌。關於我們的團隊是怎麼保持凝聚力、怎麼玩兒得開心的可能可以專門寫一整篇博文，但是這個我們改天再談。讓Airbnb與眾不同的是我們的文化將工程師和企業願景以及彼此緊緊地聯繫在一起，我在別的地方都沒有看到過這種聯接。在這裡，工程師們有影響力、優先幫助他人、默認分享信息並總是讓經手過的代碼更好，我們的企業文化使得工程師能夠呈現最出色的工作，並令他們每天來工作時都興緻勃勃。

另外，PingWest也寫過關於Airbnb文化的一篇充滿好玩細節的文章，補充閱讀在此：

Airbnb創始人說別搞砸了公司文化，他們的公司的文化是什麼？

題圖來自Airbnb官網