如果軟件開發(fā)的伊始目標就是為了演示或是純粹做個玩具，我并不反感甚至認可“明天就要”的開發(fā)方式，因為敏捷高效成本低。但奈何我們選擇了汽車這個產(chǎn)品品類，這幾乎就是軟件開發(fā)的地獄模式。很多三觀是需要被顛覆的。 ?

曾經(jīng)作為一個軟件算法工程師，能夠讓軟件在車上跑的好，就是唯一的目標。這個目標邏輯上沒有問題，但量產(chǎn)是什么概念，是多個項目并行開發(fā)；人員嚴重短缺，關(guān)鍵人員隨時放鴿子；需求變化快還存在大量差異。前序流程頻發(fā)狀況，項目時間計劃后墻不倒。在這些背景，要保證大規(guī)模車輛，在每個版本上都能夠有線性的性能提升，還要維持長周期下的穩(wěn)定性。并且要維持大量的數(shù)據(jù)、測試、版本、記錄、流程以支持跨部門的合作配合。對，雖然簡單說還是軟件在車上跑的好，但難點似乎不僅僅在能夠跑的好的軟件上。 ?

曾經(jīng)作為一個軟件算法工程師，覺得掌握了核心技術(shù)是舞臺上的C位，這個邏輯上也沒問題?？墒堑材闩龅揭恍┳枇?，一開始都是技術(shù)點的問題，深入看是架構(gòu)出了問題，解決了架構(gòu)問題，會發(fā)現(xiàn)軟件工程化跟不上，而這又會上升到公司管理問題而最終都是人的問題是公司文化的問題。雖然說軟件算法還是很重要，但是一個在指揮、需求、硬件、架構(gòu)、工程化、軟件算法、項目管理上能力平均的團隊才是有效戰(zhàn)斗力的保障。 ?

曾經(jīng)作為一個軟件算法工程，覺得勇于擔(dān)當(dāng)是好事，要竟可能的用技術(shù)解決上下游算法和流程碰到的苦難。這種英雄主義思想是寶貴的，但最好在危難的時候拿出來用，平時就算了。你會發(fā)現(xiàn)任何問題總有處理它整體效益最好的環(huán)節(jié)，你上百行代碼解決不好的問題，上游模塊可能1行代碼就穩(wěn)定解決了。如果在一個長期項目上，你最后仍然實施了百行代碼去解決這個問題，那就是噩夢的開始?？赡墚?dāng)上游順便解決了這個問題，而你的代碼卻因為耦合性淪為技術(shù)債。也有可能由于你的環(huán)節(jié)無法穩(wěn)定解決，但又由你負責(zé)解決，則穩(wěn)定性的壓力和無所適從就會壓垮你。擔(dān)當(dāng)是好的品質(zhì)，但是全局觀往往更重要。 ?

從一個成熟系統(tǒng)上看，都是前道重，后道輕。問題的解決越靠前越好，無論是算法上的前道感知模塊，還是流程上的前道需求或是前道測試搭建，亦或是管理上領(lǐng)導(dǎo)的前道決策。良好的前道工序才能保證后道的品質(zhì)，也為后道留出更多時間和精力靈活解決意料外的問題。而一個非成熟的系統(tǒng)，是前道輕，后道死。前道如果出現(xiàn)紕漏，后道為了逐級消化這些問題，就可能導(dǎo)致架構(gòu)的混亂和節(jié)奏的失調(diào)，最終就是一地雞毛，一旦更換項目可能就是重頭再來。人不可能都很認真和專業(yè)，但認真和專業(yè)的人部署到前道，收益會更好。 ?

工程化是量產(chǎn)的核心保障，其確保了“功能實現(xiàn)”的魯棒性、穩(wěn)定性和一致性。從幾個維度我們能夠初步了解工程化的點滴思想。 ?

從產(chǎn)品長周期管理的角度來說，對于定期要發(fā)布復(fù)雜產(chǎn)品的公司來說，往往都是預(yù)研一代，研發(fā)一代，量產(chǎn)一代，各個職能塊之間的配合，背后也有一個工作的流水線，而產(chǎn)品管理最重要的就是產(chǎn)品型譜的管理，這揭示了公司發(fā)展的基本方向。當(dāng)然這需要很好的市場預(yù)判以及高標準的執(zhí)行力。 ?

從產(chǎn)品開發(fā)流程的角度看，汽車研發(fā)制造流程代表了制造業(yè)開發(fā)流程的最高水平，其核心就是APQP質(zhì)量先期策劃。簡單來說，就是通過對風(fēng)險的更多關(guān)注，來補償設(shè)計生產(chǎn)過程中可能出現(xiàn)的失敗。長期而多維度的計劃與風(fēng)險評估是汽車工程師的常態(tài)。這種物理硬件的制造，組裝和大規(guī)模生產(chǎn)和純粹的軟件開發(fā)差異很大。最大的區(qū)別就是“變化周期”。有人和實體物參與的工作，都無法突破物理限制，工人在流水線上變更工藝，需要時間熟悉，制造新的零件需要重新設(shè)計模具和夾具，這些變化并不快，至少相對GIT重新集成一版軟件來說并不快。因此對長周期風(fēng)險的預(yù)判成了區(qū)別制造業(yè)和互聯(lián)網(wǎng)的一個重要特征。 ?

互聯(lián)網(wǎng)思維下的敏捷開發(fā)，雖然讀上去感覺和制造業(yè)的思路背道而馳，但個人感覺其同樣有濃厚的工程化思維支持。在敏捷開發(fā)下，架構(gòu)仍然是核心。行業(yè)有一句話我非常喜歡，架構(gòu)是遠景與殘酷現(xiàn)實(需求)的黎明交匯。愿景只能是被翻譯成架構(gòu)設(shè)計的那些內(nèi)容，無法被翻譯的叫幻想，兩者之間的位置是敏捷開發(fā)的上限。敏捷只不過開發(fā)分成了架構(gòu)設(shè)計和細節(jié)設(shè)計。敏捷的是細節(jié)設(shè)計，而支持敏捷的仍然是具有長周期預(yù)判的架構(gòu)設(shè)計。在這點上制造業(yè)和互聯(lián)網(wǎng)的思想仍然是一樣的，只不過規(guī)避了不同的風(fēng)險。敏捷開發(fā)往往是軟件關(guān)鍵模組的平臺化定義所帶來的，而不是堆砌工程師沒日沒夜的推倒重來壓榨出來的，兩者的邊際效應(yīng)天差地別。 ?

從人員管理上來說，最基本的諸如團隊梯度的搭建，崗位AB角的設(shè)置以及團隊能力的平衡，保證項目人員管理的有序、穩(wěn)定。往往一個項目一個復(fù)雜工作，維持70%-80%的人力資源是穩(wěn)妥的，貿(mào)然增加人力資源，可能導(dǎo)致通過“人海戰(zhàn)術(shù)”解決問題的思想出現(xiàn)，這對于工程化是不利的。 ?

綜上所述，無論是制造業(yè)的硬件還是互聯(lián)網(wǎng)的軟件，工程化的思路往往是殊途同歸。對長周期的變量（架構(gòu)，制造，人）給予充分的預(yù)判，建體系，搭架構(gòu)，做工具把一切可以標準化，平臺化的東西自動化。為短周期變量（用戶需求，軟件算法，功能應(yīng)用）的快速迭代提供質(zhì)量保障，這就是工程化。 ??



審核編輯：劉清

?

?