0、引言
“效率”作为得物技术部的关键词之一,大家在研发效能、会议效率、协作效率、办公效率等方面一直进行着持续地探索。在实际落地的过程中,为了更好地评估应用效果,往往需要将定性描述转换为可量化的数据指标。这些数据指标可以帮助我们了解研发过程中的变化和趋势。但是你真的能“读懂”这一堆冷冰冰的数字吗? 在看到这些数据指标时,我们往往很容易陷入一个误区:只关注具体的数字,而忽视了数据采集和分析解读的过程。这意味着即使我们对这些指标进行了定期监控,我们仍然不能真正了解研发过程中的状况和障碍。 因此,如何正确地解读这些数据指标变得尤为重要。为了有效解读数据,我们需要了解数据来源和分析过程,以及数据指标与业务实际情况之间的关系。只有这样,我们才能更好地理解我们所面临的问题和挑战,并且采取适当的措施来加以解决。
1、研发数据从哪里来
第一阶段:人肉统计
当我们从0到1定义一个新流程、新数据指标时,通常是处于探索验证的阶段,这个时候通常不会耗费过多人力来搭建线上化的系统,导致数据采集的过程十分痛苦,文档、表格、甚至群聊等五花八门的数据来源,不少同学应该有亲身体会。
第二阶段:分散、未经处理的系统数据
技术部全链路的研发过程数据往往分散在多个内部系统中,当你需要分析某个数据的时候,可能会涉及到不同系统之间的交互,而各个系统由于数据维度、统计口径的不同,必须先梳理清楚数据背后对应的逻辑,其次再进行数据清洗、关联业务线/部门等统计维度,最终形成可用的数据源。除此之外,一旦涉及到某个系统的改造/数据加工,想要获取到可用的数据更是难上加难。
第三阶段:流程不规范,导致数据不可用
这是系统建设中最常见的问题,由于系统沉淀的数据强依赖用户操作,如果在流程中没有规范化的操作方法及卡点管控,就有可能造成数据不可用。最典型的例子就是项目管理软件中需求/任务的状态流转,会出现任务长时间处于未开始状态、长时间滞留在进行中、任务完成但是消耗的工时为0等各种异常场景。
第四阶段:成熟阶段
工具一体化,流程规范化,数据标准化。效能度量和项目管理人士心驰神往的阶段,这个阶段要流程有流程、要系统有系统、要数据有数据,无需耗费大量精力来获取数据和处理数据。
2、数据指标之略问一二
大数据时代,万物皆可数据化。在研发过程中,沉淀下来的数据可以定义出种类繁多的数据指标,基于这些数据,我们往往会耗费大量人力打造出一个数据指标大盘,甚至美其名曰“驾驶舱”。虽然我们的理想绝不仅限于拥有数据大盘,但现实很骨感,残酷到“你以为的起点竟变成了你的终点”,没错,数据大盘可能是大部分团队的终点,它具有取数、看数以及基础的可视化图表,值得注意的是,面对五花八门的指标,我们稍不注意就会迷失了方向。
2.1 你知道X指标的定义是什么吗?
看到这个问题,很多人认为没有难度,不需要太多思考就可以列出具体的公式和取数逻辑,但是真正想问你的不仅仅局限于此,更深入一步的问题是:你知道X指标为什么这样定义吗?想要通过它来衡量什么?
在软件研发领域,提到研发数据就不得不提研发效能度量,后者在各路大神的研究及科普下已经逐步走向成熟,与此同时也沉淀出很多业内通用的研发效能指标。但如果你仅仅是生搬硬套指标定义,而不去深入理解指标背后隐藏的业务目标,你会发现最终的结果往往不尽人意。所以我们要知其然,还要知其所以然,当你在使用或定义一个数据指标时,必须要清楚地知道度量X指标的真正目标,想要发现或改进什么问题,避免变成纯纯的数字游戏。
2.2 你知道最核心的指标是哪个吗?
在几十个数据指标中,你能分辨出哪个指标最重要吗?看到这里,你可能在仔细对比各个指标的重要性,但是,
这是个带有误导性的问题,在我看来,没有最核心的指标,只是不同的领域会有相对核心的指标。想想新广告法开始限制“最”、“第一”这种词语的使用,是不是感觉也挺合理?这些形容词是需要基于真实场景的,同时又会因为所处阶段不同,导致你关注的指标也会发生变化,就像OKR一样,不同的时期你会设立不同的O,自然就会有不同的KR。
举个例子:
- 公司在Q1要快速扩张,它对应的KR可能会包含DAU、GMV等指标
- 公司在Q2要提升体验,它对应的KR可能有NPS、秒开率、工单解决工作时长等指标。
参照OKR的概念我们也能发现,我们要从一堆指标中筛选出你真正关注的指标,而不是所有指标一手抓。
3、不解读 或 无效解读 = 毫无意义
筛选出了核心指标后,就需要来合理地解读指标。数据指标分成过程指标和结果指标,结果指标只能告诉你好坏,通常需要参照和它相关的多个过程指标来进行归因。
对于大多数人来说,我们不是专业的数据分析师,即使是长期在项目管理和研发效能领域工作的专家,可能在数据分析方面的能力也有所欠缺,所以如何解读数据指标就成了一个难题。 如果你不解读数据指标,直接把一堆指标丢到用户面前,用户看了半天,没看出指标的好坏,也不知道要不要改进,更不清楚如何改进,最终只能是一脸茫然。 如果你用数学的方式进行了无效解读,比如需求吞吐率下降,解读为团队承接的需求数减少(分子),而提报的需求数增加(分母),这就属于无效解读,这个结论几乎没有价值,需要进一步挖掘分子减少和分母增加的根因。 所以,我们要通过数据指标解读出关键性的结论,告诉用户存在的问题及改进的方法,只有这样你的指标才是有价值的,否则空有指标,啥也不是。
4、解读数据指标的几个步骤
度量数据指标不是目标,只是实现目标的手段。我们希望可以从中获得有价值的信息和结论,从而指导实际的业务决策。碰巧之前数据团队的大佬来团队普及数据分析的基础知识,提出了“可量化、可解释、可干预”的观点,此处正好把想问的三个问题分别对应到其中:
第一层:基础
可量化:我们希望通过客观的数据指标来描述现象,就需要明确数据指标的定义,确定其和业务目标的对应关系,判断指标的适用性,以及在不同场景下的不同意义。
第二层:分析
可解释:就是让通过分析数据指标得到的结果,能够被用户理解。在开始正式工作之前,我们先熟悉下列几个问题,因为接下来的工作,主要都是围绕着这些问题进行的:
指标对应的数值是好还是坏?有没有基线标准?跟基线相比是好是坏?
跟自己比趋势是变好了还是变坏了?是正常波动还是异动?
带着问题,接下来进入正式的研发数据分析流程:
-
数据采集及清洗:获取到高置信度的数据,同时可能会使用表格或者可视化的图表来展示数据
-
选取特定的维度,如业务线、部门、个人等维度,得到相应的数据;同时选定基线,得到基线的数据。根据这些数据,我们可以得出指标对应的数值是好还是坏的结论
-
使用基础的统计学方法,如对比分析、趋势分析等方式对数据指标进行分析,通过横向对比及历史趋势数据的对比,得出趋势变好还是变坏的结论。与此同时,我们还需要分析出指标是正常波动还是异常波动
-
如果上一步的数据指标是异常波动,则可以对关联指标进行分析,举例:我们发现研发交付周期数据发生异动,同时发现与它相关的需求变更率、缺陷引入率指标都发生了异动,此时可以通过相关过程指标进行下一步分析
-
通过具有相关性的过程指标来分析主要影响因素,最终定位指标异动的根因。
至此,我们成功定位了指标异常波动的根因,这也预示着第二步的完成。在实际分析的过程中,此阶段往往是最为耗时的阶段,值得注意的是,我们通常不会将整个分析的过程体现到最终的分析报告中,虽然其复杂耗时,但对大多数用户来说,更加关注的是结论而不是过程。
第三层:价值
可干预:通过适当的方法来改进我们归因发现的问题。辛苦了半天,定位到了数据指标异动的根因,但是这并不意味着结束,接下来还有更重要的一步,这一步能体现你对业务的思考,体现你这份分析报告的真正价值,刚刚让我们辛苦了半天的分析过程,也要靠它赢回票价。
首先,需要评估指标异常波动带来的影响,以及关联指标异常波动带来的影响,整体是正向影响还是负向影响,如果影响程度可接受,不需要干预,那到这里就结束了
其次,结合该指标的历史数据趋势以及其他相关指标情况,尝试对未来做预测,评估指标再次劣化的可能性
随后,针对不同的场景及关联指标情况,提供可改进该数据指标的措施,并评估预期效果(注意预期效果和实际执行落地的效果相比可能会打折)
最后,评估改进措施所需要的投入,结合ROI来辅助你做出最终的业务决策。
经过这一波分析可能得出一条结论:指标异常波动,相比基线低XX%,经过分析发现本季度遇到了A、B、C问题,归因是X、Y、Z原因,负向影响显著。结合历史趋势综合评估未来发生的可能性约XX%。建议通过1、2、3等方式来做改进,分别预期投入XXX,能够解决XXX问题,并带来XXX额外效果。
结论是分析数据指标得到的产物,它远比冷冰冰的数字有价值。从管理者及普通用户的视角来看,给我一堆数字我也不知道要从哪下手分析,不如你直接告诉我现在的问题是什么,是否需要改进,要怎么做才能改进,改进后能拿到什么结果。
5、结语
在项目管理和度量领域,基础的数据分析能力是从业者们必备技能,你可以不精通,但需要掌握入门技巧,同时必须要有专业领域的业务思考,一旦脱离了业务,数据指标也就变成了纯纯的“数字游戏”。
纵观整个数据分析过程,从取数、分析,到得出结论并给出改进建议,最终形成一份分析报告,哪怕看起来不算特别复杂的一份报告,实际上都包含着编写者们的一把心酸一把泪。
在实际工作中,受惠于系统工具的不断迭代,已经逐渐向系统化的取数和分析过程过渡,大大简化了数据分析的困难和复杂度。在结合人工分析过程中,也在逐步摸索更加高效的方法,快速得出结论和建议。未来也希望能通过系统化、智能化的方式,让大多数人能够看懂数据指标,能够直接利用有效的建议来实施改进,解决望指标兴叹的问题。
*文/阿杜
本文属得物技术原创,更多精彩文章请看:得物技术官网
未经得物技术许可严禁转载,否则依法追究法律责任!