荐言：修文兄的新书《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》终于出版了！这本书凝聚了作者在OEM与Tier. 1 十余年的技术开发与管理的实践与思考。系统地阐述了汽车软件产品的开发方法、流程体系、项目管理等，这对当下正处于软件定义汽车转型的汽车行业从业者极具参考价值。在这里特别推荐给广大的读者。(文末有购书链接，618前限时5折）本文节选自此书的第九章《转型软件的痛点与困惑》，我几乎被每一段的标题吸引，这不就是我们当下正在面临的痛点么？且看段落标题：
互相低不下的头颅
硬件交样与软件迭代的冲突
对敏捷自身价值的质疑
依旧太高的信息壁垒
ASPICE的爱与恨
bug怎么这么多
欲拒还迎的转型
在写本文时，刚刚参加了几个技术研讨，软件、新能源、AI、转型、SDV、SOA......对于业内处于迷乱的从业者，光看会前的日程介绍，心心念念地觉得是饕餮之盛宴，可让自己从乱如麻的局里脱困。但是，期望越高，失望越大，讲演者同样处于迷乱中，间隙的闲聊中，不乏“光给问题不给答案”“他所说的我也知道啊”“他们做得也就那样”“只不过是广告宣传”的怨念之词。我也同样在口嗨几句之后，回过头来又细想了一下，期待这些个别同行就能解决困扰整个行业的痛点与困惑，实为妄念，总结并抛出这些挑战已经是一种贡献。而答案的找寻需要时间和地位。时间的大浪淘沙作用最具说服力，可以筛选出那些真正有价值的观念、观点、方案；地位的马太效应则印证了“以成败论英雄”的商业世界铁律。回到现实工作。既然行业格局在被打乱，我们都想成为被选择的人，面对纷乱，首先得知道我们乱在哪里，这个问题的答案其实挺难，因为这乱很多时候是在脑子里，大家都觉得乱糟糟的、做得不好，但又不知道怎么算好，或者也不笃定是不是真的不好，所以抛问题出来就有了意义。01.
互相低不下的头颅
这一节的灵感来源于最近和一位互联网同事的争论，我认为他缺少对造车复杂性的理解，他认为我没有软件与用户的思维......
也不仅仅是个人，这几年，现实中不乏看到各种经验背景的人才、各种演变历程的知识体系、各种文化基因的公司在大融合过程中的各种思想撞击与冲突。
或许，百舸争流之下，应尽量开放与包容，虽知易行难，但多听多做。以项目目标导向的思维来看待，硬件（包括机械）交样及组装与软件迭代及交付成为传统汽车业与现如今（或将来的）汽车业各自显著的代表，而这二者的显著差异也成为汽车行业转型路上的一些障碍。2.1 硬件交样
早期也做过机械件的开发管理，当时最恐怖的一件事是什么呢？PV 失效。依稀记得当年面对第一次PV 失效时茶饭不思的场景。在机械开发中，我们依赖的是成熟的技术积累，一次尺寸合格、一次测试通过似乎是理所当然，正常项目计划里并没有安排失败返工的空间，所以一旦遇到失效，尤其是马上SOP 时的 PV 失效，心里的慌乱定是难以自持，万一再遇到时间损失和财务成本巨大的修模，接下来，就更是一个又一个的失眠与救火之夜了。
传统“黑盒子”ECU的开发尚可，毕竟对于不承担运动与匹配功能的常规ECU而言，机械和硬件的变动很是稀少，而软件本身的“软”让其迭代个一两次也没什么问题。技术的稳定和变化的可控之下，一次通过的概率和期待也都是比较高的，再加上，多数情况需要软件刷写到硬件里来统一按时交付，面对的还是固定的里程碑，与机械件一样。这时，还没有软件迭代与交付的概念。2.2 软件迭代
时代显然在变化，更多的新需求、更多的玩家、更多的合作模式、更多的交互、更多的软件，这都让传统的按里程碑交样的思路受到了一定的冲击，尤以智能座舱为代表，频繁的软件迭代和软件交付越来越不鲜见，原本纯软件领域的常规操作小场面成为汽车人没见过的“大场面”。在以前，供应商凭借稳定的供应链和成熟的方案定时定点地交付样件，基本不成问题。OEM则掌控主动权，供应商都要按照OEM的节奏来，如果供应商让OEM停线，那么它们将面临巨额的赔偿。可是现在，整个涉及大量软件的产业链都处于一片混乱之中，上一个方案还没搞清楚，新的需求就来了；这个需求刚做一半，又被要求更改，而好不容易改好的方案，还测出来一堆bug......眼看着时间一点点流逝，OEM工程师催促供应商赶紧改、赶紧交，不然就要投诉，但供应商却表示，你们领导已经投诉过了......大家面对来软件都有些无奈，这让以工程严谨性著称的汽车工业感觉到了一定的失控，就像一队按部就班向前推进的军队方阵，没大搞软件的地方还算稳健，哪里想大搞，哪里就炮火连天。总之，软件虽在频繁迭代，但总还有未尽需求与未解bug，当到了交付时间点，这些半成品还不得不进入统一调度的硬件交样组装模式里，水土不服自然是预料之内的，分处于两种模式阵营中的人都是三省吾身后五省对身。怎么融合软硬件的开发交付，就成为一个待解决的难题。软件频繁迭代与交付的特点在汽车业里甚是扎眼，如何消除这种不适？大家都在寄希望于敏捷，敏捷的基本诉求在于价值。但在其致力于价值的过程中，还是引起了大家对其本身价值的质疑。3.1 水土不太服的敏捷
这两年，大家开始把敏捷谈得风生水起。
总之，一番操作下来，领导觉得SOP可以提前了，项目经理觉得团队可以自组织了，开发人员觉得可以不用加班了。然而，迁延一段时日之后，项目跌跌撞撞还是要延期，散漫的团队一问三不知，坐等时间盒的开发人员还得加班追时间......于是，软硬件解耦、OTA升级、娱乐与底盘差异化开发、大规模敏捷等概念又出来了。时至今日，尽管各位专家同仁都有不同的思考和尝试，但与敏捷实效的距离似乎仍然不小，渐渐地，很多人开始失去了耐心。
3.2 敏捷的现状约等于“乱”
最接近互联网行业的汽车软件就是车机，即现在的智能座舱或娱乐系统，这也是现在造车最喜欢玩儿的热点，原因有三。
所以，最适合走敏捷的就是车机及其他各类大小屏。那么，效果如何呢？整个行业看起来都似乎一般。需求不进系统了、基线不打了、文档不维护了、bug也看心情修了......美其名曰，我们是走敏捷的。当然，车机即便卡死，听起来也没那么害怕，这里只是想说仅仅把项目管理的严格度降低似乎和敏捷关系没那么大关系，也不是敏捷的初衷。除了车机，其他的一些或供应商或OEM的软件也有局部的敏捷试点，但在整车网络架构和整车里程碑约束的前提下，所谓的敏捷更多在于形式上或称呼上，至少小范围受约束的试行看不到太明显的收益，无论是时间、成本，还是所谓的价值。当然，理论上我也认为娱乐系统作为能够导入更多不确定需求的产品，是适合敏捷的，但可能还未摸索到一个好的方式。或者说在当下的技术成熟度、需求不确定性、管理复杂性、新场景清晰度等综合维度下，对敏捷这板斧头的需求还没那么高。敏捷的价值就在于着眼“价值”，以及包括其他的快迭代、小批量、多交付、重视人、消除浪费等，而这些在丰田汽车的精益体系面前又着实属于后辈。汽车工业属于制造业的皇冠，工厂运营已经进入到了高度的成熟化和标准化，JIT（Just In Time，准时化生产）、看板、拉动、零库存、单件流等模式已经在相当多的汽车主机厂或零部件工厂落地生根。相比较工厂精益生产的高效交付价值，更多停留在理念阶段的非标化敏捷反而是稚嫩的、落后的。当然，从另一个角度理解的话，汽车精益制造毕竟是在相对稳定与成熟环境下发展的，如果把敏捷的非标性作为新兴汽车时代内生的属性，它倒又成了先进的代表。敏捷之下，非标和标准化成为最难平衡的一个点。这种难以把握与平衡又会引出下一小节的话题。敏捷应该作为意识，这一论述在很多敏捷相关的专著或者推行敏捷的咨询师的认可。敏捷是一种意识、一种理念，是武术内功，套路只是众多形式之一。此外，还有很多其他的争论，方法论、模型、思想、哲学、文化等。打个比方，我们初中政治学过的“抓住重要矛盾”是不是和敏捷关注价值的思路相合呢？孔子的中庸之道是不是也和敏捷的平衡理念接近呢？……敏捷有形可见（比如Scrum），敏捷更是不可见却无处不在。对，这是一种听起来很有道理的观点，可要是偏向了这个观点，就也从另一个角度放弃了敏捷，将敏捷认为是一种“务虚”的存在，似乎就意味着我们常规意义的敏捷不存在了。所以，当我们决定或宣布要采用敏捷方法时，依然脱离不开那些框架，依然要走一些形式，这种要把握某种恰到好处的分寸的感觉实在不容易。封闭是汽车行业的一个典型特点，信息壁垒也自然是高筑。
存在即合理，信息也是一种资源，处于不同位置的每个角色都有不同的利益诉求，所以把握信息差就把握了先手的机会，壁垒的形成有着人性趋利避害的力量的推动。另外，知识产权也是提高行业积极性的手段，应当鼓励。然而，如今我们处于转型浪潮中，如果只看弊端，显然信息壁垒也是带来了不少障碍。在百年汽车工业的发展历程中，或考虑解耦与并行，或考虑外包的低成本，或考虑专业化协作，又或考虑其他种种原因，主机厂一般都集中在整车属性定义与验收、造型设计、品牌渠道开发、供应链管控、零部件组装这些方面。除了动力总成和白车身的一些附属件，主机厂的参与度稍高些，其余多数零部件都是分包给几十或几百家供应商来做的。简单来说，我只负责提要求、验收及从宏观体系标准上把控，剩下的交给你来做。慢慢地，精于细微的供应商掌握了越来越多的Know-How，信息差带来了话语权。为了避免主机厂诸如年降之类的不断压价，也为了保持自己垄断的市场地位，供应商开发的模块越来越集成化，交付的产品也都是黑盒模式。平常主机厂想看看FMEA、设计文档、技术参数等，供应商都会以保密为由拒绝提供。那时的市场还宽裕，形成了平衡的态势。多方因素下，被传统汽车称为“野蛮人敲门”的新势力闯了进来，平衡被打破。它们绕过三大件、钻研新能源、打造智能化、注重客户体验、营销能力也是一流，大量的新供应商也随之而来，终端客户发现了新奇的感觉，价值链在向软件转移，新生态被营造，而原有的供应链依然可以共享。整个汽车市场以出乎大家意料的速度被瓜分或重新划分。当传统主机厂开始考虑如何应对、如何打造差异化、如何实现智能化时，它们才意识到自己在长期的黑盒交付和红利蜜罐中，早就没有了定义能力。没有办法，重新建立自研能力、投资独立软件公司，志在打破僵局，但仓皇组织起来的一支团队也是困难重重。更何况，很多软件团队依然是由来自底盘、发动机、内饰的领导来管理，更需求透明的软件开发似乎仍然受着某种神秘力量的牵绊。而传统零部件也并没有更顺心，面对着传统主机厂的困境、互联网的新技术、EEA的演变、功能定义权的流走，看着自己手里的黑盒子，往日的金光似乎在暗淡下去。这么多年来，黑盒子不单是给主机厂，也给庞大的内部团队，大家各做各的，业内的不知道业外的，本土的不知道国外的，软件的不知道硬件的，系统的不知道组件的，跨供应商的产品更是难以兼容。数据深井、信息壁垒也推着行业发展的车轮绕着自己走，看着滚滚尘烟，疲于转身，也是心力交瘁。4.2 互相制衡的文化
说到互相制衡的文化，帝王御人之术有几千年的历史的，100岁的汽车显然仍是婴儿。很多人非常痴迷于这种政治博弈的理念，也算是所谓管理学的一部分吧。对于参与管理的“帝王们”，互相制衡、互相掣肘已经成了第一课和最重要的一课。不过，好消息是，工程师们倒还单纯些。这会带来一件很蠢的事情，就是重复造轮子。有时候，我们会发现，公司里不同的人在用不同的方法向不同的方向做同一件事情，直到结果暴露的一刻，再进行一番较量，结果很可能是这件事情早在半年前就由另一拨人证明了没必要做。在日常工作中，看到的文件版本很老了、你没有权限访问这个系统、这保存在我本地盘上、这个我不清楚应该是张三负责但估计只有李四知道......这类事情层出不穷，软件工程的一大关注点就在于让信息透明，包括在9.5节要讲的ASPICE以及敏捷里提的信息发射源也是这样的目的。最令人沮丧的是，所有这一切，所有人都知道，心照不宣，或宣而不发。ASPICE一度很鼎盛，认证此起彼伏，L2、L3的宣传也是沸沸扬扬。尤其是新势力刚刚入场、汽车行业刚刚张开怀抱迎接智能软件的那几年，汽车行业刚开始做软件几乎就是左手边摆着ASPICE、右手敲代码。很合理，脱胎于CMMI并针对汽车软件产品定制的ASPICE，早已经是传统汽车电子巨头的基本流程骨架，有成功先例、有最佳实践，为何不使用呢？
随着软件在汽车中的深入和拓展，预期的价值并不直观，落地也非常困难，大家对ASPICE的信心开始下降，也逐渐将其推入爱之深又恨之切的矛盾中央。
ASPICE确实很好，这是从它的形式和工程逻辑来看的，如果一个项目慢慢地、精细地完全按照ASPICE做下来，会成为一个非常漂亮的项目，井井有条，环环相扣，挑不出毛病来。理论上，软件质量也应该是过关的。
但是漂亮的背后是十分严谨的、按部就班的工程推进逻辑，有追溯、有策略、有计划、有跟踪、有结果、有评价、有反馈，它是个非常经典的汽车软件开发模型。业内主流企业中绝大多数产品的开发模式基本都能被这个框架所覆盖。所以，当我们面对一个功能安全级别很高的产品、一个跨汽车跨其他行业的团队、一个与硬件耦合性较高的软件或者有多层级关系的供应模式，甚至一个完全没做过车载软件的团队开始工作时，ASPICE都是一个非常好的参考与理解模型，它有助于大家拉平认知、统一规则，也是进一步优化、适配的基础。回看ASPICE的应用历程，其实会发现，汽车电子Tier 1在开发、供应ECU给主机厂的过程与ASPICE的结构非常匹配。或者换句话说，ASPICE正是为供应链的这一段量身定做的。继续沿着这个角度往下讲，我们也会发现，想执行好ASPICE的门槛实际上是很高的。长期的技术积累与理解可以让架构按层级拆分，同时，这也需要精细化的甚至显得很冗余的角色与流程来匹配，复杂的流程一定会带来缓慢的动作和高昂的成本，而如果市场能够允许你缓慢，那就说明你有足够的市场地位与领域话语权，这些多重的因素都不是唾手可得的。这也是为什么，时至今日，也只有那些大型的传统汽车电子公司，才能算得上在认真执行ASPICE（实际上，也已经开始承受不住了）。接着上一小段的那个情形看，反过来说，为什么多数公司都推行不下去呢？它糟糕在哪里呢？就是因为江湖动荡，大家实在无福消受缓慢而昂贵的ASPICE，吃饱尚且困难，谈什么举止优雅、穿着得体。
另外，从产品属性变化来看，从需求规范到用户故事、从测试验证到体验感受的工程思路都也有了巨大变化，如最知名的智能座舱与智能驾驶，座舱用着Android系统、专注于人机交互，智驾关注机器算法、不断挖掘着长尾场景，这实在不是脱胎于传统ECU的ASPICE能够严丝合缝对应的，如果强行解释，只会让ASPICE显得很复古。于是，风向转向了敏捷，但9.3节又刚讲了敏捷的痛苦，也算是进退维谷了。06.
bug怎么这么多
代码行数越多，打开软件的次数越多，参与软件开发的人越多，带来的bug必然越多。
我们似乎自问自答地回答了标题的问题，新型功能、强算力芯片不断累加需要频繁的软件迭代，而软件发版越多需要的人也越多，这让我们所有人都在球门前混战，心力交瘁。如若守得住还好，但实际上，在项目周期内，当软件交付时，即便是嵌入式ECU，真正的bug量也常以千计，要是再看座舱和智驾，数以万计这个词都显得苍白。而由于一个新项目的周期被极致压缩后，这些发现的、没发现的问题继续流到量产的现象也不鲜见，但那时就是有心而无力了。这种不堪可以总结为两个词，“发现不了”和“修复不完”。
6.1 前期发现不了
发现不了是指在前期发现不了，在后期才发现，而不是永远发现不了，永远发现不了就是没有。发现bug的时间越晚，影响越大——这个道理自是不必多说。
bug发现不了有两种潜在的原因：
另一种就是发现了却修不完，时间不够，拆东墙补西墙，修了3个带来5个，来不及做回归测试和风险评估......最开始，要注重安全与质量，零星的bug得清零，这也是大家的共识。慢慢地，有些bug实在找不到原因或者属于偶发情况，软件经理开始给大家刷新认识——软件有bug是正常的，但还得经过相对全面的风险评估和审批。再往后，软件代码量开始激增，奇怪的现象也越来越多，再加上经验丰富的人员流失和交付时间的紧迫，想要做出一个可靠的评估也是心有余而力不足。就像火势蔓延时，我们只能尽力救火，而无法再去考虑防火的事情了。07.
欲拒还迎的转型
其实这里主要是针对传统主机厂和零部件而言的，新势力、初创本身就是要“新”。
传统的汽车企业自是面临大船难掉头的困境，投鼠忌器。转吧，业务的阵痛、各方势力的抗拒、转型的风险、原有竞争力如何维持等都让所有人驻足观望；不转吧，日益下滑的销量、越来越少的项目订单、不断降低的EBIT（Earnings Before Interest and Tax，息税前利润）、持续走低的市场份额等也都让人焦虑不安。写到这里，我突然想起五六年前接触的一家做内饰的Tier 1，它竟然开始做起了广告和周边产品，当时是觉得有点突兀，Tier 1做大众营销确实比较少见，以往更多地只需要主机厂认可即可。几年过去了，效果如何呢？该公司的境况依然不错，市场份额小幅提升，主要竞争对手也将这部分业务剥离出售，比当时的预期强不少。我们无法通过这个案例证明面向大众营销、给消费者讲故事与销量的正相关关系，但无论是消费者，还是从业者，都前所未有地感觉到汽车走进了传媒中心。那么，刹车失灵、电池自燃这些不断入耳的传媒信息不会影响消费者决策吗？这样看，它们之间似乎确实存在着一些微妙联系。伴随着移动互联网将人们的生活推向热搜年代，这种微妙让主机厂与零部件都开始尝试在营销上发力，但同样是因为太微妙、直接给的效果还没拉满，讲故事的坚决还不足，讲故事的水准也比较粗糙。当然，二者也是相关的。分庭抗礼的市场格局被打破后，厮杀的汽车市场需要新意、需要亮点，当打算推出一款新产品或新车型时，得需要一个卖点，不然，客户凭什么买你的产品？7.2 转向体验感
讲故事与体验感也是相关的。通过讲好的故事，将消费者显性或隐性的需求潜移默化地与某款车绑定起来，这个品牌将会给你带来精神上的愉悦感、满足感。比如，有些车特别贵，但能卖得动，实际上，带有“贵”的品牌形象才是它的核心卖点。如果我们作为一个潜在的消费者，会不由地带着某种营销下的观感，去将某些品牌列入待选清单。然后，开始一家一家走进4S店或商场体验店。在服务人员的引导下，从第一眼的造型与颜色开始，到打开门、调整座椅、感觉空间、握方向盘，再到摸内饰、点车机，以及试驾时的启动、转弯、加速、刹车等一系列的操作结束后，再问一下价格......在这大约一小时的时间里，或多或少都有一些劝买或劝退的点，这些点幻化成一种东西，就是感觉，即体验感。毕竟，参数都很漂亮，基本功能都差不多。这种让人舒适或不适的体验感，很大程度是依赖于智能化的。我曾经体验过一款车，打开车门，座椅会自动略微面向车门旋转，并稍稍靠后，以便人直接坐上去，而人坐上去后，座椅又会以一个恰到好处的速度调整到比较适合驾驶人体型的位置。这个功能点一下子打动了我，让我想起以往拉座椅滑轨的费力，或者等待电动座椅调整的烦躁感。08.
小结
本章讲的话题比较宽泛，却也是我们在整个转型过程中始终面临的一些具体问题的总结，从从业者心态开始，到软硬件差异的处理，再到要掀翻传统汽车开发流程桌子的敏捷，都让人感觉到强烈的冲突感与断裂感。一直为人诟病的信息壁垒，让大家做事磕磕绊绊及频繁重复造轮子，ASPICE倒是致力于提升软件开发的透明度，但其繁重的步骤又和当下价值导向的环境与体量激增的软件规模不符，很难落地。无奈之下，整个开发的质量把控落入了关注验收测试、修复bug，忽略前期预防的恶性循环中。既然现状如此艰难，是不是得转型？然而转型的路并不平坦，其中涉及的讲故事、体验感都是以往汽车行业所陌生或不屑的东西。如今我们身处变革的风暴中，背负着沉重的包袱，欲拒还迎地踏上转型之路，也算是苦不堪言了。以上是分享的节选内容，更多精彩内容，可以通过以下链接购买本书：这是一本从技术与管理角度全景式介绍智能汽车电子与软件的著作，涵盖行业背景、组织架构、项目管理、软件开发方法、系统集成、流程体系、人员搭建、核心标准、开发工具链、痛点及展望等核心内容。本书是作者在博世等头部Tier 1与OEM企业10余年技术与管理经验总结，得到了来自华为、腾讯、广汽、长城、极氪、蔚来、小鹏等20余家车企和机构的25位专家高度评价和推荐。本文摘编自《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》，机械工业出版社出版，经出版方授权发布，转载请标明文章来源。
