张晓亮：用原子功能库承接复杂场景和需求 天天新视野

来源：次世代车研所

(资料图片)

汽车商业评论

撰文 /温 莎

编辑 / 张 南设计 / 琚 佳

智能电动时代，一切都在被颠覆。从产品定义的阶段开始，思考的逻辑就已经发生变化。

新年伊始，SoCar产品战略咨询创始人张晓亮曾发表《2023年汽车产品定义十大最新趋势》，其中一条就提到：脱离场景的加法毫无意义，配置对标逻辑弊端将会更加凸显。

如今，随着使用场景越来越复杂，车辆的功能和配置也随之变得复杂很多。在这种情况下，传统的以配置对标为核心指导思路的PVA逻辑已经完全无法满足当下的竞争要求。

新汽车已经成为新物种，场景逻辑更适合当下的产品定义。与以往的把每个配置基本独立筛选并组合的PVA逻辑（点状逻辑）不同，场景逻辑要求产品定义人员着重梳理故事线，然后把功能沿着故事线推进的逻辑组织起来。这实际上是线状逻辑。

在第十五届中国汽车蓝皮书论坛上，张晓亮发表了主题为《覆盖场景如何避免堆料》的演讲，他表示，场景宽度和深度急速膨胀的同时，产品响应策略必须绕开每项需求堆叠一个配置的传统思维，硬件的增加必须追求“复利”。

为了应对场景和用户需求的增加，SoCar将智电车型解构为四个层级：物理层、服务层、场景层与体验层。

物理层，搭建硬件架构和技术方案来实现“基础功能模块”；服务层，调用“配置能力”（原子功能及服务） 来实现“过程任务”；场景层，把用户需求（需求洞察）分解成若干“过程任务 （二级场景）；体验层，在解决“过程任务”的同时，产品带给“用户感性价值”。

上述四个层级应用到产品开发目标管理上，被表述为WHAT-HOW矩阵背后的“三张表”

在张晓亮看来，用户需求仍是产品定义的起点，场景则是梳理详细需求、组织解决方案的线索，软件是调配产品资源，响应需求的灵魂，硬件需要成为软件的资源。在产品战略管理和产品定义过程中，SoCar从场景端入手，通过构建结构化的场景库，形成对智能电驱车产品演化路径的持续跟踪。

“其实这些年我们一直思考如何做场景定义，场景定义最大的问题就是，每个人眼中的场景并不能对齐，场景有颗粒度，有大有小，大家都在说场景，但是每个人说的场景是不一样的，我们如何去构建一个规范的结构化语言，让每一个场景在场景定义当中都有非常它具体的含义，是我们一直解决的问题。”

如今，SoCar已经形成了一套自己的场景化的，面向智能电驱车的产品定义方法论。

以下是张晓亮的演讲实录。

谢谢贾可老师，很荣幸有机会和大家分享一下我们今年对于整个新物种的思考，包括对于智能化、场景化整个产品定义、逻辑，以及策略方法的最新实践。

今天主题是覆盖场景如何避免堆料，我们也都知道，在整个智能化过程当中，我们关注场景越来越多，用户需求越来越多，大家很容易产生不断往车上去加配置，加配置会导致我们这两天一直在说的卷。

我们如何在一个体系上、架构上设置一套新的逻辑来避免堆料，同时保证我的产品有比较好的竞争力，这是我今天重点和大家分享的话题。

首先智能电驱车作为一个新物种，不管是已经进入到的下半场还只是新物种的初具形态，但我们都已经观察到了一个最直接的影响，就是汽车在面临使用场景的时候，不管是从宽度还是深度上，都有了非常大的变化，也就是说场景越来越多，而且每个场景要求为用户承担的问题也越来越多了，场景的深度也越来越深了。

举一个例子，我们一直讲用户洞察，什么是有效的用户洞察？有很多类似的例子，我们直接问用户想要什么东西，马车时代就是更快的马车，在汽车时代很多用户直接反馈出来的产品痛点大多数就停留在A柱太宽这类问题上，这样的回答就会导致往A柱上去贴一个屏幕，实际上到市场上，这肯定不是一个好的解决方案。

这样的洞察没有意义，或者它并没有为用户真正创造价值，那么什么样的洞察是有意义的？我这几年经常举一个例子，北方会遇到下雪天气，如果车停在户外，早上去铲雪，这是一个很难受的事情。过去几十年没有人说早上为车窗除雪除冰这件事儿是一个痛点，因为大家觉得这是理所当然。

什么时候这个东西就转化为需求了？技术导致了原来由人去承担的工作变成了由机器承担，以前所有人都承担的时候，它不是痛点，当一辆车能够在很早的时候把车上的空调打开，把风霜融化，上车只要扫一下雨刮器就可以开走，这时候旁边拿冰铲除雪的人就会意识到，原来这是我的痛点。

所以很多洞察都是来自于我们看到冰山水面下面的部分，这个部分有些是由技术改变驱动的，有些是由于重新的利用技术和有效设计去展开的，但无论如何，随着智能电动车不断升级，我们面临的场景宽度和深度两个层面都在不断扩大。

这就会导致一个非常直接的问题，场景的宽度和深度的集聚膨胀，带来用户需求的急速膨胀，如何在复杂的场景中进行取舍？

越来越多的场景未必是用户关注的亮点或者惊喜的属性，或者增值的属性，反而是如果我没有，或者做得不好，就会成为用户放弃购买的门槛属性，这个时候就需要保证足够场景的覆盖宽度，同时又不能用原来的方式，每个需求都在车上加一个配置。

举个例子，比如说我的手写字是一个功能，解决是一个场景需求，拿水杯喝水是另外一个场景需求，吃饭又是一个需求。但人类的进化不可能为这三个场景设计三个不同的手出来。但我们以前做车的时候，恰恰是用了这样的逻辑，所以就需要去做一些能够去追求复利价值的硬件或者配置或者解决方案，在复杂场景集聚膨胀的过程中，以更高的效率去响应更复杂的需求，这个是智能化对车企整个研发设计，整个链条里面产生最大的一个挑战。

这样一个过程中如何实现它，整体的逻辑是用户仍然是我要去解决所有需求的发起的起点，但是场景是这些问题的线索。今天智能化所带来的最大变化，就是场景持续膨胀，持续增加，所以场景是所有问题的核心线索。

然后软件，是要让我的三个不同场景下的手能够呈现出三种不同形态去解决三种不同问题的控制神经或者灵魂，硬件在这个时候必须要去成为软件的资源，这样的话我们才能够让这个车，以最高的效率去覆盖不断多的场景，这样其实我们就需要去把整个智能车重新解构竞争力模型。

分享一下我们对这个问题的理解，我们把智能电气化的产品的能力模型解构为四个层级。最上面层级是体验层，每个场景下完成一个相应的需求，解决一个需求或者完成一个任务的时候获得的主观感受，也就是说对这个功能和产生的价值和利益的一种感受，一种判断。

第二层是场景层，也就是说我们前面一直讲的各种线索，各种需求，所谓的场景其实就是用户需求所产生的这种背景，更多的变化是从这个场景开始的。但是如何去承接场景层带来的需求，就需要下面两层。

以前我们的车是靠一个配置去承接一个场景、一个需求，今天我们就不能用这样的方式。为此我们增加了一个虚拟层：服务层，也就是说我们需要为这个车虚拟出来一个原子功能库，或者一个原子服务这样一个层级，让用户控制车辆的这些操作或者是控制车辆能力形成若干个基本单元，这些基本单元承接各种需求的虚拟层级。

再下面是物理层，每个原子功能或者原子服务是由相应的配置共同去完成，也就是下面两层是一个多对多的关系，说起来有一点绕口，实际上意味着场景层发起的需求不能用配置直接去响应，而是用一些可以被打碎又重新组合起来的原子功能去承接，然后每一个功能是由这些原子功能在场景下的需求被灵活组合，去形成的一个一个的具像的功能组合或者功能单元，这样可以实现前面所讲的每个配置，先把能力拆碎，然后具体的场景当中重组这些配置的能力，迎合越来越复杂的场景和用户需求。

映射到产品定义过程当中，需要构建更加复杂的逻辑体系，我们总结为三张表。所谓场景和线索，也就是说我在what这一层，用户有什么需求这一侧，实际上由若干个主场景，也就是决定产品定位的核心故事线来发起的，然后每一个场景都可以进一步的向下拆解。

拆到一个什么样的层级是合适的？能够对应到车辆具体功能需求的时候，也就是往下拆的细分场景，会发现每一个细分场景它都可以重新组合成若干新的故事线，也就是说在what这一侧，是一个多对多的映射关系，然后更核心是what和how的这一侧，刚才讲我们是拿原子功能和或者原子服务区和场景进行握手，这样意味着场景层每一个功能都会和how上面一个一个原子服务和原子功能去产生多对多的映射。

举一个最简单的例子，我要在车上休息这样一个场景，我要去为它匹配相应的原子功能，座椅放倒，开空调，或者说非常小的颗粒度的功能，这些功能越多，用户获得体验越好。

我需要做到什么程度，两件事情决定。第一件事情，这个场景对我这车辆车来说有多重要，第二件事情我今天面临的竞争环境，竞争对手做到什么程度，决定了我大概的一个参考范围，这是一层多对多的映射。

同时，每一个原子功能绝对不是在一个场景下被应用，会应用到多个地方。今天看到座椅增加了一个振动反馈，不仅仅提醒用户去产生驾驶辅助相关的东西，比如说我要接管车辆，比如说我在倒车的时候，能够提醒我后面离障碍物过近，或者我在开门的时候产生预警；我还能够去提供，比如说在车上看电影的时候，会产生4D的沉浸效果，本质上都是由座椅下面那个振动的发起单元共同支撑的，类似的道理有很多。

通过这样的方式就能够把车辆很多硬件能力，或者配置能力打散，然后到具体场景中再去重新组合。如果说我们用这样的方法，我们就会发现，如果我的车具备了某些配置，这些配置恰好具备这样的能力，我就可以在场景当中调用现有的配置能力而不是增加配置来去创造更多的功能，来去解决更好的一个用户体验的问题，这也就是我们一直非常关注，不去堆料，不去内卷带来用户的提升。

再向上一层，每个原子功能都有具体的相应配置来支撑，又是一个多对多的映射关系。本质上来说，我们要把在智能电驱化时代的产品解决好，实际上就是要把三张多对多的映射关系梳理清晰，有了这样一个清晰的数据架构才能让这套系统真正闭环下去。

如果场景层聚焦了非常多的功能，并不是靠每个功能都去相应增加一个硬件实现，而是先从虚拟层设置一个资源池，虚拟层为目标达成原子功能，到底需要什么样的配置组合能够最高效率，最低成本，或者最高体验来实现这样的目标，我们就能有效收敛我的硬件，这才是我们去做智能化的一个更好的解决方案。

要做这件事情，说起来容易，实际上还是有非常多的挑战，后面还有辩论的环节，其实也在说这样一个话题，到底是尺寸定义还是场景定义？

其实这些年我们一直思考如何做场景定义。场景定义最大的问题就是，每个人眼中的场景并不能对齐，场景有颗粒度，有大有小，大家都在说场景，但是每个人说的场景是不一样的。我们如何去构建一个规范的结构化语言，让每一个场景在场景定义当中都有非常它具体的含义，是我们一直解决的问题。

我们经验总结起来一级场景就是两个维度去构建，一个是这个车卖给谁？第二个是用哪一些场合？也是场景定位的问题，二级场景对我们来说更灵活，拆解到车辆功能定义所需要颗粒度，我们叫过剩任务。三级场景实验室功能定义的细节，我需要去应对各种复杂的工况事件，各种影响因素来去形成一个颗粒度非常细的场景，这样我们就能形成一个相对结构化的场景架构。

How侧同样面临一个问题，虽然想去构建一个原子功能库，但是这个原子功能库从哪来？第一个事情解构现有汽车，再早先去定义什么叫做原子功能或者原子服务，我们定义为用户控制车辆的基本操作或者基本单位作为原子层级的，然后这些东西怎么来，我们就从现有的车辆配置去拆解，哪一些是符合用户车辆控制基本单位的配置能力，然后把它进行拆解之后去重，保留相对来说真实需要的这些东西，形成原子功能库的一个清单，目前不到2000项，每半年有10%到15%的增加。

这样我们做的事情，把配置由一个个黑匣子变成敞开随意组合，或者灵活组合的场景资源，对后面功能定义响应更复杂场景的时候，灵活度就会大幅提升，在这样前提下，我们再去做产品定义。

首先有目标场景，比如说有三个场景，关注日常的有人驾驶的场景，可能关注辅助驾驶场景，还有一个人在车上看视频的场景，显然每个场景下边都需要相应的原子功能或者原子服务，有的是仪表显示，车辆信息显示，车上看视频的这些东西。

我们再去看，要支撑这些原子功能需要多少个配置，就发现我的配置表，或者我的BOM里面可选的内容很多，如果不是从这一层思考，我可能提供能力很多是重复的，比如说我们看到很多，既有很大的仪表又有很多的HUD，这种前提下保留我真正需要的东西，或者体验最好的东西，或者效率最高的东西，我就有效收敛我的配置表。

类似的，我们就可以从体验层，先去定义一个目标，然后场景层找到核心场景，然后去服务层把我所有需要关注的这些原子能力从列表里拿出来，再到物理层去做。为了做这件事情，肯定刚才讲的，从What到How，若干个数据是有联系的。

我们在做另外一件事情就是，要为场景库里面，也就是用户体验场景库里面每一条场景去打造相应标签，把解决场景下的体验问题所需要的原子功能直接和这些场景连接起来，当我们再从里面抽取这些场景的时候，所需要的原子能力就会被直接代入到这个池子里面。

当我叠加了10个场景的时候，会发现关联的标签去重的时候，宣传原子能力的基本要求，然后以这些要求为目标，下去收敛我的配置表，我就可以去更好的，更高效率平衡配置清单的问题。

这样一圈走下来就会发现，整个汽车产品定义的大逻辑已经发生了非常大的变化，以前定义一个车，要某个配置，要基于市场调研，问用户要不要。比如说方向盘电调节，方向盘加热，方向盘振动，我们是分为三个配置，我们会分别问三个配置用户有多少人要这个配置，以及原以为这个配置付多少钱，我们基于用户答案去设置相应的组合以及产品的定价。

但是我们会发现，如果按照这样的思考方式去解决问题，每个配置都是一个一个独立的单元，它一个点状的逻辑，场景实际上在上面叠加了第一层逻辑，也就是一个现状的逻辑，有一个场景就有一个故事线，有了故事线我们就知道这个故事线里面所有的需求，我需要方向盘提供哪些配置响应这些需求。

仅仅这样是不够的，还是需要有一个更加面状的逻辑，把多条故事线叠加起来的时候，哪一些是能够被复用的这些配置能力，这样我们就能够以最少的配置去覆盖最多的场景，解决用户最多的问题，这样才是一个更加有效率的产品力或者产品管理逻辑。

为了做好这些事情，跟大家汇报一下，我们近期的主要工作。SoCar一直在构建并完善用户体验场景库。这是从用户体验管理角度出发定义和积累的场景库。然后按照每一层级的结构把它整理为结构化，规范化的东西。单有场景是不够的，必须形成一个闭环的系统，我们就要去动态筛选每一个细分市场，每一个品牌的用车场景，大家最关注的场景是哪一些，抽取出来形成关键场景。

这些关键场景又需要转化成你去衡量现有的市场中其他产品的一个标尺，也就是说产品体验好不好，实际上是从用户关心的场景当中去转化出来测试脚本去看，带着这些测试脚本就可以去看市场中的场景，积累足够多的案例。

你就知道什么样的东西体验是好的，形成什么样的指标对用户来说是最关键的，这样我们就能够去构建一个半固化的产品评价基准，这个核心是在于我们把现在市场中的这些车，按照刚才讲的每一个层级的能力进行拆解，同时去看它场景层，响应用户需求的这种能力到底还不好，带来的体验好不好，实现这些机制是什么样的。

这里面因为图的关系，就不跟大家去做太详细的展示了，基本上相当于从场景到原子功能，再到配置一个丰非常复杂的网络，我只拿一个场景发起，如果100个场景，这张图会变得非常长，实际上是三层网络的数据。

在这个过程中就会发现，原来产生了很多产品评价是基于过去时代所建立的评价基准，今天到了新物种选择新的评价，真正难题在于产品的演化在快速推进，所以无法形成一个完全固化的评价标准，我们怎么做？就把已经形成一些共识的，趋势的东西沉淀下来，形成可以量化打分，把不能形成趋势的，大家暂未找到共识的留下来，做主观的场景化，体验化的评价。

举一个例子，这两年看到电动车设计最大的趋势就是几乎所有的电动车都改用怀档，都从原来的档杆，水晶球头，旋钮换成怀档，为什么？是因为怀档成本又低，体验又好，这样形成趋势，这些趋势形成我们固化的打分体系里面一部分标准，并不是说我们直接说怀档最好，而是怀档带来的体验，这种体验背后实际上就是我驾驶的档位切换，手部动作简单，控制逻辑简单，同时这个地方能够给用户提供更家充裕的储物空间，这个是从体验层更明确的体验标准。没有形成趋势，我们就案例总结案例，不断向下沉淀一些固化标准，这样从场景到体验，到响应策略，评价，形成一个相对完整的闭环。

时间关系，我跟大家主要分享这些，谢谢大家。

标签：