阿里巴巴 CTO 的修煉——商業和技術的共同進化
作者： 2022年04月27日 來源： 瀏覽量：
字號：T | T
程立,花名魯肅,2005年加入支付寶,是支付寶技術平臺奠基人之一。他也是阿里巴巴招收的第一位博士生,現任阿里巴巴集團CTO。
本文內容來自湖畔創研中心的一次技術高管的培訓交流,過程中魯肅非常坦率地探討了一位合
程立,花名魯肅,2005年加入支付寶,是支付寶技術平臺奠基人之一。他也是阿里巴巴招收的第一位博士生,現任阿里巴巴集團 CTO。
本文內容來自湖畔創研中心的一次技術高管的培訓交流,過程中魯肅非常坦率地探討了一位合格 CTO應該具備的素質,以及他自己一路摔打成長的心路歷程。
文 /程立
本文摘自《云棲戰略參考》第2期
我的經歷
我的經歷很簡單,2004年之前一直在學校讀書,讀到 30歲。2004年跟著一個師兄做外包項目,為淘寶網做一個重要的架構升級——把原來 PHP/MySQL架構換成 Java EE架構。2005年 2月份正式以實習生身份加入支付寶。
2005到 2014年,我主要的崗位是支付寶架構師。2013年,當時螞蟻的 CTO要回美國,螞蟻當時的 CEO彭蕾找我談過話,我當時對帶這么大團隊完全沒有信心。我最沒有信心的不是帶技術團隊,而是 CTO另外一半的職責,作為公司經營管理的一部分,怎么跟 CEO對話。
前任 CTO會在公司管理會議上和業務吵得面紅耳赤,我覺得我做不到。后來王堅博士約我去喝茶,他說沒有關系,每個人都是不一樣的,但是每個人都能用自己的方式解決問題。這給了我信心。
于是,2013年我開始帶支付寶整個技術團隊,經過一年的考察,在 2014年公司任命我為螞蟻 CTO,2014年到 2019年我一直在這個崗位。
2018年,公司發現技術確實會對在某些業務起到更加關鍵作用,需要更強的技術背景同學進入業務。當時對技術有很強需求的是螞蟻的國際業務,就讓我做了兩年螞蟻國際業務的 COO。2019年年底,轉任阿里巴巴的 CTO。又過了一段時間,菜鳥也需要一位 CTO,就讓我兼任菜鳥 CTO。
商業與技術共同進化之旅 @螞蟻
我挑了幾個螞蟻 CTO工作的節點,非常好地印證了“商業和技術的共同進化”。最早期支付寶非常簡單,就是要做一個互聯網的第三方支付平臺,技術只要能把業務需求實現就好了,項目最大特點就是快、輕量。
2005年,某個國際支付巨頭要進入中國,很多同事很緊張,那時陸兆禧是支付寶的 CEO。他說:這有什么可怕的,他們一個需求兩個月才能實現,我們支付寶兩天就能實現,他們肯定不是我們的對手。
到2007年,公司面臨一個技術分叉點:互聯網支付一定會成為行業非常主流的支付方式,我們已經能夠看到業務的規模,但需要做一個判斷——該用什么技術架構支撐。
支付寶最早對技術架構沒有很強的要求,什么好用就什么。我們既有非常互聯網的架構,脫胎于淘寶網;也有非常金融的架構,2005年我們敲鑼打鼓、披紅掛彩買了一臺小型機處理核心賬務。
但在 2007年我們必須做一個判斷,未來我們更像一家銀行,還是更像一家互聯網公司?幸好后來我們沒有走彎路,我們判斷未來必須要用互聯網架構去解決支付相關的問題。
于是我們決定把系統做一個面向未來的架構設計:分布式改造。整整一年時間,我們將核心交易、核心賬務、核心會員、核心支付,全部分布式化。
但涉及到一些核心技術如何解決的問題,比如在這么大的分布式系統里,怎么解決核心事務的問題——這其實不容易。
2007年某個國際支付巨頭也曾經想解這個問題,結果系統上線后宕機兩周,CTO離職。在對這個問題的改造過程中,我們也膽戰心驚,但最終還是把這塊硬骨頭啃下來了。
第二個關鍵節點是 2011年,移動業務起來了,但移動場景下支付到底是個怎樣的形態,需要做一個非常關鍵的判斷。當用戶拿著手機和商家支付時,到底用什么方式進行?
那時智能手機的格局并沒有完全定形,一些手機還沒有攝像頭。當時公司部署了很多方案,有掃一掃的,當時叫悅享拍,拍一下就能完成支付;有叫“咻一咻”的,讓手機發出聲波,商家接收這個聲音;還有靠藍牙的。幾輪下來之后,其實很多商家裝了咻一咻的設備,很多商家用二維碼,最后發現用戶能接受的是掃碼支付。
2013年,也是我擔任螞蟻 CTO的第一年,發生了很多重要的事情。我們內部起了非常多的重要項目,編號從 1號到 9號。
2013年這一年, 1號項目是網商銀行;2號項目是余額寶上線,讓支付寶業務實現真正破圈,真正做數字普惠金融;3號項目是花唄。當然還有 456,我們醞釀了很多項目,有成功的,也有不那么成功的。
這個過程對整個技術架構造成了非常巨大的沖擊,從原來互聯網支付脫胎的技術架構,開始往數字金融這個方向走。在這個過程中,我反而覺得技術正好可以發力,幫助公司技術實現變革。那一年支付寶開始正式“去 IOE”,最后一臺小型機下線。
商業與技術共同進化之旅 @阿里巴巴
阿里巴巴的技術其實非常廣,后半程的發展會以阿里云為主線。
第一階段非常清楚,就是技術支撐商業發展,從淘寶網上線開始。那時淘寶網為什么能夠贏,除了它商業上有很多創新之外,“快”也是非常關鍵的因素。在這個過程中,CTO要能在業務快速增長時,提前在技術上做布局,讓商業成長能夠持續。2004年,我做淘寶架構升級外包業務的階段其實是淘寶網非常關鍵的時期,Jave EE架構的形成對淘寶的增長奠定了非常好的基礎。
2009年有一個神來之筆——那個時間點阿里巴巴敢于判斷云是未來,敢于為云寫下第一行代碼。阿里巴巴內部很多人都不看好云,但是為什么那時候能判斷對呢?我覺得阿里巴巴有一句話說的非常好:“因為相信,所以看見”。就像電商業務也一樣,很早阿里巴巴就判斷電子商務一定是未來,先發先至,所以在很長的一段時間,堅定相信這個方向、持續地走,只要時機到來,就自然可以取得商業上的成果。技術其實也一樣,阿里巴巴很早就做了一個判斷:大數據、云計算一定是未來,后面所有發展都以這個為主線。
現在回頭來看,后面每個關鍵節點都是和云相關的。比如阿里云 2009年寫下第一行代碼后,內部找了一圈都找不到客戶,這時候 CEO就指定阿里小貸業務必須用阿里云,給阿里云一個場景去打磨,這才給了阿里云一線生機。2010年孫權是阿里小貸的負責人,后來當了阿里云的負責人。
我自己印象比較深的是 2013、2014年,經過幾年和阿里小貸的打磨,阿里云開始有一點技術了,大數據處理開始慢慢成熟。當時有一個很重要的“5K項目”,阿里云開始具備 5000臺機器大集群處理數據的能力。具備這個能力之后,公司又做了一個重要決定,阿里巴巴和支付寶所有的數據全部要上到阿里云的大數據平臺上,那時我正好是螞蟻的 CTO,我舉雙手支持——因為我知道即使不支持,集團也會按下來。阿里云也因此又上了一個臺階。
2015年,大家都聽過“大中臺、小前臺”,聽上去很牛。“大中臺、小前臺”背后完成了一件事情:把阿里巴巴和支付寶所有的基礎技術全部統一到阿里云上,這是個重大的技術變革,為了完成這個技術變革,阿里巴巴做了非常好的組織設計,讓當時的阿里巴巴 CTO行癲兼任阿里云 CTO,把技術收在一起,加強阿里云。“大中臺、小前臺”策略執行了三年,阿里云整個技術架構就非常完整了。阿里巴巴是集全公司之力支持一個技術戰略的達成。
2017年之后,這個階段用行癲的話講,是“用技術創造新商業”,開始去探索技術本身能不能成為商業的一個部分,城市大腦就是典型的由技術創造的商業。2017年達摩院成立,同樣是“因為相信,所以看見”。因為我們判斷未來一定是數字經濟,圍繞數字經濟所需要的核心技術達摩院要進行布局,無論是 AI、計算,還是芯片,都是圍繞數字經濟的核心問題的思考和布局。
2020年,我已經是阿里巴巴集團的 CTO了,我們完成了上云的封頂,所有核心業務基本都跑在云上,包括最具挑戰性的業務,比如搜索、推薦、廣告業務,云都能支撐,我覺得這是云非常大的技術進步,也是集團非常重大的技術變革。
現在我們進入一個新的時代,要把云和業務技術的邊界定義清楚,邊界就是云原生。我們未來業務應用全是云原生的應用,這是一個云原生時代。另外,云本身也在升級,就是大家都知道的“云釘一體”。
不同業務階段下的三種技術領導力
三種技術領導力,我是受到俞永福的啟發,他覺得企業發展就是這樣波浪式的發展過程:一開始要先找到一個方向,進入一個業務的軌道;如果這個方向判斷準了,企業就會進入快速增長階段;發展到一定階段,就必須要脫離現有的慣性,再去找新的發展方向——就是這么一波波的過程......
在波浪式發展過程中,技術在每個階段起的作用不一樣。在入軌的階段,CTO應該是整個公司業務一號位班子的成員,是支持一號位的二號位,班子一起看清方向,把業務帶入正軌。
一旦入軌之后,業務進入快速增長期,CTO的核心不是看方向,而是怎么做好技術,這時首席架構師會變得非常重要,技術讓業務更高速增長、加速成長,業務不要被技術拖慢增速。同時,組織設計在這個階段和技術架構一樣重要。然后不能等到業務停滯時才去判斷未來,CTO要提前判斷未來會發生什么,第二曲線是什么,設計一條未來的路線。
我是覺得整體上組織需要有兩種領導力:一、專業的領導力:CTO、首席架構師、技術總監和 VP;二、組織設計的管理領導力。CTO在不同時候戴著不同帽子,有時會承擔一個專業角色,有的時候會承擔一個管理的角色,有的時候會承擔一個戰略的角色。
很難說一個 CTO是萬能的,CTO一定有強項和短板。比如我自己,我的定位是一個工程師,工程能力是我相對比較強的一項能力,組織是我的弱項。在這個過程中,一個核心班子里需要非常好的配合,具備不同的領導力,給不同的人戴上不同的帽子。
CTO的職責
1.建立商業與技術的“共振”連接
CTO在一個公司中到底扮演什么角色和職責?
我覺得第一個非常基礎的職責,是要建立起商業和技術連接。前面講到商業和技術是共同進化的,而共同進化的過程中兩者要發生很好的共振連接。為了實現社會價值、客戶價值,企業要判斷需要怎樣的核心能力?這個判斷不是一個純粹技術判斷,也不是純業務判斷,而是一個公司核心班子共同的判斷。
這個過程中,CEO和 CTO怎么對話就變得非常關鍵了,能不能說一樣的語言? CTO要和 CEO問清楚幾個框架性的問題:一是我們公司服務誰,要把客戶定義的非常清楚;二是我們為這些客戶創造什么樣的核心價值、差異化價值;三是我們的商業模式,用什么樣的商業模式實現核心價值;四是為了實現這樣的商業模式,我們需要什么樣的能力、走過什么路徑、構建什么樣的組織。把這些問題理解清楚之后,技術就能理解業務要干什么了。
我在阿里巴巴接到任何一個新業務,都一定要對它進行新的理解,后續可能還會有多的問題、更深入的理解,但這是我做的第一件事情,這是 CTO的職責。
2.一張圖、一場仗、一顆心,愿景牽引前行
很多時候,牽引團隊往前是非常有挑戰的事情,小團隊還可以靠關系。大團隊里大部分人你都不能認識,怎么還能“一張圖、一場仗、一顆心”?這時候就需要有領導力了。
我分享幾個例子,比較有挑戰,也有很多不一樣的方法。
第一個例子,我在團隊里建立領導力的方式,是跟團隊一起定義非常清晰的目標。2013年經過一番猶豫之后,我決定接受負責螞蟻整個技術團隊的任命。當時我遇到的最大的挑戰就是和團隊之間的信任——本來大家都是平級,突然我要成為這個部門的總負責人。當時大家給我的反饋是,覺得魯肅做技術可以,但不懂業務技術。
我覺得信任是要靠跟大家一起把事情做成,甚至沒有必要讓大家建立起對領導者的認同,就看大家能不能相信共同的目標,并把目標實現。2013年,我跟團隊共識了“1234”目標:
1.公司從互聯網平臺向數字普惠金融平臺轉型,我們的技術架構怎么去支撐?需要重新定義支撐數字普惠金融新的平臺。做平臺架構這件事情,至少是我的本行,大家認同。
2.螞蟻哪些核心技術是我們今年必須要突破的?當時定了兩個核心點:一是 OceanBase在這一年能落地;二是我們要把螞蟻的平臺建在云上。
3.我們能不能在這一年大促的時候實現 3萬筆 /秒的支付?大家知道從 2010年開始,每年會有一次大考:大促能扛多高的峰值。前兩年,螞蟻都是非常吃力的去扛。甚至 2012年對團隊來說是個很大的恥辱——大促前 50分鐘系統被沖垮了,50分鐘后才恢復。2013年大家都想一雪前恥:2012年時峰值是每秒 3000筆,已經是性能極限了。我們定一個 10倍的目標實現 3萬筆 /秒!
4.因為我們的服務不僅僅是支付,還開始提供金融服務,穩定性必須像銀行一樣,甚至比銀行更穩定。我們定下可運行目標 4個 9(99.99%),之前 3個 9都很吃力。
這四個目標,大家非常認同,雖然都很有挑戰。年底的時候,經過大家的努力,四個目標里實現了三個半:完成了平臺的轉型,余額寶、花唄業務都起來了; OceanBase在螞蟻系統里落地了;做到 4個 9;但我們沒有做到 3萬筆 /秒,只做到 1.5萬筆 /秒,是 5倍的提升。之后大家開始建立起對我的信任。
我到了阿里巴巴之后,第一件事情也是需要大家聚在一起,一起定下目標。空降到一個平臺,其實很難給團隊定一個全新的愿景。如果新 CTO上來就先畫一張未來的圖,基本是不太靠譜的,還是要和團隊一起定下非常扎實的目標、一起達成目標。于是,我選擇先在云這個關鍵戰略上穩中有進,全面上云必須全部完成。二是在云之上,如何從“上云”到“用云”,把云原生做深入,將阿里巴巴中臺做深入,包括 AI中臺、數據中臺和業務中臺。另外一個目標是組織數字化,阿里巴巴雖然生于數字時代,但也需要做數字化升級和轉型,阿里巴巴數字原生商業系統和數字原生組織是去年和團隊一起確定的方向。
CTO和團隊在一起要有一個面向未來的思考,不只是當下與業務的連接。未來是什么,關鍵的路徑是什么,核心的幾場仗是什么,這是 CTO的牽引力。
3.關鍵決策,掃清前進中的障礙
CTO需要幫團隊解決問題,掃清一些障礙,做出一些關鍵的決策。在螞蟻做 CTO時,第一個關鍵的決策是技術架構往金融方向還是互聯網方向?最后決策是互聯網。第二個關鍵決策是關于 OceanBase的轉型。
2010年,陽振坤老師帶著團隊開始打造 OceanBase。最早 OceanBase還不是一個真正的數據庫,當時第一個場景是解決淘寶的收藏夾問題,需要海量數據但不需要很強的數據處理能力。但到了 2012年,OceanBase面臨一個發展決策,要不要成為一個真正的數據庫。
螞蟻團隊對 OceanBase的懷疑有合理的理由,我們現在的業務對數據庫要求這么高, Oracle那么先進的數據庫團隊打造了幾十年,才剛剛能滿足我們的業務需求。陽老師帶著幾十個人花兩年時間打造一個數據庫,能把 Oracle替代掉嗎?
我覺得王堅博士是很有領導藝術的,當時他做了一個選擇,他說:“把 OceanBase送給支付寶吧。”到了螞蟻這邊就成了我當時定的“1234目標”中“2”的部分:看 OceanBase能不能再往前發展。
當時我們采用了什么辦法呢?第一先了解清楚 OceanBase能干什么;第二,既然公司整體不能做,就搞一個小場景,在螞蟻的核心交易里切了 1%的流量給 OceanBase,讓它在 1%流量里證明能力。OceanBase也很珍惜這個舞臺,撐住了 1%的流量,最終在這一年完成了從非關系型數據庫向真正關系型數據庫的轉變。2014年我們再大膽往前邁一步,把“雙 11”大促 10%的流量切給它,讓它進核心賬務系統——賬務系統比核心交易系統要求更高。當時這個決策是有一些冒險的,但現在回頭看,正是這些決策讓 OceanBase有了不一樣的未來。
后面幾個決策也類似,作為 CTO如何拿捏好風險和穩定,是非常關鍵的。
比如余額寶上線的第一天我們就知道這個產品一定會成功,因為它的客戶價值特別清晰,讓用戶每一塊錢的余額都有收益。但我們沒有料到,它成功得那么快,一個月時間迅速就把原來準備的系統容量全部用掉了。我們自己還好,因為螞蟻的平臺已經完全分布式化了,可以快速擴容。但我們的合作伙伴天弘基金,因為老系統無法支撐余額寶這么快速的增長,擴容成了核心難題。
于是我們做了一個非常重要的決定:把天弘的系統搬到云上,用分布式架構重寫一遍,三個月內必須完成。這件事也證明了金融云的價值,金融云的業務也就起來了。
這些都說明,CTO要在關鍵決策中發揮作用,幫助團隊下決心并把握好不確定性。
4.應對風險,化危為機
公司的技術風險有幾類。
第一類,技術架構不能夠支持業務發展,這是業務不能接受的風險。但這類的風險,相對顯而易見。阿里巴巴為什么在 2009年啟動“去 IOE”,就是判斷到這個風險早晚會出現,“IOE”架構已經不能支持公司業務發展,必須去掉。螞蟻在 2010年開始啟動“去 IOE”,因為那一年“雙 11”大促讓我們看到原來架構基本不能支持業務了。
2010年的“雙 11”大促被我們稱為“人肉云計算”。大促開始,我們看到流量瘋漲,判斷白天肯定會沖破設計容量,就趕快把服務器庫存全部加進去了,結果發現還是不行,又馬上去“殺”服務,把不必要的服務全部關掉,把容量放在核心關鍵鏈路上,結果還不夠,我們又去看關鍵服務里還有沒有能“殺”的。那年“雙 11”最后幾分鐘,我們的核心賬務數據庫和會計數據庫都到了極限,還有 10秒鐘就要掛掉了。最后關頭,團隊非常果斷,把會計數據庫殺掉了。會計記賬本身很重要,但斷個幾分鐘還能承受,核心賬務不能掛,否則整個業務就全部中斷了。就這樣,2010年的“雙 11”大促是硬撐下來的。
其實后來很長一段時間,都是“人肉云計算”,人在做資源調配的事情,人來做決策判斷。這太痛苦了,這一切逼著螞蟻非常堅定地擁抱云的分布式架構,要上云。
第二類風險不是技術架構的問題,而是穩定性出現重大問題。CTO必須要判斷出這個情況,CEO一定要給 CTO相應的資源支持。
比如螞蟻的“527”。2015年我們實現了整個支付寶系統的異地多活,華南機房和華東機房異地可以做分布式交易,這在金融系統里應該是第一次。我們還特地做了斷網演練,直接把華東區域全部關掉,華南直接接管業務,結果非常成功,大家非常開心。我還給當時的 CEO彭蕾發了一個戰報,說螞蟻首次實現了異地多活,你們可以放心睡覺了,以后任何情況下系統都會穩如磐石。
2015年 5月 27日,我開車在路上收到了報警,通常遇到這種情況團隊就直接處理了,但那個報警就一直響。我就把車停在路邊,才發現光纖被挖斷了,系統中斷將近 2個小時。原來異地多活,光纖一斷,系統就切不過去了。從那之后,我再也沒有發過任何一份戰報,沒有和 CEO報過任何一次喜。
當時這個事情對螞蟻技術團隊打擊非常大,公司受到最大的打擊是客戶的信任。外面有很多文章調侃螞蟻的技術,螞蟻的技術形象和外部的信任喪失了。內部從我到整個團隊與 CEO的信任也開始出現了危機——以后再講話,別人只聽一半,因為說的話不見得靠譜。
危機也可以是好事情。“527”之后,我們做了幾件非常關鍵的事情,第一,開始跟公司溝通,我們需要在螞蟻成立一個專門的部門,叫技術風險部。這個部門就一個職責,守住螞蟻技術底盤的風險,公司額外撥 10%的技術資源給到這個團隊。也就是說,我們愿意付出額外 10%的技術資源專門確保螞蟻系統未來沒有風險,這件事情至少幫我們爭取到這個資源。第二,立刻啟動實戰演練,前面說其實我們做過異地多活的斷電演練,但這是有準備的演練。從那一天開始我們要做無準備演練,一直到今天。第三,我們確定把 5月 27日這一天作為螞蟻的技術日,螞蟻未來無論是存在 102年還是更長的時間,所有技術工程師都要記住這一天,讓我們永遠能夠記住風險。
這三件事情做完,反而讓團隊更加凝聚了,螞蟻技術的風險防控水平有很大的提升,我覺得這是轉危為機。
第三類風險,可能是 CTO和 CEO都最擔心的,一個新技術出現之后會不會顛覆原有的業務模式。不僅是很多發展中的公司會擔心,即便阿里巴巴這樣規模的公司也非常擔心。當一個新技術出現,無論公司大小,都有被完全顛覆的風險。螞蟻面對移動互聯網時代時,我們有一段時間很擔心,通過好幾年努力定義移動支付,基本上算是渡過這個危機,但當時對螞蟻的挑戰還是非常大的。當比特幣開始成為一個現象時,我們也是非常擔心的:它會不會把支付完全顛覆了? 2019年 6月 Libra出現,更讓人擔心了:全球支付會不會被一種新的貨幣重新定義,這是一種降維打擊。
這時候 CTO必須要站到一號位班子里去,幫助 CEO做判斷。每一次對未來危機的判斷,都可以觸發未來新的商業機會。大的策略是:面對任何技術風險不能只是看,要親自去試,需要公司投入一些有價值的浪費。
第四類風險,是溫水煮青蛙。技術會不會反過來傷害公司,它不像風險那么直接,但是如果因為技術、架構或組織問題讓公司效率變慢了,公司會慢慢喪失競爭力、創新力。隨著時間的推移,這是最大的危機。阿里巴巴的中臺就是一個很好的例子,中臺的優點在于可以減少很多重復建設,讓業務可以基于中臺快速創新,因為重復建設的繁忙約等于效率低下。但阿里巴巴的中臺已經非常完善了,開始進入了另外一個階段。目前,業務中臺里有面向核心電商的中臺、數字供應鏈的中臺、職能線業務中臺、數據中臺、AI中臺等一系列技術中臺。當我做一個新業務的時候,我需要跟這么多中臺打交道,需要他們去支撐我,過程中如果有任何一個中臺支持不能到位,我的業務可能就做不成。我們現在開始大力推動中臺能力進一步升級,改善中臺的交付方式,把中臺再升級。這里涉及到很多技術架構的變化。為了防止溫水煮青蛙就是要一直做系統化的梳理,再去一個階段一個階段的解決。
5.組織設計與治理——平衡秩序與創新
一個人當 CTO的時間越長,專業能力下降得就越嚴重。我判斷自己的專業能力大概每隔兩年會降一級。也有好處,你可以跟團隊一起做,團隊會更強。組織設計的核心是要既有秩序又能創新。這是有矛盾的,創新是在一個混亂的土壤里長出來的,秩序讓效率高,但會把很多創新吃掉。這個過程有點像踩鋼絲,處理秩序和創新的平衡。
阿里巴巴圍繞技術的組織,是有兩條線的。一條線是實的管理線,是分層分布的:
前臺,面向業務的,為客戶贏;中臺,是能力中心,中臺的客戶是前臺,讓前臺更加高效,讓前臺更有競爭力;底層后臺,是強調技術先進性的,確保業務永續。這個組織每一層都是獨立的業務經營單元,現在我們在做一件事情,讓每個獨立的業務經營單元都有 CTO。這個 CTO會對這個業務經營單元負全責。實線管理機制的核心就是把每一層之間的界面定義清楚。
這種治理讓每一塊業務都很靈活,都可以自主發展,但又帶來了一個新問題,我們該統一發展的技術怎么形成合力,所以我們有另一條虛線:技術委員會,下設二三十個核心的技術小組,把所有的共性領域橫向拉通。通過技術委員會和技術小組的專業領導力,實現策略通、人才通。這兩條線會同時運作,隨著管理線越來越清晰的分層,這條專業的虛線就會變得非常重要。比如音視頻技術,每個業務里都會用到音視頻技術,中臺也有音視頻能力,底層需要優化以提升音視頻技術的競爭力。前臺、中臺和底層跟音視頻相關的技術專家組成一個技術小組,由一個專家帶領。
這條虛線會轉化成實線的管理決策,我們必須要打通這個鏈路,這個體系的運作會比較有挑戰。作為 CTO,我覺得要在過程中保持非常開放的心態,要信賴每個領域技術專家的判斷。技術專家意見不一致時要有獨立思考,做出自己獨立判斷,要知道創新和秩序的平衡點在哪里。
組織大到一定程度之后就會遇到這樣的問題,我確實也不建議技術組織還不大時就把組織結構搞的太復雜,這會帶來額外的管理和溝通成本。
6.凝心聚氣、薪火相傳
凝心聚氣其實是最重要,也是最難的,這是一個技術文化的事情。每隔一段時間,我們都會聚在一起討論阿里巴巴的技術文化。去年我們討論了一輪,三年前我們也討論過一輪。三年前定下阿里巴巴技術的 slogan叫“技術創造新商業”,再之前的 slogan是“技術拓展商業邊界”。
除了 slogan,阿里巴巴的技術文化底色是務實、有一說一,不要打花腔,不要做包裝,事實是什么樣就什么樣,用事實說話。沒有數據、沒有事實的時候,就不要說話。如果大家都能踐行這個文化的話,很多事情會變得特別簡單,但其實踐行文化并不容易。
我們有一些技術土話,比如“面向未來去思考”、“因為相信,所以看見”,是需要看準未來,敢于投入,真正做到先發先至。因為如果別人做、你再去做,永遠是追趕者,會非常累,但看準未來、敢于投入,也不會輕松。
這些文化、愿景能不能在一個大的場景里形成共識,尤其這個組織每年都有人離開、有新同學進來,還能保證一致的文化,其實是非常有挑戰的。但只有文化做好,很多事情才能順理成章。
CTO可能不是思想家,但一定是行動派
前面是我思考的 CTO的六個職責,雖然不完整,雖然不可能每件事情都做得非常好,但核心思考是,我是相信 CTO或者說技術團隊需要跟著公司業務發展不斷進化。我從螞蟻到阿里巴巴,差不多經歷了前面六個階段,我稱之為 CTO的六步曲:
1.跟團隊先一起定義好目標,先一起做成一些事情。
2.多了解團隊、了解業務,知道未來要去哪里,跟團隊一起共創一個愿景,把大家熱情點燃。
3.CTO的一個核心工作,是怎么能夠讓自己不要成為團隊的天花板,而是把自己當成團隊的地板,用人做事。如果 CTO是公司技術天花板的話,那你把公司技術就壓在一定的高度和范圍內,公司技術永遠是在一個小的、狹窄的領域。當 CTO的技術能力是公司的地板時,公司可以通過新同學擴展邊界。成為 CTO還是用人做事為主,而不是做事用人為主。
4.一切都很好時,別忘了晴天去修屋頂,永遠居安思危。一旦危機出現,樂觀地看待,每個危機背后都有機會,轉危為機。
5.過程中不只看當下,也要布局未來,為公司建立技術縱深。在業務發展早期,技術的縱深就是一個點。當發展到像阿里巴巴現在這個規模時,技術縱深就是一個多面體,必須有充分的、多面的布局,才能支撐一個大公司的發展。決定布局投入多少,要和 CEO充分對焦。
6.最后一點,人才。薪火相傳,人才才是公司未來發展的關鍵。我記得阿里云曾經有一位技術負責人分享說:什么是一家公司技術的最高境界,就是誰來當 CTO都能當好,我覺得這是我要努力的一件事情。
如何發展與培養CTO
最重要的事情放在最后,就是人才。
前面講到我們的分層分布治理,每個經營單元要有一個小 CTO,這個 CTO怎么培養?基本上我們讓他在戰場里去練,為他設計發展路徑,也有“奇點營”這樣的班專門培養業務小 CTO。
當然最難的事情就是培養接班人,自己的接班人和團隊的接班人,這件事情其實是我上任第一天就在想的事。但選準人、選好人,有非常多的挑戰。
我有兩個小經驗:
1.CTO發展是“Z”字型的路線。
直線成為 CTO的人,往往會因為路徑太單一、沒有足夠磨煉而出問題。行癲負責過淘寶的業務,負責過 B2B業務,再做阿里巴巴的 CTO,再做阿里云的總裁。我做過螞蟻的技術,做了兩年螞蟻國際業務,再做阿里巴巴的 CTO。做過業務再回頭看技術,跟 CEO對話會有共同的框架,這一點很關鍵。
2.做“L”型職責設計。
CTO最怕做虛了,畢竟這是公司里非常高的位置,每件具體事情都有相應的核心骨干幫你負責,但你手不伸下去就很容易做虛,看不到下面的實際情況,會導致決策出錯。
阿里巴巴怎么解決這個問題呢?就是給 CTO一橫一縱:橫向管理的 CTO,也給你一個縱向的業務技術一號崗位,保持與一線的對接。比如我現在既是阿里巴巴集團的 CTO,又是菜鳥的 CTO。行癲也曾經既是阿里巴巴的 CTO,也是阿里云的 CTO,也是一橫一縱。
CTO應該具備怎樣的特質?每個 CTO都有不一樣的風格,但有幾點是共通的:一是要求真務實,真正“No Data No BB”,永遠不是高高在上地做決定,而是做決定時能夠看得到下面,這很重要;二是要有擔當,在做關鍵決策時敢負歷史責任,有進取心;三是必須時時自省和開放。如果不具備自省和開放的能力,是很難去進化的;四是一個大組織和大業務的 CTO要有全局觀,能夠做架構,能把各方面、各種信息形成一張大圖。
曾國藩非常懂用人之道,他這么選人:“專從危難之際,默察樸拙之人,則幾矣”。我特別喜歡這句話,把自己的釘釘簽名都寫為“樸拙”,這是對自己的要求。
到現在為止,我覺得自己很多方面做得依然不夠,包括對未來的判斷。 CEO和 CTO實際上是要共同成長、共同進化,在工作中形成默契的,這是非常重要的。
全球化工設備網（http://www.tupvw34.cn ）友情提醒，轉載請務必注明來源:全球化工設備網！違者必究.
標簽：
相關資訊
免責聲明：1、本文系本網編輯轉載或者作者自行發布，本網發布文章的目的在于傳遞更多信息給訪問者，并不代表本網贊同其觀點，同時本網亦不對文章內容的真實性負責。
2、如涉及作品內容、版權和其它問題，請在30日內與本網聯系，我們將在第一時間作出適當處理！有關作品版權事宜請聯系：+86-571-88970062
2、如涉及作品內容、版權和其它問題，請在30日內與本網聯系，我們將在第一時間作出適當處理！有關作品版權事宜請聯系：+86-571-88970062
推薦資訊