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

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

需求分類型管理

汽車行業(yè)的需求管理，一直就有分類型的傳統(tǒng)。在V模型里面，至少會被分為 3種類型：市場需求、系統(tǒng)需求、軟件需求（有時可能還有硬件需求，系統(tǒng)需求包含硬件需求和軟件需求）。和敏捷開發(fā)里面的epic、feature、story 的分類很不一樣（有些團(tuán)隊(duì)可能還有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個需求類型的理解，存在非常大的差異。對于什么樣的功能應(yīng)該被歸為feature，什么是story，也會非常主觀。更多時候，這3種需求類型根本不夠用，于是引入更多自定義的需求類型。這時候，要讓大家理解一致就更難了。開會的時候，經(jīng)常會因?yàn)樾枨髮儆谑裁搭愋投鵂幊场?/p>

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

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

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

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

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

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

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

這是一種更為嚴(yán)謹(jǐn)?shù)男枨蠊芾矸绞?。在MappingSpace 里面，架構(gòu)文檔也是用思維導(dǎo)圖來寫的?；谒季S導(dǎo)圖，我們可以對架構(gòu)進(jìn)行層層分解。架構(gòu)文檔的根節(jié)點(diǎn)，我們可以畫一張整體的架構(gòu)圖。架構(gòu)文檔的每一個子節(jié)點(diǎn)，也可以附帶子節(jié)點(diǎn)的詳細(xì)架構(gòu)圖。

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

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

需求評審

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

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

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

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

需求基線

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

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

如何既能保存一條基線，團(tuán)隊(duì)有需要時可以參考，同時又能快速需求的響應(yīng)變化呢？

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

需求變更

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

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

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

需求復(fù)用

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

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

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

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

審核編輯 ：李倩