如何在國內構建一個矽谷級的高效技術團隊？
文章內容
本文將通過對比傳統國內網際網路公司和 Facebook 等矽谷網際網路公司的團隊構成和專案流程，結合其中對比的利弊，以及融合兩種風格在小紅書落地的實戰經驗， 總結一條，以資料驅動和 Ownership 為核心的高效團隊組建和協作的方法論，作為增長型公司如何在“效率”上超越大公司的最核心的競爭力。本文整理自 QCon 2018 上海站上的演講。
從矽谷到中關村到底有什麼差別？以 Data Driven+Ownership 組建高效團隊！
效率差距
在加入小紅書之前，我曾先後在百度、知乎、Facebook、Airbnb 工作。今天就想分享我在這過去的十幾年間看到過、經歷過的不同公司在“效率”上不同做法，以及一些自己的總結。
“從矽谷到中關村到底有多遠？”大家在十年前覺得矽谷是技術型公司的聖殿。但是，今時今日中美網際網路公司，這些差別都變得非常小。
2018 年初 Mary Meeker 的年度網際網路報告裡面，Top 20 市值 / 估值的網際網路公司中國佔了一半，但從實際角度，還是在一些領域內差距明顯。以 Facebook 和阿里巴巴為例。他們兩個的市值曾經非常接近。但平均每個員工創造的收入，Facebook 大概是阿里巴巴的 3 倍。這個資料代表了一個公司的效率。
站在今天，中美網際網路企業最明顯的差距就是團隊效率。
接下來，我們將對比差別產生的原因，及能從矽谷能學到的東西，包括在小紅書的一些實踐當中看到的效果和遇到的問題。
網際網路時代的軟體工程
我們今天對於效率的討論，都是在網際網路時代這個大背景下如何能夠最大化團隊的效率，最大化團隊的產出。但中文網際網路元年大概是在 2000 年左右，我們現階段的所有網際網路企業都是脫胎於那個軟體時代。
軟體時代和網際網路時代有什麼區別？軟體時代 release 週期大概是半年到一年，背後的邏輯就八個字：質量第一，按期交付。
我們來講講其中的巨無霸：微軟。
在中國網際網路企業裡，大家沿用了微軟的開發流程。PM 中心制，以交付文件作為各個階段的結果產出。這是一個對於整個軟體開發而言好的流程。
但到了網際網路時代，這樣軟體工程有什麼問題？
第一點，所有原始設計的功能點的週期不再是月級別，是周級，甚至可能都是天級。
第二點，職能化區隔。基本上我們的團隊構成都是以職能切分，PM、工程師、測試工程師等。
在複雜的網際網路場景中，我們就會出現 PM 的需求和排期，會分別細化到客戶端團隊，到伺服器後端等。Team 越來越大，時間卻越來越少。流程能帶來安全和質量，但流程不能帶來效率。
我們再來看看網際網路時代下帶來的變化：
第一點，迭代速度比不出問題重要。如果一個特別嚴重的 BUG 放到線上，1 分鐘就能定位，5 分鐘就能 Release 修復，可能隻影響到了非常少的人，可以用迭代速度去彌補出現的問題。
第二點，一個基本功能的 MVP，也就是一個功能的最小化產品單元，比一個完備的產品設計要重要得多。
第三點，使用者反饋就顯得比按期交付更重要。應該用最小化的產品單元，用最快的迭代速度，將使用者的反饋收集到，確定這個產品的功能要不要，做不做深耕。
在網際網路時代下，對比傳統軟體時代，我們的最終生產效率能差多少？10 倍肯定是有的。效率就是第一競爭力。
我們再舉個網際網路時代公司的例子：Facebook。
Facebook 的一個最小 TEAM 單元叫做三人組，是設計師、產品經理和工程師，三個人完成基本功能。三個人之間不是流水線上各自獨立的環節，而是相互討論，相互交織。
產品經理，他不再只是 Product Manager，而是 Problem Manager，讓大家能看到問題的全貌，一起來探索解決的方案。
三人組這樣的團隊，與那個按職能來劃分的團隊相比，有什麼區別？
第一點，對問題負責，所有人不再只負責流水線上的一環，而是負責最終結果。
第二點，因為存在大量的面對面交流，而不是文件交流，它的結果是對於主觀能動性的激發是大的。
這兩點是為什麼能激發 10 倍的效能的基礎。對一件事情有 Ownership 可以激發個人巨大的效能。
以效率為中心，帶來了哪些變化呢？
變化 1：團隊
我們先來看看團隊的變化。
例如 Instagram 從創業團隊做大，一定要有術業有專攻。對於 Instagram 而言，第一個切分出來的團隊是基礎架構，他們支撐一個底層業務。
第二個拆分出來的團隊是 Growth。這個增長團隊是閉環的，為了目標就是一個，如何協同一起把這件事情做成，把問題解決。
之後，還會切分出 Engagment 團隊，以及 monetization 團隊。
團隊的切分方式都是以能讓大家分享同樣一個使用者側的目標，或者是公司級的目標。
在實際場景當中，大家最怕與跟自己職能不一樣的人放在一起。但我認為，單一驅動在今時今日這個場景下面是不存在的。
驅動大家的東西，是使用者側的反饋，或者叫資料。每個人都應該放下只有我說了算的 EGO，平等的對話，在各個地方收集問題，一起找到解決路徑。
變化 2：資料
在這樣的團隊裡面，帶來了第二種變化，資料無比重要。職能不一樣，團隊的共同語言是什麼？資料驅動決策的含義，就是團隊裡面每個人都需要去閱讀資料，讀懂資料。
資料驅動分幾級：
第一個，公司級。出個 Dashboard，加個 BI 團隊，負責給老闆跑數。這是低 level。
中等 level 是團隊級，每個團隊都有自己的可以量化的目標和結果。
高等 level，應該是團隊當中的每一個人每天都在跟資料打交道，每個人都能用資料，每個人都會用資料。但這需要有配套的機制和工具做輔助。
在 Facebook 內部，五年前有三大工具：Scuba，Hive，Ods。ODS 傳統 KV 儲存，主要是一些計數器。HIVE 就是資料倉庫，可以跑很大的資料量，缺點就是反應慢。SCUBA 在 Facebook 內部是人大家日常使用最多和最有幫助的工具，可以實時地做多維聚合。
實際應用工具當中的一個轉變，對人的影響是非常大的，工程師關心的不單是 CPU、MEMORY，關心的是全鏈路業務上面的使用者反饋，要有工具能看到結果長什麼樣子。產品經理也要有能力自己取數，要有 data sense。
這樣，資料科學家和資料分析師不再是取數工具了，而是可以去做資料分析，找到驅動資料變化的深層原因。
最後資料應該是公開的，應該是能覆蓋到儘量多的維度，資料的生產者和資料的消費者應該是一體的。我想知道，我做了這個功能有沒有人用，有多少人用，用得好不好，這才是最大的驅動力。
變化 3：職責
優秀的團隊，需要對結果負責。對結果負責很重要的一點，或者說做出成功產品的團隊核心是什麼？叫做 DOGFOODING。
DOGFOODING 是什麼意思呢？就是自己用自己的功能，自己吃自己的狗糧，或者狗屎。自己做出來的功能，首先自己要先用起來。
在 Facebook 有幾種簡單的工具去支援大家快速做使用者側嘗試，哪怕是隻給自己使用嚐鮮：
一種是 gatekeeper。通過在 gatekeeper 上設定過濾條件，對一小批使用者做測試。
另外一種是 AB 測試，切 10% 的使用者嘗試新功能，另外 10% 的使用者最對照。
那工具為什麼可以讓大家變成對結果負責呢？原因叫做賦能。因為有能力，所以有擔當。
除了靠各種 CI，Canary 工具以外， gatekeeper 和 AB testing 也可以讓你小流量去實驗，實驗個 5000 使用者，覺得沒問題，再放大，用這樣的工具去輔助這樣的權力。
總結來說，在網際網路時代，為什麼 Data driven 和 ownership 可以提供 10 倍的效能差別？因為在大目標對齊的情況下，各個小團隊之間可以組成一個分散式的決策機制，大家可以跨職能的團隊協作，去中心化進行決策，做到面對不確定性時的敏捷。
小紅書的實踐
最後我們來看一下過去這兩年，對於效率，我和我的團隊一起在小紅書的一些真實的實踐。
小紅書是一個生活方式平臺，裡面涉及到衣食住行，吃喝玩樂，並且可以完成從發現到決策到記錄的全鏈路流程。
我們是一個面向使用者、有豐富資料的平臺，這是我們產品上的天生優勢。我們一天的使用者閱讀量有數十億次，這種流量規模情況下，我們可以做非常多的 AB Testing，用 1% 的流量就可以做非常多的事情。
我們剛才講的對於各種效率理念，在過去兩年一步一步在小紅書做落地實踐。雖然有種種挑戰，過去的兩年裡面我們還是摸索著落地了很多效率層面上的改進：
首先第一點：資料賦能。每個人都會玩的資料平臺。我們自己做了一個前端，後面主要是 Hive，Presto，Spark 等等這樣的資料計算平臺。在這裡使用者可以套用模板寫 query。在小紅書團隊中最引以為傲的一點是，幾乎每個人都會寫。然後通過一些工具可以把這些資料變成一個圖，或者是變成一個每天監控的 dashboard，還可以變成 high level 的報警。
第二點，工程賦能。工程師有能力決定自己功能什麼時候上，要什麼時候上，或者要不要上。我們用了 Phabricator 做 Code Review，集成了後面 Jenkins 做 CI。所以工程師在這裡邊每天會看到說我現在有多少個 Diff 等著我去 Review，以及我的 diff 在被 review 的狀態是什麼樣子。當有一個 reviewer 點選了 accept，就代表可以上線了，就觸發了我們最終的 deploy 流程，就上到線上，這是對於工程權力的下放。
第三點，實驗賦能。我們現在線上 AB testing 平臺一天有 300+ 個實驗，也就是說我們每天在嘗試的新功能有 300 多個。AB testing 就是應該犯錯的，AB testing 就應該是 10% 的成功率才對，或者更低，代表實驗的效率更高和跑得更快。
我們剛才討論這些關於效率的話題，在小紅書團隊裡面都有所實踐並且一直在進步。我能看到工程師、產品經理、資料分析師在團隊裡面效能的變化，效率成倍的激變。
我們大概在今年年初的時候，我們整個的使用者突破了 1 億，現在已經超過 1.5 億。小紅書所有核心指標都是一年 4 倍到 5 倍地指數級增長。
我們就是一個從十來個人的團隊到 100 多人的團隊，QPS 從百到萬到十萬，去撐起了這麼一個每年 5 倍左右的核心 metric 的變化。
那麼從矽谷到中關村到底有多遠呢？
在小紅書，我們其實就是 為一線團隊做兩件事情，一個叫做放權，一個叫做賦能。
放權的意思是通過 Data Driven 的方式給予決策權的分散式下放；賦能的意思是通過工具，無論是測試工具也好，CI 也好，實驗平臺也好等等這樣的工具能讓團隊每個人有 ownership。最後，歡迎大家加入小紅書團隊，來一家高增長的公司高效率地做事情。