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

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

過去兩年，我們在需求管理方面進行了持續(xù)探索和實踐，希望通過這篇文章，分享我們在智能座艙項目中的需求管理方法，幫助更多團隊理清思路，實現(xiàn)需求的落地和高效交付。

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

需求，簡單來說，就是人們在特定情境下，對產(chǎn)品、服務(wù)或資源的渴望和期待。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

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

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

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

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

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

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

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

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

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

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

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

二、需求管理的解決思路與實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、實施兩年后的沉思

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

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

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

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

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

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

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

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

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

沒有銀彈，適合團隊自身的，就是最好的實踐。