职能篇—自动驾驶产品经理

自动驾驶产品开发流程

在讲自动驾驶产品经理之前，先简单了解一下自动驾驶的开发体系。如上图所示，从产品需求开始，经由系统需求、系统架构、软件需求、软件架构，最终分解到软件代码实现模块，再经由MIL、SIL、HIL、VIL完成各个测试，最终完成自驾产品的设计开发。其中，产品需求便是由产品经理负责，产品经理的一切活动都是围绕产品需求开展的。

自动驾驶产品经理工作职责

上面讲了产品经理的核心工作是产品需求，但具体应该如何做呢？下面我们详细介绍一下产品经理在整个开发体系中的具体工作内容，内容如下：

法规解读

众所周知，自动驾驶当前还是一个比较敏感的话题，政府对于此类产品，一般会出台一些政策，甚至有些国家将一些法规列入强标，例如:UN R79，如果不满足法规，你的产品都不会让你上市。此外法规也在一定程度上反应了政府的态度及行业发展趋势，一个合格的自动驾驶产品经理，必然需要熟知相关法规，在设计初期就要将其考虑进去，否则设计出来也只能是个Demo，无法作为产品去量产，相关法规如下：

当了解上述法规之后，需要将跟自驾相关的内容拆解出来，形成法规点检清单CheckList，方便后边点检功能设计是否符合相应法规要求；除以上内容外，产品经理还会作为法规标准工作组成员定期参与法规的制定与评审，及时了解行业动态，进行产品调整

竞品对标

俗话说“知己知彼，百战不殆”，只有认清对手实力，才能有更好的应对策略，同时对手也能让我们更好的认清在同行中的位置。特别强调一点，由于设计前期所有想法都停留在纸面，对标竞品是验证设计思路的最好渠道

对标渠道

竞品分析的渠道有很多，例如：
1.竞品车型的用户手册
2.网上的一些测评视频
3.相关发布会
4.测评公众号
5.租赁车辆实车测评
6.购买相关测评报告
…等等
不过我还是比较推荐亲历亲为，自己测过印象才能深刻，并且在测评过程中也会对功能有新的认知与理解

对标内容

这里主要讲一下对标的内容：
1.硬件系统方案
2.功能配置
3.相关交互逻辑【功能开启、激活、抑制、中断、退出、故障】
4.运营方案
5.亮点场景
备注：如果有测试设备，可以量化相关参数

对标报告

针对对标活动中所产生的原始视频、对标报告，最好建立竞品数据库，方便以后的查找，同时后续如果有其他人也要对标，免得重复去测

用户调研

用户调研的主要目的是挖掘用户的原始需求，通过分析用户的需求，为自驾产品附能

调研方法

调研方法有很多，例如：
1.问卷调查
2.头脑风暴
3.用户访谈
4.数据分析
…等等

调研结果

在经过调研活动后，最终收集的可能都是一些比较口语化、模糊化的原始需求，有些需求可能根本就不合理，这时候产品经理需要将原始需求进行筛选、转化，将有效需求筛出来，同时将其转化为产品功能，产品功能是对用户需求的专业化描述，适用于工程开发

产品规划

在经过N次的调研及分析之后，最终产品经理会形成一份根据用户需求转化而来的产品功能清单，对于这些功能，产品经理的主要职责是管理，具体描述为：定义优先级【哪些功能比较重要、或者哪些功能性价比较高】、分析可行性【哪些功能合理，但是当前技术能力做不了】、功能后续迭代计划Roadmap【哪些功能需要后续OTA、以及后续OTA的时间节点】
示例：

产品需求输出

针对产品规划中，具备实现条件的，产品经理将以产品需求文档【FRD或PRD】的形式正式输出给下游作为工程开发目标，其内容主要包括：功能概述、设计运行条件、功能场景、人机交互、性能要求；此文档的作用是向下游描述清楚产品的三个特性【你的产品能解决用户的哪些需求？用户如何使用你的产品？怎么做才能让用户用的好？】，下面我们针对文档具体内容进行描述：

功能概述

主要描述这个功能的外在表现，示例：高速导航驾驶辅助（H-NOP）指的是驾驶员在高速公路和城市快速路驾车行驶时，在开启并设置导航路径的情况下，系统可自动进行车辆的横纵向运动控制，实现跟随导航路径的自动驾驶。高速导航驾驶辅助功能可以实现跟车行驶、居中行驶、拨杆变道、自动上下匝道、导航变道、超车变道等功能以实现高速点到点的场景覆盖

设计运行条件

设计运行条件(Operational Design Condition)，简称ODC，其表示功能能够正常运行所依赖的外部条件，包括：道路、交通、天气、光照、车辆状态、驾乘人员状态及其他状态；示例如下：

功能场景

在定义了设计运行条件之后，相当于功能运行的大框架定了，只要满足ODC定义的条件，功能就能运行，但真正落地需要细化到具体的场景，例如：ODC定义了高速H-NOP功能只要满足高速有高精地图功能就能正常运行，但如何运行需要明确出来，需要分析在这个ODC大框架下有哪些场景，比如，高速有上匝道、超车、下匝道、按路线导航等场景，这些都需要解决，功能才能运行，所以此章节主要描述功能所需要解决的场景及应对的策略

导航变道【示例】

导航变道需满足以下功能要求：
1） 变道触发：【触发的前提：到达变道触发点&满足变道要求】
——变道触发点定义：
●当位于最左侧车道时，于距离通视三角区端点(1000+500*N)米处发起变道，N代表从最左侧车道驶入最右侧车道的变道次数；其他车道的发起距离以200米梯度逐级递减；
●无论道路结构如何，最右侧车道都以通视三角区端点为准
——变道要求：
●变道范围内不存在静止障碍物
●当前车速＞35km/h
●前方4秒范围内，相邻车道宽度＞2.8米
●前方4秒范围内，跨越车道线为虚线或虚实线
●前方4秒范围内，当前车道曲率半径＞150米
●转向拨杆位于中间位置
●距离上次变道完成（无论成败）时间＞5秒
●距离NOP开始时间＞5秒
●用户未进行横向Override
●未触发脱手警报
●目标车道后方空间不得小于下图计算所得Scritical

●目标车道GAP预测2秒：GAP前车：时距≥1s，TTC≥4s；GAP后车：时距≥2s，TTC≥6s
2） 变道确认：【确认方式与变道模式关联】
●推荐变道：系统发起变道请求，不会去激活转向灯；待驾驶员确认后，激活转向灯，并执行变道【变道确认方式：拨打同侧转向灯】
备注：若车辆达到接管点，则不再请求驾驶员确认，转而发送接管请求
●自主变道：系统发起变道请求，自动激活转向灯；
3） 变道执行：

●系统激活拨打转向灯后，导航变道功能运行，居中功能抑制
●车辆向目标车道的横向移动不得早于拨打转向灯后1秒
●整个变道过程应作为一个连续运动完成
●变道前半段（前轮未压线）：驾驶员拨打转向灯后3至5s内完成
●变道后半段（后轮压线）：需在5s内完成
●变道完成后，居中功能恢复
●转向灯应在整个变道过程中保持激活状态，在恢复居中功能后的0.5s内自动熄灭
●如果需要完成多次变道才能达到目标车道，需要在一次变道成功后，车辆姿态摆正后，再次尝试下一次变道
4）变道抑制【根据变道过程分3种情况】：
●未执行横向移动前：车辆进入变道抑制状态，最多持续至接管请求点
●执行变道前半段：返回原车道
●执行变道后半段：继续执行变道【若无法完成变道，则触发接管请求】

变道抑制条件存在以下几种：
●目标车道条件不满足：不满足变道所需空间要求
●第三车道条件不满足：与第三车道车辆存在竞争性变道
●车道线不满足：变道期间存在实线、目标车道车道线丢失
5）变道取消：【根据变道过程分3种情况】：
●未执行横向移动前：系统关闭转向灯
●执行变道前半段：系统关闭转向灯并返回原车道
●执行变道后半段：系统不关闭转向灯，继续执行变道【若无法完成变道，则触发接管请求】

变道取消方式：
——主动取消：
●反向拨打转向灯拨杆
●反向转动方向盘【超越系统所需的横向控制力不得大于50N】
——被动取消：【不满足以下条件之一】
●车速＜35km/h
●自车到达接管请求点
6） 导航任务风险提示：
●若系统到达接管请求点时，仍未执行变道，则发出变道接管提示，请求驾驶员自行变道；
●若驾驶员未进行自行变道以致错过路口，则自动降级至ICA功能
7）接管请求：
●系统检测到碰撞风险，TTC＜3S时，进行接管请求
8）变道优先级：
●变道避障>导航变道>超车变道
●当车辆处于导航变道作用区间内时，超车变道受抑制，系统将不再触发超车变道

人机交互【功能使用】

人机交互是个大课题，下面将讲解如何一步步完成人机交互设计

交互通道梳理

在定义人机交互前，最先做的事便是将整车所具备的交互通道及相关参数明确出来：

交互内容及交互方式梳理

在定义人机交互前，需要明确功能在使用过程中，哪些是需要与用户进行信息交互的以及通过什么样的交互方式去进行交互。其中交互信息包括：设置项、功能开启、激活、功能场景相关提示、功能抑制、中断、退出、故障；交互方式包括：视觉、听觉、触觉、用户操作等

之后简单列下表，将功能交互的框架轮廓先做出来：

在这个过程中，最重要的是对交互内容的梳理，在此期间需要明确正常流及各种异常流，以及相关交互，对产品经理的要求相对高一些，就拿功能激活来讲，就存在用户激活成功和激活失败两种情况，产品经理需要明确哪些条件会造成激活失败，以及激活失败之后，如何提示用户，示例如下：
功能激活方式：需要用户手动操作
正常流：功能激活成功：提供视觉+声音提示
异常流：功能激活失败：提供视觉+声音提示

当存在以下异常条件之一时，功能激活失败：
1）ODD不满足
2）主驾安全带未系
3）驾驶员踩制动
4）行驶速度超过150km/h
5）车辆处于非D挡
6）四门两盖，任一处于打开状态
7）车辆不稳定，ESC/ABS/TCS/EBD激活
8）胎压异常（胎压过高、过低）
9）自车发生碰撞
10）AEB激活
11）方向盘转角过大
12）车辆航向角与道路方向偏差过大
13）自车横向加速度过大
14）转向灯打开
15）双闪灯打开
16）不在高精地图覆盖区域之内
17）系统故障（含传感器）
18）关联ECU故障（含转向、制动、驱动）
19）脱手惩罚模式

当所有的正常流与异常流分析完成后，便可得到功能交互的基本框架，下一步需要将交互细化明确，形成详细交互方案

交互方案

经过上面步骤，我们已经知道哪些场景需要给用户视觉提示，哪些需要给用户听觉提示，以及整车有哪些交互通道，现在需要根据交互方式选取合适的交互通道，把交互策略细化出来，例如：功能激活成功，需要提供视觉+听觉提示；仪表/中控/HUD等交互通道都是支持视觉提示，我们可以选择仪表进行视觉提示，仪表支持视觉提示方式可以是文言弹窗、图标、场景重构SR、3D动画、3D模型渲染，我们可以选择一个或几个；听觉提示可以使用仪表自带的喇叭，最终我们可以细化出交互方案，如下：

——功能激活成功：
●状态图标：显示NOP蓝色图标
●文言提示：“请握住方向盘，准备随时接管”
●声音提示：激活成功提示音，音色“咚咚咚”，升降调，提示一声
●场景重构SR：显示蓝色中央引导线

性能要求

针对产品设计中对产品性能及体验有关键影响的参数，需要明确其要求：

以上仅为单个自驾功能的产品需求文档，在实际开发过程中，需要对每个或每类自驾功能都需要出一份《产品需求文档》，涉及功能如下：

产品需求承接

当产品经理完成以上功能的产品需求文档之后，下一步工作就需要把产品需求传递给下游，支持下游开发设计；下游单位包括：HMI部门、功能安全、系统、测试，下面将描述一下相关承接内容：

HMI部门

产品经理最终形成的交互方案包括：仪表显示、中控显示、声音、3D模型、3D动画效果等，这些都需要HMI部门支持，才能实现，由于每个部门的关注点不一样，不可能让所有部门去将每个功能的产品需求文档都认真阅读一遍，这样不现实也会浪费大家时间，因此需要产品经理针对性的把相关需求提炼出来形成额外的一些文档，相关文档如下：

UE交互文档

关于显示类的，需要生成一份UE交互文档，这份文档有两个用途：1.方便HMI部们根据UE做相应的UI设计；2.交互方案一般需要经过多方评审打和，UE交互文档可以很方便的进行评审。不过个人更喜欢以交互流程图的形式去输出，这样可以让其他人员更容易理解功能交互策略，逻辑性较强。

在这里推荐几个比较好用的UE设计工具：Axure、Figma、墨刀；

备注：界面设计工具基本都是HTML、CSS、JAVASCRIPT语言的封装，工具的使用其实就是对属性的自定义，感兴趣的小伙伴可以去菜鸟教程简单看下语言使用，可以提升对界面设计工具的理解及使用

音源文件需求

需要明确声音的音色、频率、音调、类型，最简单的方式是可以自己录一个声音作为参考，这样需求承接的相对快些，有些声音通过语言真的很难表达出来，相关部门收到需求后，会进行相应音源的设计

3D模型需求

需要明确3D模型的类型【例如：人、骑行者、汽车等】、面数、相关组件等，支持HMI部门设计相关3D模型

3D动画效果需求

需要明确3D动画的含义、效果样式，最好有可以附加参考图，方便HMI部门作3D效果设计

功能安全

功能安全部门会针对产品经理输出的产品需求文档进行分析，结合整车安全分析相关功能安全等级，并提出功能安全相关要求，产品经理需要结合此要求复查产品设计，并与功能安全部门达成一致意见

系统部门

系统是产品的主要承接方，承担产品的实现，系统需要认真阅读产品需求文档，需要明确产品经理的需求，在承接过程中，产品经理与系统将持续对接，保证系统能够完全承接自己的需求；系统的工作主要包括：系统架构设计、系统需求输出【内部状态机、外部关联系统需求】、信号实现逻辑；在这个过程中，产品经理需要与系统共同评审系统需求，同时参与信号逻辑设计，确保自己的需求能够完全被承接

测试部门

当产品经理输出产品需求文档之后，测试部门将根据其撰写测试文档，用于产品实现的跟踪与核查，产品需求仅为测试的一部分，除此之外，测试也会结合系统需求以及信号实现逻辑等进行测试及问题描述

走查

当各部门完成产品需求承接后，就进入开发阶段，在这个过程中，产品经理会定期进行走查，掌控产品实现状态，走查形式可以是实车体验，也可以根据测试部门反馈结果进行了解

新技术、新方案交流

对于同一产品或功能，实现方案可能存在差异，并且有些方案可以很大程度上提升产品的竞争力，例如：最近提出的无图化NOP方案，可以在一定程度上解决对高精地图的依赖，提升NOP的适用范围，针对此类新技术，产品经理会组织相关方交流讨论，确定技术方案，及时进行产品迭代

寄语

当你看到此处，你应该对自驾产品经理已经有了一个比较完整的认知，希望可以帮助现在的你或将来的你，同时也欢迎自驾相关的小伙伴私信交流，一起成长
————————————————————————————————