1.軟件工廠
我估計很多人都已經有這個意識,傳統(tǒng)車企向電子軟件轉型時,非常容易陷入機械思維,就是仍然習慣以產品測試表現來論成敗,領導們往往關注的都是有沒有什么問題表現,這會直接或間接地推動項目組向解Bug上聚集。
PM、測試、開發(fā)、系統(tǒng)、客戶、QA……一擁而上,都是以Bug狀態(tài)為目標導向,而對于提出的過程問題、風險問題、改善問題,往往是不說什么,甚至認為是紙上談兵。
這樣對嗎?
我認為不完全對,軟件和機械既有背后管理邏輯的類似,也有產品和流程本質上的差異。
機械已經歷經上百年的發(fā)展,已經足夠成熟了。一般來說,在研發(fā)端,流程的管控并不算嚴格,數模畫好,模具開好,尺寸合格,然后DV&PV通過后,就意味著產品設計不會有什么大問題了,剩下的質量就是要靠工廠的標準化作業(yè)。
而把機械研發(fā)思維有意無意地用在軟件開發(fā)釋放上,我認為,是這些管理層最大的問題,把機械研發(fā)階段的唯測試論作為軟件可以自由“敏捷”的信心,也顯然是其對軟件的一種誤解。
對比機械產品研發(fā)和生產的明顯分離,軟件開發(fā)過程其實是一個融合過程,并沒有清晰的開發(fā)和生產的界限。畢竟軟件一旦發(fā)版,就是簡單的復制粘貼了,不會存在原材料不良,不會存在作業(yè)過程錯誤,不會存在物流問題,不會受到環(huán)境溫度影響,也不會依賴于設備的好壞…… 對于軟件,這些外界的影響質量的非標因素、管理因素都會前移,相當于每次軟件釋放都是一次開發(fā)和生產融合在一起的過程。
但是,背后的管理邏輯是相似的,對汽車安全的要求也是同樣的。制造業(yè)生產要遵守流程,要標準化,軟件“生產”也要,而不是只盯著開發(fā)的測試問題。這也是為什么早在上世紀80年代就有人提出“軟件工廠”的概念。
那這里就想問個問題了?為什么大家十分認可制造業(yè)要特別重視工廠的流程化或標準化,反而到了軟件,卻忘記了,這可能是因為他們忽略了軟件的“生產”。
做一個簡單的對標,現在讓大家有些反感的ASPICE有點類似于工廠標準化作業(yè),備受追捧的敏捷開發(fā)又類似于產線柔性。
我想,不管是機械時代,還是軟件時代,這是個平衡問題,不是非此即彼的問題。
2.軟件產品問題不好講清楚
另外,軟件和機械的失效特點也不同,機械產品是具象的物理體,有實實在在的問題,斷了,還是裂了,長了,還是短了,相對清晰可見,也會隨時間延續(xù)而老化磨損。
軟件產品則不同,是個抽象的邏輯體,Bug看不見,摸不著,也會偶發(fā),還有很多潛在問題不能被識別出來,甚至一個Bug的準確描述都頗費周折,到底是什么場景造成了什么影響,有沒有附帶問題,很難說講得很清楚。
抽象的邏輯本身就是兩可或多可的。
此外,軟件修改、維護都可能會帶來新的問題??傊?,軟件一旦被打開過,就極可能會帶來新的軟件問題,也就是軟件的退化,這退化基本不是可控的。
既然產品問題很難講清楚,那么按照盯問題的管理方式也就很有局限性,所以呢,過程管理并不是過時,而是走向卓越的必然過程。
3.這事本身也不好講清楚
盡可能去講得明白,但說實話,想說服領導和同事不太容易。
無論是從機械時代出來的老人,還是只懂軟件不懂汽車的軟件人,他們都不太愿意關注復雜的流程,前者不懂軟件邏輯,認為管產品就夠安全,后者不懂汽車邏輯,認為不安全也無所謂,或者說也沒發(fā)現多不安全嘛。
這是我們當下汽車軟件轉型的一大障礙,轉型的第一步是技術快速積累,第二步是體系的搭建,第三步是觀念的轉變。實際商業(yè)中呢,大體會有以上的次序,觀念的轉變一般都放在最后,這是迫于現實的競爭,但觀念會反哺前兩者,也會是前兩者的障礙。
最后總結一下,我們需要既懂軟件邏輯,也要懂機械邏輯,二者不可偏廢。
想必一定時間內,融合這兩套知識體系和觀念是我們面臨的一項課題。
審核編輯:劉清
-
汽車軟件
+關注
關注
0文章
102瀏覽量
3209
原文標題:軟件和機械到底有何異同?
文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論