特斯拉颠覆传统车厂的新思维

传统车厂的硬件更新频率通常是以年份来计算，因为每次引进新的硬件（例如：保险杠、后视镜、中控台软硬件、引擎、刹车系统等）都要经过所有的测试与生产程序。

从选择供应商、测试、报价、供货、存储、列入生产程序，到员工训练、后勤支援体系建立、经销商训练等，按部就班，最终通过政府的法规与测试之后，公开上市。一个车型每一、两年有一个小改款，每三到五年甚至十几年来一个大改款，这样的改款频率相信大家都习以为常了。

但特斯拉不是如此，这家新兴的汽车厂完全颠覆传统车厂的思维，将发源自软件开发的敏捷思维，应用到硬件生产制造上。特斯拉通过敏捷，以最快、最低的成本完成新硬件的导入，每周能对每个车型的27项硬件产品进行更新，随时精进品质。换言之，不同月份出厂的特斯拉可能都是不同的，因为可能刚换过不同的零件或胶水。

敏捷开发 vs. 瀑布流程的差异

传统生产模式下的瀑布式流程特性

要了解特斯拉是怎么将敏捷应用在硬件制造，你可能要先了解什么是瀑布式的工作流程。传统的生产模式，是从工业时代开始发展，它有个别名叫「瀑布式流程」，意思是它的生产模式就像瀑布一样，从上往下无法倒流。这样的生产模式有几个重要的特性：

1.生产目标非常清楚，短期内不会改变

2.材料成本昂贵，且需要较长的前置加工时间

3.各项工序间有一定的次序性，例如：要先完成防锈处理才能上漆，施工顺序不能任意调整。

「瀑布式流程」也是传统车厂最常见的做法。这几个特性导致瀑布式流程会花非常多时间在前期规划、设计，确认一切的需求和规格都没问题了，才会开始执行。

如果在执行过程中出现问题或是随意变更需求，之前花费的材料和时间就浪费了，因此执行过程中的变更管理非常严格，希望能不变就不变。很大的缺点是，在执行过程中，很容易因为需求或执行上的突发状况，花更多时间处理，反而造成时间、成本上的浪费，应变能力较低。

敏捷开发与瀑布流程的比较表

瀑布流程	敏捷开发
固定的、没有弹性的	在过程中，可能是以几周或几个月的周期来测试部分功能，然后滚动调整计划
过程中很难与客户互动	强调提供部分可评估功能，及早给客户价值，依客户反馈即时调整计划
如果一开始的需求不够清晰，或过程中需要变动，最终的结果可能会偏离期望	在整个开发的过程中，可以持续的改善，滚动调整计划，以增加新功能

敏捷开发 vs. 瀑布流程的比较表

特斯拉不用传统车厂的瀑布式流程，而是导入敏捷的做法。在特斯拉，车子被切割成了一个个独立模块，例如：车身、热汞、内饰、电池组、以及驱动模块等。

这些模块可以独立开发及运作，并在完成时可以完全组合在一起。有人形容特斯拉造车就像是组乐高积木一样，可以说是十分贴切。每一个模块团队都有自己的采购、财务、会计、电气、机械、软件工程师。团队有自己的产品负责人（PO）来决定优先顺序，也有自己的Scrum主管来移除障碍。

特斯拉团队的共同目标：提高品质、降低成本

每个模块团队都有一个共同的目标：「提高品质、降低成本」。

在这个目标下，如果你需要购买任何设备、车辆，甚至于是土地来进行测试，公司都会无条件支持你。但如果你做了几次不太聪明的决策，公司当然也会帮助你提高你的决策直觉。犯错是没有关系的，不然公司怎么会进步的这么快。只有你明显在花费上具有不正当的意图，才可能会被开除。

机器手也让硬件更新变得更简单，只需修改程序，机器手就能正确地焊接、钻孔或组装，让硬件频繁地更新变得可行，也让来自人工的影响，例如：操作工的招聘、训练、与可能的人为失误减到最低。

特斯拉的敏捷迭代周期，工厂每45分钟完成一次冲压和铸造变更；整车电子设备的循环周期则是3个小时一次。迭代更短不是为了快速生产，而是加快创新速度。而这些快速迭代是基于技术创新和高度自动化的。

每一次的产品审批，都是透过机器学习自动进行反馈的，也透过自动化反馈完成敏捷回顾。每辆车子的零件都有详细记录，包括：螺丝、胶水类型、生产人员等，如果需要召回，他们会知道需要召回哪些车。

持续检讨改进一直是敏捷最关键精神，敏捷管理下，每一轮迭代（或称为Sprint）固定会有两个品质改善会议：

第一个是Sprint检讨会议，检讨的是新产出成品的品质
第二个是Sprint回顾会议，检讨的是团队运作的品质。

尽管特斯拉刚开始生产时的组装品质经常受到批评，但在敏捷的滚动检讨精神下，品质持续提升与成本不断降低是必然的结果。

基于持续创新的精神，特斯拉已经慢慢走出自己的模式，例如：以6000吨的车体压铸机，一体成型生产车身关键结构，以节省370个零部件，减重10%，增加续航力14%。特斯拉最终目标是整车铸造，以减少更多的零件和重量，这已经不是传统车厂能轻易跟上或超越的了。

应用敏捷的十大主要挑战

不过硬件上的修改会有新的成本，不像软件只需修改程序码那么简单，硬件修改后的测试也不像测试一项APP中的新功能那么容易，以下是将敏捷的概念从软件开发走向硬件研发的十大主要挑战：

挑战一：能否采用模块化的设计

模块化的设计在软件中是很常见，APP中的功能可以藉由新增的程序模块来持续扩充，但硬件就不是这么回事。你想把车上的音响系统新增DVD播放功能，也得看音响厂商是否提供该车型的款式，不然你只能换台新车。

但硬件采用模块化的成功例子也不少，例如：电脑能透过USB接口来扩充各种不同的硬件功能、战斗机可以挂载各式新型飞弹而不需大幅修改机体结构等，重点是在不同硬件间必须有共同或明确的界面规范，让分开研发制造后，可以在共同的规范下重新连接或更新。

挑战二：各模块间的迭代长度差异

软件可以切割成较小的功能单元，在2～4周内完成设计，但硬件不见得所有部件都适用这么短的周期。同一辆汽车，不同零件模块，可能需要个别制订一个Sprint（或称为迭代）的长度，不同的迭代长度可能形成整合上的挑战。

挑战三：硬件有更高的功能相依性

软件功能可以设计得彼此独立，一个APP中的功能损坏，其他的功能仍然能用，一个新增的功能也可以不影响既有功能的运行。但硬件就不是这么回事，要加大车身尺寸，要同时考虑变更轮胎的大小，要增加第三排座椅，要先考虑车身是否够长，要更换冷气机，也要考虑电力系统的负荷能力。所以各硬件间经常会相互影响，需要全盘的考量。

挑战四：更高的变更成本

软件模块重新设计耗费的是人工成本，但硬件模块重新设计损失的可能是上百万元的模具，甚至于是全部重新设计，成本的考量非常关键。

硬件的变更成本可能远高于软件，尤其是越接近研发的后期阶段，变更的成本越高。用电脑透过软件来模拟新开发硬件的效能是常用的解决方案，或先用低成本做一个模型，验证成功之后再正式生产制造，这做法也符合敏捷「滚动修正」的精神。

挑战五：硬件有更高的专业性，很难相互支援

当软件开发进度落后时，可以集中程序员的人力来赶上进度，只要大家用的是同样的程序语言与数据库，一般来说人力可以相互支援，确保任务能如期完成。

但硬件研发不是在仓库搬东西，这边搬不完，找旁边的人来帮忙搬。会做模具的可能不懂电焊、懂胶水特性的可能不懂电机，人力很难相互支援，有任何一个模块延误，都可能会导致整体时程的延误。

挑战六：需要更长的时间来展示功能

软件的功能通常较容易展示，可以很快得到用户反馈，所以一个为期四周的研发迭代，检讨会议通常不超过四小时。硬件的新设计可能不太容易在几小时内呈现效果，例如：新设计的引擎可能需要一段时间才能测出耐用性、一个新设计的汽车头灯也需要一些时间才能测出可靠性、一个新材料的锈蚀测试可能需要一些时间才能完成。

硬件是有可能在短时间内做出经常性的更新，但评估新硬件是否优于旧硬件的等待时间将是一大挑战，评估时间或检讨会议的时长远于研发时间，不是不可能的。

挑战七：更广泛的操作环境要求

软件只需要硬件能正常运行就能运作，但硬件需要考虑操作环境，例如：温度、湿度、意外的坠落、水中操作，甚至是被打翻的咖啡，导致硬件设计更需要从整体的观点来统筹规划，而不能放任各模块各行其是。

挑战八：硬件需考虑前后工序及供应商

一件硬件的形成可能需要一连串的加工程序，所以前后段工作的衔接非常重要。部分加工程序或原材料的规格可能需要供应商的配合，但不是所有的供应商都愿意为每一个小量订单量身定做，配合你进行测试，也不是每个供应商都能如你所愿准时交货。

挑战九：硬件有更多的产业规范与规格限制

如果硬件会直接与使用者接触，就必须满足各式各样的安全规范。

例如：美国与欧盟的FCC/UL电磁波规范，让电器用品在使用时能保护消费者不受电磁辐射伤害，产品设计上在电器的外型上就要尽可能将电路板与所有的电子元件包覆起来以通过政府的测试，但包覆的过密或材料选择不当又可能影响散热，造成硬件的故障。这些都需要整体的考量，不能每个硬件模块各做各的。

挑战十：验收的难度更高

硬件的验收需要更复杂的设计，甚至是第三方检验单位的协助，所以很难判断工作是否「完成」。例如：产品外壳塑化剂的含量需要检验设备来测试，无法目视验收；车体的耐撞击性需要特殊的设备才能测试。如果可能影响人身安全，验收的过程会更加繁复。

整体来看，把敏捷概念用在硬件设计制造上的敏捷开发，可以让我们更早确认原先规划的构型或材料是否可行、是否符合客户的期望，可以提早发现问题，避免更大的投资浪费，这就是现在各大公司强调的「快速失败」（Quick Fail）的观念。

将敏捷的概念用在硬件制造上，虽然目前看起来还是困难重重，但结论就是，谁可以先解决这些敏捷硬件制造上的障碍，谁就能在未来的制造领域上持续领先。

敏捷开发：从特斯拉看导入敏捷概念的硬件制造趋势与10大挑战