上文讲到随着软硬件集成逻辑的重要性越来越高，围绕场景和功能开展产品定义相比围绕特征目录指标开展更容易把新产品的面貌描述清晰。
但是，这里有一个核心问题：在产品定义过程中，场景的颗粒度到何种程度更为妥当？显然场景拆的太细了会让产品早期工作陷入过多细节，从而丢失全貌；太粗线条又无法说清楚功能的基本逻辑，导致功能清单与配置表无异。
面对这个问题，我们还是回到新产品诞生过程中，自上而下决策的链条本身，也就是从BRD到MRD，再到PRD和FSD的整个过程。BRD主要在新车立项前，面向战略决策层，重点探讨的是产品概念机会问题。因此BRD更多是针对大场景概念，比如车辆的用途以及某些创新场景，总之是能够把目标车型的产品定位方向说清楚的场景。到了MRD则是面向产品策略问题，重点解决新产品需要有哪些关键特征，尤其是面向哪些典型场景，拥有哪些功能，以及这些功能组合起来应该带给用户什么样的体验这些具体问题。同时，这些场景都应服务于把产品整体描述清楚，而不是把具体某个功能描述清楚。从这个角度看，MRD是解决整车产品定义问题的，BRD则是产品概念定义问题。在BRD和MRD之后，才是PRD和FSD，这两层则是针对具体功能如何定义，以及如何实现展开的。
有了这样的理解之后，我们大致可以得出一个判断，也就是产品定义在逻辑上应该解决的问题是：说清楚一台车需要应对哪些典型场景，需要多少功能，以及这些功能如何相互配合，如何给用户带来连贯而且统一的体验。在产品概念确定后，把上述问题回答清楚了，新产品的完整面貌也就被勾勒出来了。因此在这一阶段需要把场景拆到何种颗粒度，以及需要在产品定义文件中涵盖多少条场景也就有了比较明确的判断依据：通常一台车的Function list大概200-400项左右（不同车企的颗粒度还是很不相同的，此外不同价位的产品拥有的功能数量也存在很大差异，因此这个范围误差还是有些大），要在产品定义文件中指出每个功能如何起到作用，功能与功能之间如何相互配合，我们就需要将场景的颗粒度拆分到每个细节场景可以指向某一确定的功能，以及通过场景的上下文能够界定清楚每个功能需要与哪些功能组合调用这两大关键问题。从这个角度看，每个功能关联的细节场景大致需要3~5条。按此推断，整车产品定义大致需要列举600~2,000条场景才能把问题描述清楚。基于这个判断，我们也更加容易确定场景拆分的标准，以及建立场景分级的规则。
在整车产品定义之后，具体到每个功能如何定义，如何实现，这个就属于Function Owner的工作范围了。到了PRD和FSD的层级，就需要把每个功能应对的场景列举清晰、完整，尤其是需要考虑很多备用路径和corner case等问题。这个过程就需要解决场景的完备性问题了。因此在功能定义阶段的场景需要更大的数量以及更细的颗粒度。
讨论上述标准不仅仅用于把控场景拆分的颗粒度，更加重要的是明确每个阶段的工作方向、范围和边界。如果这些问题没有界定清晰，整车的体验就难以保证。通过很多产品评价，我们可以看到一些典型问题，大部分的根源都在于没有把上述问题回答清楚。例如下面两类最为典型的现象：
1、功能与功能之间缺乏配合，导致很多体验断点的出现。
造成这种问题的原因，大概率是PRD工作主要是自下而上的，缺乏自上而下的战略或策略指引。其实很多车企都有了PRD，但这些工作基本都是从研发部门自发组织的，甚至很多PRD文档都是直接来自供应商。简单地把这些文档汇集起来，功能与功能的衔接问题自然就不会那么妥当了。功能组合的逻辑还不够，还只是第一层，由此导致配置冗余或者配置效率不高，配置与配置之间无法协同才是更大的问题。
2、某些车为了强调卖点，把某些功能做得过于突兀，装到车里显得非常生硬。
导致这种问题大概率是由于产品定义阶段过于强调对创新卖点的“冥想”，尤其是把对卖点数量以及行业第一或者唯一作为重要考核内容，但是缺乏对整车体验协调性和统一性的考核。要知道KPI在哪，团队努力的方向就会去哪。如果在MRD当中过于从某个功能细节甚至技术细节角度强调“创新”，而缺乏对整车完整体验的定义，这种突兀就是高发问题了。
关注So.Car官方公众号
掌握So.Car最新观点动向
