如果軟件開發(fā)的伊始目標(biāo)就是為了演示或是純粹做個(gè)玩具，我并不反感甚至認(rèn)可“明天就要”的開發(fā)方式，因?yàn)槊艚莞咝С杀镜汀?/strong>但奈何我們選擇了汽車這個(gè)產(chǎn)品品類，這幾乎就是軟件開發(fā)的地獄模式。很多三觀是需要被顛覆的。
曾經(jīng)作為一個(gè)軟件算法工程師，能夠讓軟件在車上跑的好，就是唯一的目標(biāo)。這個(gè)目標(biāo)邏輯上沒有問題，但量產(chǎn)是什么概念，是多個(gè)項(xiàng)目并行開發(fā)；人員嚴(yán)重短缺，關(guān)鍵人員隨時(shí)放鴿子；需求變化快還存在大量差異。前序流程頻發(fā)狀況，項(xiàng)目時(shí)間計(jì)劃后墻不倒。在這些背景，要保證大規(guī)模車輛，在每個(gè)版本上都能夠有線性的性能提升，還要維持長周期下的穩(wěn)定性。并且要維持大量的數(shù)據(jù)、測試、版本、記錄、流程以支持跨部門的合作配合。對，雖然簡單說還是軟件在車上跑的好，但難點(diǎn)似乎不僅僅在能夠跑的好的軟件上。
曾經(jīng)作為一個(gè)軟件算法工程師，覺得掌握了核心技術(shù)是舞臺上的C位，這個(gè)邏輯上也沒問題?？墒堑材闩龅揭恍┳枇?，一開始都是技術(shù)點(diǎn)的問題，深入看是架構(gòu)出了問題，解決了架構(gòu)問題，會發(fā)現(xiàn)軟件工程化跟不上，而這又會上升到公司管理問題而最終都是人的問題是公司文化的問題。雖然說軟件算法還是很重要，但是一個(gè)在指揮、需求、硬件、架構(gòu)、工程化、軟件算法、項(xiàng)目管理上能力平均的團(tuán)隊(duì)才是有效戰(zhàn)斗力的保障。
曾經(jīng)作為一個(gè)軟件算法工程，覺得勇于擔(dān)當(dāng)是好事，要竟可能的用技術(shù)解決上下游算法和流程碰到的苦難。這種英雄主義思想是寶貴的，但最好在危難的時(shí)候拿出來用，平時(shí)就算了。你會發(fā)現(xiàn)任何問題總有處理它整體效益最好的環(huán)節(jié)，你上百行代碼解決不好的問題，上游模塊可能1行代碼就穩(wěn)定解決了。如果在一個(gè)長期項(xiàng)目上，你最后仍然實(shí)施了百行代碼去解決這個(gè)問題，那就是噩夢的開始。可能當(dāng)上游順便解決了這個(gè)問題，而你的代碼卻因?yàn)轳詈闲詼S為技術(shù)債。也有可能由于你的環(huán)節(jié)無法穩(wěn)定解決，但又由你負(fù)責(zé)解決，則穩(wěn)定性的壓力和無所適從就會壓垮你。擔(dān)當(dāng)是好的品質(zhì)，但是全局觀往往更重要。
從一個(gè)成熟系統(tǒng)上看，都是前道重，后道輕。問題的解決越靠前越好，無論是算法上的前道感知模塊，還是流程上的前道需求或是前道測試搭建，亦或是管理上領(lǐng)導(dǎo)的前道決策。良好的前道工序才能保證后道的品質(zhì)，也為后道留出更多時(shí)間和精力靈活解決意料外的問題。而一個(gè)非成熟的系統(tǒng)，是前道輕，后道死。前道如果出現(xiàn)紕漏，后道為了逐級消化這些問題，就可能導(dǎo)致架構(gòu)的混亂和節(jié)奏的失調(diào)，最終就是一地雞毛，一旦更換項(xiàng)目可能就是重頭再來。人不可能都很認(rèn)真和專業(yè)，但認(rèn)真和專業(yè)的人部署到前道，收益會更好。
工程化是量產(chǎn)的核心保障，其確保了“功能實(shí)現(xiàn)”的魯棒性、穩(wěn)定性和一致性。從幾個(gè)維度我們能夠初步了解工程化的點(diǎn)滴思想。從產(chǎn)品長周期管理的角度來說，對于定期要發(fā)布復(fù)雜產(chǎn)品的公司來說，往往都是預(yù)研一代，研發(fā)一代，量產(chǎn)一代，各個(gè)職能塊之間的配合，背后也有一個(gè)工作的流水線，而產(chǎn)品管理最重要的就是產(chǎn)品型譜的管理，這揭示了公司發(fā)展的基本方向。當(dāng)然這需要很好的市場預(yù)判以及高標(biāo)準(zhǔn)的執(zhí)行力。
從產(chǎn)品開發(fā)流程的角度看，汽車研發(fā)制造流程代表了制造業(yè)開發(fā)流程的最高水平，其核心就是APQP質(zhì)量先期策劃。簡單來說，就是通過對風(fēng)險(xiǎn)的更多關(guān)注，來補(bǔ)償設(shè)計(jì)生產(chǎn)過程中可能出現(xiàn)的失敗。長期而多維度的計(jì)劃與風(fēng)險(xiǎn)評估是汽車工程師的常態(tài)。這種物理硬件的制造，組裝和大規(guī)模生產(chǎn)和純粹的軟件開發(fā)差異很大。最大的區(qū)別就是“變化周期”。有人和實(shí)體物參與的工作，都無法突破物理限制，工人在流水線上變更工藝，需要時(shí)間熟悉，制造新的零件需要重新設(shè)計(jì)模具和夾具，這些變化并不快，至少相對GIT重新集成一版軟件來說并不快。因此對長周期風(fēng)險(xiǎn)的預(yù)判成了區(qū)別制造業(yè)和互聯(lián)網(wǎng)的一個(gè)重要特征。
互聯(lián)網(wǎng)思維下的敏捷開發(fā)，雖然讀上去感覺和制造業(yè)的思路背道而馳，但個(gè)人感覺其同樣有濃厚的工程化思維支持。在敏捷開發(fā)下，架構(gòu)仍然是核心。行業(yè)有一句話我非常喜歡，架構(gòu)是遠(yuǎn)景與殘酷現(xiàn)實(shí)(需求)的黎明交匯。愿景只能是被翻譯成架構(gòu)設(shè)計(jì)的那些內(nèi)容，無法被翻譯的叫幻想，兩者之間的位置是敏捷開發(fā)的上限。敏捷只不過開發(fā)分成了架構(gòu)設(shè)計(jì)和細(xì)節(jié)設(shè)計(jì)。敏捷的是細(xì)節(jié)設(shè)計(jì)，而支持敏捷的仍然是具有長周期預(yù)判的架構(gòu)設(shè)計(jì)。在這點(diǎn)上制造業(yè)和互聯(lián)網(wǎng)的思想仍然是一樣的，只不過規(guī)避了不同的風(fēng)險(xiǎn)。敏捷開發(fā)往往是軟件關(guān)鍵模組的平臺化定義所帶來的，而不是堆砌工程師沒日沒夜的推倒重來壓榨出來的，兩者的邊際效應(yīng)天差地別。
從人員管理上來說，最基本的諸如團(tuán)隊(duì)梯度的搭建，崗位AB角的設(shè)置以及團(tuán)隊(duì)能力的平衡，保證項(xiàng)目人員管理的有序、穩(wěn)定。往往一個(gè)項(xiàng)目一個(gè)復(fù)雜工作，維持70%-80%的人力資源是穩(wěn)妥的，貿(mào)然增加人力資源，可能導(dǎo)致通過“人海戰(zhàn)術(shù)”解決問題的思想出現(xiàn)，這對于工程化是不利的。
綜上所述，無論是制造業(yè)的硬件還是互聯(lián)網(wǎng)的軟件，工程化的思路往往是殊途同歸。對長周期的變量（架構(gòu)，制造，人）給予充分的預(yù)判，建體系，搭架構(gòu)，做工具把一切可以標(biāo)準(zhǔn)化，平臺化的東西自動化。為短周期變量（用戶需求，軟件算法，功能應(yīng)用）的快速迭代提供質(zhì)量保障，這就是工程化。
轉(zhuǎn)自汽車ECU開發(fā)
