對于一個現(xiàn)代化的企業(yè)來說，數(shù)字化管理系統(tǒng)非常重要。

將范圍縮小到汽車行業(yè)，企業(yè)的數(shù)字化管理系統(tǒng)大致包含了ERP（人力、資源、財務(wù)、供應(yīng)商等）、MESS（生產(chǎn)制造）、PLM（BOM、PDM、供應(yīng)商管理，有形的硬件產(chǎn)品生命周期）和ALM（需求管理、測試管理、bug管理，無形的軟件產(chǎn)品生命周期管理）。

一些汽車行業(yè)的企業(yè)，在搭建自身的車載軟件研發(fā)數(shù)字化管理系統(tǒng)中，存在的一些誤區(qū)，以及可能導(dǎo)致的一些風(fēng)險。

1.?過于關(guān)注單點問題的高效解決，而忽視了整體流程的高效管理

2.?高估了流程的獨特性，而低估了流程的通用性

3.?被動收集各類平臺數(shù)據(jù)，形成“虛假”且“臃腫”的研發(fā)數(shù)字化管理系統(tǒng)

1 過于關(guān)注單點問題的高效解決，而忽視了整體流程的高效管理

有一次我去給一家企業(yè)講解研發(fā)管理系統(tǒng)，客戶是做電驅(qū)系統(tǒng)的架構(gòu)設(shè)計與集成。我的講述思路是，如何在滿足汽車行業(yè)的三大法規(guī)標(biāo)準(zhǔn)（ASPICE、功能安全和信息安全）的情況下，實現(xiàn)從需求管理、開發(fā)任務(wù)管理、測試管理、項目管理、質(zhì)量管理等流程的全打通。

我自以為講解的還算比較充分，事實上也得到了對方實施這一計劃的工程師認(rèn)可，將我推給了其他正在創(chuàng)業(yè)的同事。

不過我也碰到了一些挑戰(zhàn)，對方的負(fù)責(zé)人質(zhì)疑說，整個系統(tǒng)是站在流程質(zhì)量和項目管理的角度來設(shè)計的，對于工程師直接提高某一現(xiàn)有工序的效率，比如幫助需求工程師更快速地、自動化地生成需求，幫助測試工程師更快地生成自動化測試用例，或者更高效地掃描出代碼缺陷等，則缺少效果。

這家公司擁有業(yè)界最優(yōu)秀的汽車工程師。事實上，他們一方面能提供最佳的產(chǎn)品設(shè)計品味、最好的內(nèi)外飾設(shè)計思路、富有競爭力的售后運維服務(wù)，但是卻在研發(fā)和運營效率上有所拖累。內(nèi)部系統(tǒng)和工具過多，數(shù)據(jù)傳輸效率低于同行。

在公司創(chuàng)業(yè)早期，人員冗余+強大的工程師個體，是一個優(yōu)勢，很容易通過賽馬機制，使得某一方提前跑出來。但是當(dāng)同行都推出車型之后，此時更考驗不同團隊的精細(xì)化管理和效率提升，龐大而臃腫的研發(fā)團隊和研發(fā)數(shù)據(jù)，反而形成了太多噪音，成為拖累。

以車載軟件開發(fā)為例，這是一個涉及多個環(huán)節(jié)的復(fù)雜過程，包括需求分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、測試驗證、部署上線以及后續(xù)的維護和更新。如果管理者只關(guān)注測試用例的自動化，或者代碼自動掃描，可能會導(dǎo)致以下幾個問題：

1. 研發(fā)流程的瓶頸轉(zhuǎn)移：即使測試用例的自動化提高了測試效率，但如果需求分析和設(shè)計階段存在問題，可能會導(dǎo)致測試階段頻繁修改用例，反而增加了工作量。同時，如果代碼實現(xiàn)階段的質(zhì)量控制不到位，可能會導(dǎo)致測試階段發(fā)現(xiàn)大量問題，導(dǎo)致測試工作量激增，從而形成新的瓶頸。

（精益管理里面，有一個很經(jīng)典的提高效率的例子。比如項目是“某五星級餐廳準(zhǔn)備晚餐”，分析其流程包含了：確定菜品、app下單買菜、小哥送菜、洗菜、炒菜、上菜。這其中不僅涉及了像炒菜這種“工序”，還包含了炒菜和上菜這兩道工具之間的交接時間。因此，為了提高整體的做飯效率，需要先調(diào)研每一個工序花費的時間，以及工序之間的交接時間，找到效率瓶頸，然后再逐點解決。可見，不僅僅是“工序”會成為效率瓶頸，工序與工序之間的“交接流程”本身，也可能成為效率瓶頸。）

2. 資源分配不均衡：過多的資源可能被分配到測試自動化上，而其他同樣重要的環(huán)節(jié)，如需求分析的準(zhǔn)確性、系統(tǒng)設(shè)計的合理性、代碼的可讀性和可維護性等，可能因資源不足而受到影響。

3. 產(chǎn)品質(zhì)量風(fēng)險：車載軟件對安全性和穩(wěn)定性的要求極高，如果開發(fā)流程中的某些環(huán)節(jié)被忽視，可能會導(dǎo)致軟件在實際運行中出現(xiàn)嚴(yán)重的安全問題或穩(wěn)定性問題。

4. 市場競爭力下降：如果因為開發(fā)流程中的問題導(dǎo)致產(chǎn)品上市延遲，或者產(chǎn)品質(zhì)量不符合市場預(yù)期，可能會導(dǎo)致公司在激烈的市場競爭中失去優(yōu)勢。

5. 維護成本上升：在車載軟件的后續(xù)維護階段，如果因為前期開發(fā)流程的問題導(dǎo)致軟件存在大量隱患，可能會導(dǎo)致維護成本大幅上升，甚至需要進行昂貴的召回。

因此，管理者應(yīng)該采取一個更全面的視角，關(guān)注整個車載軟件開發(fā)流程的每一個環(huán)節(jié)。

2 高估了流程的獨特性，而低估了流程的通用性

這里也分享一個案例，這個案例來自于我和某車載團隊一名測試leader的對話。

我和其討論的話題是：如何更好地構(gòu)建測試團隊的管理工具，以提高軟件測試團隊的效率。他向我展示，在測試管理工具層方面，他的團隊做了大量工具開發(fā)，形成了一個相對完善的測試管理系統(tǒng)，包含所有的測試用例、用例評審、測試計劃、發(fā)版計劃、執(zhí)行結(jié)果回填等等。

1. 當(dāng)我問他，整車需求和該團隊的產(chǎn)品需求、開發(fā)任務(wù)，都存在于需求管理系統(tǒng)，測試用例如何和這些需求、開發(fā)任務(wù)做關(guān)聯(lián)？----通過鏈接關(guān)聯(lián)，雙向點擊可訪問，已解決

2.?以及需求、開發(fā)人員是否能隨時訪問他的測試平臺，以方便查看測試用例和結(jié)果？----局部可以開放權(quán)限，大部分人不行，因為這個平臺是測試部門內(nèi)部的平臺

3. 其他測試部門是否也使用他的平臺？----不使用，其他部門也會開發(fā)自己的測試管理平臺

4.?為什么其他測試部門不使用他的平臺，而需要自己獨立開發(fā)？------因為每個部門的測試流程和使用習(xí)慣不同

5.?追溯性的統(tǒng)計，功能安全、信息安全流程如何支持？----暫時無法解決，也不考慮

6.?如果產(chǎn)品和開發(fā)很少能訪問他們的測試工具，那如何才能讓產(chǎn)品、開發(fā)、測試形成一個更高效的溝通機制？----

他有點犯難了，他認(rèn)為那是整個大部門的事情，他這邊沒有辦法干涉，也解決不了，所以他只能想盡辦法讓測試過程更高效，至于整體團隊的效率，他難以推動

這位測試leader雖然意識到將測試管理平臺，和需求、開發(fā)平臺一體化管理，能提高效率，他卻無法推動整個團隊往一個平臺上使勁兒和遷移。

即使他意識到，各個部門重復(fù)建立測試管理平臺，是資源的大浪費，他也無法推動其他部門使用他的工具。

這不是工程師個人能力的問題，而是因為，這是企業(yè)一把手工程。

使用不同的測試平臺，和各個部門測試流程的獨特性有一定關(guān)系，但顯然關(guān)系不大。

因為看了一遍他的系統(tǒng)，我們自己開發(fā)的MappingSpace系統(tǒng)，也能夠在幾乎不怎么調(diào)整的情況下，滿足絕大部分功能。

換句話說，我們往往容易高估企業(yè)流程的獨特性，而低估了企業(yè)流程的通用性。

這也是很多國內(nèi)公司非常喜歡做定制化系統(tǒng)的原因。

寧愿摒棄一套行業(yè)通用的平臺，也要找業(yè)余團隊定制化開發(fā)，認(rèn)為自己的流程非常獨特。往高大上了講，就是源碼可見，自主可控，隨時可調(diào)整。

不過深入分析里面的原因卻很復(fù)雜，和國民性格、復(fù)雜的采購申請流程、對產(chǎn)品的認(rèn)知、對乙方的信任、幕后交易都不無關(guān)聯(lián)。但是，自研有很大風(fēng)險。

一方面，部門之間的測試管理系統(tǒng)，差距肯定會越來越大，這樣的測試平臺，在誕生之初，就無需考慮設(shè)計的通用性。

另一方面，隨著差距越來越大，再也無法做到統(tǒng)一，此時就進入了下一個狀態(tài)——打通。請看下一個故事。

3 被動收集各類平臺數(shù)據(jù)，形成“虛假”且“臃腫”的研發(fā)數(shù)字化管理系統(tǒng)

這個故事是我和整車部門的一位大項目管理的對話，這位PM的目標(biāo)是開發(fā)整車項目管理的數(shù)字化平臺。他自述是這個平臺的第4代產(chǎn)品經(jīng)理，因為前面三代產(chǎn)品經(jīng)理都離職了，留下了一大堆還未完成的feature，他這個平臺的目的是，將各個部門、各類工具上的研發(fā)數(shù)據(jù)匯總，建立追溯性，然后在這個平臺上以更加可視化、結(jié)構(gòu)化的方式顯示出來，基于此來做更高效、更清晰的項目管理和質(zhì)量管控。

我說那這個系統(tǒng)豈不是很復(fù)雜，因為他不僅要去和各個業(yè)務(wù)部門梳理業(yè)務(wù)數(shù)據(jù)，以判斷這些數(shù)據(jù)分別屬于什么類型，然后才能和自己做的這個平臺的數(shù)據(jù)結(jié)構(gòu)做匹配。而且這似乎只是一個“數(shù)據(jù)匯總平臺”，離真正的研發(fā)流程管控還差了很遠(yuǎn)。

他表示同意，現(xiàn)階段各個部門不同的工具平臺都太多了，還有不少部門在線下管理，沒有形成線上的數(shù)據(jù)，沒有辦法去做流程管控，只能先將業(yè)務(wù)數(shù)據(jù)匯總到這樣一個平臺上來，然后基于數(shù)據(jù)再去反推流程，針對異常數(shù)據(jù)或者無法提供數(shù)據(jù)的部門，再去各個擊破。

這確實是一個很復(fù)雜、很繁瑣的工程，而且我非常懷疑這個項目在第四代產(chǎn)品經(jīng)理手上，能不能順利完工。我對這個數(shù)據(jù)匯總平臺，能產(chǎn)生多少效果，也有一些懷疑。

最終，我提了一個可能的方向：現(xiàn)在這種情況，有點像逆向工程。通過結(jié)果數(shù)據(jù)來反推過程。但是由于需要理清楚的過程涉及到太多不同的部門，以及部門之間的交互錯綜復(fù)雜，這是一個龐大得似乎看不到頭的工程。有沒有可能采用正向開發(fā)的模式，先找到一個大家都認(rèn)可的開發(fā)流程，然后將已有的流程往這個正向開發(fā)的流程的方向去靠近，最終將大家的流程梳理到一個統(tǒng)一的平臺上

總結(jié)

汽車行業(yè)的研發(fā)數(shù)字化系統(tǒng)搭建過程中，對于以下三點的考慮非常重要：

第一：要站在全局的角度設(shè)計。所謂的全局，應(yīng)盡可能依賴汽車行業(yè)的標(biāo)準(zhǔn)和法規(guī)，減少后期逆向工程來滿足法規(guī)的成本和代價。基于標(biāo)準(zhǔn)和法規(guī)，并不一定意味著繁瑣，也可以裁剪，追求更快地開發(fā)速度。

第二：中大型企業(yè)的數(shù)字化研發(fā)系統(tǒng)設(shè)計，應(yīng)盡可能讓不同部門采用相似的流程，采用相同的工具。而不是每個部門采用一套工具，最終去打通數(shù)據(jù)流轉(zhuǎn)，極易造成上述第二和第三個例子中的情況，從而拖累整體的研發(fā)數(shù)字化流程。

第三：單點效率很重要，但整體的流轉(zhuǎn)流程更重要。使用精益管理的方法，逐個分解流程中涉及的“工序”和“交接”，各個擊破，提高整個團隊的協(xié)作效率。

作者介紹：羅宇超，云體科技創(chuàng)始人，軟件質(zhì)量工程師，工具連接工程師