QA要致力于成为研发领域数据分析专家

1

汽车研发领域是否有必要关注数据？

上海疫情，被困上海近4个月，每天都会刷到各种新闻报道，看到各种文章，里面有很多不同维度的数据分析，来佐证其观点；

企业里，领导们会基于各种数据来进行重大决策；

金融大咖们、行业大佬们会分析研读各种数据，来定义可决定企业生死存亡的方向；

这两年热火朝天的大数据、推荐算法也是频频在耳边响起；

甚至，国计民生、大国博弈都离不开数据的支撑……

似乎已经形成了一个共识，数据很重要，有信服力的观点或决策都需要数据来撑腰。

不过，对于一名深耕汽车工程领域的人而言，长期以来，我更多会看到市场、财务、物流、生产等职能用到更多的数据，而并未看到数据在汽车工程研发领域占有一席重要之地，偶尔我们会看看工时、成本，或者总结一下项目基本数量类信息，即使在软件领域，至多看看bug趋势、需求条目数、分布柱状图、测试覆盖率一些简单维度的数据分析，或者更准确的说法是统计。

即便如此，这些数据的准确性、完整性、及时性都非常值得怀疑，特别是一些和工程定义不那么相关的数据，大家扪心自问，数据的可信度确实不尽如人意。

究其原因？可能有这两方面。

一是，这个领域没有那么多数据，巧妇难为无米之炊；

二是，行业积累的经验已经可以让“拍脑袋”判断的可靠性足够高了，没必要画蛇添足，没必要花精力、花代价去做一件性价比没那么高的事情。

为了印证自己的经验是相对准确的，也特意在招聘平台看了下汽车行业数据分析的岗位，只在两个新势力里各发现一个有和研发领域搭点边的数据分析岗位，还是比较空洞的描述，估计也没有具体的落地思路，其他的数据分析岗位，基本都是和市场、销售、战略相关的。所以，基本可以下这么个结论，汽车研发领域很少会关注到数据及数据分析。

那么，自然就回到了我们本小节题目的问题上，汽车研发领域是否有必要关注数据？

在以前，可能确实没太大必要，但随着互联网模式、软件、所谓生态以及数字化等相对新鲜血液的不断涌入，数据会越来越多，“没数据”和“靠经验”这两个场景都会越来越弱化，现在及以后靠这越来越多的数据进行分析、判断、决策的必要性应该也是越大的。

假以时日，在某个发展阶段，当人的交互更多、系统更复杂、代码量更大、数字化程度更高时，可能就会产生及催生大量的数据，由此独有的数据分析岗位需求或许也就在传统汽车行业应运而生了，所以我们不妨先做起准备来。

2

谁来做这个角色比较合适呢？

正如，我们题目所言，无论是CMMI&ASPICE，还是Devops，都有设置SQA的岗位，度量、分析是QA的分内之责，报告展示也是QA常做之事，也是其他业务所直观见到的QA的主要交付。

尽管多数QA并未在此领域做出显著成绩（当然，本身这个领域就未占有核心位置），客户似乎并不愿意为你的几份报告买单，而这似乎又是一个契机，QA这种性质的工作可以包罗万象，也相当于是万象不专，随着数据量的增加，QA可以顺势将自己推入数据分析的潮流。

开发、测试这种实实在在Value Adding的角色，自然是有人愿意为你的付出买单的。

项目经理呢，虽然不是直接增值，但作为项目第一背锅侠的委屈和压力就是他们的最主要付出。

对于QA的话，论对产品的理解不可能比得上具体业务，论对项目整体和细节的把控也不可能比得上项目经理，而加深对于数据的掌握和理解是一个不错的考量，将自己打造成数据分析专家，用数据作为武器去打开局面，或可以尝试一下。

可能会有人有疑问，我们有各种信息系统，已经自动做了统计分析，还需要专门分析吗？

显然需要。

一方面是各个信息系统要兼顾特定领域多方面需求，兼容性、普适性更好，但对于产品或项目针对性自然不强，没有聚焦。

另外一方面呢，信息系统又是针对特定领域开发的，整个业务流又形成信息孤岛，无法打通。此外，这样的系统改动起来极其繁琐，周期长、灵活性差都是问题。

此外，太阳底下没有新鲜事，我前面文章反复用制造业工厂对照过软件开发，工厂质量类问题多数需要数据分析来印证、判断、决策。长年累月的制造业经验有很多可以被软件业借鉴，我们可以持续关注、探索。

3

我们应该怎么理解汽车软件的数据分析？

概念是我们认识事物的一个入口和交流问题的一个基础，但也要考虑语境、环境、目的。

上海交通大学出版社的《英汉多媒体技术辞典》是这样定义的。

“数据分析指用适当的统计、分析方法对收集来的大量数据进行分析，将它们加以汇总和理解并消化，以求最大化地开发数据的功能，发挥数据的作用。数据分析是为了提取有用信息和形成结论而对数据加以详细研究和概括总结的过程。”

而PMBOK有这样的描述：

“数据收集和分析是为了加深对某种情况的了解而收集、评定和评估数据和信息的方法。数据分析的输出可用第 4.6.6 节中所示的某个工件加以组织与呈现。此处所述的数据收集和分析方法以及第4.6.6 节所述的工件通常用于为决策提供依据。

4.6.6可视化数据和信息

可视化数据和信息是以图表、图形、矩阵和示意图等可视化格式组织和呈现数据和信息的工件。将数据可视化可使人们更容易理解数据，并将之转化为信息。可视化工件通常是在收集和分析数据后生成的。这些工件有助于决策和确定优先级。”

自然还有其他的描述，但结合这两个还算不错的定义、我们自己的经验直觉、汽车软件领域的实践情况以及本文致力于实用易理解而非理论严谨的目标，我们可以将数据分析限定在三个动作上：整理数据、画出图表、写出文字。

做出这样的解释，乍看之下，似乎显得促狭，但正是我们的用意，我们经常会有种不良思维，无限放大自己的内涵和外延，结果就会导致宏大而无根，不妨做颗尖而专的钉子，而非到处找钉子的锤子。

4

汽车软件数据分析的几个段位

从整理数据到画出图表，再到写出文字，基本是走过了这个领域数据分析的路径，但怎么玩出花儿来，并不是一件容易的事。

4.1 度量和指标

度量和指标都是比较书面的词汇，翻阅专业书籍，会看到很多不同角度的解释。我们不是标准制定者，也不进行概念深挖，就按照贴合业内玩法来看，度量可以理解为对软件、过程、项目定性或定量的描述与评价，且侧重于定量驱动定性。

指标比较好理解一些，我们都知道KPI，大体上就是画的一条边界，不能越过，比如Bug数量不能超过多少个，度量的内涵要比指标大一些，可以认为度量包含指标，指标是度量项里Key的部分。

无论是度量还是指标，都有很多大大小小粗粗细细的维度，时间的、成本的、产品的、过程的、项目的、组织的、比例的、数量的、分布的、趋势的……

整体看下来，我们会发现度量本身并不简单，理论上，需要非常系统和专业的知识体系，建立、落地和维护的过程都是很大的工程，但为什么我们把它放在最低段位？

这是因为，尽管度量驱动效能或业务转化为指标的方式并不怎么成熟或有效，但这个领域本身已经有比较惯常的做法，一次性搭建好框架后，对于一个小小的QA，更多是在已经建立的度量和指标体系里看看是不是超标，是个算术题，甚至是个看数题，没有太多的思考和经验的注入。

4.2 展示和说明

展示和说明，即写报告、做汇报是QA的日常工作和主要输出，也是所有数据分析者要经常做的事，也基本对应上面讲的数据分析的三个动作：整理数据、画出图表、写出文字。

提到数据我们会想到什么？可以尝试想一两秒钟。

会不会想到一张密密麻麻的excel表格，里面有一条条的数据，有行有列，有文字，有数字……

那么，这表格有没有什么背后的铺陈规则呢？

有的，主要的概念是“维度”和“事实”。

维度，也就是认识事物的角度，是认识事物的一个独立的逻辑视角，比如，描述人群，可以从姓名、性别、年龄、身份证、户籍、政治面貌等维度来看，但要注意维度区分最好有清晰的概念界限，所有维度要处于同一逻辑级别，而且要考虑普罗大众认识和思考的习惯。如果我们描述人群，按小于20岁、20~30岁、30~40岁、40~50岁等作为维度，有时会让人理解起来有些混乱，因为这些划分有很多相似性，都属于年龄，把“年龄”或“年龄范围”作为维度会更好些。

事实，是指这个维度下的客观记录，常见的有连续型的数字（年龄）和离散型的类别（户籍）。

它们在表格里有不同的体现形式：一维表、二维表和多维表。理解表格的几维注意不要和空间的概念混杂，有些人会按照线面体这种空间概念来对照，但其实不是特别容易讲清晰，因为所有的表格从空间上看都是二维的。

一维表是将所有的维度放在第一行，从列去看，数据都是这个维度下的不同“事实”数据点，如下表。

二维表是将一个维度的“事实”放在行，一个维度的“事实”放在列，行列交汇处是分析或展示结果，如下表，行是“户籍”维度，列是“姓名”维度，交汇处为叫各个姓名的人在各地的数量。

多维表实际上是二维表的变体，行或列可以增加更多的维度，如下表，列增加了“性别”的维度，可以看到各个姓名不同性别的人在各地的数量。

对于一般的数据分析，一维表作为源数据，而二维或多维表作为进一步分析或展示的基础。

走到这一步，算是整理数据的工作基本告一段落，再接下来，要基于需求和分析思路绘制出各种更复杂的表或图，或边绘制边识别思路、边分析，比如，亲和图、因果图、控制图、流程图、层级图、直方图、矩阵图、思维导图、散点图、折线图、饼图、面积图、雷达图、气泡图等等。

虽说字不如表、表不如图，但必要的文字说明和解释也是需要的，毕竟对背景不了解的人，看到一张图表未必能很快看明白是什么。

简单说，数据分析就是基于“维度”和“事实”这两个基本要素，完成各种分组、对比、交叉、汇总、计算等处理，然后选择合适的方式展示及说明出来。

这里的难点在于维度的拆分、数字的敏感性、数理统计知识、工具掌握以及文字的表达能力。

“展示和说明”的完成基本上代表数据分析在形式上的结束。在这个段位，你可以在数据的完整及准确性、图表的直观及美观性、文字的通顺及严谨性等上面下功夫做好，但多数人只能停留在这个形式上的好与坏。

4.3 业务拿来用

完成上面两个段位，基本算是一个合格甚至还不错的QA，但不管是从自身长期发展上，还是组织需要上，还不够，我们最终的期待是让业务能够更深入地用起来。

最好呢，基于你的数据分析结果，业务能够去理解并评估项目或产品状态、预测未来走势、及时控制潜在偏差，以及改善技术实现或管理方式。

然而，分析明显不仅仅是一个技能，不是说用Excel函数倒背如流、当过大学数理统计课代表、高考作文还满分就够的，背后需要的是全方位的业务经验和能力。

比如，现在最多的数据是Bug的信息，一般工具链导出来就是一维表，如果直接通过透视表识别出Bug在COM模块有明显聚合，或许结合其他信息可以判断出信号列表传递和评估过程有些问题。那么，业务部门就可以参考我们这样的判断去优化相关的合作流程。

这里暂不多言，毕竟这部分需要充分结合业务来讲，我们不在本文里涉及太多。

                        5

写在最后

当然呢，通过数据来强力驱动研发效能提升，是个美好的期待。

在当前汽车研发领域，既不具备充分的文化环境和数据积累，也不具备拥有这样能力的人。

总之，不太容易，这需要我们QA同学或其他类似角色花一些精力，力争找到一个好的突破口和落地点。

大数据时代要逐步走进。