关于互联网造车的一点想法
上周末和一群汽车人有幸聚一起讨论互联网造车的话题,其中一位曾在自动驾驶车企Tesla工作,且称为T吧。其他几位都是在德国顶级车厂或供应商里浸淫多年的专家。我作为一个纯IT人士,从另一个行业视角看汽车研发蛮有意思的。面对互联网公司造车的对传统车企的野蛮冲击,到底是传统流程重要,还是快速迭代重要,是个与会者难以达成共识的问题。
以下全为回忆复述,难免有偏差。
某OEM测试:我们公司产品发布前,一定会通过2xxx标准非常严格的一系列测试。请问Q有什么流程确保行车的安全性?
T笑问:2xxx标准是什么?
某OEM测试:瞬间石化
某Supplier电池研发:德国这边任何一个汽车部件在发布或升级前,必须通过某种标准的严格测试,所有测试经手人必须签名留文档。我们部门是六个人,如果真出了大问题,这六人都可能都会牵涉法律控诉。有次产品release后第二天早上,一下收到几百份警告邮件,还直接上司被喊去参加紧急会议质问原因。因为一辆Audi出了事故,初步调查原因是因为这个新的release。我当时就蒙了,不会真去坐牢吧。还好是虚惊一场,后来查清是其它原因。
T:德国这么严格啊?!我们这里软件研发没有任何文档,什么记录都没有,无据可查。所有工程师都在全力工作,我们根本没有时间去写文档。有时拿回来的某些标准文档,几十页看下来都不知道到底讲什么,我就去找头抱怨,明明几行就能说清的问题。
我:这里软件开发必须文档化,任何步骤都需要有记录。
T:我们不允许留下任何今后可能会被控诉的文字文档。有一次我在中国试驾我们的车,发现了不少问题,我就给管理层发了个email,抱怨了一句:It’s dangerous. 结果我飞回去一到公司就被管理层拉去开会,所有人被告知,这种话决不允许出现在email或其它有据可查的文档里!
某Supplier PO:那万一顾客用这套系统开死了人怎么办?
T:公司准备了数亿现金来面对潜在的未来的控诉。我们所有的路测都是Musk去高速上测试的,我们每发布一个新版本,他就去测,没有什么测试步骤文档,就是各种开车。回来后我们根据数据改bug。他每次出去测我都提醒吊胆,因为我自己都不知道我写的程序到底有没有问题。有些程序模块,比如气温风速的计算,当通过实际路况和不同天气情况下的测试后,我自己都很非常惊讶,程序是怎么过的?
某Supplier电池研发:德国绝不可能有这种路测,只要有一人出事就完了,前年柴油机门测试作假被罚死了。
T:Musk说过,全美高速30%的事故是司机分心失误造成的,我们的Autopilot系统可以把这类失误降到1%,凭什么说我们不安全?
某Supplier码农:其实德国车厂都在紧盯着Tesla,就等着Tesla在前面冲过一个个法律界限,他们就知道那些是法律或消费者的底线。这等于是Tesla在给所有车厂铺路,同时车厂也在继续技术研发和储备,等到法律上再没有什么阻碍时,车厂就会火力全开,碾压Tesla。
某Supplier电池研发:但Tesla也不会裹足不前,它的研发也会一直前行呀?
某OEM测试:Musk有这么多公司,怎么管理过来的?
T:Musk是个非常聪明的人,他不像别的CEO不懂技术,你和他解释项目上的细节,他都懂,根本糊弄不了他。他有时甚至会让工程师给他讲解代码!他经常会提一些匪夷所思的要求。而且最恐怖的是,他记忆力非常好,你说过的什么都记得住。同时他又非常敬业,生产线有问题时,他真不是作秀,真的是睡在工厂,一周不换衣服。他是真的拼命工作。
某Supplier研发:我和同事讨论过SpaceX回收火箭和Autopilot相比哪个难度高,结论是Autopilot难度更高。回收火箭是点到点导航,之间没有突发障碍。而地面导航突发障碍太多了。
某OEM底盘研发:像Tesla这种快速研发,而忽略标准流程的做法,怎么能保证车的质量?
T:Tesla目前定位就是高端人群,是乐意尝试新鲜东西的人,这些人,会把Tesla电动车当做一种身份的象征,充电桩边上Tesla的车主往往会交谈甚欢,因为是一个圈子的人。他们享受的是车整体的设计和科技感,而不会去关注普通汽车那些质量问题。有次酒会上,有个硅谷的ceo拉着我说:你们的车真是piece of art!这个ceo之前一次在驶出高速后,开启自动驾驶擦到了个马路牙子,他去Tesla服务点,工作人员告知他Tesla只能对高速上自动驾驶产生的损坏保险。结果他自掏几千美刀修了挡泥板,却没有一句怨言。对他来说,自动驾驶带来的震撼感已经让他忽略了其它一切问题了。
某Supplier电池研发:我做一点补充。Tesla每一个车型,我们都会拿来拆了研究,同事拆完做测试后都会骂,这些部件根本不达标啊,怎么能上路的!后来我想通了,Tesla对车的定义不一样。我们做研发,往往95%的目标很容易达到,但如果我们想精进一点,达到98%,99%,那将要投入巨大精力和金钱,还有非常多的时间。Tesla怎么做的?他的目标就是达到95%!!! 比如我们做一个歀电池,标准就是任何一个电池单元绝对不能起火。但是Tesla在十年前申请了一个专利,当电池有一个单元起火时,这个专利可以延迟它关联电池单元的起火时间,这将为司机空出40秒的时间逃到车外。Tesla定的标准就是司机有40秒逃生时间,德国企业是不可能做出这样的标准的!
我:软件工程也是一样,做到完美那一丁点投入的时间非常多。
某Supplier研发:Tesla的高端顾客会把车当如一个易耗品,和你的iPhone一样,两三年换了,根本不会考虑用十年。你的iPhone会用十年吗?
大家笑。
某Supplier电池研发:Tesla现在只有高端车型,等量产没问题后,后继的面向普通消费者的车型也会推出,那时随着技术提高,质量问题也会得到改善。德企内部虽然不少人轻视Tesla,但是他们对外还是声称要向Tesla学习做革新的。他们也不愿意消费者想到Tesla就是高科技,想到他们却是老古董。
我自己的想法:传统流程重要,还是快速迭代重要,其实是市场最重要,能活下去最重要。现在的民用消费品迭代太快了,像德企那样设计一种电转生产几十年的思维其实已经跟不上现在的消费市场了。
会后我和一位OEM研发就此又延伸聊了下:
我:汽车研发和软件工程也有互通之处。比如双方都有deployment步骤,汽车release前需经过标准测试,和软件release前的黑盒白盒测试,集成测试也是相通的。
某OEM研发:我的理解是快速迭代是大家都在争取的目标,但迭代过程中对改变可能带来的系统级影响一定要在每个级别测试里cover掉,最后整体看传统开发V模型该做的事情也都得做了
我:软件发布流程其实真的一模一样,你说的这个目标现实中是个悖论。比如我们项目中间单单一个app可能有10个大模块,100个交互行为,其中小单元测试可能有四五百。我们已经用了全自动集成测试,但是任何一个feature的变动,都要整合测试跑一遍(不少测试必须人工手动测试),一次一天多。这就是导致任何小改动的全系列测试都是非常耗时的,整车的研发所涉及的模块和单元更是海量。想要快速迭代,必须像tesla那样省掉某些步骤;你想保留全套,那就不可能快速迭代。
某OEM研发:特别理解~ 我们现在做的就是不靠feature来定测试周期而是直接看release,每个feature只测自己内部的,所有的function和feature的交互测试都放在release test里。一般一个release都会有几个feature,而且release完了我们要上车测,所以这时候提前在SIL和HIL跑的结果就很重要
我:和sprint模式差不多,这种就是敏捷开发。不过实际中总是有各种各样突发问题,好像只有一种解决办法——-加班!
某OEM研发:德国加班没戏了,好在有印度兄弟们做外包,承担世界上1/3大公司的测试哈哈哈
我:好吧,印度人的活,我们只能信任一半,每次必须自己再测一次
某OEM研发:哈哈印度哥哥们的坑大家都踩过 其实美国很多团队也在做 我觉得质量超级好而且很快 就是贵… 每次感觉PM在选择外包给美国还是印度时候都陷入极度痛苦中。