從Airbnb的資料文化與組織架構,學習企業推動數據驅動轉型的方法論

Views by Airbnb

寫作動機

我們都知道,走過了平台、交易時代,未來data可以變成一個非常具有競爭力的的優勢,在Airbnb創始之初就曾經因為創辦人對資料的熱情(建立data team以及建立組織的資料文化),讓許多工程師投入Airbnb的懷抱。藉由這個Case,我們可以學習到頂尖的科技獨角獸是如何從零到無限的建立資料科學文化。並且將BI人員從取數、拉報表的任務中解放出來,讀完這個案例,我想大家會更理解為什麼頂尖的資料科學人才都希望能到Airbnb工作,因為在這裡,你可以享受在解決「面對世界最前沿的問題」的過程裡,同事之間、跨部門也可以學到很多,這樣的工作環境是多麽美好,而這其實也跟推動資料大眾化息息相關,就讓我們一起來看這篇案例吧!

資料問題的緣起可以靠寫文章解決?

標準文件是否為商業巨獸的韁繩?

Airbnb,也就是「小團隊,沒人見過的服務」這在當時的矽谷是一件很浪漫的事情,畢竟你可以在穩固的資料基礎上快速試錯、修正自己的假說,當你穩定命中一件事情,科技與資本又會將他推成一個big things,對於能享受到資料所帶來的影響性絕對是資料科學家感到最開心與成就感的一件事情。

剛開始的增長也是飛快,任何得到的洞見看起來都非常具有開創性,也因為團隊規模還小,所以任何人都可以在這個data driven的loop裡面快速前進。不過五年過後,隨著這家公司慢慢成長為一個獨角獸,達到43000倍的增長,此時的資料科學就更加複雜了,這時候的課題為「如何使用早期的高速成長來駕馭這間規模大到難以控制的商業巨獸?」,而他們的解決方案是:

寫blog,讓其他人了解資料科學團隊目前處理的課題

問題要足夠具體,不過答案可以just an overview,因為撰寫blog的目的在於「讓其他人了解data team目前在做的事情」,Data是如何幫助目前的Airbnb的?如何幫助管理層下一個數據化的決策?這個高層的決策又是如何影響大家的工作?

所謂的資料不是數字與編碼,是人

商業資料不只限定於格式與非格式,他是顧客的聲音

在過去,所謂的資料往往是指那些冷冰冰的數字,完全就是建立在「可以測度」的標準工具,而這樣的認知對組織有什麼影響呢?就是他直接影響了「資料科學家的工作」,如果公司其他人士都將資料當作數字,那麼資料科學家能做的事情只限於「統計與報表」、「幫忙撈資料出來」,此時資料科學家所面對的「挑戰」就是基於資料的需求與事實,好比「我們在巴黎有多少訂單?」、「台北最熱門的10個名勝是哪些?」

當然,回應業務人員的資料需求以及統計報表絕對是商業智慧工作的一部分,但是在Airbnb更傾向於「將資料當作顧客的聲音」,一筆資料就是一個交易紀錄與行動,它反映了顧客的決策過程,如果我們可以將這些資料都重組,還原出一個決策序列,那麼我們就可以學習到:這個人喜歡與不喜歡的是什麼。而這些意見會變成決策的金礦,可以被應用在其他業務如:社群增長、產品開發、資源優先配置……. 但是要達到這些商業行為,妳就必須要能夠將資料換成information,所以這時候大家對資料科學家的認知應該要是「顧客行為的翻譯與解讀者」,他們將顧客的聲音翻譯成一個決策因子。

此時資料就變成一個很好的助手,資料科學家用統計指標等等去了解個別的行為、總體的規則,並且將用戶的行為趨勢表達出來,告訴決策者哪邊會成為key driver。Airbnb花費了好一段時間利用撰寫blog的方式,讓所有人都逐漸了解資料團隊不只可以回應他們對資料的需求,還是一群開採資料黃金的專家。

主動找需求 v.s. 被動接受

透過深入合作,專心在資料專案上

一個好的資料科學家能夠及早洞察夥伴的需求,否則光做「分析」自嗨其實沒太大意義,他們利用深刻的商業洞見去試圖影響公司的產品、決策,並且追蹤這些分析是否有效。

有一個很大的坑是當專案期間過長,資料科學家們傾向於分析「分析結果」然後轉換到下個問題去,也就是「事後諸葛」,當他們花費了很大量的時間在做統計驗證、保證結果可以受到解釋與足夠說服人,這些事情讓他們的分析變得像是「無聊的事後檢視」,也就是你會回:「我早就知道了!做什麼分析?」畢竟業務都還是業務人員做出來的,此外如果遇到決策者並不了解你的insight,或者不對分析報告做什麼行動,分析與洞察都會變得毫無價值。要避免這些情況的最好結果就是「確保分析與商業決策是吻合的」,那怎麼做好這件事情呢?這就牽涉到data team的組織架構了,目前的資料團隊組織架構其實分成兩種:

  1. centralized:獨自設立一個部門,好比國泰金控的數數發、玉山金控智慧金融處
  2. embedded:嵌入類型,跟隨業務、相關領域人士一起做專案,協助資源資料工作

其實絕大多公司都是雙者並行,包括Airbnb也是如此,一開始他們是採用集中化資料團隊,畢竟在組內的每一人都可以專心在指標、方法論、演算法、過去的資料科學專案知識上,但是馬上就遇到一個問題:「其他部門不曉得該如何與資料科學團隊合作」,同時資料科學團隊也不曉得商業問題的背景、該如何讓這個問題的解決方案具體到變成下一步行動?甚至聽不太懂業務人員的需求。而這段時間,團隊很理所當然變成一個「資源」,被動接收統計查詢、報表製作、撈資料的需求工作,而不是主動地提出數據分析的專案。

於是,Airbnb著手調整了組織架構到混合類型,還是維持資料中心的運作,但是拆分成許多小team跟工程師、設計師、產品經理、行銷人員等等合作,這麼做的結果是「加速了公司整體對資料的接受程度」,並且將資料團隊的人從一個資料庫管理變成主動分析的合作夥伴,而保持資料集中的好處,也讓公司在面對不同問題時,能夠保有對資料模型本身的理解,將一個看似不同的問題回歸到解決過的問題,並且共享解決方案。

顧客驅動決策

data = customer voice

組織結構是邁向強而有力資料科學公司的一大步,但是故事到這裡還沒結束,當資料科學家已經具備將資料轉化為洞見,問題就來了:「該在什麼時候、用什麼樣的方式把這些消費者的聲音轉化為商業決策呢?」

因為先前與其他部門的夥伴關係,data team他們獲得了許多如何將資料整合進專案的想法,有些人將資料看作一個將「問題」與「解決方案」牽連的必須元素,有些人將資料看作過去的足跡、未來制訂決策的手冊……..其實這些觀點都是對的,每一次的資料解決方案,其實都在「局部優化」整個公司對於資料的使用程度,而一次次迭代優化,可以使得公司朝向「全局優化」走,這也使得團隊、上到整個公司為了對應這些「大量的資料專案」,制訂出一套決策流程,縮寫為LPTM。

LPTM ,增強決策品質的專案流程

LPTM, decision process of Airbnb

這邊的LPTM是代表我個人對Airbnb這套流程的理解,並不一定是作者與Data team原本的意思,因為在我閱讀完之後發現與Mckinsey consultant在想事情的角度如出一徹,有興趣的人可以閱讀原文(最下方連結),或者對照「麥肯錫教我的思考武器」這本書來檢視。

Learn

學習問題為什麼發生的前因後果,每當遇到一個新的問題,利用過去累積的專案經驗來檢視這個新的問題,並且評估「這件事情值不值得被解決?」(問題的solution帶給我們的價值大不大?)、並且針對問題產生假說。

Plan

根據對過去專案的review,可以協助我們排序解決方案的優先順序,並且設計出一個「解決問題後的畫面」,也就是對於解決問題的成效。比如說在德州的團隊遇到跟過去相似的問題,舊金山地區如果有過類似經驗,德州團隊可以藉由審視過去在舊金山的成功經驗與「踩過的坑」來制定一個Success Metrics,並且分析這個問題的關鍵解決點在哪

Test

當計劃開始與執行,團隊會執行大量的商業實驗,比如A/B testing就是一個很常用的方法,而且這個A/B testing「並不限定於軟體上」,因為整個公司在上個階段已經體驗過data team與其他Business、Operations合作的經驗,現在的測試可以直接利用營運端來執行並回報。

Measure

實驗結束,data team會評估這次的實驗成效有沒有符合我們的假說、思考因果關聯,如果實驗成功,就可以套用到整個公司,如果失敗,那就回到假說階段,並且迭代整個流程。

有時候這整件事情是很直覺的,問題就是一個「直球」。

比如問題如果很明顯:「App這個按鈕的調整導致點擊率跟原本的也差太多了!」,畫出來的柱狀圖差距很大,這時候其實就不太需要上面這個繁複的流程,但相對的,因為這種「乏味的問題」實在太多太多了:

data team的做法是希望「不管任何細小、看起來乏味的明顯的問題,都用這套方法論去執行」

畢竟越用越熟悉,如果今天這套流程被持續遵守、不需要你額外判斷「該不該使用這套決策流程」,而是處理任何情況,讓所有人更專心在理解這套流程與原則,每個人解決問題(特別是資料問題)的能力就會越來越好。

就我的觀點,我覺得「要求大家使用與遵守組織的決策流程」這件事情的效益很直覺,畢竟學習很大一部分是靠自我輸出,如果今天反覆使用這套流程,自己對於解決問題的能力也會更有自信,而站在管理的角度,讓員工的注意力轉到「問題」、避免「該不該使用」的多重標準,這也是一個很成功的組織文化案例。

資料科學大眾化,組織擴張時該怎麼面對雪片般的問題

decision scale scheduling

上面的案例看起來很美好,但是這時候資料科學團隊又遇到一個問題:「成長所面臨的問題、決策數量實在太多太大了! 」尤其在2011年,Airbnb開始跨國擴張,一年前甚至還只是舊金山的一家小型新創而已,當時的確是可以緊密的合作,然而短短半年間,組織擴張包含行銷、產品、客戶服務等等部門的人力增加,使得「讓資料科學家與每個人互相密切合作」似乎變得遙不可及…不對,是根本不可能!

這時候的問題變成:「怎麼樣讓每個人與資料科學家合作?」,因為問題就出在「每個人」的基數實在太龐大,Airbnb的解決辦法就是「讓每個人都變成小小資料科學家!」,也就是推動資料普及、大眾化。此時的合作關係也希望不只建立在交互的個人,還包含整個團隊、公司、社群。

這時候投資科技、建立內部自有的資料處理工具,也就是data product就變得更加重要。

如何推動資料普及的文化?

這裡Airbnb給出了三個具體的解決方案:

投資與建立資料處理工具

比如資料越來越大,需要一個快速、交互式的介面來讓團隊管理資料,這時候ETL 工具就很重要,也是在這個時候產生了後來廣為人知的Airflow(工作流管理系統)。

airbnb開源的airfow

EDA(探索性資料分析)的任務交給每個人,除了資料科學家

將資料分析與其他團隊的隔閡解除,data team設計了一個BI Dashboard(商業儀表板),如此一來資料科學團隊可以更專心解決比較困難、影響性高的任務,並且他們開發了一個從資料倉儲裡面下載資料的工具Airpal,同時教學與分享資料科學團隊怎麼閱讀、解釋資料,讓大家學會工具與方法,移除掉資料處理的障礙,讓每個人都可以變成資料分析師。

這件事情也讓資料科學團隊更好地從拉報表、統計資料等routine的request解放出來,可以更專心在解決專案類型上的資料任務。

airpal

讓客戶(房東與房客)透過資料更好理解彼此

比如房客可以看評價、文字資料、推薦資料來思考要住什麼樣的房間,而房東可以透過Airbnb開發的資料產品優化自己的服務,透過回饋改進房間品質。

下一步,就是讓大家都理解「這個上線的模型到底是什麼」,也就是模型的普及化,並且讓每個人都可以建模。目前Airbnb還在朝這個「模型普及化」的方向努力。

註*Airpal與Airflow都是放在Github上經由Airbnb提供的開源軟體。

終章,資料科學的持續優化精神

截圖自airbnb官網

接近10年了,資料科學團隊在持續的進步,透過與決策者的互動、推動資料大眾化的文化,做了這麼多事情,我們該怎麼解讀成效呢?

評估一個資料專案的成功其實是很困難的,其實Airbnb的資料團隊在目前也沒有一個很固定的方式來評估說「這件推動資料大眾化」的成效到底如何,但是就事實而言,他們讓每個人都參與進決策流程,使得資料團隊的其他人不再受到統計、聚合等報表工作束縛,而是可以專心在提供資料科學的諮詢以及優化上。

還有一個事實是,團隊越來越能掌握因果推論以及行動所造成的影響,拜功於整個公司遵守標準決策流程以及大量設計線上線下實驗。這對於Airbnb這樣一個複雜的生態系來講其實是很驚人的,畢竟它代表了一個網路效應極強的雙邊市場,旅遊產業的特性包含高度的季節性(可能就過節才會旅遊)、不頻繁的交易(呼應到前一句),不過也因為這些特性,使得資料團隊可以面對到很前沿的、令人興奮的挑戰,即使工作了這麼多年,還是可以不停探索資料團隊解決問題的能力與濳力。

現在的Airbnb可以保證有不斷電的、穩定的機房、有齊全的資料工具與產品,資料倉儲非常的乾淨與穩健,有了這些後援,在面對更新的數據分析與建模挑戰時他們可以更無後顧之憂,包括即時性處理資料、開發一個更穩定的異常檢測系統,加深他們對於網路效應的理解,然後,更了解每個客戶,包括房東與房客,這世界上的所有人。

Airbnb的下一步會怎麼走呢?沒人知道,但很肯定的是,他們必然會跟隨資料 — -顧客的聲音來源,緊跟在後。

我的觀點

從學界走到業界,我發現大部分的公司還是停留在這篇文章早先描述的「DATA Early」,許多公司的資料部門對於其他部門的人而言,還是一個「管理資料」的角色,合作模式通常僅限定於「我需要XXX的資料,幫我撈一下!」

目前更多的痛點是公司在「資料科學發展的時空穿越」,他們跳過了建立業務人員與資料科學家合作模式的建立、資料大眾化文化的培養,而是直接來到比較晚期的階段「發展人工智慧」,但是就連很基本的「將資料團隊從拉報表的角色中解放出來」都沒有做到。或者說平行而立,讓資料人員一下開發工具,一下被拉去做模型,所以許多公司的數位轉型失敗,就在於不夠清楚規劃整個資料科學建立的邏輯。

而當大家對AI的信任降低,就是造成AI泡沫的緣起,投資了這麼多卻沒有辦法做到預期的成果,不是泡沫是什麼呢?有的時候並不是資料科學本身的方法不好,而是我們沒有辦法充分利用資料與正確推動上到組織變革的文化。

這也是很可惜的一點,希望透過這個案例,我們可以學習到矽谷在科技與培養管理文化的精神與方法,並且一步一腳印,這樣面對將來挑戰時才可以從容不迫的利用資料,沈浸在「面對最新的問題」裡。

參考資料:

歡迎想學習Python資料科學、商業分析、金融知識的人一起交流!本部落格的內容全部都是基於「分享」的實作、理論兼顧文章,希望能夠幫助到所有對資料科學領域有興趣的人們,長期關注可按左手邊的Follow!若喜歡我在 Medium 的內容,可以拍個手(Claps)這邊想做個實驗,好讓我知道你/妳喜不喜歡這篇文章:
拍 10 下:簽個到,表示支持(謝謝鼓勵!)
拍 20 下:想要我多寫「商管相關」
拍 30 下:想要我多寫「資科相關」
拍 50 下:我有你這讀者寫這篇也心滿意足了!

敬請期待下一篇!或是您也可以逛逛我的其他資料科學文章:人工智慧商務系列:

Python資料科學系列:

看我用金融的概念解釋AI:

如果想跟著我實作資料科學,開始寫程式必知必會基礎系列:

--

--

戴士翔 | Dennis Dai
Finformation當資料科學遇上財務金融

外商分析顧問,Ex- Apple Data Scientist,曾在FMCG巨頭/日商管顧/MBB管顧/高成長電商從事商業分析與數位轉型,專注分享管顧、商業、數據分析的思考。分析/演講/合作歡迎來信:dennis.dai.1011@gmail.com