【編者按】本文來自FreeS 組織的內部第一次創業公司 CTO 交流會，FreeS技術合伙人、前 Facebook工程師覃超，以及神州專車 CTO、前 Facebook 工程師徐萬鴻，向創業者講述：
創業公司應該如何創造自己的工程師文化？以及 Facebook 的看家產品 News Feed 背后的原理。
創業者常常會說：“請幫我們找個CTO 吧。”確實，資深工程師不少，但合格的 CTO 卻不多。作為 “C” 字頭的技術人員，CTO 所關注的絕不僅僅是工程質量這么簡單。內部運營的管理、HR 事務、整體架構都需要用到這位資深碼農。而就算從硅谷挖來一位技術大牛，應該如何與之磨合，也是困擾國內創業團隊的一個問題。
那么，Facebook在打造企業文化的時候都做了什么？創業公司可以從中學到什么？
Facebook 的 CTO 都在做些什么？
覃超：峰瑞資本技術合伙人，前 Facebook 工程師。
我在 2010-2014 年在 Facebook 工作，主要負責前端移動開發，從 Facebook Phone 到 iOS/Android Facebook App 和 Messager 等做過很多功能。同時我之前做過 PHP 后端的東西。
Facebook 第一特點就是重視技術兼設計。不像蘋果純設計而谷歌純技術，Facebook 是各占 50%。公司整體裝飾有意外多的藝術元素，而新的總部大樓更是由巨擘 Frank Gehry 設計的。
公司內部的彩虹樣式裝修，是美國高院宣布同性戀合法時加上的，也體現公司對于不同事物的包容和尊重。產品的活力和企業文化包容有很大的關系，所以我建議創業公司不妨都包容開放一點，比如放一個無人機或者 Oculus VR 的眼鏡就很棒。
公司里還有很多 Poster，其實我覺得這 Branding 和企業的 “政治教育” 內容。這些海報并不是專門一個人做，公司每個人都做，且公司有一個房間是專門造這些東西的材料，只要你把你的設計交給他們，最后海報就會制作出來。
Facebook 另一個特點就是開放，沒有嚴格的權限控制，例如 iOS 可以看到后端代碼，PHP可以看安卓的代碼。任何員工只要在公司的內網里，就可以隨時打開數據展示的頁面，然后看到公司的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 的行為會實時反饋到這個模型里面，重新訓練模型，讓效果越來越好。
京公網安備 11010502049343號