软件和机械到底有何异同？

1

软件工厂

我估计很多人都已经有这个意识，传统车企向电子软件转型时，非常容易陷入机械思维，就是仍然习惯以产品测试表现来论成败，领导们往往关注的都是有没有什么问题表现，这会直接或间接地推动项目组向解Bug上聚集。

PM、测试、开发、系统、客户、QA……一拥而上，都是以Bug状态为目标导向，而对于提出的过程问题、风险问题、改善问题，往往是不说什么，甚至认为是纸上谈兵。

这样对吗？

我认为不完全对，软件和机械既有背后管理逻辑的类似，也有产品和流程本质上的差异。

机械已经历经上百年的发展，已经足够成熟了。一般来说，在研发端，流程的管控并不算严格，数模画好，模具开好，尺寸合格，然后DV&PV通过后，就意味着产品设计不会有什么大问题了，剩下的质量就是要靠工厂的标准化作业。

而把机械研发思维有意无意地用在软件开发释放上，我认为，是这些管理层最大的问题，把机械研发阶段的唯测试论作为软件可以自由“敏捷”的信心，也显然是其对软件的一种误解。

对比机械产品研发和生产的明显分离，软件开发过程其实是一个融合过程，并没有清晰的开发和生产的界限。毕竟软件一旦发版，就是简单的复 制粘贴了，不会存在原材料不良，不会存在作业过程错误，不会存在物流问题，不会受到环境温度影响，也不会依赖于设备的好坏……

对于软件，这些外界的影响质量的非标因素、管理因素都会前移，相当于每次软件释放都是一次开发和生产融合在一起的过程。

但是，背后的管理逻辑是相似的，对汽车安全的要求也是同样的。制造业生产要遵守流程，要标准化，软件“生产”也要，而不是只盯着开发的测试问题。这也是为什么早在上世纪80年代就有人提出“软件工厂”的概念。

那这里就想问个问题了？为什么大家十分认可制造业要特别重视工厂的流程化或标准化，反而到了软件，却忘记了，这可能是因为他们忽略了软件的“生产”。

做一个简单的对标，现在让大家有些反感的ASPICE有点类似于工厂标准化作业，备受追捧的敏捷开发又类似于产线柔性。

我想，不管是机械时代，还是软件时代，这是个平衡问题，不是非此即彼的问题。

2

软件产品问题不好讲清楚

另外，软件和机械的失效特点也不同，机械产品是具象的物理体，有实实在在的问题，断了，还是裂了，长了，还是短了，相对清晰可见，也会随时间延续而老化磨损。

软件产品则不同，是个抽象的逻辑体，Bug看不见，摸不着，也会偶发，还有很多潜在问题不能被识别出来，甚至一个Bug的准确描述都颇费周折，到底是什么场景造成了什么影响，有没有附带问题，很难说讲得很清楚。

抽象的逻辑本身就是两可或多可的。

此外，软件修改、维护都可能会带来新的问题。总之，软件一旦被打开过，就极可能会带来新的软件问题，也就是软件的退化，这退化基本不是可控的。

既然产品问题很难讲清楚，那么按照盯问题的管理方式也就很有局限性，所以呢，过程管理并不是过时，而是走向卓越的必然过程。

3

这事本身也不好讲清楚

尽可能去讲得明白，但说实话，想说服领导和同事不太容易。

无论是从机械时代出来的老人，还是只懂软件不懂汽车的软件人，他们都不太愿意关注复杂的流程，前者不懂软件逻辑，认为管产品就够安全，后者不懂汽车逻辑，认为不安全也无所谓，或者说也没发现多不安全嘛。

这是我们当下汽车软件转型的一大障碍，转型的第一步是技术快速积累，第二步是体系的搭建，第三步是观念的转变。实际商业中呢，大体会有以上的次序，观念的转变一般都放在最后，这是迫于现实的竞争，但观念会反哺前两者，也会是前两者的障碍。

最后总结一下，我们需要既懂软件逻辑，也要懂机械逻辑，二者不可偏废。

想必一定时间内，融合这两套知识体系和观念是我们面临的一项课题。