我一直是基于装备价值定义车型配置表单的反对者。如果你看看每个装备的用户价值是如何确定下来的，只要你是说真话的人，你就知道我为什么反对了。但仅仅我的反对是没用的，毕竟车型配置表单（Feature list）的定义始终是各大车企，尤其是合资品牌车企产品战略部门管理的核心职责。无论调研逻辑是否成立，有数据，有人愿意背书就可以往下走了。
但是，今天，我反对配置定义基础逻辑的机会再次出现了。这个机会源于过去两年来的一种直观体会：如果仅仅观察配置表，无论是官网的还是第三方汽车网站的，我根本看不出特斯拉在智能化方面对比奔驰/宝马这样的传统车有什么区别。但只要你深度体验一下特斯拉，你又能够体会到这种区别。所以，我越来越坚定地认为，车型配置表的这套逻辑已经越来越没有意义了。
为什么会这样判断？原因是在过去，几乎每个配置都对应一个特定的功能，每个功能又对应一项特定的用户需求。因此车型配置表的定义过程原则上首先是低配/中配和高配之间满足不同支付能力用户需求的过程。只不过随着市场竞争的加剧，配置表的定义增加了更多无聊的东西，比如低配和中配之间，中配和高配之间，似乎都要做出5000-10000元装备价值梯度。结果这样的做法导致很多机械的装备梯度惯例。例如十年前，用户花15万元买一辆速腾，结果连扶手箱都买不到。花30万元弄一辆奥迪A4，多功能方向盘也是没有的。这样做虽然对于车企增加短期利润是有帮助的，但购买乞丐版的用户一定会在使用过程中不断抱怨，因为车企根本没有满足他的用车要求。
而今天，很多条件都发生了变化：
首先，配置和功能，或者硬件和功能不再是一一对应的关系。比如一个车载大屏幕，可能集成非常多的控制功能。特斯拉的大屏幕可以打开手套箱，也可以调节后排座椅。原本用于倒车影像的摄像头也可以用来采集流媒体后视镜的视频影像。
其次，实现同一种功能，他的实现机制有更多路径可选了。比如，以前我们为了解决夜晚转向辅助照明的问题，可以依靠低成本的角灯，也可以让大灯转动起来。再如我们为了监测胎压，可以使用直接式胎压监测，也可以使用间接式胎压监测。这个过程刚好和上面过程是互逆的。
第三，既然上述同一问题的两个方向都发生变化了，我们就需要找到下一步定义的关键。按照这个线索走下来，功能定义（Function list）的优先级是大于配置定义（Feature list）的，而配置又必然基于某些特定的硬件或者技术解决方案支撑。我们可以把这个硬件基础定义为Boundary。于是，Function和Boundary就构成了多对多的一组映射关系。其实这正是今天智能车超越传统车的关键所在。
比如，打开或关闭车窗是一种功能（function），他的实现方式（boundary）可能有5种：通过玻璃升降器开关，通过语音控制，通过车钥匙遥控，通过手机遥控，又或者通过大屏幕的菜单控制。上述这5种方式都可以支撑同一个功能，那么这些并存的boundary意义何在呢？其实是场景差异导致的。比如下雨天，我已经离开车回到了家里，如果车窗忘了关了，而车又恰恰有这种传感器或者识别能力，我就可以通过手机远程遥控把车窗关上，而不用再下楼了。如果我在盛夏时节把车停在马路边上，回到车里之前，我很有可能会通过车钥匙遥控开窗，把车里的热气释放掉，这是第二种实现方式。但我绝对不会傻呵呵地坐在车里拿钥匙遥控开窗……因此场景不同，决定了同一种功能诉求的实现机制是不同的。
说到这里，大家也许就更加理解“场景“究竟是个什么逻辑了。其实场景决定了功能需求，功能需求需要特定的技术解决方案。于是产品定义的很大一部分逻辑就从配置定义转入功能定义了。而功能定义清晰了，支撑这些功能的最佳技术解决方案也就清晰了。
没错，这就是So.Car针对智能车时代梳理的一套更为前瞻的产品定义逻辑，当然这只是很小一部分。为此我们构建了场景架构/功能对标架构/技术解决方案对标架构等等可以直接应用的数据基础。我们相信随着软件权重的日益增加，这样的逻辑将更加具有创新能力，同时又具备继承成熟结构的传承能力。
关注So.Car官方公众号
掌握So.Car最新观点动向
