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

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

需求分類(lèi)型管理

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

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

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

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

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

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

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

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

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

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

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

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

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

需求評(píng)審

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

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

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

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

需求基線(xiàn)

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

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

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

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

需求變更

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

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

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

需求復(fù)用

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

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

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

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

審核編輯 ：李倩