餓了麼“短平快”創新專案的架構取捨之道
(點選“ 此處 ”可獲取史海峰演講完整PPT)
講師介紹
史海峰, 餓了麼高階總監 ,曾在神州數碼、亞信聯創長期從事電信行業業務支撐系統整合工作,參與移動、聯通多個專案,具有豐富的大型業務系統研發實施經驗。曾在噹噹負責總體架構規劃、技術規範制定和技術預研推廣,並負責技術委員會組織管理工作,發掘最佳實踐、推動技術革新,組織內外部技術交流。 負責餓了麼技術創新部,2017年推出NOW無人貨架,切入新零售風口。
大家好,我今天的分享主題是“從0到1:創新專案架構取捨之道”。大概一兩年前,餓了麼的CTO在會上問大家,你們覺得像餓了麼這樣級別的網際網路公司,最重要的資產是什麼?作為一個技術領導者,有沒有考慮過這個問題?到底是資料、程式碼、客戶、人才、系統?其實到最後會發現每一種資產都很重要,還有創新能力也非常重要。
我今天也會提到一些這方面的考慮,主要內容是以下四點:
-
創新專案從0到1架構演進策略:一個專案從0到1,你要上來就搭個大的架構還是慢慢來?顧慮是對手可能比你還敏捷,中間有很多環節顧不上,別人上的我也要上,那怎麼辦?
-
成熟技術體系中如何快速創新:餓了麼這麼大一個公司,已經擁有成熟的體系,如果想做一些創新,怎麼才能實現?
-
敏捷迭代中的技術債如何償還?
-
技術怎麼與創新業務齊頭並進?這兩點都圍繞技術問題展開,情況是開始可能技術不夠成熟,後面功能越來越豐富,資料越來越多, 是不是可以做技術驅動業務的事情?
一、案例引入
我們用一個案例來分析:去年餓了麼做了無人貨架這個業務,無人貨架是2017年新零售行業的一個風口,很多公司的辦公室裡面都有。去年的9月份開始,到現在不足一年,所以還有很大的發展空間。它的作用是放在辦公室裡面,如果你餓了,想吃點什麼喝點什麼,走過去掃碼就可以。
為什麼它是新零售的風口?跟你在路邊買水果直接掃碼有什麼區別?我們展開來講:
-
無人貨架模式定位在辦公室裡,這是一個封閉的公共空間。如果想吃飯可以叫餓了麼,但是想吃點零食或者喝點水,無人貨架三十秒之內就可以拿到手,而且不用考慮我什麼時候去買去囤,因為隨時都可以。
-
貨架面對空間裡這麼多的人,核心問題是怎樣最大程度地滿足需求,以及在此基礎上是否能給一些新的口味。甚至再進一步,在這些流量上能不能做一些拓展,架子上沒有的東西是不是也可以賣,比如新鮮水果。很多公司可以看到有冷櫃和熱櫃,熱櫃負責保溫的,標準化的場景是可以熱乎著吃,放個豆漿、包子等。所以無人貨架是一個很好的零售業務場景。
-
我們可以對接企業的需求,比如老闆看大家挺累,我們來喝個下午茶,買光架子上的零食水果,大家隨便吃也沒多少錢。所以這個模式有很多展開空間,未來行業裡,會有更多的玩法。
二、創新專案從0到1架構演進策略
去年8月6日業務團隊提出要試水專案的時候,我們知道一些創業公司做的風生水起,甚至一些大公司比如京東、順豐、蘇寧都已經開始進入這個領域,包括後來的獵豹。這個業務上我們是後來者,後發優勢就是你知道別人是怎麼做的,但面臨的壓力也很大。試水期間(8月6 日 ~23 日 ),我們做了商品調研、業務場景調研,也提了一些解決方案,跨部門協作開發,還做了Demo在公司裡試用。
9月6日無人貨架專案立項;9月20日V1.0.0產品正式上線。整個過程看起來還比較順利,業務總體反饋也都比較好。但是當時這個專案沒有任何後端體系,比如營銷後臺、運營後臺、供應鏈等,就是業務團隊去買一堆貨,自己往上面放,這種模式完全不可控,不具備擴充套件性。
11月20 日 ,我們打通了餓了麼當時原有的供應鏈系統。到今年3月5 日 ,對接餓了麼新零售地網供應鏈系統,採購倉儲物流這些都打通了。CRM、預售、拼團、鮮食等都是今年上半年我們做的一些拓展嘗試,下一步也會做智慧貨櫃。
三、成熟技術體系中如何快速創新?
我們說一下成熟體系和創業公司的區別是什麼。
餓了麼擁有一個大型、成熟、彈性、多活的技術體系。日訂單量千萬級別,整個技術團隊上千人,系統指標要求很高,所以基礎設施必須完善,不可能靠人力天天操作;架構設計有嚴格的評審機制和一套規範的操作流程。2017年餓了麼做了一個行業比較牛的“異地多活”,在兩個機房之間可以排程流量,並做日常演練。最後就是容器化、混合雲、計算力外賣等,這些關鍵詞大家可以網搜一些文章瞭解一下。面對這樣的體系,我們剛才說的無人貨架這種短平快小專案如何應對?
分析一下其中優劣:
-
首先要求一定是快,而且需求可能變。今天這麼玩,明天一拍腦袋那麼玩,即敏捷迭代,快速試錯,靈活響應。你不能跟他說你能不能有點譜,因為大家都不知道該怎麼玩。那優勢在於餓了麼有非常完善的機制,高水平人才充足,比如我們想成立一個團隊,拉起來很容易。業務立項會分到某一個技術團隊,前後端測試、專案管理等的磨合過程中,團隊配合度已經很好。不必從0到1建設一個新的產品技術團隊。
-
但是劣勢就是我們有太多條條框框,由於餓了麼體系很大,架構規範嚴格,不可能自己再做一套使用者體系,不可能自己做支付,一定得對接公司的。那就得跨團隊溝通。做這樣一個試水的創新專案,跟公司整體專案的級別一定是不匹配的。有時就是需要去刷臉,才能把這些提上去。
-
最後,如果我們今天資料出了一個bug,想把資料修 一下,不行。按照嚴格的操作流程,這個事情不能你去操作;而且要進行評估:風險有多大,一次要多少條,會不會對效能有影響。這個時候可能業務團隊已經忍不了,所以其實是優勢劣勢並存的。
我們要把這個事情做成的話應該怎麼辦?首先得有一支能打的團隊:召之即來、來之能戰、戰之必勝。我們搞的是一個獨立的專案,全新的系統,但是所有參與專案的人,都是從各個團隊拉過來的。 團隊都坐在一起,在“小黑屋”裡,環境相對來說封閉,能更專心,更高效,更團結一心。 以創業的狀態進行,把所有的任務都排好然後開始開發,最後所有的任務都是完成狀態。
上帝用七天創造了世界,我們最終用六天把這個專案做好了。期間有什麼事情?除了剛才講的攢人,還有對架構的取捨。
-
微服務: 雖說一開始沒有那麼多要拆分的微服務,但是畢竟是網際網路主流架構,要把系統做得特別靈活,為了能拓展。但也不需要考慮那麼遠,所以有考慮,以後再說;
-
技術棧: 餓了麼現成的拿過來用,大家都熟,再選擇其他技術棧是不太可能的;
-
自有的IDC: 很多創業公司都是在阿里雲上做起來的,我們當時也考慮說是不是乾脆找個阿里雲。阿里雲都在自己手裡頭,想怎麼玩怎麼玩,不用關心公司的條條框框。但是最後想了一下,還是要用自己的系統。因為比如你要跟公司的使用者系統、公司的使用者系統、支付系統打通,你不能說我外掛一下,除非自己做。不能自己再做一套基礎的體系,成本太高了。跟很多創業公司不同,他們往往資料庫只有一個,反正使用者資料少,能活著就行,但我們在一個體系裡面,這些技術是現成的,我們要用;
-
異地多活: 有沒有必要呢?有必要,但是暫時可以繞過。因為我們一般切換服務的時候是在晚上,是有人在辦公室甚至熬夜到兩三點鐘會用無人貨架,但是畢竟不是常態。我們先不考慮多活,因為實現多活更復雜;
-
中介軟體: 一定是公司現成的,包括資料庫的中介軟體,資料的備份等;
-
測試環境: 也是公司現成的,同上;
-
持續部署: 需要知道誰發了什麼版本,而且要有工具想回滾就能回滾;
-
容器化: 暫不考慮, 我們直接來臺虛擬機器當成裸機來用也OK,容器化有更高的技術複雜度,我們現在只要做一個簡單的業務跑起來;
-
日誌監控:日誌監控這個體系是公司現成的,對當前的業務有很大幫助。當時我辦公室的電視上接了個監控檢視,有天早上一看,業務量爆增,我說這一定有問題,查了一下發現有人在爬我們的資料,這種情況如果沒有監控,你根本就不知道。
四、敏捷迭代中的技術債如何償還?
同樣的我們欠了很多債,下面分析一下:
-
業務層: 包括一開始只是設定價格就進行銷售,沒有做營銷、促銷,運營的策略等。 比如說在不同架子的相同的位置上擺不同的貨,這些都是後來做的,一開始沒有考慮,都是放上去就OK。供應鏈,業務級的監控,許可權(運營、業務操作等這些許可權),一開始也沒有做那麼多,是後來補上的;
-
應用層: 反爬、埋點、快取、搜尋、多活等這些也是這樣。多活,剛才說了,影響不大但是是有影響的;
-
資料層: 我們一開始對使用者的行為資料沒有埋點收集(比如,他進來瀏覽了多少東西然後跳出了,或者他點了什麼是不是失敗的),當時沒有考慮那麼多。但畢竟有個基礎的東西在,比如最後一個爬蟲,我們做好了也可以爬別人,看看其他公司的怎麼樣;
-
系統層: 容器化暫時不用。
對於現在這個架構,我們做的取捨其實是一種選擇,以最快滿足業務上線,具備基本功能為目標,而不是一拍板就定了。
五、技術怎麼與創新業務齊頭並進?
再往下延伸,要考慮幾個問題:
-
調整策略,從突擊隊到正規軍: 現在我們已經有上萬的點位,已經有穩定的業務,那後面如果想怎麼著就怎麼著,想怎麼變就怎麼變,想怎麼玩就怎麼玩,想怎麼抓資料就抓資料,這個一定是有風險的。一開始,從0到1搞起來,這個階段有點損失沒關係。但是一旦業務、技術、運營都是穩定團隊的話,就需要轉換你的戰略。不再用突擊,要用正規軍的方法;
-
控制節奏,提高協同效率: 我們會調整我們專案的結構,提高協同的效率,大家提前做溝通,做一些規劃;
-
合理分配資源,償還技術債;
-
架構規劃,模組拆分;
-
沉澱資料,智慧運營: 把這些資料收集起來,一個業務沒準兩三年以後能有更大的市場,那這些資料沉下來就是有價值的。比如前兩天餓了麼就在準備重啟一個去年被停掉的專案,那個專案之前運行了大概兩年,一旦老闆決定重啟,我們所有的程式碼、資料都還在,可以隨時使用。不過要想重啟,可能最大的問題是人,就是原來那些人去做其他專案了,有多少人還留在這個團隊都不好說。但資料程式碼的資產都還在,很快就能拉起來;
-
做減法,保持架構健康度: 之前做這麼多需求,業務團隊有這麼多想法,現在都還有用嗎?不見得。很可能一個東西上來之後發現使用者不買賬,但它還是系統的一部分,依然天天執行著,還要考慮他的運維等,這時候做減法更能保持架構的健康度。
六、總結
所以總結一下:在風口創新裡面,快一定是第一位,天下武功唯快不破。既然技術要去支援業務,那絕對不能拖後腿;但從0到1並不需要想那麼多,以MVP為第一目標,不追求技術先進、架構完美。
還有,既然我們是一個比較成熟的體系,而且相對來說更有經驗,那麼我們要適度地前瞻一些。把產品、把架構設計得稍微好一點、靈活一點,將來拓展就不用改太多,不用推翻了就要重來,然後針對不同階段、不同策略,適時做一些調整。
最後,技術上,先支援業務,深入理解業務,再驅動業務。一開始業務人員讓你幹什麼你就幹什麼。 接下來你還要深入理解,然後才能和業務的同學平等對話。如果業務是比較輕量級,2C的,這種情況下大家要互相溝通。如果你已經做的量級非常大,可能從業務、從運營的角度來講,難以瞭解全國情況,比如我們做的O2O,基於地理位置不同,各地都不太一樣。全國各地業務什麼特點這都不好說,需要有一個強大的體系把資料收集起來,去做資料分析,去做策略指導業務,而不是靠一個人即興的想法。所以我們要做到更好,就需要更多的資料,根據這些資料來分析使用者,可以去看我們業務的趨勢,能做一些更好的指導,接下來可能成為用技術驅動業務。不是說用人員驅動業務,而是一套比較大的系統,這個系統能夠驅動業務,把公司業務能力固化在體系裡。
最近一個在政府單位工作的同學和我聊起創新,創新很重要,但更重要的是有沒有一個合理的體系,換句話說就是不能指望某個人力挽狂瀾,不是一個有志之士想激發創新,就能創新。要靠一個公司或者一個組織,要有活力,要能保證多樣性,要能夠實時變化,這需要一套體系。所以在座的各位手裡都有那麼多資料,希望我們可以給後面的人留存更多的資產,能給我們後面的業務給予指導和幫助。
Q & A
Q1: 快速迭代的時候,你的時間有限,像這種時間控制裡面有什麼東西?
A1: 沒有更多的選擇,但是一旦你迭代的節奏調整過來,每個迭代多少大家都是有數的,而且一個比較好的團隊有這個優勢,開發一定要自測。
Q2: 貨架的資料是從哪些維度進行收集?
A2: 比如登入網站,或者開啟一個APP,你是在什麼樣的環境下(4G、3G、WiFi還是其他的),還有比如你使用什麼樣的手機、登入進來之後你先點了什麼,這些都是可以記錄的。最常見的, 如果你前面的頁面做得不那麼友好,可能使用者找不到他想要的東西,因為手機螢幕很小,需要翻頁,那麼怎麼翻是合理的?一定是按照貨架上的順序嗎? 不見得。一開始大家都在乎貨架上的順序,從上到下第一層、第二層、第三層、第四層,但是我可能上來就想拿最底層的。或者說如果有促銷,那把促銷的東西放在最上面,讓人看到,給他引導。這些東西可以通過你的佈局操作,但前提是有資料,你才能進行設計,不然你不知道他是不是按照你預想的來做。