1.軟件工廠

我估計很多人都已經有這個意識，傳統車企向電子軟件轉型時，非常容易陷入機械思維，就是仍然習慣以產品測試表現來論成敗，領導們往往關注的都是有沒有什么問題表現，這會直接或間接地推動項目組向解Bug上聚集。

PM、測試、開發、系統、客戶、QA……一擁而上，都是以Bug狀態為目標導向，而對于提出的過程問題、風險問題、改善問題，往往是不說什么，甚至認為是紙上談兵。

這樣對嗎？

我認為不完全對，軟件和機械既有背后管理邏輯的類似，也有產品和流程本質上的差異。

機械已經歷經上百年的發展，已經足夠成熟了。一般來說，在研發端，流程的管控并不算嚴格，數模畫好，模具開好，尺寸合格，然后DV&PV通過后，就意味著產品設計不會有什么大問題了，剩下的質量就是要靠工廠的標準化作業。

而把機械研發思維有意無意地用在軟件開發釋放上，我認為，是這些管理層最大的問題，把機械研發階段的唯測試論作為軟件可以自由“敏捷”的信心，也顯然是其對軟件的一種誤解。

對比機械產品研發和生產的明顯分離，軟件開發過程其實是一個融合過程，并沒有清晰的開發和生產的界限。畢竟軟件一旦發版，就是簡單的復制粘貼了，不會存在原材料不良，不會存在作業過程錯誤，不會存在物流問題，不會受到環境溫度影響，也不會依賴于設備的好壞…… 對于軟件，這些外界的影響質量的非標因素、管理因素都會前移，相當于每次軟件釋放都是一次開發和生產融合在一起的過程。

但是，背后的管理邏輯是相似的，對汽車安全的要求也是同樣的。制造業生產要遵守流程，要標準化，軟件“生產”也要，而不是只盯著開發的測試問題。這也是為什么早在上世紀80年代就有人提出“軟件工廠”的概念。

那這里就想問個問題了？為什么大家十分認可制造業要特別重視工廠的流程化或標準化，反而到了軟件，卻忘記了，這可能是因為他們忽略了軟件的“生產”。

做一個簡單的對標，現在讓大家有些反感的ASPICE有點類似于工廠標準化作業，備受追捧的敏捷開發又類似于產線柔性。

我想，不管是機械時代，還是軟件時代，這是個平衡問題，不是非此即彼的問題。

2.軟件產品問題不好講清楚

另外，軟件和機械的失效特點也不同，機械產品是具象的物理體，有實實在在的問題，斷了，還是裂了，長了，還是短了，相對清晰可見，也會隨時間延續而老化磨損。

軟件產品則不同，是個抽象的邏輯體，Bug看不見，摸不著，也會偶發，還有很多潛在問題不能被識別出來，甚至一個Bug的準確描述都頗費周折，到底是什么場景造成了什么影響，有沒有附帶問題，很難說講得很清楚。

抽象的邏輯本身就是兩可或多可的。

此外，軟件修改、維護都可能會帶來新的問題。總之，軟件一旦被打開過，就極可能會帶來新的軟件問題，也就是軟件的退化，這退化基本不是可控的。

既然產品問題很難講清楚，那么按照盯問題的管理方式也就很有局限性，所以呢，過程管理并不是過時，而是走向卓越的必然過程。

3.這事本身也不好講清楚

盡可能去講得明白，但說實話，想說服領導和同事不太容易。

無論是從機械時代出來的老人，還是只懂軟件不懂汽車的軟件人，他們都不太愿意關注復雜的流程，前者不懂軟件邏輯，認為管產品就夠安全，后者不懂汽車邏輯，認為不安全也無所謂，或者說也沒發現多不安全嘛。

這是我們當下汽車軟件轉型的一大障礙，轉型的第一步是技術快速積累，第二步是體系的搭建，第三步是觀念的轉變。實際商業中呢，大體會有以上的次序，觀念的轉變一般都放在最后，這是迫于現實的競爭，但觀念會反哺前兩者，也會是前兩者的障礙。

最后總結一下，我們需要既懂軟件邏輯，也要懂機械邏輯，二者不可偏廢。

想必一定時間內，融合這兩套知識體系和觀念是我們面臨的一項課題。

審核編輯：劉清