最近小米SU7高速碰撞起火事故上了热搜，原因不明，但抛开对逝者家属的同情外，这对当今这个礼崩乐坏如春秋般的汽车行业多少算一点好事。
至少可以让大家躺在2秒移动至100km/h的精装“家”里，回望一眼质量与安全、生命与敬畏，尽管这事大概率会如油箱、门锁事件一样，清明踏青之后就被逐渐遗忘，对行业规则与文化的推动微乎其微。
在被遗忘之前，也正好又有朋友拿这篇文章（《汽车软件质量这个活儿到底该怎么干？》）来交流，针对这个问题，写一些其他的思考，但会更高视角些，写给进阶员工或中高管理者。
1
行业还没来得及想明白该怎么干
原本打算还是按照之前一篇文章的模式，收集一下招聘JD，仔细分析一番，但在和几个典型企业的朋友交流以及看了100来份JD后，就放弃了，基本没太大变化，大体的变化趋向在于加入了AI和强化催人解决问题，前者是潮流，后者是本能。
对于前者——AI，我的观点是，一定是未来，但暂时还是辅助阶段（当然，目前也还有很多工作可做，后面会提），尤其是最近频繁遇到的不可控的幻觉、不稳定的输出、大词下的细节缺失。
对于后者——催人解决问题，规则失序后，太多的职能在本能地干这事了，并不缺软件质量再扑上去。对于1个defect，秃顶的工程师“苦迎八方来客、怒纳四海宾朋”地反复解释后，来客和宾朋捧着PPT到处去汇报自己推动解决了，这是一个笑话，请尽量不要打乱开发节奏。
软件质量应该始终明确自己的价值：通过机制的建立系统性地预防与监控，形成信任体系，保证集体的合理预期。
2
减少价值自我证明机制
价格战带来的是全方位成本压缩，从产品到人员，各类不直接交付结果的角色，就被迫地需要证明自己存在的意义。于是，你方唱罢我登场地拍胸脯、喊口号、摆数据、抢资源、不前进地拔河推手，来说明自己做了多少贡献。
这是一种错误的本末倒置的行为，职能价值应该在组织设计时就应考虑到，不同职能也应有不同的评价体系。如上段所言，软件质量着眼点在于体系化和预防。自身也应该努力通过体系化去实现“减少价值自我证明机制”，为己为人。
不过，有个真相是，软件质量确实不需要太多的人，也不需要技术专家，需要的是有能力与各种职能对话的通才，关键人员1人配比100～200人的开发团队即可。
3
致力于透明
有人的地方，就有人想掌握信息差，这就会导致不透明，而不透明会造成大量的浪费和方向性错误。
透明化的方法可以尝试以下四个：
1）大量指标的看板展示
指标可以多一点，但惩罚性指标少一点。
因为指标会简化很多因素，不准确、有漏洞是必然的，所以要从多个维度来评价，而且指标要互相制衡，即A指标的人为美化或控制会被B指标监控到。
此外，看板需要多个层级，给不同的人展示他们关心的、看得懂的不同内容。
2）文档的规范性
这个肯定会被人质疑，但软件没有数模，也没办法通过几张图纸讲清楚。让复杂的软件整个过程透明，这就是文档最大的价值。我们要避免人工的大量笨重工作，要依赖工具、依赖AI。
3）AI+工具
接前一段，AI加工具会辅助上面两件事情效率大增，不管是智能体，还是将AI接入企业内部开发工具链，都有着很好的效果。
现在我们团队已经有了一些不错的尝试，等有一定的系统性了，再和大家交流。
4）不带PPT的小会
面对面的会议还是需要的，但要小（比如，15分钟），还不能有PPT，要直接对着看板来沟通，信息要原始的，不要二次加工。对于软件质量而言，要有办法让原始信息可用。
4
术业有专攻，搭建桥梁
汽车电子软件公司里普遍存在一个现象，项目经理这类管理性角色给更上层的管理者讲一些他自己一知半解的软件内容，二者云里雾里后互相点头称是。当然，即便让真正的开发去讲，他们又会太陷入追求技术精确上，更是无法去沟通。
这个普遍现象可以通过个人技术与沟通能力的提升来优化，但仍然是治标，核心症结在于术业有专攻，讲和听的人都做了自己不专业的事，而且专业的信息没有办法流通过去。
这里有人为控制信息差的问题，更有专业链条断档的问题。
除了沟通效率低下，这种专业链条断档更会影响到软件产品的质量。
软件质量可以做一件什么事情呢？
就是把整车与代码、客户与供应商的各个层级串联起来，狭义来讲，就是追溯。
但追溯更多是工程意义上的，我们应该更往前一步，关注如何从流程体系设计与人性趋利避害的角度来保证工程追溯的持续维护与可靠。
只要地球不爆炸，层级永远存在，打通永远有价值。
写到这里，突然想到，前段时间，何小鹏接受采访时说“下面的人一直在骗我，我看不出门道”。凭这句话，要给小鹏点个赞。
5
基于问题的深度复盘
这个思路并不新鲜，8D出来都有四五十年了。
但实践下来看，带着问题一层层查下去，去识别体制上的真正根因，然后驱动改进，还是很有意义的，而意义的大小取决于这个人的能力，软件质量要花心思加强这块的水平，比如，如何发问，如何引导，如何理解。
不管这次事故的责任是否在小米，我非常有兴趣知道问题发生的根因在哪里，究竟是高速交付下的开发流程缺失，还是汽车安全文化对互联网极致体验思维的退让，还是驾驶员在营销下对于产品的过高期望（用户期望和技术发展水平的匹配是个深刻的话题，以后有机会探讨。先提一个概念——“普遍接受的技术规则”，即业内专业人士知道并认为正确的规则，其执行是符合行业或大众预期的，而且它们必须在使用中得到充分证明、广泛传播，并且必须经受住时间的考验）及自身驾驶经验的欠缺，或者这就是一起常规的交通事故，只是各种因素聚集在一起生成了一次热搜。
6
尽力扳入轨道
2025年，大部分车企的软件开发都脱离了原有的轨道。需求没定好就开发，开发做一半就测试，测试没做完就开发布会，defect还在修用户已经上了高速……这成了常态。
新能源的车轮滚滚向前，国货崛起不可逆转，个体属实难以抵抗，但我们还是需要尽量让开发在轨道上运行，信息要真实、状态要清晰、数据要可靠、标准要统一。进一步地，行业要慢一点，要有共识的秩序。否则，我们本文所讲的很多主题都是空谈，没有基础。
在这里，软件质量要促成开发留痕，并确保痕迹准确。
7
帮助项目提高效率
白热化竞争时代下，对于个体企业来说，快是被逼的，也就是应该的。
我们有责任支持团队提升效率，比如，优化冗余流程，以减少等待，提高工具的便捷性与自动化能力等。
8
写在最后
几个感想：
1）秩序混乱与信任缺失的环境下，我们对软件质量有更高的期待，即让软件开发回到正轨并重建信任。
2）汽车行业会像130多年间的很多次，终会回归轨道，一切变革下的波折乃至流血牺牲都是必然，只是我们个体最好不要被选中成为那块垫在扳道工撬杆下的石头。
3）程序正义是看得见的正义，公开透明合规也是我们汽车行业赢得公信力和成功出海的必要条件。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
