汽车行业如何做需求管理

 

首先，我们需要明确汽车行业的需求管理和其他行业有什么不同？为什么要单独把汽车行业的需求管理单独拎出来？

基于汽车行业的行业特点（通过提高产量，降低单车成本）、产品特点（与人身驾驶安全相关，因此面临着比较多的法规要求，如功能安全ISO 26262、信息安全ISO/SAE 21434），汽车行业至少在如下6点，与其他行业的需求管理相比，存在着较大差异。

需求分类型管理

汽车行业的需求管理，一直就有分类型的传统。在V模型里面，至少会被分为 3种类型：市场需求、系统需求、软件需求（有时可能还有硬件需求，系统需求包含硬件需求和软件需求）。和敏捷开发里面的epic、feature、story 的分类很不一样（有些团队可能还有requirement等）。汽车行业的分类依据，更多的是需求来源，以及承载的主体。敏捷开发中，需求的分类依据，则主要是根据需求的大小及范围。epic 是一个大的需求集合（中文翻译为史诗，从这个名字也可以知道，它涵盖的范围很广），feature 是一个产品特性，story 则被理解成一个用户故事，或者一个用户场景。

V模型和敏捷开发融合的第一道坎就是，怎么让汽车工程师听懂敏捷开发的语言？听懂epic、feature、story，并能和互联网工程师对话。

简单地把敏捷开发的需求类型，生搬硬套用到汽车行业是不可行的。首先，需要让汽车工程师理解什么是epic、feature、story ，就存在一定的难度。我在蔚来汽车工作3年，发现对这3个需求类型的理解，存在非常大的差异。对于什么样的功能应该被归为feature，什么是story，也会非常主观。更多时候，这3种需求类型根本不够用，于是引入更多自定义的需求类型。这时候，要让大家理解一致就更难了。开会的时候，经常会因为需求属于什么类型而争吵。

当时，我所在的整车研发部门，有一份叫 FDS的excel文件，Function Definition Specification。在这份文件里，整车级别的需求，逐层往下细分。整车需求被分为 8 大块，包含了自动驾驶、智能座舱、车联网等等。每一个大块又被分为无数的小块，一层一层地往下分。每条需求都有多个字段，主要包括ID号、需求名称、需求描述、责任人、关联部门、当前状态、备注信息等。相信当时使用过这份FDS表格的同学都会记忆深刻，这份表格比当时任何一个在线工具都好用，每一层级都是可以无限往下细分，也可以折叠、展开。既可以从整车层面把握需求的完成情况，也可以从更细节的层面，了解需求的上下文。它另外一个最大的优点就是：需求的颗粒度，工程师拥有最大程度的自由度。无需根据epic、feature、story这种死板的模型，来死抠需求的颗粒度，而是完全根据业务场景的需要，根据需求的复杂程度来划分。有些需求比较复杂，场景比较多，可能会被分为五六层。有些需求则比较简单，两层就可以说清楚。

但是这张表格也有一个显著的缺点，它是平面二维的，不擅长在此基础上，继续关联架构、测试用例、bug等等，一定要做也行，但表格的复杂度会指数级升高。所以，在此基础上，我们也使用jira做任务管理和bug跟踪。后来，智能座舱部分的需求也完全是在jira上进行管理的。然后就碰到了我上面描述的“生搬硬套”问题：为了适应敏捷管理工具的特点，我们牺牲了对需求颗粒度的自由度把控。

为了让汽车行业的需求工程师，更好做需求管理，我们开发了一款完全针对汽车行业的研发管理工具 MappingSpace。在MappingSpace 里面，需求是以思维导图的方式进行管理的，每一个节点就对应的一个需求。思维导图天生的特点，决定了需求具有不同层级的颗粒度，根节点颗粒度最粗，越往外层，颗粒度越细。工程师根据产品特点以及团队需要，对需求不断往下做分解，直至需求描述足够清晰，且可以将需求落实到每一个责任人。需求工程师再也不需要考虑，究竟什么样的需求是story，什么样的需求是feature。

需求的关联及追溯性

在汽车行业，架构一般会伴随着需求出现。在V模型里面，对应系统需求，有系统架构；对应软件需求，有软件架构。

一图胜千言，图解能引起的误解，会比文字小很多。架构图一般来说是必须的，特别是团队需要通过ASPICE或者功能安全或者信息安全。架构图一般包含静态架构图和动态架构图。静态架构图包含了模块图、组件图等等，动态架构图包含了软件运行的时序图。

在汽车行业，每一条需求都需要与对应的架构做关联。

这是一种更为严谨的需求管理方式。在MappingSpace 里面，架构文档也是用思维导图来写的。基于思维导图，我们可以对架构进行层层分解。架构文档的根节点，我们可以画一张整体的架构图。架构文档的每一个子节点，也可以附带子节点的详细架构图。

由于天生嵌入了drawio这个第三方插件，在架构绘制上拥有很大优势。

每一条需求，同样需要与测试用例相关联。每个行业都有类似要求，只不过在汽车行业，这条要求尤为严格，需要检测需求的覆盖度。在MappingSpace里面，我们可以从两个地方去查看覆盖度：一个是在思维导图页面，一个是在测试报告里。

需求评审

当需求被写出来之后，需要经历评审。很多行业都会做需求的评审，但是在汽车行业，需求的评审同样更为严格。系统中需要明确含有需求的评审过程、评审条目，以及评审完之后的修改过程，需要有过程记录。很多团队知道评审的重要性。通过评审，可以在产品开发之前就发现很多的潜在缺陷（汽车行业的FMEA分析，和需求评审有异曲同工之妙）。在这时候解决问题，显然要比产品发布之后再来解决，更为敏捷，并且效率更高，付出的代价也更小。

最高效的评审当然是面对面讨论。但很多情况下，讨论的过程无法被准确的记录下来。评审的过程，一般需要多个角色参与，如需求工程师、开发工程师、测试工程师、架构师等等。很难在同一时间把所有人都聚集起来，开一个漫长且有效的会议。这是评审过程中最大的两处难点：改进点的记录及后续的跟踪、经常有人缺席评审会议。

在MappingSpace里面，我们也提供了评审工具。我们可以很轻易地从一个需求的思维导图中，选择需要评审的需求，然后去发送评审请求，包含了固定评审人和用户此次指定的评审人。

它是一个线上的、非实时的评审机制。在评审任务结束之前，在任何时间进行评审都是可以的。系统会在所有人评审完之后，根据用户预置的评审通过规则，来确定最终的结果。评审通过或不通过的结论，也会出现在每个需求的详情页。对于不通过的需求，用户可以进行进一步的修改，直到该条需求下次通过评审。

需求基线

在敏捷开发里面，需求变化特别快，基线的概念非常弱。需求一直在变，整个团队的开发，一直是基于最新的需求进行开发的。无需知道每一个版本的开发起点是什么。但是这种做法在汽车行业不太可行。

汽车行业需要有明确的基线概念。如果某个版本是基于5月1号的需求版本进行开发的，那么可能意味着，在5月 1 号到5月30号版本发布之间，整个团队都是基于5月1号的需求版本，中途是不会接受特别频繁的变化的。那是不是可以直接把5月1号需求给锁定了呢？有些团队这么做的。通过流程或者工具进行限制，如通过SVN拉出一个副本。团队基于这个副本进行开发。但是我们需要承认：需求的变化是不可避免的。这种方式关闭了快速响应需求变化的通道，如果明知道需求错了，团队还得按照错误的需求去做，等到下一个版本才去更正，这显然是一种低效的开发方式。通过SVN拉出的副本，也无法进行需求任务的分配、状态变更等，这是另一个缺点。

如何既能保存一条基线，团队有需要时可以参考，同时又能快速需求的响应变化呢？

在 MappingSpace 里面，我们提供基线页面。这样整个团队就有了一个基线的参考页面。基线中的内容会被锁定，无法修改需求的内容，但是状态推进、任务分配等操作仍然是可以的。当需要对需求进行变更时，需要走变更评审流程，并且基线页面会明确显示，发生了怎样的变化或者需求新增。

需求变更

变更管理特别重要，如果变更管理没有做好，特别消耗时间精力，会导致团队效率降低。通常来说，有两种比较常见的处理方式。一种是当拉出基线之后，就不再允许变更，直到当前版本开发结束。显然，这种方式不够敏捷。

另外一种方式就是，当拉了基线之后，如果有变更，需要走变更流程，经过变更委员会的评审，评审通过之后，再加入到基线里面。变更委员会里面，可能包含了架构师、项目经理、测试工程师等等。这个过程如果在线下，或者一些线上工具使用不当，也会造成很大的困扰。比如，变更一般发生在拉基线之后，很多工具没有基线的概念，那么变更请求什么时候做，就变得比较难以把握了。再比如，变更评审会一般需要多方来参与，如何把这些人聚在一起并且参与讨论，这也是一个难题。如果只是简单地给每一个人发一封邮件，起不到真正识别变更风险的效果。

在 MappingSpace 里面，当基线开始之后，需求被锁定。锁定之后，无法直接变更，而是从需求上拉出一个副本，在副本上修改完之后，再发起变更请求。需要邀请评审人员，评审的过程也是一个非实时的线上过程。被邀请人，无论选择通过还是不通过，都会在系统中留下记录。

需求复用

在互联网行业的开发，基本上不存在复用的问题。一个软件产品被开发出来之后，一般来说，另外的产品线和它是不一样的，需求很少被复用。

汽车行业，是一个非常明显的需要通过走量，从而来摊销成本的过程。在不同车型之间改款，特别是针对硬件的改款，成本特别高。需要尽可能复用，减去设计、开模、工艺优化、生产设备调试的各类成本。特斯拉的发展历史，非常清晰表明了这一点。

在当前这个时代，汽车越来越重视软件。虽然车型之间软件的变化是非常快的，可以有更大的自由度，但是不可否认的是，汽车软件属于嵌入式软件，需要和硬件配合。如果硬件需要保持比较小的变化，必然制约了软件的变化。总体来说，不管是软件需求还是硬件需求，汽车行业复用的比例，都比互联网高很多。

在MappingSpace里面，每个车型上的通用型需求，通过思维导图，可以快速并且批量地移入到企业级需求池。当有了新的车型项目时，也很容易从需求池里面，将这些需求移入到全新的项目中。这一点对于硬件需求的管理，优势更加明显。

作者介绍：

罗宇超，云体科技创始人，软件质量工程师，工具链工程师。