Level 5 工程副總裁：如何從零開始打造自動駕駛軟體團隊？

雷鋒網新智駕註：本文由雷鋒網新智駕編譯自 Mudium, 作者為 Lyft 旗下自動駕駛部門 Level 5 工程副總裁 Anantha Kancherla。

原文鏈接：https://medium.com/@LyftLevel5/going-from-zero-to-sixty-building-lyfts-self-driving-software-team-1ac693800588

加入 Level 5 並開始負責核心軟體開發工作時，我們的團隊只有 5 名軟體工程師和 5 名硬體工程師。不過，大家肩上卻扛著一個重量級的挑戰：打造一輛自動駕駛汽車。

18 個月後，我們已經擁有 300 名工程師和一個不斷擴大的自動駕駛測試車隊。這樣的成長速度確實令人驕傲，不過速度並非一切，在團隊培養和車輛搭建上，我們必須深思熟慮。

自動駕駛技術的開發算得上是我們這個時代最具挑戰的工程任務，在微軟做 3D 圖形的經驗和在 Facebook 搞移動產品的積累讓我認識到，想要成功拿下挑戰，你就得打造一個配得上這個挑戰量級的團隊。當然，當你的團隊人才濟濟時，如何保證他們能持續產出就是另一大挑戰。

雖然我們還在繼續探尋自動駕駛的終極奧義，但這一路的奮鬥已經讓 Level 5 學到了太多。接下來，我就來分享 Level 5 的團隊建設經驗。

為了追上其它先來者的進度，我們得完成兩大核心任務：

1. 打造一個有能力開發自動駕駛汽車的團隊；

2. 儘快出成果。

鑒於我的職業生涯趕上過多次技術潮頭，因此這兩大任務我早已駕輕就熟（當然，這次還是很有挑戰性的）。我心裡很清楚，Level 5 這個項目的第一個絆腳石就是如何吸引正確的人才進來。

這個工作非常難做，因為自動駕駛領域裡有經驗的人實在是太少了。

針對這個問題我們也有自己的解決方案，Level 5 先是對自動駕駛汽車的零部件細節進行了深入分析，並以此確定我們到底需要哪類工程技能。隨後，我們用宏觀角度設計出了 Level 5 的理念體系，以保證團隊文化支持整個項目走向未來。

在搜索人才之前，Level 5 先是對不同技能之間的關係進行了梳理。在這裡，我推薦你們用 SPA（即了解、計劃和行動）架構，它能幫你完成自動駕駛技能結構的搭建。

顯然，人工智慧、機器學習和機器人專家是 Level 5 最為需要的人才。

不過，得出了大致方向後我們發現，需要做的事情還很多，因為這三大領域幾乎完成了對計算機科學的全覆蓋（如上圖）。

除了人工智慧、機器學習和機器人，我們還得網羅一些擅長操作系統、安全、汽車製造和圖形的人才。

網羅人才這個事解決後，你還得想辦法把他們捏合到一起。

要知道，來自不同領域的他們有著差異巨大的理念，而在新的團隊中他們必須勁往一處使，朝著同一個目標前進。在這裡，我們需要處理好敏捷和統一的關係。

敏捷可不僅僅意味著寫代碼要快，這些桀驁不馴的人才還得時刻跟蹤並適應業界的快速變化。至於統一，則意味著我們需要員工相互扶持，畢竟軟體是個緊密連接的產品，任何輕微的 bug 都有可能引發系統級的大麻煩。

舉例來說，如果某人更改了編譯器標記，他就有可能徹底改變自動駕駛系統的駕駛策略。想要長期維持高增速，每個團隊成員都得對平台負起責任，拿出高質量的 API 和代碼。

這樣，後續大家才能以此為基礎完成上層建築的搭建。

設定了理想的團隊輪廓後，我們正式開始為 Level 5 團隊添磚加瓦了。在這裡，五步走戰略起了重要作用：

a）尋找關鍵人才

大多數行業中，尋找人才並不困難，因為同行業中能人一抓一大把。不過，自動駕駛是個相對較新的行業，因此定海神針似的關鍵人才並不好找（即使找到了也是奇貨可居）。

好在，Level 5 有一系列政策及願景，它對人才有十足的吸引力。如果我們找不到適合某個特殊崗位的專家，就會轉而尋找有相近技能的人才，並對其進行特訓。

b）培養核心工程師

與其每次創立一個子團隊，我們更願意在各個核心領域培養自己的核心工程師。這些人才必須能理解自己職責範圍內的問題和框架，並且知道如何通過團隊的力量來解決問題。

c）搭建均衡團隊

我們偏愛各具特色的人才，並希望他們能實現技能互補。在團隊搭建時，Level 5 會讓經驗豐富但專業技能不足的人以及專業技能出色但經驗不足的人追隨核心工程師，以實現整個團隊的均衡發展。

d）大膽放單飛

團隊和技術得到成長後，Level 5 就會大膽放他們單飛，而非對人員進行重新配置。我們的軟體團隊最終成了車輛和雲團隊，而車輛團隊則成了平台與自動化團隊，原本的自動化團隊成了我們的計劃與感知團隊。

Level 5 推動者各個團隊玩「細胞分裂」，直到這些團隊都活成了最初預想的樣子。這樣的安排讓我們能維持團隊成員的一致性，保證溝通順暢並增強團隊間的凝聚力。

e） 創建遠程辦公室

世界太大了，許多人才無法聚在一起工作，因此我們把人才招聘的視野擴展到了 Palo Alto 之外。

Level 5 快速建起了自己的慕尼黑辦公室，這裡聚集了大量實時定位與地圖（SLAM）人才。此外，我們還收購了倫敦的 Blue Vision Labs。

想要搞好這種規模的工程項目，理想的團隊架構恐怕都不夠。團隊里有 100 人和團隊里有 10 人運營方式可不一樣，即使大家坐在一起討論也只會帶來混亂，因為聲音太多了。

顯然，團隊快速擴張後，那些額外的噪音會拖慢大家前進的速度，而在自動駕駛這個快速增長和變化的行業中，失速就意味著死亡。

那麼 Level 5 是如何處理這個問題的？很簡單，我們選擇直面問題，迅速進行調整。

這也是拜團隊成員的經驗所賜，大家過去做過不少複雜產品，我們能提前預知哪些領域會有「雷」，這樣就能提前解決一些麻煩。

為了避免大公司病，我們還主動對時間線、架構、會議頻率與風格進行了調整，同時還重塑溝通渠道以滿足團隊的需要。

舉例來說，隨著團隊成長，除了日常會議，我們還逐漸引入了一周或兩周一次的碰頭會。

定義基本法則

兵強馬壯外加主動調整機制建立後，我們需要定下一些基本法則，防止公司在快速行駛中翻車。這部分，我從馬拉松訓練中攫取了不少靈感。

以下，就是我用在 Level 5 核心工作流中的經驗教訓：

1. 沒人讓你上來就跑馬拉松，訓練並蓄積力量才是第一步

不斷迭代並達成一個個裡程碑是進步的關鍵。我們的第一輛車幾個人就造出來了，但它卻只能在停車場工作，右轉是這輛車的能力極限了。

這樣尷尬的情景讓我們意識到，先把基礎設施準備好才是王道。後來，隨著 Level 5 的隊伍逐漸壯大，我們的野心也越來越大。

2. 早發現早治理

每次迭代時，務必找到不對勁的地方並趕緊對其進行修復。這件事你會不斷經歷，千萬別在快速反饋循環和測試設備上省錢，否則後患無窮。

3. 找對路子事半功倍

仔細想想你在打造什麼，你又買到了什麼？鑒於自動駕駛市場上已經有大量商業解決方案，因此我們的選擇很多。不過，這會讓人感覺亂花漸欲迷人眼，不知道該如何下手。

好在 Level 5 找到了自己的方向，我們只願意在工具上花錢，這些工具主要用來排除故障並推動軟體不斷進步，而它們才是 Level 5 的核心 IP。

4. 安全必須和速度放在同等地位

如果只有半吊子水平還非讓測試車上路，恐怕會捅出大簍子。在 Level 5 看來，不斷的迭代就是為了訓練出「安全肌肉」。為了保障安全，我們的團隊先是弄懂了測試車安全運行到底要付出什麼，然後才是派他們上路做端對端測試。

5. 工欲善其事，必先利其器

由下而上固化代碼是題中應有之意，畢竟一旦依賴的軟體發生了變化，許多團隊就會手足無措。現實中，誰都想要完美無缺的軟體，但自動駕駛項目的複雜性讓突破來的相當緩慢。

在這方面，Level 5 就理智的多，我們選擇先對底層軟體進行優化，並做好長期打算，以便在前進的道路上繞過一些路障。

即使團隊配置最優，戰略決策殺伐果斷，想在自動駕駛行業雲淡風輕也幾乎不可能。我們在發展中就經歷了不少痛點，當然還有彌補方案。

1. 工程師很迷信代碼風格指南。不同工程背景的人會自帶不同理念，這也會反映到他們的做事方法上。

針對這個問題，我們堅持和而不同的理念。大家也會針對一些問題進行友好討論，最終打破分歧達成一致。這樣我們就能以一個團隊的姿態繼續向前。

2. 溝通工具一團亂麻。在工作中我們發現，隨著團隊成員不斷增加，我們的通訊頻道和項目管理工具也在增加，正常工作流也因此被大亂，抑制了團隊的效率。

好在 Level 5 有解決方案。我們直接創了個工作群，這裡面清空了不必要的工具，而且設定了嚴格的溝通標準。對我們來說，花時間解決眼前問題的理念重塑了各團隊的工作流。

3. 出了問題後，找原因成了大麻煩。有時候找原因看似簡單，但在日常工作中你經常會做徒勞無功的事。

在工作中，我們設定了數據驅動的標準，而各種「儀錶」則成了追蹤問題根源的好幫手。

4. 遠程合作沒想像中容易。光是 Palo Alto 辦公室的溝通已經夠麻煩，所以想想與不同時區同事的交流，更是讓人頭疼了。

針對這一點，我們先是給海外辦公室配了個強大的領導，隨後放權給他們獨立性，讓他們自行完成一些項目「拼圖」。

經過 15 個月的工作，我們超優秀的團隊終於搭建完成。

可以很驕傲地說，我們的試水很成功，Level 5 的測試車已經能應對許多複雜路況，不再是那個只會右轉的菜鳥了。

雷鋒網推薦閱讀：

麥格納向Lyft投資2億美元後，首次公布3大合作成果

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！