張建鋒：阿里如何管理超大規模研發團隊？
play
歡迎關注“新浪科技”的微信訂閱號：techsina
文、編輯/張帥 采訪者/劉湘明
來源：鈦媒體
揭秘阿里巴巴的研發團隊，看阿里云智能總裁、達摩院院長張建鋒(花名行癲)如何管理超大規模開發團隊？
鈦媒體注：本文刊發于阿里云及鈦媒體聯合策劃的《云棲戰略參考》2021年第一期。
2011年，網景創始人、著名風險投資人馬克·安德森(Marc Andreessen)寫道，“Software is eating the world”(軟件正吞噬整個世界)，用以表達各行各業都被軟件所瓦解，之后再重構，未來所有的公司都是軟件公司。
事實證明，馬克·安德森的預判遠比大部分人想象的還要長遠。
今天，全球市值最高的幾家公司盡數為軟件公司，不同領域的巨頭內部有著相同的軟件工程師群體。這么一群高智商、高薪酬的人聚在一起，是腦力的風暴還是角力的漩渦，是在冥思苦想還是在渾水摸魚，很大程度上決定了一家公司的生產力。
不僅如此，隨著數字化升級的深入，越來越多的企業組建起自己的軟件開發團隊，以滿足自身在業務上的定制以及業務發展需求。因為系統復雜性的提高，軟件團隊的規模也變得越來越大，管理難度也隨之呈指數增加狀態。如何有效管理創新開發團隊，也成了很多傳統企業的一個隱形痛點。
而對于管理超大規模開發團隊的經驗和教訓，阿里云智能總裁、達摩院院長張建鋒(花名行癲)可能是最有資格回答的人之一，當年他帶著12個人三個月完成天貓商城項目開發就是經典的案例。本期《云棲戰略參考》(以下簡稱《參考》)就和行癲仔細探討了這個問題。
管理超大規模研發的秘籍
《參考》：很多客戶其實非常好奇阿里巴巴管理超大規模研發團隊的經驗和教訓，阿里巴巴有怎樣的最佳實踐?
行癲：這是個很好的問題，但是我想先說說我對最佳實踐的看法。
首先，阿里巴巴未必有最佳實踐，因為業務的成功會掩蓋很多真相。就像當年谷歌說有很多創新，是因為員工可以有20%的時間考慮“與工作無關的東西”。這就有可能弄錯了因果關系，谷歌并不是因為這個原因成功的，而是因為谷歌成功才可以這么做。
所以這里面有個挑戰是要知道哪些是真正可以復制的最佳實踐，哪些只是因為業務成功之后總結成的“最佳實踐”。結果很容易看到，但真正找到“因”是很難的一件事情。
我們可以通過這本內刊和讀者一起來尋找最佳實踐，和大家分享、碰撞一下。
我沒辦法告訴銀行家，他應該怎么做“一二三步”，因為我沒有辦過銀行，但如果這個銀行家有足夠的領悟能力，他會從阿里巴巴的最佳實踐、阿里云的客戶的最佳實踐中取得一些借鑒，獲得啟發，然后提出他自己的問題。
我們只能說我們在這個行業里面做了什么，或者自己不見得成功，但是提倡的理念是成功的，能夠引領未來的。比如說以后的辦公是數字化的，像釘釘這樣的平臺；比如以后軟件的開發是碎片化的。這些我覺得是趨勢，未必見得在我們這里成功，可能在我們的客戶里實現成功，比如太平洋保險，用了釘釘之后，把很多系統就自己開發上去了。
《云棲戰略參考》就是把這個行業里的先行者的探索、實踐，呈現出來。但是“核”永遠不可能靠別人告訴你——如果我能告訴你，那意味著我能做你的業務。
《參考》：關于創新的研發管理最大的挑戰是什么?
行癲：你覺得研發人員不好管理，是因為你不知道應該做什么。最基本的“管理”，就是告訴下屬應該做什么，而程序開發是項目化、組織化程度最高的一個活動。
所有項目第一個動作都是立項，第二個動作是所有項目都要被準確的評估，到底要花多少時間進行開發，比如我當年做天貓商城，在規定時間內要把天貓商城上線。評估很重要，比如一個系統登錄use case(用戶用例)，通常有經驗的程序員寫這個use case，三天可以寫完。我們盡可能把所有的use case都給列出來，如果列不出來，說明這個需求沒弄明白，需求沒有弄明白就去做，肯定是很難收斂的，做到最后就會發現做的不對。
所以第一步就是把所有的use case都要列出來，列不出來的話，就不要開始后續的工序，就要弄明白這個軟件到底有哪些功能。列完之后就在后面標注三天、五天、六天、七天，所有加起來就是總共花的工時。比如可能要花1000個工時，就需要思考，1000個人做一天，還是100個人做10天，還是10個人做100天?這肯定不一樣的，但絕不可能1000個人做一天就做完了。必要的周期還是要有的，這個周期有經驗的管理者會有自己的判斷。
我們根據必需的時間，把人員核算好，就開始做。精髓是，需求必須明確！
我們才能夠按部就班列出來，然后得到一個工時數，確定所有的資源投入，之后就是標準化的系統管理：什么時候應該研發介入，什么時候應該測試介入，什么時候應該提交測試，提交測試的提交標準是什么——這都是非常標準的流程，只是很多軟件開發團隊沒有嚴格去遵循。
比如，聽別人說很多軟件公司不做測試了，自己也不要測試了，開發工程師來測試就可以了，但實際上有些測試很重要，甚至需要有一半人做測試。原則很簡單：如何讓總體研發時間最短、成本最低。但一個項目應該是測試多，還是應該是開發多？不同的項目不一樣，管理者自己決定。但必須保證總體的時間最短，投入的資源最少。
《參考》：阿里有沒有自己的軟件開發方法論?
行癲：方法論可以探討，但是方法論需要固化成為工具。你必須要有一整套工具來支撐方法論落地，怎么管理需求、怎么提交代碼等等，我們內部有Aone。
但Aone是很重的，比較適合于大型項目的開發，小公司可能不需要這么重的工具，可以去做裁剪，我覺得各自有各自的做法，認同你的方法論就會采用你的工具，不認同你的方法論人家也不會采用你的工具。
很多公司沒有方法論，只關心工具——這是兩個層面，都需要關注。阿里現在的方法論，所采用的工具是我們自研的Aone。其實我個人是反對所有的公司都自研工具的，因為我覺得方法論一定是有普適性的。不是說在阿里這個方法論奏效，換個公司就不行了，沒法復制。
我現在要求工具一定要開源，開源之后所有的工程師才會來使用，甚至會反過來優化你的方法論。
原來我們中國的軟件開發，基本上工具決定了你的方法，有些工具很重很重，互聯網公司肯定不能用，因為互聯網強大之處在于反復迭代，容錯性很高，關鍵流程不出錯，其他東西有點瑕疵無所謂。但是站在其他行業的軟件開發維度來看，軟件分發出去之后修復成本很高，需要在分發前反復測試。
《參考》：對業務的理解是需要經驗積累的，在摸不清需求的那段日子是怎么過來的?
行癲：沒有use case的時候，往往項目是很小的時候，是業務推著你在走，那時候是不管白貓黑貓，抓住老鼠就是好貓。
我2004年加入阿里，阿里那時候沒幾個人，沒有人關心你用什么工具，你只要實現目標就可以。那時候很難說效率高，很難說是最佳解決方案，但一定是找到一個比較合適的解決方案。技術要追求合適性，不要追求先進性。
《參考》：研發管理和業務規模強相關，阿里何時開始重視這件事?
行癲：2004-2006年時業務跑的比較快，所以技術只要能夠滿足業務發展就可以。最近幾年，特別是人工智能、大數據涌現之后，其實很多業務已經不是簡單的業務方能夠想明白了，比如程序化交易或者廣告競價、商品推薦，業務方可能想的是一句話的事情，但研發可能是很復雜的事情，在這些系統里面工程師會占更大的主導地位。
《參考》：“雙11”這種大項目，阿里是怎么管理的，是一個什么樣的流程?
行癲：關鍵就是模塊化，我們每天模擬“雙11”的情況，模擬最壞情況下，怎么做降級處理的操作。
當然研發一個模擬系統，這是另一個重要的工作了。如何定義問題，大的項目里需求的定義變得非常重要。需求定義是最關鍵的！
喬布斯有句話叫做“消費者并不知道自己需要什么，直到我們拿出自己的產品，他們就發現，這是我要的東西”，軟件工程里這個提需求的人也很重要。
我認為很多的產品不好，是因為需求是沒有想明白。有時所謂的“提需求”，并不是在提需求，而是在討論，因為他自己也不知道這是不是個需求。
當年開發天貓商城的挑戰非常大，大家討論了很久，包括有沒有購物車功能，需不需要選擇尺碼。要知道原來淘寶是沒有尺碼的，如果你要買鞋的話，必須用旺旺跟賣家溝通。我們認為天貓是不需要旺旺溝通的，那我們就開始做SKU，讓消費者自己可以選，你買下來直接付款就可以了，也不需要支付擔保。
這些問題都反復討論了很久，那時候我帶了12個人，做了三個月就全部做完了。前提是，我們確保需求是非常明確的，我們有足夠的管理能力，就能實現快速開發。
我們也提倡開發工程師來寫PRD(產品需求文檔)，產品經理寫的可能比較簡略一點，開發工程師會把文檔寫的特別詳細。寫的過程中需要畫流程圖，這就強迫他去弄明白需求。想明白之后，開發會非常快。
揭秘阿里巴巴的研發團隊
《參考》：阿里現在有多少開發人員？層級分布情況大概是什么樣子的？
行癲：具體人數我也不知道，大概五六萬人，中間層P7/P8最多。
《參考》：阿里內部的程序員職級體系是什么樣子的？不同的崗位描述是什么樣的?
行癲：阿里把工程師分為不同層級，做研究的在達摩院，還有做基礎工具、基礎平臺的，阿里云的工程師開發業務產品，阿里巴巴電商系的工程師也有開發電商技術的。但都遵循四個標準：穩定是底線，穩定壓倒一切；第二是效率；第三是成本，效率高還要考慮成本；第四要有創新，創新技術能夠反向推動業務，比如人臉識別技術可以簡化登錄。
淘寶、天貓的技術研發不是產品研發，產品是淘寶、天貓。這個看似很簡單：把技術能力變成產品，把產品變成市場。但是你有很強的能力，不見得就有很好的市場。
但我們很多工程師有個誤區，覺得我有能力，什么都能干，這個肯定是有問題的。你能不能讓技術能力變成產品？產品能不能有市場？都是未知。
《參考》：管理體系是什么時候開始建立的?
行癲：阿里的研發管理體系，一開始也沒有什么體系，跟所有工作一樣的，都是在爭吵中度過的。
一個經典的問題就是工程師到底應該屬于哪個部門？現在很多工程師都不屬于業務部門，而是個資源部門，那么哪個需求優先做，就是個很現實的問題。但正因為你是個資源部門，你有這個權力，就需要你有判斷力，去平衡很多東西。
阿里現在的業務工程師占70%左右，業務的工程師那很簡單，業務贏了你就成功，業務如果做不好，那你的評價肯定不會高。
工程師的工作是不能精準量化的，最終看貢獻，包括你的技術能力、你對這個組織的貢獻。技術體系的晉升是個相對性的事情，無法追求絕對公平。
追求絕對公平的有兩個體系，一個是行政體系，第二個是技術委員會，技術委員會不會特別考慮業務的問題，而是從純技術角度評價員工的能力水平。
我倒覺得技術委員會是阿里相對超脫的一個組織，就是工程師自治的組織，它是從技術品牌對外的影響力來思考，比如如何吸引更好的員工來加入。
我覺得技術人員從來都不是一個商業部門的核心問題，業務部門最大的挑戰永遠都是業務在市場上有沒有競爭力，而這種競爭力絕大多數都不是技術決定的。抖音也好，快手也好，都不是因為技術跟別人不一樣才成功的。云，是一個特例，技術本身即產品，它的市場是由客戶的業務需求決定的。
《參考》：在阿里，是怎么定義架構師?
行癲：我原來也做架構師，架構師的變遷史很復雜，架構師原來就是技術水平最好且最了解業務的那個人，才是架構師。這個人往往后來都會成立架構組或者架構部，架構部一成立就脫離了業務，他會去搞自己的架構。
所以阿里也是在來來回回調整，架構師在部門里面-獨立出來-又融合，一直在循環。但是我覺得架構師越來越難培養，因為業務系統越來越復雜，懂得整個系統的人可能后來就不在公司了。
所以后來，我們提出一個要求，就是把系統模塊化，所有人能處理問題的邊界都是有限的，阿里有很多系統，每個人來負責一個系統，系統里一個主要的人就是架構師，他必須把自己的系統全部做好。
再到后來項目多了起來，一個項目里面有項目經理、架構師、產品經理、程序員，但在業務系統里面那個人不叫架構師了，一般是系統分析師。架構師是偏純技術的，系統分析師比較偏復雜的業務系統分割，梳理好系統之間的關系。
技術架構師現在的地位被削弱，因為太多的東西都標準化了，沒有必要從技術的角度想一個新方案出來，但業務架構師因為復雜業務系統越來越多，比如銀行是典型的復雜業務系統，他們需要的就是好的業務架構師。
業務架構師的培養周期很長。技術架構師從A公司到B公司，是能夠很快去接手的，業務架構師需要很多年的積累。他一定是技術出身的，因為業務的知識相對容易積累，技術的知識業務人員是積累不起來的。
《參考》：如何看待精英程序員和普通程序員的差別？阿里內部傾向于哪一類？
行癲：比如我們一個部門有10個人，10個人都是P8，這個部門的水平就是P8，10個人里面有一個P10，這個部門的整體水平就是P10。
技術是靠一些特別牛的人把整個水平提上去的，但沒有那個人的話，整個團隊水平就比較低，因為你永遠達不到那個水平，但只要有一個人的水平非常好，整個部門都會到較高的水平。
《參考》：阿里的老程序員都在干什么?
行癲：阿里的老程序員有兩種，這個沒有貴賤之分。因為哪個公司都需要非常熟練的人，他不見得有特別牛的技術，一個公司里面百分之八九十的工作就是把業務能夠快速的變成一個系統，然后去迭代試錯。
可能有百分之十、二十的工作才是需要去想怎么把整個系統的水準提到非常高的水平，然后把關鍵的系統寫出來，關鍵系統永遠是只占不到10%。所以我覺得兩種人都重要，某種程度上，一批很熟練的人更重要，特別是新的業務需要快速推出的時候。
《參考》：CTO這個崗位是如何定義的?
行癲：在我的邏輯里，CTO其實是站在集團的業務角度來管理技術的角色。他首先要理解業務，第二他要保證業務可以快速實現，這是CTO要干的事情。
CTO是業務和技術非常平衡的那個人，他要把業務弄明白，才能夠有效的部署下去，如果業務都不明白，他沒辦法部署，只能當一個傳聲筒。
互聯網公司里三個關鍵角色——研發、產品和運營。有些公司把產品加技術放在CTO下面管理；有些公司的產品是獨立的放在CTO下面；有些公司因為產品更加獨立，以產品為閉環，把研發、運營也放在產品下面，比如像一些APP，它自己有個獨立的團隊。
《參考》：現在云原生的技術起來之后，未來對整個項目管理和工程師的管理，有沒有什么影響?
行癲：阿里本來也不建議前端工程師去做那些非業務系統相關的事情，需要分工合作，因為不懂技術的老板最怕聽見“又要建一個新系統”，老板都很難判斷這個非業務系統有沒有必要性。
云原生之后更加透明化了，資源全部清晰可見，再不用去開發那些底層系統，只要上面跑應用系統就行，它是天然分開的。
（聲明：本文僅代表作者觀點，不代表新浪網立場。）
