加入 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 的测试车已经能应对许多复杂路况，不再是那个只会右转的菜鸟了。