2090
對于一個現(xiàn)代化的企業(yè)來說，數(shù)字化管理系統(tǒng)非常重要。
將范圍縮小到汽車行業(yè)，企業(yè)的數(shù)字化管理系統(tǒng)大致包含了ERP（人力、資源、財務、供應商等）、MESS（生產制造）、PLM（BOM、PDM、供應商管理，有形的硬件產品生命周期）和ALM（需求管理、測試管理、bug管理，無形的軟件產品生命周期管理）。
一些汽車行業(yè)的企業(yè)，在搭建自身的車載軟件研發(fā)數(shù)字化管理系統(tǒng)中，存在的一些誤區(qū)，以及可能導致的一些風險。
1.?過于關注單點問題的高效解決，而忽視了整體流程的高效管理
2.?高估了流程的獨特性，而低估了流程的通用性
3.?被動收集各類平臺數(shù)據(jù)，形成“虛假”且“臃腫”的研發(fā)數(shù)字化管理系統(tǒng)
1 過于關注單點問題的高效解決，而忽視了整體流程的高效管理
有一次我去給一家企業(yè)講解研發(fā)管理系統(tǒng)，客戶是做電驅系統(tǒng)的架構設計與集成。我的講述思路是，如何在滿足汽車行業(yè)的三大法規(guī)標準（ASPICE、功能安全和信息安全）的情況下，實現(xiàn)從需求管理、開發(fā)任務管理、測試管理、項目管理、質量管理等流程的全打通。
我自以為講解的還算比較充分，事實上也得到了對方實施這一計劃的工程師認可，將我推給了其他正在創(chuàng)業(yè)的同事。
不過我也碰到了一些挑戰(zhàn)，對方的負責人質疑說，整個系統(tǒng)是站在流程質量和項目管理的角度來設計的，對于工程師直接提高某一現(xiàn)有工序的效率，比如幫助需求工程師更快速地、自動化地生成需求，幫助測試工程師更快地生成自動化測試用例，或者更高效地掃描出代碼缺陷等，則缺少效果。
這家公司擁有業(yè)界最優(yōu)秀的汽車工程師。事實上，他們一方面能提供最佳的產品設計品味、最好的內外飾設計思路、富有競爭力的售后運維服務，但是卻在研發(fā)和運營效率上有所拖累。內部系統(tǒng)和工具過多，數(shù)據(jù)傳輸效率低于同行。
在公司創(chuàng)業(yè)早期，人員冗余+強大的工程師個體，是一個優(yōu)勢，很容易通過賽馬機制，使得某一方提前跑出來。但是當同行都推出車型之后，此時更考驗不同團隊的精細化管理和效率提升，龐大而臃腫的研發(fā)團隊和研發(fā)數(shù)據(jù)，反而形成了太多噪音，成為拖累。
以車載軟件開發(fā)為例，這是一個涉及多個環(huán)節(jié)的復雜過程，包括需求分析、系統(tǒng)設計、編碼實現(xiàn)、測試驗證、部署上線以及后續(xù)的維護和更新。如果管理者只關注測試用例的自動化，或者代碼自動掃描，可能會導致以下幾個問題：
1. 研發(fā)流程的瓶頸轉移：即使測試用例的自動化提高了測試效率，但如果需求分析和設計階段存在問題，可能會導致測試階段頻繁修改用例，反而增加了工作量。同時，如果代碼實現(xiàn)階段的質量控制不到位，可能會導致測試階段發(fā)現(xiàn)大量問題，導致測試工作量激增，從而形成新的瓶頸。
（精益管理里面，有一個很經典的提高效率的例子。比如項目是“某五星級餐廳準備晚餐”，分析其流程包含了：確定菜品、app下單買菜、小哥送菜、洗菜、炒菜、上菜。這其中不僅涉及了像炒菜這種“工序”，還包含了炒菜和上菜這兩道工具之間的交接時間。因此，為了提高整體的做飯效率，需要先調研每一個工序花費的時間，以及工序之間的交接時間，找到效率瓶頸，然后再逐點解決?？梢?，不僅僅是“工序”會成為效率瓶頸，工序與工序之間的“交接流程”本身，也可能成為效率瓶頸。）
2. 資源分配不均衡：過多的資源可能被分配到測試自動化上，而其他同樣重要的環(huán)節(jié)，如需求分析的準確性、系統(tǒng)設計的合理性、代碼的可讀性和可維護性等，可能因資源不足而受到影響。
3. 產品質量風險：車載軟件對安全性和穩(wěn)定性的要求極高，如果開發(fā)流程中的某些環(huán)節(jié)被忽視，可能會導致軟件在實際運行中出現(xiàn)嚴重的安全問題或穩(wěn)定性問題。
4. 市場競爭力下降：如果因為開發(fā)流程中的問題導致產品上市延遲，或者產品質量不符合市場預期，可能會導致公司在激烈的市場競爭中失去優(yōu)勢。
5. 維護成本上升：在車載軟件的后續(xù)維護階段，如果因為前期開發(fā)流程的問題導致軟件存在大量隱患，可能會導致維護成本大幅上升，甚至需要進行昂貴的召回。
因此，管理者應該采取一個更全面的視角，關注整個車載軟件開發(fā)流程的每一個環(huán)節(jié)。
2 高估了流程的獨特性，而低估了流程的通用性
這里也分享一個案例，這個案例來自于我和某車載團隊一名測試leader的對話。
我和其討論的話題是：如何更好地構建測試團隊的管理工具，以提高軟件測試團隊的效率。他向我展示，在測試管理工具層方面，他的團隊做了大量工具開發(fā)，形成了一個相對完善的測試管理系統(tǒng)，包含所有的測試用例、用例評審、測試計劃、發(fā)版計劃、執(zhí)行結果回填等等。
1. 當我問他，整車需求和該團隊的產品需求、開發(fā)任務，都存在于需求管理系統(tǒng)，測試用例如何和這些需求、開發(fā)任務做關聯(lián)？----通過鏈接關聯(lián)，雙向點擊可訪問，已解決
2.?以及需求、開發(fā)人員是否能隨時訪問他的測試平臺，以方便查看測試用例和結果？----局部可以開放權限，大部分人不行，因為這個平臺是測試部門內部的平臺
3. 其他測試部門是否也使用他的平臺？----不使用，其他部門也會開發(fā)自己的測試管理平臺
4.?為什么其他測試部門不使用他的平臺，而需要自己獨立開發(fā)？------因為每個部門的測試流程和使用習慣不同
5.?追溯性的統(tǒng)計，功能安全、信息安全流程如何支持？----暫時無法解決，也不考慮
6.?如果產品和開發(fā)很少能訪問他們的測試工具，那如何才能讓產品、開發(fā)、測試形成一個更高效的溝通機制？----
他有點犯難了，他認為那是整個大部門的事情，他這邊沒有辦法干涉，也解決不了，所以他只能想盡辦法讓測試過程更高效，至于整體團隊的效率，他難以推動
這位測試leader雖然意識到將測試管理平臺，和需求、開發(fā)平臺一體化管理，能提高效率，他卻無法推動整個團隊往一個平臺上使勁兒和遷移。
即使他意識到，各個部門重復建立測試管理平臺，是資源的大浪費，他也無法推動其他部門使用他的工具。
這不是工程師個人能力的問題，而是因為，這是企業(yè)一把手工程。
使用不同的測試平臺，和各個部門測試流程的獨特性有一定關系，但顯然關系不大。
因為看了一遍他的系統(tǒng)，我們自己開發(fā)的MappingSpace系統(tǒng)，也能夠在幾乎不怎么調整的情況下，滿足絕大部分功能。
換句話說，我們往往容易高估企業(yè)流程的獨特性，而低估了企業(yè)流程的通用性。
這也是很多國內公司非常喜歡做定制化系統(tǒng)的原因。
寧愿摒棄一套行業(yè)通用的平臺，也要找業(yè)余團隊定制化開發(fā)，認為自己的流程非常獨特。往高大上了講，就是源碼可見，自主可控，隨時可調整。
不過深入分析里面的原因卻很復雜，和國民性格、復雜的采購申請流程、對產品的認知、對乙方的信任、幕后交易都不無關聯(lián)。但是，自研有很大風險。
一方面，部門之間的測試管理系統(tǒng)，差距肯定會越來越大，這樣的測試平臺，在誕生之初，就無需考慮設計的通用性。
另一方面，隨著差距越來越大，再也無法做到統(tǒng)一，此時就進入了下一個狀態(tài)——打通。請看下一個故事。
3 被動收集各類平臺數(shù)據(jù)，形成“虛假”且“臃腫”的研發(fā)數(shù)字化管理系統(tǒng)
這個故事是我和整車部門的一位大項目管理的對話，這位PM的目標是開發(fā)整車項目管理的數(shù)字化平臺。他自述是這個平臺的第4代產品經理，因為前面三代產品經理都離職了，留下了一大堆還未完成的feature，他這個平臺的目的是，將各個部門、各類工具上的研發(fā)數(shù)據(jù)匯總，建立追溯性，然后在這個平臺上以更加可視化、結構化的方式顯示出來，基于此來做更高效、更清晰的項目管理和質量管控。
我說那這個系統(tǒng)豈不是很復雜，因為他不僅要去和各個業(yè)務部門梳理業(yè)務數(shù)據(jù)，以判斷這些數(shù)據(jù)分別屬于什么類型，然后才能和自己做的這個平臺的數(shù)據(jù)結構做匹配。而且這似乎只是一個“數(shù)據(jù)匯總平臺”，離真正的研發(fā)流程管控還差了很遠。
他表示同意，現(xiàn)階段各個部門不同的工具平臺都太多了，還有不少部門在線下管理，沒有形成線上的數(shù)據(jù)，沒有辦法去做流程管控，只能先將業(yè)務數(shù)據(jù)匯總到這樣一個平臺上來，然后基于數(shù)據(jù)再去反推流程，針對異常數(shù)據(jù)或者無法提供數(shù)據(jù)的部門，再去各個擊破。
這確實是一個很復雜、很繁瑣的工程，而且我非常懷疑這個項目在第四代產品經理手上，能不能順利完工。我對這個數(shù)據(jù)匯總平臺，能產生多少效果，也有一些懷疑。
最終，我提了一個可能的方向：現(xiàn)在這種情況，有點像逆向工程。通過結果數(shù)據(jù)來反推過程。但是由于需要理清楚的過程涉及到太多不同的部門，以及部門之間的交互錯綜復雜，這是一個龐大得似乎看不到頭的工程。有沒有可能采用正向開發(fā)的模式，先找到一個大家都認可的開發(fā)流程，然后將已有的流程往這個正向開發(fā)的流程的方向去靠近，最終將大家的流程梳理到一個統(tǒng)一的平臺上
總結
汽車行業(yè)的研發(fā)數(shù)字化系統(tǒng)搭建過程中，對于以下三點的考慮非常重要：
第一：要站在全局的角度設計。所謂的全局，應盡可能依賴汽車行業(yè)的標準和法規(guī)，減少后期逆向工程來滿足法規(guī)的成本和代價?；跇藴屎头ㄒ?guī)，并不一定意味著繁瑣，也可以裁剪，追求更快地開發(fā)速度。
第二：中大型企業(yè)的數(shù)字化研發(fā)系統(tǒng)設計，應盡可能讓不同部門采用相似的流程，采用相同的工具。而不是每個部門采用一套工具，最終去打通數(shù)據(jù)流轉，極易造成上述第二和第三個例子中的情況，從而拖累整體的研發(fā)數(shù)字化流程。
第三：單點效率很重要，但整體的流轉流程更重要。使用精益管理的方法，逐個分解流程中涉及的“工序”和“交接”，各個擊破，提高整個團隊的協(xié)作效率。
作者介紹：羅宇超，云體科技創(chuàng)始人，軟件質量工程師，工具連接工程師
下載ECAD模型
