首先，我們需要明確汽車行業(yè)的需求管理和其他行業(yè)有什么不同？為什么要單獨把汽車行業(yè)的需求管理單獨拎出來？

基于汽車行業(yè)的行業(yè)特點（通過提高產(chǎn)量，降低單車成本）、產(chǎn)品特點（與人身駕駛安全相關，因此面臨著比較多的法規(guī)要求，如功能安全ISO 26262、信息安全ISO/SAE 21434），汽車行業(yè)至少在如下6點，與其他行業(yè)的需求管理相比，存在著較大差異。

需求分類型管理

汽車行業(yè)的需求管理，一直就有分類型的傳統(tǒng)。在V模型里面，至少會被分為 3種類型：市場需求、系統(tǒng)需求、軟件需求（有時可能還有硬件需求，系統(tǒng)需求包含硬件需求和軟件需求）。和敏捷開發(fā)里面的epic、feature、story 的分類很不一樣（有些團隊可能還有requirement等）。汽車行業(yè)的分類依據(jù)，更多的是需求來源，以及承載的主體。敏捷開發(fā)中，需求的分類依據(jù)，則主要是根據(jù)需求的大小及范圍。epic 是一個大的需求集合（中文翻譯為史詩，從這個名字也可以知道，它涵蓋的范圍很廣），feature 是一個產(chǎn)品特性，story 則被理解成一個用戶故事，或者一個用戶場景。

V模型和敏捷開發(fā)融合的第一道坎就是，怎么讓汽車工程師聽懂敏捷開發(fā)的語言？聽懂epic、feature、story，并能和互聯(lián)網(wǎng)工程師對話。

簡單地把敏捷開發(fā)的需求類型，生搬硬套用到汽車行業(yè)是不可行的。首先，需要讓汽車工程師理解什么是epic、feature、story ，就存在一定的難度。我在蔚來汽車工作3年，發(fā)現(xiàn)對這3個需求類型的理解，存在非常大的差異。對于什么樣的功能應該被歸為feature，什么是story，也會非常主觀。更多時候，這3種需求類型根本不夠用，于是引入更多自定義的需求類型。這時候，要讓大家理解一致就更難了。開會的時候，經(jīng)常會因為需求屬于什么類型而爭吵。

當時，我所在的整車研發(fā)部門，有一份叫 FDS的excel文件，F(xiàn)unction Definition Specification。在這份文件里，整車級別的需求，逐層往下細分。整車需求被分為 8 大塊，包含了自動駕駛、智能座艙、車聯(lián)網(wǎng)等等。每一個大塊又被分為無數(shù)的小塊，一層一層地往下分。每條需求都有多個字段，主要包括ID號、需求名稱、需求描述、責任人、關聯(lián)部門、當前狀態(tài)、備注信息等。相信當時使用過這份FDS表格的同學都會記憶深刻，這份表格比當時任何一個在線工具都好用，每一層級都是可以無限往下細分，也可以折疊、展開。既可以從整車層面把握需求的完成情況，也可以從更細節(jié)的層面，了解需求的上下文。它另外一個最大的優(yōu)點就是：需求的顆粒度，工程師擁有最大程度的自由度。無需根據(jù)epic、feature、story這種死板的模型，來死摳需求的顆粒度，而是完全根據(jù)業(yè)務場景的需要，根據(jù)需求的復雜程度來劃分。有些需求比較復雜，場景比較多，可能會被分為五六層。有些需求則比較簡單，兩層就可以說清楚。

但是這張表格也有一個顯著的缺點，它是平面二維的，不擅長在此基礎上，繼續(xù)關聯(lián)架構、測試用例、bug等等，一定要做也行，但表格的復雜度會指數(shù)級升高。所以，在此基礎上，我們也使用jira做任務管理和bug跟蹤。后來，智能座艙部分的需求也完全是在jira上進行管理的。然后就碰到了我上面描述的“生搬硬套”問題：為了適應敏捷管理工具的特點，我們犧牲了對需求顆粒度的自由度把控。

為了讓汽車行業(yè)的需求工程師，更好做需求管理，我們開發(fā)了一款完全針對汽車行業(yè)的研發(fā)管理工具 MappingSpace。在MappingSpace 里面，需求是以思維導圖的方式進行管理的，每一個節(jié)點就對應的一個需求。思維導圖天生的特點，決定了需求具有不同層級的顆粒度，根節(jié)點顆粒度最粗，越往外層，顆粒度越細。工程師根據(jù)產(chǎn)品特點以及團隊需要，對需求不斷往下做分解，直至需求描述足夠清晰，且可以將需求落實到每一個責任人。需求工程師再也不需要考慮，究竟什么樣的需求是story，什么樣的需求是feature。

需求的關聯(lián)及追溯性

在汽車行業(yè)，架構一般會伴隨著需求出現(xiàn)。在V模型里面，對應系統(tǒng)需求，有系統(tǒng)架構；對應軟件需求，有軟件架構。

一圖勝千言，圖解能引起的誤解，會比文字小很多。架構圖一般來說是必須的，特別是團隊需要通過ASPICE或者功能安全或者信息安全。架構圖一般包含靜態(tài)架構圖和動態(tài)架構圖。靜態(tài)架構圖包含了模塊圖、組件圖等等，動態(tài)架構圖包含了軟件運行的時序圖。

在汽車行業(yè)，每一條需求都需要與對應的架構做關聯(lián)。

這是一種更為嚴謹?shù)男枨蠊芾矸绞健Ｔ贛appingSpace 里面，架構文檔也是用思維導圖來寫的。基于思維導圖，我們可以對架構進行層層分解。架構文檔的根節(jié)點，我們可以畫一張整體的架構圖。架構文檔的每一個子節(jié)點，也可以附帶子節(jié)點的詳細架構圖。

由于天生嵌入了drawio這個第三方插件，在架構繪制上擁有很大優(yōu)勢。

每一條需求，同樣需要與測試用例相關聯(lián)。每個行業(yè)都有類似要求，只不過在汽車行業(yè)，這條要求尤為嚴格，需要檢測需求的覆蓋度。在MappingSpace里面，我們可以從兩個地方去查看覆蓋度：一個是在思維導圖頁面，一個是在測試報告里。

需求評審

當需求被寫出來之后，需要經(jīng)歷評審。很多行業(yè)都會做需求的評審，但是在汽車行業(yè)，需求的評審同樣更為嚴格。系統(tǒng)中需要明確含有需求的評審過程、評審條目，以及評審完之后的修改過程，需要有過程記錄。很多團隊知道評審的重要性。通過評審，可以在產(chǎn)品開發(fā)之前就發(fā)現(xiàn)很多的潛在缺陷（汽車行業(yè)的FMEA分析，和需求評審有異曲同工之妙）。在這時候解決問題，顯然要比產(chǎn)品發(fā)布之后再來解決，更為敏捷，并且效率更高，付出的代價也更小。

最高效的評審當然是面對面討論。但很多情況下，討論的過程無法被準確的記錄下來。評審的過程，一般需要多個角色參與，如需求工程師、開發(fā)工程師、測試工程師、架構師等等。很難在同一時間把所有人都聚集起來，開一個漫長且有效的會議。這是評審過程中最大的兩處難點：改進點的記錄及后續(xù)的跟蹤、經(jīng)常有人缺席評審會議。

在MappingSpace里面，我們也提供了評審工具。我們可以很輕易地從一個需求的思維導圖中，選擇需要評審的需求，然后去發(fā)送評審請求，包含了固定評審人和用戶此次指定的評審人。

它是一個線上的、非實時的評審機制。在評審任務結束之前，在任何時間進行評審都是可以的。系統(tǒng)會在所有人評審完之后，根據(jù)用戶預置的評審通過規(guī)則，來確定最終的結果。評審通過或不通過的結論，也會出現(xiàn)在每個需求的詳情頁。對于不通過的需求，用戶可以進行進一步的修改，直到該條需求下次通過評審。

需求基線

在敏捷開發(fā)里面，需求變化特別快，基線的概念非常弱。需求一直在變，整個團隊的開發(fā)，一直是基于最新的需求進行開發(fā)的。無需知道每一個版本的開發(fā)起點是什么。但是這種做法在汽車行業(yè)不太可行。

汽車行業(yè)需要有明確的基線概念。如果某個版本是基于5月1號的需求版本進行開發(fā)的，那么可能意味著，在5月 1 號到5月30號版本發(fā)布之間，整個團隊都是基于5月1號的需求版本，中途是不會接受特別頻繁的變化的。那是不是可以直接把5月1號需求給鎖定了呢？有些團隊這么做的。通過流程或者工具進行限制，如通過SVN拉出一個副本。團隊基于這個副本進行開發(fā)。但是我們需要承認：需求的變化是不可避免的。這種方式關閉了快速響應需求變化的通道，如果明知道需求錯了，團隊還得按照錯誤的需求去做，等到下一個版本才去更正，這顯然是一種低效的開發(fā)方式。通過SVN拉出的副本，也無法進行需求任務的分配、狀態(tài)變更等，這是另一個缺點。

如何既能保存一條基線，團隊有需要時可以參考，同時又能快速需求的響應變化呢？

在 MappingSpace 里面，我們提供基線頁面。這樣整個團隊就有了一個基線的參考頁面。基線中的內(nèi)容會被鎖定，無法修改需求的內(nèi)容，但是狀態(tài)推進、任務分配等操作仍然是可以的。當需要對需求進行變更時，需要走變更評審流程，并且基線頁面會明確顯示，發(fā)生了怎樣的變化或者需求新增。

需求變更

變更管理特別重要，如果變更管理沒有做好，特別消耗時間精力，會導致團隊效率降低。通常來說，有兩種比較常見的處理方式。一種是當拉出基線之后，就不再允許變更，直到當前版本開發(fā)結束。顯然，這種方式不夠敏捷。

另外一種方式就是，當拉了基線之后，如果有變更，需要走變更流程，經(jīng)過變更委員會的評審，評審通過之后，再加入到基線里面。變更委員會里面，可能包含了架構師、項目經(jīng)理、測試工程師等等。這個過程如果在線下，或者一些線上工具使用不當，也會造成很大的困擾。比如，變更一般發(fā)生在拉基線之后，很多工具沒有基線的概念，那么變更請求什么時候做，就變得比較難以把握了。再比如，變更評審會一般需要多方來參與，如何把這些人聚在一起并且參與討論，這也是一個難題。如果只是簡單地給每一個人發(fā)一封郵件，起不到真正識別變更風險的效果。

在 MappingSpace 里面，當基線開始之后，需求被鎖定。鎖定之后，無法直接變更，而是從需求上拉出一個副本，在副本上修改完之后，再發(fā)起變更請求。需要邀請評審人員，評審的過程也是一個非實時的線上過程。被邀請人，無論選擇通過還是不通過，都會在系統(tǒng)中留下記錄。

需求復用

在互聯(lián)網(wǎng)行業(yè)的開發(fā)，基本上不存在復用的問題。一個軟件產(chǎn)品被開發(fā)出來之后，一般來說，另外的產(chǎn)品線和它是不一樣的，需求很少被復用。

汽車行業(yè)，是一個非常明顯的需要通過走量，從而來攤銷成本的過程。在不同車型之間改款，特別是針對硬件的改款，成本特別高。需要盡可能復用，減去設計、開模、工藝優(yōu)化、生產(chǎn)設備調(diào)試的各類成本。特斯拉的發(fā)展歷史，非常清晰表明了這一點。

在當前這個時代，汽車越來越重視軟件。雖然車型之間軟件的變化是非常快的，可以有更大的自由度，但是不可否認的是，汽車軟件屬于嵌入式軟件，需要和硬件配合。如果硬件需要保持比較小的變化，必然制約了軟件的變化。總體來說，不管是軟件需求還是硬件需求，汽車行業(yè)復用的比例，都比互聯(lián)網(wǎng)高很多。

在MappingSpace里面，每個車型上的通用型需求，通過思維導圖，可以快速并且批量地移入到企業(yè)級需求池。當有了新的車型項目時，也很容易從需求池里面，將這些需求移入到全新的項目中。這一點對于硬件需求的管理，優(yōu)勢更加明顯。

審核編輯 ：李倩