Facebook是如何打造自己的企業文化的？
【編者按】本文來自FreeS 組織的內部第一次創業公司 CTO 交流會，FreeS技術合夥人、前 Facebook 工程師覃超，以及神州專車 CTO、前 Facebook 工程師徐萬鴻，向創業者講述：
創業者常常會説：“請幫我們找個CTO 吧。”確實，資深工程師不少，但合格的 CTO 卻不多。作為 “C” 字頭的技術人員，CTO 所關注的絕不僅僅是工程質量這麼簡單。內部運營的管理、HR 事務、整體架構都需要用到這位資深碼農。而就算從矽谷挖來一位技術大牛，應該如何與之磨合，也是困擾國內創業團隊的一個問題。
那麼，Facebook在打造企業文化的時候都做了什麼？創業公司可以從中學到什麼？
Facebook 的 CTO 都在做些什麼？
我在 2010-2014 年在 Facebook 工作，主要負責前端移動開發，從 Facebook Phone 到 iOS/Android Facebook App 和 Messager 等做過很多功能。同時我之前做過 PHP 後端的東西。
Facebook 第一特點就是重視技術兼設計。不像蘋果純設計而Google純技術，Facebook 是各佔 50%。公司整體裝飾有意外多的藝術元素，而新的總部大樓更是由巨擘 Frank Gehry 設計的。
公司內部的彩虹樣式裝修，是美國高院宣佈同性戀合法時加上的，也體現公司對於不同事物的包容和尊重。產品的活力和企業文化包容有很大的關係，所以我建議創業公司不妨都包容開放一點，比如放一個無人機或者 Oculus VR 的眼鏡就很棒。
公司裏還有很多 Poster，其實我覺得這 Branding 和企業的 “政治教育” 內容。這些海報並不是專門一個人做，公司每個人都做，且公司有一個房間是專門造這些東西的材料，只要你把你的設計交給他們，最後海報就會製作出來。
Facebook 另一個特點就是開放，沒有嚴格的權限控制，例如 iOS 可以看到後端代碼，PHP可以看Android的代碼。任何員工只要在公司的內網裏，就可以隨時打開數據展示的頁面，然後看到公司的MAU（Monthly Active User-月活），DAU（Daily Active Users-日活）以及其他按照地區和功能切分的細節數據。這樣可以節省工作的管理開支，每個人也不會覺得束手束腳。
另外我們的工作空間就是網吧式的結構。這樣有兩個特點，好交流也鬧哄哄。最重要是有 Peer Pressure，比如你遲到或者打遊戲，都會被別人看到。比起其他很多美國的好處是，在 Facebook 工作刷 News Feed 或者微博和知乎是不會被限制的。
公司另一特點是默認給予員工最大程度的信任（按照老美的話説：trust by default），這也是美國文化的特點之一。一進公司就默認對你信任和尊重。它的相對應面是絕對強的執法能力，如果你泄露公司機密，則立馬把你開除。歷史上出現過幾次 Zuck 在 QA 的會議上説的公司機密被泄露的事件，那些泄密者最後基本都被開除。
一個公司最重要的是氣氛的和諧。不僅是程序猿之間，還有和設計師、PM，他們也會參加一些討論，且我們一定要坐在一起，這樣類似 UI 上細節的問題，比如顏色、像素對齊等，都可以當面溝通。即使 Facebook 的遠程會議系統和線上溝通工具都已經很健全了，但公司還是鼓勵坐在一起工作。
Facebook 項目的人員配比：一個項目一般是兩三個設計師、5-10個工程師 2-3 個產品經理。每個月一波推進（Scrum 裏強調的 sprint），包括 2-3 個功能，按每個功能分一小組來做，但設計師可能會同時做多個設計。Facebook 的流程其實比較傳統，但又夾雜很多敏捷開發的元素：一般是設計師先進行設計，然後工程師來開發，但整個過程中雙方又經常有交互。整個產品研發過程中，所有人都互相尊重、互相合作，從一開始設計師、工程師、PM 都會在一起討論，做出來之後還會坐在一起討論，會馬上給一些反饋，然後馬上修改好。
工程師寫代碼的時候也會跟設計師一起交流，交流用的是 IRC 外加 Facebook Chat。但這些我覺得比較過時，比起微信來説，它們算難用的，甚至還沒 QQ 好用。任務管理方面，Facebook有自己的Inhouse Task系統，可惜沒有開源。類似的工具，現在Trello 、Tower、Teambition 或者 Jira 就很好用，可以用來做產品上的規劃，開發進度管理和 bug tracking。
最後我們的 IC 、release、monitoring 這些全部都是內部工具，開發花了不少人力，對於創業公司不是特別適用。對持續集成來説，我覺得最經典的是 Jenkins，但是它的問題就是功能繁複、界面像 80 年代的軟件。如果你們用 Github 的話，我也推薦 Travis CI 和 Drone。
在矽谷公司裏，在開發流程上我覺得最重要的就是：Code Review。Facebook、Google、Uber 到現在的 Airbnb，無一不是強制要求 Code Review。Code review 過程中，不僅是可以互相檢查對方的代碼，還可以自動跑 lint 和unit test，對於代碼質量的提高和去除沒必要的bug非常有幫助。
這裏重點推薦一下 Facebook 的 Phabricator。
它是個開源的代碼審核和任務管理工具；它的其他功能也極其豐富；還可以搭在私有的服務器上，使其代碼和數據不會被盜用。另外我們基金已經把它進行了漢化，變成中文的一個定製版本，並且擴展到其他功能上。比如對BP的審核工作：我們自建了機器人來監控我們 BP 郵箱的內容，然後對於每一個進來的 BP，自動在系統中建立 Deal Review Task；然後我們的BP審核人員和投資經理們跟進。
最後一點 Facebook 讓我覺得印象深刻的，是它對於工程師技術能力的高要求和提供的一整套培訓。另外就是在矽谷公司工作，要學會有效地描述表達一個觀點，逼自己去學和反覆複習。我覺得反覆的一個過程很重要。反覆的過程中，看似在做重複的事情，但是每次我都會意外地迸發出新的靈感。最後對於設計這一塊，我們有一個特別強大的設計工具 Origami，可以很方便做交互設計，並且支持直接生成特效的代碼。
以下來自徐萬鴻：神州專車 CTO，前 Facebook 工程師。
Facebook 的 News Feed（新聞流）是怎麼做的？
新聞流（News Feed）是 Facebook 最重要的產品，有 10 億用户，平均每個用户每天會收到他關注的朋友/主頁所推送的 2000 個以上 stories。
從發出 story 到其他人接受 story 的時間在1秒之內，其中排序所花的時間在200毫秒之內。Data loss 要小於1E-6，實現這一點的關鍵在於系統架構。
用户更傾向於與頁面前面的內容互動，所以把更好的內容放在前面會帶來用户在 Facebook 上更大的參與度。實現這一點的關鍵在於 Ranking 部分。
Push model 和 Pull model 這兩種模型都是可行的。
Push model 寫入多次，讀取一次。如果有 1W 粉絲，發佈一條消息，會存儲在每個粉絲那裏，存儲 1W 次。這個模型速度比較快，但是需要存儲比較多。Pull model 寫入一次，讀取多次。發佈的都寫在一個庫裏，然後每個用户都來讀這個數據。
Facebook 內部更傾向於 Pull model，因為 Pushmodel 需要太多的存儲空間。
如何確定哪些是更好的 stories？我們需要給每一個 story 打分。我們賦予不同類型的行為不同的權重。比如 click, like, comment。這幾種行為中，comment 需要更多的代價。click 的代價很小，而 comment 意味着用付出更多的時間來互動，所以我們會給 comment更高的權值。
對於每一個 story，我們需要預測這個 story 被推送給用户後點擊、點贊、評論的概率。這裏會用到機器學習（machine learning）的算法。先要實時地生成 features，然後要利用數據來 train models，最後 publish models，得到每個用户對每個 story 的每種行為的概率。
關於個性化的部分，採用的是通用的模型和個性化的信息。如果能針對每個用户做不同的 model，效果會更好。但是用户數目太多，這部分的工作量過大。
同時這也是一個實時反饋的系統。用户對每個 story 的行為會實時反饋到這個模型裏面，重新訓練模型，讓效果越來越好。
資料來源：雷鋒網
作者/編輯：峰瑞資本
引用創業公司應該如何創造自己的工程師文化？以及 Facebook 的看家產品 News Feed 背後的原理。
創業者常常會説：“請幫我們找個CTO 吧。”確實，資深工程師不少，但合格的 CTO 卻不多。作為 “C” 字頭的技術人員，CTO 所關注的絕不僅僅是工程質量這麼簡單。內部運營的管理、HR 事務、整體架構都需要用到這位資深碼農。而就算從矽谷挖來一位技術大牛，應該如何與之磨合，也是困擾國內創業團隊的一個問題。
那麼，Facebook在打造企業文化的時候都做了什麼？創業公司可以從中學到什麼？
Facebook 的 CTO 都在做些什麼？
- 覃超：峰瑞資本技術合夥人，前 Facebook 工程師。
我在 2010-2014 年在 Facebook 工作，主要負責前端移動開發，從 Facebook Phone 到 iOS/Android Facebook App 和 Messager 等做過很多功能。同時我之前做過 PHP 後端的東西。
Facebook 第一特點就是重視技術兼設計。不像蘋果純設計而Google純技術，Facebook 是各佔 50%。公司整體裝飾有意外多的藝術元素，而新的總部大樓更是由巨擘 Frank Gehry 設計的。
公司內部的彩虹樣式裝修，是美國高院宣佈同性戀合法時加上的，也體現公司對於不同事物的包容和尊重。產品的活力和企業文化包容有很大的關係，所以我建議創業公司不妨都包容開放一點，比如放一個無人機或者 Oculus VR 的眼鏡就很棒。
公司裏還有很多 Poster，其實我覺得這 Branding 和企業的 “政治教育” 內容。這些海報並不是專門一個人做，公司每個人都做，且公司有一個房間是專門造這些東西的材料，只要你把你的設計交給他們，最後海報就會製作出來。
Facebook 另一個特點就是開放，沒有嚴格的權限控制，例如 iOS 可以看到後端代碼，PHP可以看Android的代碼。任何員工只要在公司的內網裏，就可以隨時打開數據展示的頁面，然後看到公司的MAU（Monthly Active User-月活），DAU（Daily Active Users-日活）以及其他按照地區和功能切分的細節數據。這樣可以節省工作的管理開支，每個人也不會覺得束手束腳。
另外我們的工作空間就是網吧式的結構。這樣有兩個特點，好交流也鬧哄哄。最重要是有 Peer Pressure，比如你遲到或者打遊戲，都會被別人看到。比起其他很多美國的好處是，在 Facebook 工作刷 News Feed 或者微博和知乎是不會被限制的。
公司另一特點是默認給予員工最大程度的信任（按照老美的話説：trust by default），這也是美國文化的特點之一。一進公司就默認對你信任和尊重。它的相對應面是絕對強的執法能力，如果你泄露公司機密，則立馬把你開除。歷史上出現過幾次 Zuck 在 QA 的會議上説的公司機密被泄露的事件，那些泄密者最後基本都被開除。
一個公司最重要的是氣氛的和諧。不僅是程序猿之間，還有和設計師、PM，他們也會參加一些討論，且我們一定要坐在一起，這樣類似 UI 上細節的問題，比如顏色、像素對齊等，都可以當面溝通。即使 Facebook 的遠程會議系統和線上溝通工具都已經很健全了，但公司還是鼓勵坐在一起工作。
Facebook 項目的人員配比：一個項目一般是兩三個設計師、5-10個工程師 2-3 個產品經理。每個月一波推進（Scrum 裏強調的 sprint），包括 2-3 個功能，按每個功能分一小組來做，但設計師可能會同時做多個設計。Facebook 的流程其實比較傳統，但又夾雜很多敏捷開發的元素：一般是設計師先進行設計，然後工程師來開發，但整個過程中雙方又經常有交互。整個產品研發過程中，所有人都互相尊重、互相合作，從一開始設計師、工程師、PM 都會在一起討論，做出來之後還會坐在一起討論，會馬上給一些反饋，然後馬上修改好。
工程師寫代碼的時候也會跟設計師一起交流，交流用的是 IRC 外加 Facebook Chat。但這些我覺得比較過時，比起微信來説，它們算難用的，甚至還沒 QQ 好用。任務管理方面，Facebook有自己的Inhouse Task系統，可惜沒有開源。類似的工具，現在Trello 、Tower、Teambition 或者 Jira 就很好用，可以用來做產品上的規劃，開發進度管理和 bug tracking。
最後我們的 IC 、release、monitoring 這些全部都是內部工具，開發花了不少人力，對於創業公司不是特別適用。對持續集成來説，我覺得最經典的是 Jenkins，但是它的問題就是功能繁複、界面像 80 年代的軟件。如果你們用 Github 的話，我也推薦 Travis CI 和 Drone。
在矽谷公司裏，在開發流程上我覺得最重要的就是：Code Review。Facebook、Google、Uber 到現在的 Airbnb，無一不是強制要求 Code Review。Code review 過程中，不僅是可以互相檢查對方的代碼，還可以自動跑 lint 和unit test，對於代碼質量的提高和去除沒必要的bug非常有幫助。
這裏重點推薦一下 Facebook 的 Phabricator。
它是個開源的代碼審核和任務管理工具；它的其他功能也極其豐富；還可以搭在私有的服務器上，使其代碼和數據不會被盜用。另外我們基金已經把它進行了漢化，變成中文的一個定製版本，並且擴展到其他功能上。比如對BP的審核工作：我們自建了機器人來監控我們 BP 郵箱的內容，然後對於每一個進來的 BP，自動在系統中建立 Deal Review Task；然後我們的BP審核人員和投資經理們跟進。
最後一點 Facebook 讓我覺得印象深刻的，是它對於工程師技術能力的高要求和提供的一整套培訓。另外就是在矽谷公司工作，要學會有效地描述表達一個觀點，逼自己去學和反覆複習。我覺得反覆的一個過程很重要。反覆的過程中，看似在做重複的事情，但是每次我都會意外地迸發出新的靈感。最後對於設計這一塊，我們有一個特別強大的設計工具 Origami，可以很方便做交互設計，並且支持直接生成特效的代碼。
以下來自徐萬鴻：神州專車 CTO，前 Facebook 工程師。
Facebook 的 News Feed（新聞流）是怎麼做的？
新聞流（News Feed）是 Facebook 最重要的產品，有 10 億用户，平均每個用户每天會收到他關注的朋友/主頁所推送的 2000 個以上 stories。
- 實時發佈，不漏掉重要的 story
從發出 story 到其他人接受 story 的時間在1秒之內，其中排序所花的時間在200毫秒之內。Data loss 要小於1E-6，實現這一點的關鍵在於系統架構。
- 把最好的內容放在前面
用户更傾向於與頁面前面的內容互動，所以把更好的內容放在前面會帶來用户在 Facebook 上更大的參與度。實現這一點的關鍵在於 Ranking 部分。
- 系統架構部分
Push model 和 Pull model 這兩種模型都是可行的。
Push model 寫入多次，讀取一次。如果有 1W 粉絲，發佈一條消息，會存儲在每個粉絲那裏，存儲 1W 次。這個模型速度比較快，但是需要存儲比較多。Pull model 寫入一次，讀取多次。發佈的都寫在一個庫裏，然後每個用户都來讀這個數據。
Facebook 內部更傾向於 Pull model，因為 Pushmodel 需要太多的存儲空間。
- Ranking 部分
如何確定哪些是更好的 stories？我們需要給每一個 story 打分。我們賦予不同類型的行為不同的權重。比如 click, like, comment。這幾種行為中，comment 需要更多的代價。click 的代價很小，而 comment 意味着用付出更多的時間來互動，所以我們會給 comment更高的權值。
對於每一個 story，我們需要預測這個 story 被推送給用户後點擊、點贊、評論的概率。這裏會用到機器學習（machine learning）的算法。先要實時地生成 features，然後要利用數據來 train models，最後 publish models，得到每個用户對每個 story 的每種行為的概率。
關於個性化的部分，採用的是通用的模型和個性化的信息。如果能針對每個用户做不同的 model，效果會更好。但是用户數目太多，這部分的工作量過大。
同時這也是一個實時反饋的系統。用户對每個 story 的行為會實時反饋到這個模型裏面，重新訓練模型，讓效果越來越好。
資料來源：雷鋒網
作者/編輯：峰瑞資本