就像B端和C端的方法論存在差異一樣，智能座艙的需求，和手機(jī)上的需求處理也不一樣。本文作者通過(guò)自己實(shí)踐經(jīng)驗(yàn)，和大家分享智能座艙的需求管理方法，供大家參考。

隨著汽車行業(yè)邁入軟件定義汽車（SDV）的時(shí)代，智能座艙逐漸成為整車差異化競(jìng)爭(zhēng)的關(guān)鍵。用戶期待車內(nèi)體驗(yàn)像手機(jī)一樣絲滑，法規(guī)要求與安全標(biāo)準(zhǔn)又在不斷演進(jìn)，產(chǎn)品開(kāi)發(fā)涉及大量軟硬件交互與跨部門協(xié)作。如何高效地管理需求，確保需求從提出到交付始終保持完整性、一致性和可追溯性，成為擺在產(chǎn)研團(tuán)隊(duì)面前的一大難題。

過(guò)去兩年，我們?cè)谛枨蠊芾矸矫孢M(jìn)行了持續(xù)探索和實(shí)踐，希望通過(guò)這篇文章，分享我們?cè)谥悄茏擁?xiàng)目中的需求管理方法，幫助更多團(tuán)隊(duì)理清思路，實(shí)現(xiàn)需求的落地和高效交付。

一、智能座艙需求管理的挑戰(zhàn)

需求，簡(jiǎn)單來(lái)說(shuō)，就是人們?cè)谔囟ㄇ榫诚?，?duì)產(chǎn)品、服務(wù)或資源的渴望和期待。

在汽車研發(fā)的廣闊語(yǔ)境中，需求幾乎無(wú)處不在——產(chǎn)品定義、市場(chǎng)營(yíng)銷、生產(chǎn)制造，甚至售后服務(wù)都可以成為需求的來(lái)源。如果進(jìn)一步拆解，我們可以將需求大致歸為兩類：

• 技術(shù)類需求（Requirement）：通過(guò)工程和技術(shù)手段來(lái)實(shí)現(xiàn)，涉及軟件、硬件、系統(tǒng)集成等領(lǐng)域，支撐著產(chǎn)品功能的具體落地。
• 非技術(shù)類需求（Needs）：更偏向業(yè)務(wù)目標(biāo)、市場(chǎng)導(dǎo)向或管理層面的期望，不依賴具體的工程實(shí)現(xiàn)，卻對(duì)產(chǎn)品的方向和優(yōu)先級(jí)有著決定性的影響。

本文聚焦的，是智能座艙中至關(guān)重要的技術(shù)類需求（Requirement）——那些直接影響座艙體驗(yàn)、功能實(shí)現(xiàn)和用戶價(jià)值的核心需求。

過(guò)去兩年多的時(shí)間里，我有幸參與或旁觀了十余個(gè)國(guó)內(nèi)外智能座艙項(xiàng)目。這些項(xiàng)目涵蓋從高端到入門級(jí)的各類車型，經(jīng)歷了從藍(lán)圖繪制到泥濘前行，再到攻堅(jiān)交付的完整旅程。智能座艙項(xiàng)目就像一場(chǎng)接力長(zhǎng)跑，而需求正是那根不斷傳遞的接力棒。

需求的價(jià)值、質(zhì)量和流轉(zhuǎn)效率，不僅決定了項(xiàng)目的節(jié)奏，更影響著最終的交付成效。在無(wú)數(shù)次的評(píng)審、溝通和返工中，需求的重要性被一次次印證，而如何將需求從無(wú)形的愿景變成扎實(shí)落地的功能，是值得深思的問(wèn)題。

1. 需求來(lái)源繁多且復(fù)雜

智能座艙集成了儀表（DIM）、抬頭顯示屏（HUD）、中控大屏（CSD），高端車型甚至擁有副駕屏（PSD）和后排娛樂(lè)屏（RSD）。這不僅是“多屏互動(dòng)”，更是多方利益交織的結(jié)果——駕駛員要便捷，乘客要舒適，監(jiān)管機(jī)構(gòu)強(qiáng)調(diào)安全，而市場(chǎng)又不斷推陳出新。再加上AI、物聯(lián)網(wǎng)和5G等前沿技術(shù)的持續(xù)加碼，讓智能座艙成為一個(gè)技術(shù)密集、需求紛繁的復(fù)雜系統(tǒng)。每一條需求背后，都是一場(chǎng)在多方平衡中的艱難取舍。

2. 需求定義復(fù)雜，步步抽絲剝繭

面對(duì)如此多元的需求來(lái)源，定義出一份“所有人都滿意”的需求清單是不可能的任務(wù)。這就像剝洋蔥——一層層揭開(kāi)后，總有新的細(xì)節(jié)浮現(xiàn)。產(chǎn)研團(tuán)隊(duì)不僅需要從駕駛員、用戶體驗(yàn)、法規(guī)、市場(chǎng)等多重渠道篩選有效需求，還要在優(yōu)先級(jí)排序中尋找平衡點(diǎn)，甚至妥善處理沖突需求。每一項(xiàng)功能、每一個(gè)交互都可能牽動(dòng)整個(gè)系統(tǒng)。而如何確保需求在不斷打磨的過(guò)程中不偏離原始目標(biāo)，是需求管理中的核心難題。

3. 需求分配跨學(xué)科、跨領(lǐng)域

智能座艙往往是機(jī)電軟硬多學(xué)科一體化的系統(tǒng)。比如一個(gè)簡(jiǎn)單的語(yǔ)音操控導(dǎo)航功能，背后需要語(yǔ)音識(shí)別、導(dǎo)航、屏幕麥克風(fēng)集成、數(shù)據(jù)安全等團(tuán)隊(duì)的合力。即便在同一領(lǐng)域，復(fù)雜系統(tǒng)的開(kāi)發(fā)往往從系統(tǒng)級(jí)逐層分解到具體代碼單元，每個(gè)組件的實(shí)現(xiàn)都涉及大量分工與協(xié)作?？绮块T溝通不暢，需求理解偏差，都會(huì)成為需求落地的“攔路虎”，一旦缺乏有效的需求流轉(zhuǎn)機(jī)制，就可能造成效率低下甚至項(xiàng)目延誤。

二、需求管理的解決思路與實(shí)踐

面對(duì)上述需求管理的痛點(diǎn)與難點(diǎn)，我們根據(jù)產(chǎn)研團(tuán)隊(duì)的現(xiàn)狀，借鑒了業(yè)界的優(yōu)秀實(shí)踐，研究出了一套需求管理方案，力求在復(fù)雜環(huán)境下，實(shí)現(xiàn)需求的有序流轉(zhuǎn)與高效交付。

1. 層級(jí)分離，統(tǒng)一視角

在多車型、多領(lǐng)域交叉并行的環(huán)境下，需求往往碎片化，難以統(tǒng)籌管理。為了解決這一問(wèn)題，我們將需求管理劃分為兩層空間：

• 產(chǎn)品空間：負(fù)責(zé)整車或車型產(chǎn)品的需求輸入與管理，體現(xiàn)客戶與產(chǎn)品的視角，關(guān)注需求全局和交付范圍。
• 領(lǐng)域空間：負(fù)責(zé)具體領(lǐng)域內(nèi)的需求實(shí)現(xiàn)與交付，專注于需求的落地執(zhí)行與閉環(huán)管理。

這樣做的好處是，產(chǎn)品空間形成了完整的需求池，能夠全量跟蹤需求范圍和進(jìn)度，避免遺漏。領(lǐng)域空間確保需求在具體實(shí)現(xiàn)層面集中管理，避免需求在不同空間分散，利于統(tǒng)一排期和資源管理，有效地打通了需求的上下游鏈路，實(shí)現(xiàn)了從全局到局部、從戰(zhàn)略到執(zhí)行的統(tǒng)一視角。

2. 全鏈路覆蓋，雙向追溯

需求的實(shí)現(xiàn)往往是一個(gè)從概念到交付的逐步細(xì)化過(guò)程，為此，我們?cè)O(shè)計(jì)了四種需求類型，覆蓋需求生命周期的不同階段，確保需求貫穿全鏈路：

• 原始需求：記載需求獲取階段通過(guò)何種途徑獲取的需求信息，并判斷是否納入實(shí)現(xiàn)范圍的裁定。
• 產(chǎn)品需求：將原始需求進(jìn)行分析、轉(zhuǎn)化、定義為適合組織內(nèi)可實(shí)現(xiàn)、可管理的系統(tǒng)需求。
• 領(lǐng)域特性：將產(chǎn)品需求按照不同的學(xué)科領(lǐng)域拆解，進(jìn)入排期和交付，可以沉淀為領(lǐng)域內(nèi)的能力。
• 用戶故事：將領(lǐng)域內(nèi)的特性需求進(jìn)一步拆解，使之成為適合一線團(tuán)隊(duì)在一個(gè)固定時(shí)間盒里（比如兩周）交付的工作項(xiàng)。

需求鏈路管理的核心在于雙向追溯機(jī)制：

• 自上而下：從客戶需求到用戶故事逐級(jí)拆解，確保需求在每個(gè)階段均有具體落地。
• 自下而上：建立雙向鏈接，用戶故事、領(lǐng)域特性可向上回溯到具體的產(chǎn)品需求和原始需求，確保需求鏈路完整可追蹤，減少遺漏和需求懸空。

這種機(jī)制確保了需求在不同階段都有明確的“載體”和“路徑”，實(shí)現(xiàn)了需求的端到端可追溯性，確保每個(gè)環(huán)節(jié)有跡可循，避免懸空或者脫節(jié)。

3. 動(dòng)態(tài)閉環(huán)，適應(yīng)敏捷迭代

兩層空間、四種類型，完成了需求內(nèi)容的承載與記錄，但如何將需求導(dǎo)入研發(fā)，直至上線，這里需要的就是動(dòng)態(tài)的“狀態(tài)”管理。雖然需求從分析、到設(shè)計(jì)、到研發(fā)、到測(cè)試、到驗(yàn)證，有眾多角色的參與、有各種專業(yè)任務(wù)的配合，但我們只圍繞需求的核心價(jià)值流進(jìn)行狀態(tài)管理，聚焦以下關(guān)鍵節(jié)點(diǎn)：

• 需求分析：需求從創(chuàng)建到準(zhǔn)備就緒狀態(tài)，代表需求分析、設(shè)計(jì)、評(píng)審?fù)瓿?，具備進(jìn)入開(kāi)發(fā)階段的條件。
• 需求開(kāi)發(fā)：需求進(jìn)入研發(fā)狀態(tài)，研發(fā)團(tuán)隊(duì)開(kāi)始具體功能的開(kāi)發(fā)、集成與調(diào)試。
• 需求驗(yàn)證：進(jìn)入驗(yàn)證狀態(tài)后，需求通過(guò)測(cè)試、驗(yàn)證，確保功能符合預(yù)期，最終流轉(zhuǎn)至完成。

這種動(dòng)態(tài)閉環(huán)機(jī)制的特點(diǎn)在于，它將需求狀態(tài)與價(jià)值流緊密綁定，減少了冗余復(fù)雜的狀態(tài)管理，從而確保需求在各階段能夠有序推進(jìn)。同時(shí)，需求狀態(tài)的變更對(duì)相關(guān)方完全透明，項(xiàng)目管理者能夠?qū)崟r(shí)掌握需求進(jìn)度，及時(shí)發(fā)現(xiàn)并解決潛在問(wèn)題。通過(guò)與版本周期的同步管理，確保了需求能夠靈活應(yīng)對(duì)變更，支持敏捷開(kāi)發(fā)和持續(xù)交付的目標(biāo)。

三、實(shí)施兩年后的沉思

需求管理方案的落地，使我們?cè)谛枨笞粉?、協(xié)同效率和交付質(zhì)量方面取得了顯著進(jìn)展（具體內(nèi)容不便展開(kāi)）。同時(shí)，我們也發(fā)現(xiàn)了一些值得進(jìn)一步優(yōu)化和思考的方向。

1. 需求管理：從“內(nèi)容”到“過(guò)程”，全面覆蓋項(xiàng)目生命周期

需求管理不僅僅是對(duì)需求內(nèi)容的管理，更是一套完整的項(xiàng)目生命周期管理方式。需求的本質(zhì)涉及的不只是需求本身的文字描述和功能細(xì)節(jié)，而涵蓋了圍繞需求展開(kāi)的：

• 項(xiàng)目管理：需求的排期、狀態(tài)流轉(zhuǎn)和優(yōu)先級(jí)管理。
• 組織協(xié)作：各部門和角色間的協(xié)作，需求在不同職能間的流轉(zhuǎn)與反饋。
• 風(fēng)險(xiǎn)防控：需求變更帶來(lái)的潛在風(fēng)險(xiǎn)，需求依賴的管理以及變更評(píng)估的有效性。

2. 需求追蹤矩陣：聯(lián)動(dòng)測(cè)試與缺陷，打造更完整的需求閉環(huán)

目前，我們已經(jīng)實(shí)現(xiàn)了需求的層層拆解和全鏈路追蹤。但需求真正的閉環(huán)不僅止步于需求，更應(yīng)延伸至測(cè)試用例和缺陷管理。理想狀態(tài)下，每個(gè)需求的驗(yàn)證和測(cè)試用例都能夠與對(duì)應(yīng)的需求一一關(guān)聯(lián)，缺陷與測(cè)試用例緊密綁定，從而形成清晰的“需求-測(cè)試-缺陷”矩陣。這種方式將使需求驗(yàn)證更加直觀透明，缺陷的修復(fù)能夠直接追溯到原始需求，確保需求的每一個(gè)實(shí)現(xiàn)環(huán)節(jié)都能閉環(huán)反饋，減少遺漏或盲區(qū)。

3. 方法論：從實(shí)踐中沉淀，而非照搬框架

雖然在咨詢公司工作多年，但我始終相信“方法論是工具，而非目的”。回顧這一套需求管理方案的設(shè)計(jì)，我們并非完全依賴于某個(gè)單一的方法論，而是從各類敏捷和研發(fā)管理體系中汲取精華，將其融合成適合自身團(tuán)隊(duì)的需求管理模式。如果偏要討論理論依據(jù)，我們?cè)趯?shí)際操作中，有意無(wú)意地整合了以下實(shí)踐：

• IPD（集成產(chǎn)品開(kāi)發(fā)）的分層需求管理思路，確保需求從客戶到研發(fā)全鏈路貫通。
• SAFe（Scaled Agile Framework）的大規(guī)模敏捷框架，強(qiáng)調(diào)需求在多團(tuán)隊(duì)間的協(xié)同與追蹤。
• FDD（Feature-Driven Development）的逐步細(xì)化原則，將需求拆解至特性和用戶故事層級(jí)，逐步實(shí)現(xiàn)。
• Scrum的迭代開(kāi)發(fā)節(jié)奏，使用戶故事能夠在小步快跑中不斷推進(jìn)，適應(yīng)市場(chǎng)變化。

沒(méi)有銀彈，適合團(tuán)隊(duì)自身的，就是最好的實(shí)踐。