在當(dāng)今數(shù)字化浪潮中，軟件開(kāi)發(fā)不僅是技術(shù)領(lǐng)域的核心驅(qū)動(dòng)力，更是企業(yè)創(chuàng)新與商業(yè)成功的戰(zhàn)略支點(diǎn)。特別是軟件定義汽車(chē)的時(shí)代，軟件開(kāi)發(fā)的規(guī)范化管理成為車(chē)企的難言之痛：軟件版本如此多，如何測(cè)試？全量測(cè)試還是采樣測(cè)試？軟件版本發(fā)布如何管控？軟件質(zhì)量如何保障？軟件功能為什么總是趕不上造車(chē)的節(jié)奏？軟件是如何集成的？敏捷會(huì)讓車(chē)企的軟件開(kāi)發(fā)一夜之間發(fā)生神奇的變化？….
本篇文章以科普的方式探討軟件開(kāi)發(fā)理論基礎(chǔ)、關(guān)鍵模型、實(shí)戰(zhàn)技巧以及組織與人才發(fā)展等重要議題，旨在為讀者提供一幅全景式的軟件開(kāi)發(fā)導(dǎo)圖。
一、軟件開(kāi)發(fā)基石：軟件開(kāi)發(fā)生命周期模型的選擇
軟件開(kāi)發(fā)生命周期模型是組織軟件開(kāi)發(fā)活動(dòng)的框架，它定義了開(kāi)發(fā)過(guò)程中的階段、順序、迭代方式以及各階段間的關(guān)聯(lián)（見(jiàn)圖1）。
圖1
軟件開(kāi)發(fā)生命周期模型，大家耳熟能詳?shù)氖墙?jīng)典的瀑布模型和敏捷開(kāi)發(fā)模型。
瀑布模型：
瀑布模型遵循嚴(yán)格的線(xiàn)性順序，從需求分析到詳細(xì)設(shè)計(jì)，再到編碼、測(cè)試和維護(hù)，每個(gè)階段必須在前一階段完全完成后才能開(kāi)始。瀑布模型適用于需求穩(wěn)定、技術(shù)路徑清晰的項(xiàng)目，但其僵化性可能導(dǎo)致應(yīng)對(duì)變化的能力較弱，一旦前期需求定義有誤，后續(xù)階段修正的成本極高。
關(guān)于瀑布模型，我們需要知道，目前看到的瀑布模型（見(jiàn)圖2）更多是停留在了理論模型基礎(chǔ)之上。實(shí)際上，在1980s, Fred Brooks, 著名的產(chǎn)品開(kāi)發(fā)暢銷(xiāo)書(shū)《人月神話(huà)》作者，圖靈獎(jiǎng)獲得者，在NASA內(nèi)部會(huì)議上指出，“在超過(guò)370億美金的投資項(xiàng)目中，只有2%的項(xiàng)目使用了純粹的瀑布模型，75%的項(xiàng)目或夭折或沒(méi)有使用.”
圖2
在現(xiàn)實(shí)的世界里，更多的是采用了基于瀑布模型演化的進(jìn)化模型，如螺旋模型、V模型等。他們都融合了瀑布模型的結(jié)構(gòu)化特點(diǎn)與迭代思想。螺旋模型特別適用于高風(fēng)險(xiǎn)項(xiàng)目，通過(guò)反復(fù)的風(fēng)險(xiǎn)評(píng)估和原型迭代降低不確定性；而V模型（見(jiàn)圖3）強(qiáng)調(diào)開(kāi)發(fā)與測(cè)試的對(duì)應(yīng)關(guān)系，確保每個(gè)階段的驗(yàn)證與確認(rèn)工作緊密相連。
V模型成為了產(chǎn)品工程，特別是軟硬一體的嵌入式產(chǎn)品開(kāi)發(fā)的核心骨架，也是產(chǎn)品開(kāi)發(fā)使用最為廣泛的模型。像汽車(chē)行業(yè)的ASPICE標(biāo)準(zhǔn)、功能安全的ISO26262標(biāo)準(zhǔn)、信息安全的ISO21434標(biāo)準(zhǔn)，基本都是根據(jù)V模型制定了相應(yīng)的規(guī)范要求。
圖3
敏捷模型：
敏捷開(kāi)發(fā)模型則以快速響應(yīng)變化為宗旨，倡導(dǎo)迭代開(kāi)發(fā)和持續(xù)集成。它強(qiáng)調(diào)團(tuán)隊(duì)協(xié)作、用戶(hù)參與以及適應(yīng)需求的靈活性，通過(guò)短周期的迭代（如Scrum中的Sprint）快速產(chǎn)出可用軟件，并根據(jù)反饋進(jìn)行調(diào)整。敏捷模型更多地關(guān)注了軟件開(kāi)發(fā)過(guò)程中的工程實(shí)踐，對(duì)于軟件交付后的運(yùn)營(yíng)提及不多。交付后的管理更多的還是采用傳統(tǒng)的軟件生命周期管理的模式。
敏捷軟件開(kāi)發(fā)模型同樣存在多種實(shí)操模型，例如XP、FDD，等。
目前應(yīng)用最廣的還是團(tuán)隊(duì)級(jí)敏捷SCRUM模型（見(jiàn)圖4）
圖4
敏捷開(kāi)發(fā)在實(shí)際落地過(guò)程中有兩種具體的項(xiàng)目管理方式：基于時(shí)間盒的迭代計(jì)劃（見(jiàn)圖5）和基于流的迭代計(jì)劃（見(jiàn)圖6）。采用不同的迭代計(jì)劃，將決定了敏捷項(xiàng)目每個(gè)沖刺（SPRINT）的交付內(nèi)容。我們需要注意的是，因?yàn)楫a(chǎn)品形態(tài)及產(chǎn)品技術(shù)架構(gòu)的復(fù)雜度不同，組織架構(gòu)的不同，如果迭代規(guī)劃方式選擇與之不匹配，敏捷反而會(huì)引入更多的混亂和內(nèi)卷。
例如，如果產(chǎn)品是單一架構(gòu)的（monolithic Architecture）且功能依賴(lài)多，如果采用時(shí)間盒的迭代規(guī)劃方式，會(huì)出現(xiàn)待開(kāi)發(fā)的新功能不得不削足適履，進(jìn)行功能分拆用戶(hù)故事，確保能在一個(gè)時(shí)間盒的窗口交付，反而導(dǎo)致大量的模塊之間的相互依賴(lài)，交易成本（Transaction Cost）劇升，協(xié)調(diào)工作冗長(zhǎng)。從系統(tǒng)論的維度看下來(lái)，反而是降低了效率。針對(duì)這種情況，要么是改變時(shí)間盒的跨度，要么是采用基于流的迭代工作模式。
圖5 （來(lái)源：From Prince2 Agile）
圖6（來(lái)源：From Prince2 Agile）
軟件開(kāi)發(fā)的模型選擇：
“There's no singular technique or process that will bring about significant improvements in software development productivity”
- No Silver Bullet—Essence and Accidents of Software Engineering
Gerald Weinberg, Fred Brooks, and Grady Booch
面臨亂花漸欲迷人眼以及病急亂投醫(yī)的汽車(chē)軟件開(kāi)發(fā)，到底如何選擇自己的軟件開(kāi)發(fā)模式呢？正如Fred Brooks所言，沒(méi)有單一技術(shù)或模型能夠顯著提成軟件開(kāi)發(fā)效率。我們需要的是因地制宜，選擇適合自己組織和產(chǎn)品屬性的研發(fā)活動(dòng)的模型。
在實(shí)際工作中，我們應(yīng)該且必須學(xué)以致用，靈活適配合適的軟件開(kāi)發(fā)模型，而不是簡(jiǎn)單地照貓畫(huà)虎，仿照各種敏捷框架，如站會(huì)、結(jié)對(duì)編程......（題外話(huà)：其實(shí)，適配性（Adapability）才是業(yè)務(wù)敏捷的精髓所在）。
不管選擇何種開(kāi)發(fā)模型，其核心目的是更快、更好地交付客戶(hù)價(jià)值和業(yè)務(wù)價(jià)值。具體來(lái)講，可以基于Stacey矩陣，選擇合適的開(kāi)發(fā)模型（圖7）。當(dāng)然，除了Stacey矩陣提供的需求確定性和技術(shù)確定性的兩個(gè)維度外，還需要考慮團(tuán)隊(duì)的成熟度，團(tuán)隊(duì)成員的技能經(jīng)驗(yàn)，工作地點(diǎn)分布，團(tuán)隊(duì)規(guī)模以及組織文化等因素。
圖7
二、需求分析與架構(gòu)設(shè)計(jì)的藝術(shù)
軟件開(kāi)發(fā)始于需求的獲取與需求開(kāi)發(fā)的過(guò)程（通常將這個(gè)過(guò)程稱(chēng)為需求工程階段）。需求的獲取主要是從市場(chǎng)需求、用戶(hù)需求、業(yè)務(wù)等維度展開(kāi)，理解并分析企業(yè)所在的行業(yè)、國(guó)家、地區(qū)適用的法律法規(guī)等，綜合定義軟件產(chǎn)品的需求。
近幾年來(lái)，隨著國(guó)內(nèi)互聯(lián)網(wǎng)造車(chē)的興起，互聯(lián)網(wǎng)用戶(hù)需求分析的工具也逐步引入到垂直行業(yè)，也成為國(guó)內(nèi)傳統(tǒng)造車(chē)企業(yè)紛紛攘攘去學(xué)習(xí)的重心。但從第一性原理來(lái)看，需求獲取的原理沒(méi)有改變，變化的是傳統(tǒng)企業(yè)缺少需求獲取的數(shù)字化手段，缺少人物畫(huà)像的細(xì)節(jié)管控。
需求獲取的方法手段很多，我們總結(jié)如圖8所示。
圖8
在對(duì)軟件產(chǎn)品功能進(jìn)行定義的過(guò)程中，往往是綜合采用多種方法，確保功能能夠滿(mǎn)足最大數(shù)量的用戶(hù)期望。同時(shí)，我們要關(guān)注，對(duì)于ToC業(yè)務(wù)與ToB業(yè)務(wù)的需求獲取方法，也存在著差異。無(wú)論是從調(diào)研對(duì)象，調(diào)研數(shù)量以及調(diào)研方法，在實(shí)際過(guò)程中，要注重理論與實(shí)踐的結(jié)合。
這里，特別給大家推薦一個(gè)用來(lái)識(shí)別或改進(jìn)產(chǎn)品可用性功能需求（Usability）的強(qiáng)大工具–用戶(hù)歷程地圖（題外話(huà)：對(duì)于其他如非功能性需求的定義與改進(jìn)，建議采用其他工具方法）。圖9展示了對(duì)電車(chē)用戶(hù)充電活動(dòng)的用戶(hù)歷程地圖，通過(guò)一張紙，可以清晰地將產(chǎn)品功能的優(yōu)劣以及待創(chuàng)新的功能點(diǎn)描述清楚。
圖9
需求獲取只是開(kāi)啟了整個(gè)軟件開(kāi)發(fā)的序幕。我們下一步要做的是需求的確認(rèn)。需求的確認(rèn)，是確保軟件產(chǎn)品的開(kāi)發(fā)“做正確的事”。需求確認(rèn)的方法包括了VOC，焦糖布丁法，Y分析法，數(shù)據(jù)分析法等等。
為什么要進(jìn)行需求的確認(rèn)呢？其實(shí)，這涉及到了人類(lèi)認(rèn)知的過(guò)程，如圖10所示，當(dāng)我們看到現(xiàn)實(shí)的人形機(jī)器人圖片時(shí)，我們會(huì)根據(jù)自己的認(rèn)知(Perception)和我們個(gè)人的知識(shí)（Knowledge）對(duì)其進(jìn)行描述。然后，我們將我們自己腦海里，經(jīng)過(guò)自己認(rèn)知過(guò)濾過(guò)的圖片，用自己的知識(shí)，包括文字語(yǔ)言對(duì)其進(jìn)行描述，這個(gè)過(guò)程，將不可避免的引入人為的錯(cuò)誤。所以，在專(zhuān)業(yè)的產(chǎn)品研發(fā)環(huán)境中，我們意識(shí)到這個(gè)人類(lèi)認(rèn)知的過(guò)程偏差，所以需要建立規(guī)范的工具方法，如需求文檔的評(píng)審、需求撰寫(xiě)的規(guī)范等，作為“獲取正確需求”的底線(xiàn)保障，確保最大可能地不失真。而敏捷思想里強(qiáng)調(diào)的“客戶(hù)合作勝于客戶(hù)合同”，也正是基于這個(gè)不可更改的事實(shí)做出的更合理的過(guò)程建議。
圖10
需求的開(kāi)發(fā)包括需求分析與需求的分解與分配的過(guò)程。它是軟件產(chǎn)品開(kāi)發(fā)“正確做事”的過(guò)程。這個(gè)過(guò)程可以使用類(lèi)似FAST功能分析圖、EFFBD圖、UML建模或者其他建模工具實(shí)現(xiàn)，也可以使用其它不同的工具方法，如KJ法、KANO法、QFD法、Pugh矩陣法等等，幫助我們有效工作。
需求開(kāi)發(fā)從產(chǎn)品定義語(yǔ)境出發(fā)，逐步細(xì)化分解功能，最后分配到子系統(tǒng)和模塊。這個(gè)過(guò)程是用戶(hù)可見(jiàn)的功能和可感知的非功能性期望，轉(zhuǎn)化為我們軟件產(chǎn)品能力的過(guò)程。如果是0到1的產(chǎn)品開(kāi)發(fā)，這個(gè)過(guò)程與產(chǎn)品架構(gòu)設(shè)計(jì)交互迭代，最終形成產(chǎn)品的雛形；如果是基于原有產(chǎn)品架構(gòu)的功能增加，則更多的工作是基于原有架構(gòu)進(jìn)行需求分配的過(guò)程。當(dāng)然，不排除原有系統(tǒng)需要重構(gòu)，才能滿(mǎn)足客戶(hù)的功能要求的情況。
而架構(gòu)設(shè)計(jì)則是將技術(shù)需求轉(zhuǎn)化為系統(tǒng)的藍(lán)圖，涉及功能模型定義、架構(gòu)評(píng)估方法選擇、物理架構(gòu)布局等多個(gè)環(huán)節(jié)。軟件產(chǎn)品常見(jiàn)的技術(shù)架構(gòu)包括了C/S架構(gòu)、MVC架構(gòu)、分層的SOA架構(gòu)等。但具體的架構(gòu)設(shè)計(jì)，要考慮的不僅關(guān)乎技術(shù)實(shí)現(xiàn)，更是一種權(quán)衡藝術(shù)（Trade-Off），需要在功能、成本、時(shí)間、用戶(hù)期望等多種因素間尋求最佳平衡。
如圖11，當(dāng)面對(duì)客戶(hù)“過(guò)河”的需求，架構(gòu)設(shè)計(jì)可能需要考慮橋梁、船只、潛水艇，飛機(jī)等多種解決方案，每種方案背后代表了不同的技術(shù)復(fù)雜度、投資規(guī)模與時(shí)間周期，系統(tǒng)架構(gòu)就是需要在不同的解決方案中選擇最合適的，而不僅僅是技術(shù)最優(yōu)的。
圖11
在架構(gòu)設(shè)計(jì)過(guò)程中，可以運(yùn)用啟發(fā)式問(wèn)題法、KJ法、QFD等工具進(jìn)行評(píng)估與決策，有助于識(shí)別最合適的架構(gòu)。同時(shí)，評(píng)估軟件架構(gòu)的有效性，還可以通過(guò)創(chuàng)建原型、迭代開(kāi)發(fā)、模型模擬等方式獲取直觀(guān)反饋，必要時(shí)引入量化指標(biāo)進(jìn)行深度分析。
康威定律揭示了一個(gè)重要規(guī)律：軟件架構(gòu)往往反映出組織內(nèi)部的結(jié)構(gòu)。這意味著，良好的組織設(shè)計(jì)有助于催生高效、協(xié)調(diào)的軟件架構(gòu)，反之亦然。因此，在軟件開(kāi)發(fā)過(guò)程中，應(yīng)充分考慮組織架構(gòu)對(duì)技術(shù)實(shí)現(xiàn)的影響，確保架構(gòu)設(shè)計(jì)既能滿(mǎn)足功能需求，又能順應(yīng)組織協(xié)作模式。
三、軟件編碼與測(cè)試：質(zhì)量之盾
軟件編碼是將設(shè)計(jì)轉(zhuǎn)化為可執(zhí)行代碼的過(guò)程，需要遵循相應(yīng)的編程語(yǔ)言規(guī)范和組織內(nèi)部編碼標(biāo)準(zhǔn)（例如，谷歌C++代碼規(guī)范：Google_Cpp_Style_guide_CN.pdf (sosohu.github.io)），輔以靜態(tài)代碼掃描、動(dòng)態(tài)測(cè)試及代碼評(píng)審等工作，確保代碼質(zhì)量。
伴隨著AIGC的泛化，AI 輔助編碼和代碼評(píng)審也逐步成為現(xiàn)實(shí)，比如Github Copilot X，可以協(xié)助程序員實(shí)現(xiàn)結(jié)對(duì)編程。同樣，類(lèi)似ChatGPT，也可以幫助我們實(shí)現(xiàn)代碼評(píng)審的工作。例如，我們把下面這段冒泡算法的C代碼（圖12）輸送給ChatGPT，GPT會(huì)給出非常中肯的評(píng)審建議以及重構(gòu)后的代碼，大大減少了代碼評(píng)審的工作量。
圖12
圖13是ChatGPT重構(gòu)后的代碼。GPT的反饋如下。他不僅僅反饋了代碼的邏輯錯(cuò)誤，對(duì)程序的性能也給出了建議（第2條反饋）
-
冒泡排序算法的內(nèi)層循環(huán)條件for (j = 0; j < len - 1 - i; j++)中的len - 1 - i可能會(huì)導(dǎo)致數(shù)組越界。應(yīng)該將內(nèi)層循環(huán)條件修改為for (j = 0; j < len - 1; j++)。
- 在冒泡排序算法中，如果數(shù)組已經(jīng)是有序的，仍會(huì)執(zhí)行完所有的比較和交換操作，造成了性能上的浪費(fèi)。可以在內(nèi)層循環(huán)中增加一個(gè)判斷條件，如果沒(méi)有發(fā)生交換，即可提前退出循環(huán)。
圖13
需要注意的是目前GPT仍然是概率算法，他的反饋需要一定的人工復(fù)核，確保剔除AI給出的噪音反饋。
圖14
測(cè)試則是軟件質(zhì)量的守護(hù)神，涵蓋單元測(cè)試、集成測(cè)試、功能測(cè)試、系統(tǒng)測(cè)試及驗(yàn)收測(cè)試等不同層次，目的是盡早發(fā)現(xiàn)問(wèn)題、減少后期修復(fù)成本、確保軟件符合客戶(hù)需求與期望。無(wú)論是在V模型或者敏捷開(kāi)發(fā)模型中，軟件測(cè)試活動(dòng)的目的是一致的，而測(cè)試活動(dòng)貫穿整個(gè)開(kāi)發(fā)周期（圖14所示的V模型）。早期集成測(cè)試能有效縮短交付周期，提高客戶(hù)滿(mǎn)意度。
圖15
測(cè)試執(zhí)行過(guò)程從時(shí)間順序上可以分為三大部分：?jiǎn)卧獪y(cè)試，集成與功能測(cè)試和系統(tǒng)驗(yàn)證與驗(yàn)收測(cè)試（圖15）。單元測(cè)試聚焦單個(gè)代碼單元的功能正確性；集成與功能測(cè)試檢查模塊間交互與整體功能完整性；系統(tǒng)與驗(yàn)收測(cè)試則驗(yàn)證軟件系統(tǒng)在真實(shí)環(huán)境下的表現(xiàn)是否滿(mǎn)足需求。
通過(guò)及早發(fā)現(xiàn)問(wèn)題，測(cè)試不僅能節(jié)約成本，還能提升軟件的穩(wěn)定性和可靠性，為市場(chǎng)成功奠定堅(jiān)實(shí)基礎(chǔ)。在實(shí)際操作過(guò)程中，無(wú)論是敏捷或是V模型，測(cè)試過(guò)程并沒(méi)有這么嚴(yán)格的順序區(qū)分，往往是循環(huán)迭代的反復(fù)過(guò)程。對(duì)于如何確保已經(jīng)驗(yàn)證的功能仍然是可信的，往往是需要經(jīng)驗(yàn)和智慧的積累。
關(guān)于軟件測(cè)試，我們必須清晰地認(rèn)識(shí)到“測(cè)試不是銀彈。窮盡測(cè)試是不可能也不現(xiàn)實(shí)的”。所以，端到端的軟件質(zhì)量保障，從需求到設(shè)計(jì)，從編碼到測(cè)試，全鏈路的保障才是我們需要竭盡全力的目標(biāo)。
圖16
伴隨著AGI及數(shù)字化技術(shù)的發(fā)展，測(cè)試技術(shù)手段也在日益改進(jìn)，新的測(cè)試技術(shù)開(kāi)始逐步開(kāi)始向RPA，AI賦能的測(cè)試手段方向發(fā)展（見(jiàn)圖16）。
而對(duì)汽車(chē)行業(yè)軟件開(kāi)發(fā)而言，自動(dòng)化測(cè)試技術(shù)、RPA、AI、新的應(yīng)用場(chǎng)景的測(cè)試也慢慢開(kāi)始滲透，成為測(cè)試團(tuán)隊(duì)的新挑戰(zhàn)。
四、軟件發(fā)布：舞動(dòng)的韻律
軟件發(fā)布的全過(guò)程是一個(gè)嚴(yán)謹(jǐn)有序且不斷迭代前行的。進(jìn)入開(kāi)發(fā)階段后，采用CI/CD（持續(xù)集成/持續(xù)部署）的實(shí)踐，包括代碼提交、規(guī)則檢查、代碼評(píng)審、預(yù)編譯、軟件包構(gòu)建、內(nèi)部發(fā)布、測(cè)試驗(yàn)證以及對(duì)外發(fā)布等一整套流程，確保軟件質(zhì)量的持續(xù)性和穩(wěn)定性。在這一過(guò)程中，構(gòu)建Sanity、自動(dòng)化測(cè)試以及各類(lèi)環(huán)境下的驗(yàn)證是必不可少的環(huán)節(jié)（見(jiàn)圖17）。CICD在軟件開(kāi)發(fā)全生命周期中體現(xiàn)的核心思想是快速反饋、頻繁交付和可靠質(zhì)量。通過(guò)自動(dòng)化構(gòu)建和部署流水線(xiàn)，讓開(kāi)發(fā)團(tuán)隊(duì)能夠迅速響應(yīng)變化，減少人工干預(yù)帶來(lái)的延誤和錯(cuò)誤，確保軟件在各個(gè)階段都能高效地完成集成、測(cè)試和部署，最終達(dá)到高質(zhì)量、高效率的產(chǎn)品交付目標(biāo)。
圖17
在軟件的維護(hù)階段，針對(duì)存在的問(wèn)題和錯(cuò)誤進(jìn)行及時(shí)修復(fù)，根據(jù)用戶(hù)反饋和市場(chǎng)需求持續(xù)進(jìn)行功能改進(jìn)與性能優(yōu)化。對(duì)于汽車(chē)行業(yè)的嵌入式軟件而言，還涉及到與硬件結(jié)合的復(fù)雜集成測(cè)試，以及類(lèi)似FOTA，SOTA（空中下載技術(shù)）更新等特殊的軟件升級(jí)場(chǎng)景。此外，汽車(chē)行業(yè)軟件發(fā)布遵循項(xiàng)目生命周期的各個(gè)階段，如工程樣車(chē)（EP）、產(chǎn)品及過(guò)程驗(yàn)證（PPV）、預(yù)試生產(chǎn)（PP）、試生產(chǎn)（P），直至正式投產(chǎn)（SOP）。在整個(gè)過(guò)程中，項(xiàng)目質(zhì)量管理扮演著關(guān)鍵角色，不僅要保證軟件產(chǎn)品的質(zhì)量和性能，還要確保軟件開(kāi)發(fā)與發(fā)布過(guò)程符合既定的質(zhì)量標(biāo)準(zhǔn)和國(guó)標(biāo)、企標(biāo)。
五、研發(fā)基礎(chǔ)：技術(shù)研發(fā)與產(chǎn)品研發(fā)的“雙輪驅(qū)動(dòng)”
技術(shù)研發(fā)與產(chǎn)品研發(fā)雖同屬創(chuàng)新范疇，但各有側(cè)重。
- 技術(shù)研發(fā)著眼于長(zhǎng)遠(yuǎn)，追求技術(shù)先進(jìn)性與知識(shí)積累，目標(biāo)是開(kāi)發(fā)出具有競(jìng)爭(zhēng)優(yōu)勢(shì)的技術(shù)成果，為未來(lái)的市場(chǎng)化產(chǎn)品提供技術(shù)支持（TPF過(guò)程）。
- 產(chǎn)品研發(fā)更直接面向市場(chǎng)，關(guān)注產(chǎn)品創(chuàng)新與商業(yè)化進(jìn)程，旨在快速推出符合用戶(hù)需求的新產(chǎn)品，創(chuàng)造價(jià)值與利潤(rùn)（PMF過(guò)程）。
如圖18所示，技術(shù)研發(fā)和產(chǎn)品研發(fā)在生命周期、市場(chǎng)定位、技術(shù)難度、管理手段等方面存在顯著差異，但均需緊密?chē)@用戶(hù)需求展開(kāi)。技術(shù)研發(fā)往往領(lǐng)先數(shù)年，承擔(dān)探索未知、孵化前沿技術(shù)的角色；產(chǎn)品研發(fā)則緊跟市場(chǎng)脈搏，力求在短期內(nèi)實(shí)現(xiàn)產(chǎn)品的更新?lián)Q代。二者相互依賴(lài)，共同推動(dòng)企業(yè)技術(shù)創(chuàng)新與產(chǎn)品迭代的良性循環(huán)。當(dāng)然，因?yàn)?/span>技術(shù)研發(fā)與產(chǎn)品研發(fā)的定位不同，企業(yè)在實(shí)際管理過(guò)程中，不能把產(chǎn)品研發(fā)的管理手段，比如某款車(chē)型研發(fā)，簡(jiǎn)單地套用到技術(shù)研發(fā)管理中（比如，某款新材料、新動(dòng)力電池或平臺(tái)架構(gòu)等）。
圖18
六、研發(fā)基礎(chǔ)：組織與人才發(fā)展的軟實(shí)力構(gòu)建
軟件開(kāi)發(fā)的成功離不開(kāi)強(qiáng)大的組織支撐與人才隊(duì)伍建設(shè)。
研發(fā)組織應(yīng)注重能力建設(shè)，涵蓋組織架構(gòu)設(shè)計(jì)、業(yè)務(wù)流程梳理、數(shù)字化工具鏈集成（如禪道管理軟件，CICD工具鏈，云端軟件DevOPS工具鏈等）、知識(shí)管理、信息安全等多個(gè)維度。同時(shí)，建立健全績(jī)效考核與激勵(lì)機(jī)制，確保人才的成長(zhǎng)與發(fā)展與組織戰(zhàn)略目標(biāo)相一致。
人才發(fā)展方面，提供管理與專(zhuān)業(yè)技術(shù)兩條晉升通道，滿(mǎn)足不同類(lèi)型人才的職業(yè)發(fā)展需求。管理路線(xiàn)涵蓋研發(fā)主管、經(jīng)理、總監(jiān)等。專(zhuān)業(yè)技術(shù)路線(xiàn)包括了高級(jí)項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、質(zhì)量經(jīng)理等專(zhuān)業(yè)角色；專(zhuān)業(yè)技術(shù)路線(xiàn)還包括了技術(shù)專(zhuān)家、高級(jí)專(zhuān)家、資深專(zhuān)家等技術(shù)精英。通過(guò)明確的職業(yè)發(fā)展路徑，激發(fā)人才潛能，形成穩(wěn)定且富有活力的人才梯隊(duì)，避免“重技術(shù)，輕職業(yè)化”的問(wèn)題。根據(jù)PRTM的產(chǎn)品開(kāi)發(fā)能力成熟度評(píng)估模型（圖19），軟件開(kāi)發(fā)組織的成熟度可以分為5級(jí)。
建議優(yōu)秀的車(chē)企應(yīng)該向成熟度4級(jí)（Stage 3）努力，提升組織的核心競(jìng)爭(zhēng)力，確保打贏(yíng)汽車(chē)智能化和汽車(chē)產(chǎn)業(yè)數(shù)字化這一仗！
圖19 （Source：PRTM 產(chǎn)品開(kāi)發(fā)能力）
結(jié)束：本文為我們勾勒出一幅從理論到實(shí)踐、從模型選擇到組織構(gòu)建的全景圖。無(wú)論是初涉軟件行業(yè)的新人，還是尋求優(yōu)化研發(fā)流程的企業(yè)管理者，都可以從中汲取寶貴的知識(shí)與經(jīng)驗(yàn)，助力在瞬息萬(wàn)變的科技浪潮中穩(wěn)操勝券。軟件開(kāi)發(fā)并非孤立的編程活動(dòng)，而是涵蓋了需求分析、架構(gòu)設(shè)計(jì)、編碼實(shí)踐、測(cè)試保障、技術(shù)研發(fā)、產(chǎn)品研發(fā)、組織管理與人才培育等多元要素的系統(tǒng)工程。唯有深入理解并妥善駕馭這些要素，方能在激烈的市場(chǎng)競(jìng)爭(zhēng)中立于不敗之地。
轉(zhuǎn)自水輕言
