（质量部）
现在整车厂软件开发越来越复杂，有自研、有外包、也有联合开发，这时候搭建质量体系的着眼点在哪里呢？既然要做就参考行业标准吧，既然现在一说到汽车软件开发都会提起ASPICE，就按照这个标准做做看吧！
（软件团队）
搞ASPICE？这群搞汽车质量的对软件都是外行！知不知道搞这些文档要花多少人力！计划跟踪文档要写、需求设计要分层、追溯性要建立、还要一大堆的检查表评审记录，说人力翻倍都是保守的，这年头招一个能干活的人有多难，精力都用来搞这个了谁来写代码啊。应付16949的审核是客户要求的没办法，搞ASPICE还是省省吧！
（质量部）
搞ASPICE阻力太大推不下去，什么都不搞嘛上头又没法交代，要不就从已有流程往软件里推先做个一两件事，流程FMEA（PFMEA）、设计FMEA（DFMEA）什么的都做了，就让软件FMEA（SW FMEA）也做起来问题总不大吧？
（软件团队）
软件FMEA？没听说过，问题的why-why分析横展开倒是有的，让大家往这个表格里面填是不是有点生搬硬套了？软件如此庞大，边界图如何限定范围？结构分析的时候硬件有属性，软件的属性是什么？穷尽的功能性/非功能性要花多少工作量知道么，如何安排优先级？如何确保产品特性不遗漏？构建功能网聚焦元素在哪一层？七种失效套用到程序代码里怎么考虑？功能网与失效链的关系怎么建立，那还不是要按ASPICE那一套搞双向追溯嘛？软件的SOD（严重度/发生度/探测度）怎么算？预防和探测措施和跟踪优化我们横展开里面有做过了，抄过去不是浪费时间么？——这些问题回答不了，软件FMEA没法做！
（质量部）
行业标准（例如ASPICE/CMMI）推不下去，传统方法（例如FMEA）又不对路，那就从现有开发实践中收集提取，整一个适合公司“司情”的质量体系吧。
（两个月过去了）
完全没有头绪！现有的开发实践一个项目一个样，模板指南没法定制；度量数据的定义的进展也不顺利，光是定义工作量的单位就够头疼的——不管是代码行数、功能点还是story points都没法达成共识；软件团队拼命加班，要整理出个流程改进的措施总得明白原因吧，天天叫“缺人”偏偏又缺少数据支持说不清问题在哪怎么协调到资源呢……
汽车软件的乌卡时代
随着“软件定义汽车”的“乌卡（VUCA）”时代来临，建立汽车软件质量体系已经成为了行业公认的难题——
- V=Volatility（易变性）：汽油车到电动车、锂电池到氢能源、自动驾驶L1到L5、中美欧日群雄逐鹿……现在的汽车行业说是战国时代并不为过，无论技术的日新月异还是市场的风云变幻都让人应接不暇。
- U=Uncertainty（不确定性）：在快速变化之下，把握其中的规律就变得非常困难，仿佛一切都是不确定的，从瀑布模型到敏捷、从敏捷到规模化敏捷，往往流程定义刚刚完成市场的需求就已经不一样了。
- C=Complexity（复杂性）：为了应对各种不确定性，从政府法规到行业标准再到主机厂流程，各类需求层层加码，代码亿行起步的程序其中架构复杂自然不言而喻，更要满足功能安全、网络安全、代码规范、开源授权等等框架。
- A=Ambiguity（模糊性）：如此复杂的背景下，作为人类的我们要看清本质的难度可谓几何级数的增加，而偏偏“没有规矩不成方圆”，哪怕搭建了质量体系哪怕有了度量手段，其效果也许还是模糊不清，有如“薛定谔的猫”无法确定……
虽是难题在前，但硬着头皮也得把汽车软件体系的质量体系给DIY出来；
虽是看不到路，但只要踏出了第一步，就还有希望；
虽被百般吐槽，但反复试错持续改进，总有做成的一天。
开始《汽车软件质量体系DIY》系列，正是因为在汽车软件体系质量体系的构建和落地中遇到了太多的迷惘需要厘清思路。纵观各行各业，随着软件在越来越多工业领域中占据更重要的地位，汽车、机械、能源、航空航天、医疗器械……更多的实践更深的思考，对于把握未来相信也会有所帮助。
