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