<img id="edit_5486681" src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/58a592e245838d0530185d2eb4191ee7_1626419292.jpeg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/58a592e245838d0530185d2eb4191ee7_1626419292.jpeg"/>張建鋒（花名行癲）<blockquote>鈦媒體注：本文刊發於阿里雲及鈦媒體聯合策劃的《雲棲戰略參考》2021 年第一期</blockquote>2011 年，網景創始人、著名風險投資人馬克·安德森 (Marc Andreessen) 寫道，“Software is eating the world”(軟件正吞噬整個世界)，用以表達各行各業都被軟件所瓦解，之後再重構，未來所有的公司都是軟件公司。事實證明，馬克·安德森的預判遠比大部分人想象的還要長遠。今天，全球市值最高的幾家公司盡數為軟件公司，不同領域的巨頭內部有着相同的軟件工程師羣體。這麼一羣高智商、高薪酬的人聚在一起，是腦力的風暴還是角力的漩渦，是在冥思苦想還是在渾水摸魚，很大程度上決定了一家公司的生產力。不僅如此，隨着數字化升級的深入，越來越多的企業組建起自己的軟件開發團隊，以滿足自身在業務上的定製以及業務發展需求。因為系統複雜性的提高，軟件團隊的規模也變得越來越大，管理難度也隨之呈指數增加狀態。如何有效管理創新開發團隊，也成了很多傳統企業的一個隱形痛點。而對於管理超大規模開發團隊的經驗和教訓，阿里雲智能總裁、達摩院院長張建鋒 (花名行癲) 可能是最有資格回答的人之一，當年他帶着 12 個人三個月完成天貓商城項目開發就是經典的案例。本期《雲棲戰略參考》(以下簡稱《參考》) 就和行癲仔細探討了這個問題。<h2>管理超大規模研發的秘籍</h2>《參考》：很多客户其實非常好奇阿里巴巴管理超大規模研發團隊的經驗和教訓，阿里巴巴有怎樣的最佳實踐？行癲：這是個很好的問題，但是我想先説説我對最佳實踐的看法。首先，阿里巴巴未必有最佳實踐，因為業務的成功會掩蓋很多真相。就像當年谷歌説有很多創新，是因為員工可以有 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(產品需求文檔)，產品經理寫的可能比較簡略一點，開發工程師會把文檔寫的特別詳細。寫的過程中需要畫流程圖，這就強迫他去弄明白需求。想明白之後，開發會非常快。<h2>揭秘阿里巴巴的研發團隊</h2>《參考》：阿里現在有多少開發人員？層級分佈情況大概是什麼樣子的？行癲：具體人數我也不知道，大概五六萬人，中間層 P7/P8 最多。《參考》：阿里內部的程序員職級體系是什麼樣子的？不同的崗位描述是什麼樣的？行癲：阿里把工程師分為不同層級，做研究的在達摩院，還有做基礎工具、基礎平台的，阿里雲的工程師開發業務產品，阿里巴巴電商系的工程師也有開發電商技術的。但都遵循四個標準：穩定是底線，穩定壓倒一切；第二是效率；第三是成本，效率高還要考慮成本；第四要有創新，創新技術能夠反向推動業務，比如人臉識別技術可以簡化登錄。淘寶、天貓的技術研發不是產品研發，產品是淘寶、天貓。這個看似很簡單：把技術能力變成產品，把產品變成市場。但是你有很強的能力，不見得就有很好的市場。但我們很多工程師有個誤區，覺得我有能力，什麼都能幹，這個肯定是有問題的。你能不能讓技術能力變成產品？產品能不能有市場？都是未知。《參考》：管理體系是什麼時候開始建立的？行癲：阿里的研發管理體系，一開始也沒有什麼體系，跟所有工作一樣的，都是在爭吵中度過的。一個經典的問題就是工程師到底應該屬於哪個部門？現在很多工程師都不屬於業務部門，而是個資源部門，那麼哪個需求優先做，就是個很現實的問題。但正因為你是個資源部門，你有這個權力，就需要你有判斷力，去平衡很多東西。阿里現在的業務工程師佔 70% 左右，業務的工程師那很簡單，業務贏了你就成功，業務如果做不好，那你的評價肯定不會高。工程師的工作是不能精準量化的，最終看貢獻，包括你的技術能力、你對這個組織的貢獻。技術體系的晉升是個相對性的事情，無法追求絕對公平。<img id="edit_5433800" src="https://imageproxy.pbkrs.com/http://images.tmtpost.com/uploads/images/2016/12/435grtgf3.jpg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" alt="" original-src="https://imageproxy.pbkrs.com/http://images.tmtpost.com/uploads/images/2016/12/435grtgf3.jpg"/>追求絕對公平的有兩個體系，一個是行政體系，第二個是技術委員會，技術委員會不會特別考慮業務的問題，而是從純技術角度評價員工的能力水平。我倒覺得技術委員會是阿里相對超脱的一個組織，就是工程師自治的組織，它是從技術品牌對外的影響力來思考，比如如何吸引更好的員工來加入。我覺得技術人員從來都不是一個商業部門的核心問題，業務部門最大的挑戰永遠都是業務在市場上有沒有競爭力，而這種競爭力絕大多數都不是技術決定的。抖音也好，快手也好，都不是因為技術跟別人不一樣才成功的。雲，是一個特例，技術本身即產品，它的市場是由客户的業務需求決定的。《參考》：在阿里，是怎麼定義架構師？行癲：我原來也做架構師，架構師的變遷史很複雜，架構師原來就是技術水平最好且最瞭解業務的那個人，才是架構師。這個人往往後來都會成立架構組或者架構部，架構部一成立就脱離了業務，他會去搞自己的架構。所以阿里也是在來來回回調整，架構師在部門裏面 - 獨立出來 - 又融合，一直在循環。但是我覺得架構師越來越難培養，因為業務系統越來越複雜，懂得整個系統的人可能後來就不在公司了。所以後來，我們提出一個要求，就是把系統模塊化，所有人能處理問題的邊界都是有限的，阿里有很多系統，每個人來負責一個系統，系統裏一個主要的人就是架構師，他必須把自己的系統全部做好。再到後來項目多了起來，一個項目裏面有項目經理、架構師、產品經理、程序員，但在業務系統裏面那個人不叫架構師了，一般是系統分析師。架構師是偏純技術的，系統分析師比較偏複雜的業務系統分割，梳理好系統之間的關係。技術架構師現在的地位被削弱，因為太多的東西都標準化了，沒有必要從技術的角度想一個新方案出來，但業務架構師因為複雜業務系統越來越多，比如銀行是典型的複雜業務系統，他們需要的就是好的業務架構師。業務架構師的培養週期很長。技術架構師從 A 公司到 B 公司，是能夠很快去接手的，業務架構師需要很多年的積累。他一定是技術出身的，因為業務的知識相對容易積累，技術的知識業務人員是積累不起來的。《參考》：如何看待精英程序員和普通程序員的差別？阿里內部傾向於哪一類？行癲：比如我們一個部門有 10 個人，10 個人都是 P8，這個部門的水平就是 P8，10 個人裏面有一個 P10，這個部門的整體水平就是 P10。技術是靠一些特別牛的人把整個水平提上去的，但沒有那個人的話，整個團隊水平就比較低，因為你永遠達不到那個水平，但只要有一個人的水平非常好，整個部門都會到較高的水平。《參考》：阿里的老程序員都在幹什麼？行癲：阿里的老程序員有兩種，這個沒有貴賤之分。因為哪個公司都需要非常熟練的人，他不見得有特別牛的技術，一個公司裏面百分之八九十的工作就是把業務能夠快速的變成一個系統，然後去迭代試錯。可能有百分之十、二十的工作才是需要去想怎麼把整個系統的水準提到非常高的水平，然後把關鍵的系統寫出來，關鍵系統永遠是隻佔不到 10%。所以我覺得兩種人都重要，某種程度上，一批很熟練的人更重要，特別是新的業務需要快速推出的時候。《參考》：CTO 這個崗位是如何定義的？行癲：在我的邏輯裏，CTO 其實是站在集團的業務角度來管理技術的角色。他首先要理解業務，第二他要保證業務可以快速實現，這是 CTO 要乾的事情。CTO 是業務和技術非常平衡的那個人，他要把業務弄明白，才能夠有效的部署下去，如果業務都不明白，他沒辦法部署，只能當一個傳聲筒。互聯網公司裏三個關鍵角色——研發、產品和運營。有些公司把產品加技術放在 CTO 下面管理；有些公司的產品是獨立的放在 CTO 下面；有些公司因為產品更加獨立，以產品為閉環，把研發、運營也放在產品下面，比如像一些 APP，它自己有個獨立的團隊。《參考》：現在雲原生的技術起來之後，未來對整個項目管理和工程師的管理，有沒有什麼影響？行癲：阿里本來也不建議前端工程師去做那些非業務系統相關的事情，需要分工合作，因為不懂技術的老闆最怕聽見 “又要建一個新系統”，老闆都很難判斷這個非業務系統有沒有必要性。雲原生之後更加透明化了，資源全部清晰可見，再不用去開發那些底層系統，只要上面跑應用系統就行，它是天然分開的。（本文首發鈦媒體 App 作者 | 張帥 採訪者 | 劉湘明）<img id="edit_5486793" src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/fcf8232f685801021b79681e907b71cd_1626419292.jpeg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" alt="" width="1080" height="2920" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/fcf8232f685801021b79681e907b71cd_1626419292.jpeg"/>點擊領取《雲棲戰略參考》更多精彩內容，關注鈦媒體微信號（ID：taimeiti），或者下載鈦媒體 App

阿里巴巴-W

阿里巴巴

揭秘阿里巴巴的研發團隊，看阿里雲智能總裁、達摩院院長張建鋒 (花名行癲) 如何管理超大規模開發團隊

阿里雲智能總裁、達摩院院長行癲：阿里如何管理超大規模研發團隊？