小紅書北京辦公室

2018年10月,QCon全球軟件開發(fā)大會在上海舉行。大會上,小紅書社區(qū)技術(shù)負責人姚旭發(fā)表演講,通過對比傳統(tǒng)國內(nèi)互聯(lián)網(wǎng)公司和 Facebook 等硅谷互聯(lián)網(wǎng)公司的團隊構(gòu)成和項目流程,結(jié)合其中對比的利弊,以及融合兩種風格在小紅書落地的實戰(zhàn)經(jīng)驗, 總結(jié)一條以數(shù)據(jù)驅(qū)動和 Ownership 為核心的高效團隊組建和協(xié)作的方法論,作為增長型公司如何在“效率”上超越大公司的最核心的競爭力。

演講內(nèi)容整理如下。

效率差距

在加入小紅書之前,我曾先后在百度、知乎、Facebook、Airbnb 工作。今天就想分享我在這過去的十幾年間看到過、經(jīng)歷過的不同公司在“效率”上不同做法,以及一些自己的總結(jié)。

“從硅谷到中關(guān)村到底有多遠?”大家在十年前覺得硅谷是技術(shù)型公司的圣殿。但是,今時今日中美互聯(lián)網(wǎng)公司,這些差別都變得非常小。

2018 年初 Mary Meeker 的年度互聯(lián)網(wǎng)報告里面,Top 20 市值 / 估值的互聯(lián)網(wǎng)公司中國占了一半,但從實際角度,還是在一些領(lǐng)域內(nèi)差距明顯。以 Facebook 和阿里巴巴為例。他們兩個的市值曾經(jīng)非常接近。但平均每個員工創(chuàng)造的收入,Facebook 大概是阿里巴巴的 3 倍。這個數(shù)據(jù)代表了一個公司的效率。

站在今天,中美互聯(lián)網(wǎng)企業(yè)最明顯的差距就是團隊效率。

接下來,我們將對比差別產(chǎn)生的原因,及能從硅谷能學到的東西,包括在小紅書的一些實踐當中看到的效果和遇到的問題。

互聯(lián)網(wǎng)時代的軟件工程

我們今天對于效率的討論,都是在互聯(lián)網(wǎng)時代這個大背景下如何能夠最大化團隊的效率,最大化團隊的產(chǎn)出。但中文互聯(lián)網(wǎng)元年大概是在 2000 年左右,我們現(xiàn)階段的所有互聯(lián)網(wǎng)企業(yè)都是脫胎于那個軟件時代。

軟件時代和互聯(lián)網(wǎng)時代有什么區(qū)別?軟件時代 release 周期大概是半年到一年,背后的邏輯就八個字:質(zhì)量第一,按期交付。

我們來講講其中的巨無霸:微軟。

在中國互聯(lián)網(wǎng)企業(yè)里,大家沿用了微軟的開發(fā)流程。PM 中心制,以交付文檔作為各個階段的結(jié)果產(chǎn)出。這是一個對于整個軟件開發(fā)而言好的流程。

但到了互聯(lián)網(wǎng)時代,這樣軟件工程有什么問題?

第一點,所有原始設(shè)計的功能點的周期不再是月級別,是周級,甚至可能都是天級。

第二點,職能化區(qū)隔。基本上我們的團隊構(gòu)成都是以職能切分,PM、工程師、測試工程師等。

在復雜的互聯(lián)網(wǎng)場景中,我們就會出現(xiàn) PM 的需求和排期,會分別細化到客戶端團隊,到服務(wù)器后端等。Team 越來越大,時間卻越來越少。流程能帶來安全和質(zhì)量,但流程不能帶來效率。

我們再來看看互聯(lián)網(wǎng)時代下帶來的變化:

第一點,迭代速度比不出問題重要。如果一個特別嚴重的 BUG 放到線上,1 分鐘就能定位,5 分鐘就能 Release 修復,可能只影響到了非常少的人,可以用迭代速度去彌補出現(xiàn)的問題。

第二點,一個基本功能的 MVP,也就是一個功能的最小化產(chǎn)品單元,比一個完備的產(chǎn)品設(shè)計要重要得多。

第三點,用戶反饋就顯得比按期交付更重要。應(yīng)該用最小化的產(chǎn)品單元,用最快的迭代速度,將用戶的反饋收集到,確定這個產(chǎn)品的功能要不要,做不做深耕。

在互聯(lián)網(wǎng)時代下,對比傳統(tǒng)軟件時代,我們的最終生產(chǎn)效率能差多少?10 倍肯定是有的。效率就是第一競爭力。

我們再舉個互聯(lián)網(wǎng)時代公司的例子:Facebook。

Facebook 的一個最小 TEAM 單元叫做三人組,是設(shè)計師、產(chǎn)品經(jīng)理和工程師,三個人完成基本功能。三個人之間不是流水線上各自獨立的環(huán)節(jié),而是相互討論,相互交織。

產(chǎn)品經(jīng)理,他不再只是 Product Manager,而是 Problem Manager,讓大家能看到問題的全貌,一起來探索解決的方案。

三人組這樣的團隊,與那個按職能來劃分的團隊相比,有什么區(qū)別?

第一點,對問題負責,所有人不再只負責流水線上的一環(huán),而是負責最終結(jié)果。

第二點,因為存在大量的面對面交流,而不是文檔交流,它的結(jié)果是對于主觀能動性的激發(fā)是大的。

這兩點是為什么能激發(fā) 10 倍的效能的基礎(chǔ)。對一件事情有 Ownership 可以激發(fā)個人巨大的效能。

以效率為中心,帶來了哪些變化呢?

變化 1:團隊

我們先來看看團隊的變化。

例如 Instagram 從創(chuàng)業(yè)團隊做大,一定要有術(shù)業(yè)有專攻。對于 Instagram 而言,第一個切分出來的團隊是基礎(chǔ)架構(gòu),他們支撐一個底層業(yè)務(wù)。

第二個拆分出來的團隊是 Growth。這個增長團隊是閉環(huán)的,為了目標就是一個,如何協(xié)同一起把這件事情做成,把問題解決。

之后,還會切分出 Engagment 團隊,以及 monetization 團隊。

團隊的切分方式都是以能讓大家分享同樣一個用戶側(cè)的目標,或者是公司級的目標。

在實際場景當中,大家最怕與跟自己職能不一樣的人放在一起。但我認為,單一驅(qū)動在今時今日這個場景下面是不存在的。

驅(qū)動大家的東西,是用戶側(cè)的反饋,或者叫數(shù)據(jù)。每個人都應(yīng)該放下只有我說了算的 EGO,平等的對話,在各個地方收集問題,一起找到解決路徑。

變化 2:數(shù)據(jù)

在這樣的團隊里面,帶來了第二種變化,數(shù)據(jù)無比重要。職能不一樣,團隊的共同語言是什么?數(shù)據(jù)驅(qū)動決策的含義,就是團隊里面每個人都需要去閱讀數(shù)據(jù),讀懂數(shù)據(jù)。

數(shù)據(jù)驅(qū)動分幾級:

●第一個,公司級。出個 Dashboard,加個 BI 團隊,負責給老板跑數(shù)。這是低 level。

●中等 level 是團隊級,每個團隊都有自己的可以量化的目標和結(jié)果。

●高等 level,應(yīng)該是團隊當中的每一個人每天都在跟數(shù)據(jù)打交道,每個人都能用數(shù)據(jù),每個人都會用數(shù)據(jù)。但這需要有配套的機制和工具做輔助。

在 Facebook 內(nèi)部,五年前有三大工具:Scuba,Hive,Ods。ODS 傳統(tǒng) KV 儲存,主要是一些計數(shù)器。HIVE 就是數(shù)據(jù)倉庫,可以跑很大的數(shù)據(jù)量,缺點就是反應(yīng)慢。SCUBA 在 Facebook 內(nèi)部是人大家日常使用最多和最有幫助的工具,可以實時地做多維聚合。

實際應(yīng)用工具當中的一個轉(zhuǎn)變,對人的影響是非常大的,工程師關(guān)心的不單是 CPU、MEMORY,關(guān)心的是全鏈路業(yè)務(wù)上面的用戶反饋,要有工具能看到結(jié)果長什么樣子。產(chǎn)品經(jīng)理也要有能力自己取數(shù),要有 data sense。

這樣,數(shù)據(jù)科學家和數(shù)據(jù)分析師不再是取數(shù)工具了,而是可以去做數(shù)據(jù)分析,找到驅(qū)動數(shù)據(jù)變化的深層原因。

最后數(shù)據(jù)應(yīng)該是公開的,應(yīng)該是能覆蓋到盡量多的維度,數(shù)據(jù)的生產(chǎn)者和數(shù)據(jù)的消費者應(yīng)該是一體的。我想知道,我做了這個功能有沒有人用,有多少人用,用得好不好,這才是最大的驅(qū)動力。

變化 3:職責

優(yōu)秀的團隊,需要對結(jié)果負責。對結(jié)果負責很重要的一點,或者說做出成功產(chǎn)品的團隊核心是什么?叫做 DOGFOODING。

DOGFOODING 是什么意思呢?就是自己用自己的功能,自己吃自己的狗糧,或者狗屎。自己做出來的功能,首先自己要先用起來。

在 Facebook 有幾種簡單的工具去支持大家快速做用戶側(cè)嘗試,哪怕是只給自己使用嘗鮮:

●一種是 gatekeeper。通過在 gatekeeper 上設(shè)置過濾條件,對一小批用戶做測試。

●另外一種是 AB 測試,切 10% 的用戶嘗試新功能,另外 10% 的用戶最對照。

那工具為什么可以讓大家變成對結(jié)果負責呢?原因叫做賦能。因為有能力,所以有擔當。

除了靠各種 CI,Canary 工具以外, gatekeeper 和 AB testing 也可以讓你小流量去實驗,實驗個 5000 用戶,覺得沒問題,再放大,用這樣的工具去輔助這樣的權(quán)力。

總結(jié)來說,在互聯(lián)網(wǎng)時代,為什么 Data driven 和 ownership 可以提供 10 倍的效能差別?因為在大目標對齊的情況下,各個小團隊之間可以組成一個分布式的決策機制,大家可以跨職能的團隊協(xié)作,去中心化進行決策,做到面對不確定性時的敏捷。

小紅書的實踐

最后我們來看一下過去這兩年,對于效率,我和我的團隊一起在小紅書的一些真實的實踐。

小紅書是一個生活方式平臺,里面涉及到衣食住行,吃喝玩樂,并且可以完成從發(fā)現(xiàn)到?jīng)Q策到記錄的全鏈路流程。

我們是一個面向用戶、有豐富數(shù)據(jù)的平臺,這是我們產(chǎn)品上的天生優(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 流程,就上到線上,這是對于工程權(quán)力的下放。

第三點,實驗賦能。我們現(xiàn)在線上 AB testing 平臺一天有 300+ 個實驗,也就是說我們每天在嘗試的新功能有 300 多個。AB testing 就是應(yīng)該犯錯的,AB testing 就應(yīng)該是 10% 的成功率才對,或者更低,代表實驗的效率更高和跑得更快。

我們剛才討論這些關(guān)于效率的話題,在小紅書團隊里面都有所實踐并且一直在進步。我能看到工程師、產(chǎn)品經(jīng)理、數(shù)據(jù)分析師在團隊里面效能的變化,效率成倍的激變。

我們大概在今年年初的時候,我們整個的用戶突破了 1 億,現(xiàn)在已經(jīng)超過 1.5 億。小紅書所有核心指標都是一年 4 倍到 5 倍地指數(shù)級增長。

我們就是一個從十來個人的團隊到 100 多人的團隊,QPS 從百到萬到十萬,去撐起了這么一個每年 5 倍左右的核心 metric 的變化。

那么從硅谷到中關(guān)村到底有多遠呢?

在小紅書,我們其實就是為一線團隊做兩件事情,一個叫做放權(quán),一個叫做賦能。

放權(quán)的意思是通過 Data Driven 的方式給予決策權(quán)的分布式下放;賦能的意思是通過工具,無論是測試工具也好,CI 也好,實驗平臺也好等等這樣的工具能讓團隊每個人有 ownership。最后,歡迎大家加入小紅書團隊,來一家高增長的公司高效率地做事情。

姚旭,小紅書社區(qū)技術(shù)負責人,端到端地負責小紅書的社區(qū)功能,包括大前端,搜索、推薦、基礎(chǔ)架構(gòu)和相關(guān)的機器學習系統(tǒng)。 加入小紅書前,曾在 Airbnb、Facebook、知乎和百度等公司擔任首席架構(gòu)師和主任工程師職位。小紅書是一個擁有1.5億年輕用戶的生活方式分享平臺,2018年6月,已完成超過3億美金的D輪投資,估值30億美元。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。