麦肯锡都在用的MVP分析法,到底是什么?

大数据 数据分析
MVP(Minimum Viable Product)原本是应用于产品设计的方法。指在正式推出产品前,先推出一个版包含核心功能的简单版本,测试用户需求与反馈,从而快速判断产品是否符合市场需求,做出调整。

很多同学雄心勃勃想在工作中做出成绩,这里推荐数据分析的MVP方法,能为大家的工作保驾护航。同学们坐稳扶好,下边开始分享哦。

数据分析的MVP是什么

MVP(Minimum Viable Product)原本是应用于产品设计的方法。指在正式推出产品前,先推出一个版包含核心功能的简单版本,测试用户需求与反馈,从而快速判断产品是否符合市场需求,做出调整。

数据分析的MVP方法,是在数据正式生产出来以前,先根据数据需求和使用场景,提供虚拟的数据结果,从而检验数据有效性,发现真正的数据需求。

这套方法在数据分析领域非常好使!因为它能解决数据分析的核心难题:做了半天,没有屁用。数据分析背后的《统计学》《数学》《运筹学》《博弈论》《机器学习》各种理论多了去了,因此极易引发自嗨。

做数据的自己嗨得不行,各种理论算的腾挪跌宕,到了用户那里:

  • “我早知道了!”
  • “你做的有啥用!”
  • “你做的咋落地!”

一键三连。这项目就必败无疑了。

数据分析的MVP方法,目的就是提前梳理清楚:数据如何对业务有用的逻辑,从而避免上述悲剧。而看似牛逼,实则然并卵的数据分析,在现实中多的很……

1.0版本MVP

举个简单例子,比如互联网平台-广告销售团队提出:“要建立业务员用户画像,掌握每个业务员的性别、年龄、行为、转化率,以提高业绩”。

这时候咋办?

如果用MVP思路,先不要急着去跑数,也不要急着列一大堆“用户画像标准指标”,而是直接拿着业务方提的最初的需求:“性别、年龄、行为、转化率,以提高业绩”直接给一个虚拟结果,然后确认:“如果我真的提供这些东西,你们真的能提高业绩?”——让他确认。

图片图片

                          

至少只基于这一句话来看,数据分析能输出的结论是完全无用的。1.0版本的MVP测试不通过,要么放弃这个需求,要么继续想想:该怎么更好的抓用户痛点。这样把数据推向2.0版本。

2.0版本MVP

进一步看,1.0版本的问题在于:没有清晰目标。所谓画像指标一大堆,到底看了要干啥没想清楚。如果聚集目标,比如:找到业绩好的业务员。这样就更清晰了一步。

这里就需要引入更多分析,因为“好”“不好”本身就需要做分析

  • 用什么指标衡量好
  • 连续好,还是单次好
  • 在什么范围内评选好

在这个阶段,做MVP时,可以直接把一些可预计的,很纠结的问题提前丢出来,和业务方一起提前思考应对方案,而不是等着跑了一大堆数据,自己闷头计算好几轮以后再讨论。越早讨论,越能提前刨累,避免无用功。

比如评价:“好/坏”中常见的多指标重叠问题(如下图)。

图片图片

比如业绩表现不稳定问题(如下图):

图片图片

至于和本阶段无关的指标,可以大胆做减法,丢了再说。有新的目标出来,再围绕新的目标组织数据。避免不分青红皂白,先捞一堆数再说的做法——数据分析师不能按时下班,都是被这些破事折腾的。

把这些梳理清楚,就有了2.0版本的MVP。(如下图)

图片图片

看起来,似乎已经比1.0版清晰了很多,删减了很多无效指标,聚焦到一个明确的目标上。注意,这时候仍然还没有跑任何数据,只是基于经验的虚拟,但是已经能把“早就知道了”的数据暴露出来,并且能过滤掉“其实没啥用”的指标,并且把可能有歧义的地方以具体案例的形式具体讨论,从而极大规避问题。

但是注意,这还不是一个合格的MVP,因为知道谁好谁坏,又能怎样?知道李四是真的好了,大家就能成为李四吗?还是根本李四是不可复制的,我得找更多类似李四的人进来?这些问题都没有答案。所以此时还是无法直接得出:这数据就能提高业绩。MVP测试不通过,继续!

3.0版本MVP

只告诉谁好,谁不好是不能提升业绩的。业绩是一线做出来的,一线需要的是SOP,是弹药,因此数据要进一步做,比如:

  • 优秀标杆的数据指标(呼叫次数?时间分配?跟进机会?)
  • 优秀标杆的目标客户(是否特定客户容易成功?)
  • 优秀标杆的销售技巧(用哪些话术?利用哪些物料/活动?)

注意,这里已经不仅仅是数据的范畴了,数据只能打标签,列指标。但话术、语气、时机把握是需要培训/业务部门提供的。因此在此阶段做MVP的时候,可以直接向业务部门明确:是否只输出数据就能满足需求。如果不能,趁早拉其他部门一起干活,不要自己埋头别憋数据。

图片图片

4.0版本MVP

看起来3.0版本已经很厉害了。然而有个隐藏的BUG,就是别人有没有可能学会。注意,这个不可知,会极大的阻碍业务认可数据分析的结果——落地不见效,到底是因为数据分析结论错了,还是执行没到位?这个可得提前安排明白,不然事后背锅分分钟的事。

因此,还需要在现在版本基础上,增加测试环节,检验到底有没有用。

这样,又涉及到:

  • 选多大范围进行测试
  • 测试时间周期多长
  • 如何排除节假日、活动等其他因素
  • 测试结果认证标准

把这些想清楚了,就有4.0版本。

图片图片

在这个阶段,终于能将数据需求,指向一个业务期望的“提升业绩”的结果了。并且最终结果有测试数据回收验证,即使测试不成立,也有备用方案垫底。这时候可以放心大胆去跑数,跑出来一定有用。

MVP测试的广泛应用

注意,MVP测试,是紧密围绕用户需求的。上边的例子之所以做了好几个版本,源头上是因为用户期望值高,指望直接见业绩。如果用户期望值不高,MVP测试可以很简单。

比如:

  • 用户需求是:目前没有数据→ 尽快提供数据
  • 用户需求是:目前数据太多→ 删掉无用指标
  • 用户需求是:目标数据太乱→ 重新整理逻辑
  • 用户需求是:不清楚问题在哪→ 输出可量化的问题点

这些只要提前虚拟个数据,做个图确认下需求,就能解决

稍微复杂一点的,比如用户需求是:精准预测销量,可能只要梳理两三步,就能更细化范围,提升有用程度(如下图)。

图片图片

为什么要推MVP方法

数据分析领域,一直有一个八爪鱼派在流行,就是不管有没有用,不管有没逻辑,像一只八爪鱼一样丢一大堆指标过来(如下图)

图片图片

这种做法,张牙舞爪,看着厉害,可是实际上却是项目失败的根源。让做数据的人误以为工作就是做作业,不考虑实际效果,一味贪大求多,最后累得半死还不讨好。

相比之下,做到下面几点,才能更快地积累分析经验,让数据更好发挥作用。

  • 多研究业务数据的基本形态
  • 多发现业务对数据实际需求
  • 多测试数据有用的点
  • 剔除无用的,空洞的,高大全的指标
责任编辑:武晓燕 来源: 接地气的陈老师
相关推荐

2021-02-03 21:48:17

设计App设计师

2022-07-11 08:33:51

容器技术Docker

2018-04-26 11:05:55

分布式系统集中式系统数据处理

2020-11-05 14:34:19

云手机百度华为

2024-07-26 08:34:25

2011-04-27 09:30:48

企业架构

2020-03-05 10:28:19

MySQLMRR磁盘读

2022-10-08 00:00:00

Spring数据库项目

2021-04-14 11:20:04

无代码APPNo Code

2020-10-14 06:22:14

UWB技术感知

2020-09-27 06:53:57

MavenCDNwrapper

2020-09-22 08:22:28

快充

2010-11-01 01:25:36

Windows NT

2020-02-17 21:52:19

微信支付宝健康码

2009-06-09 22:11:44

JavaScriptObject

2013-06-09 09:47:31

.NetPDBPDB文件

2019-10-30 10:13:15

区块链技术支付宝

2021-09-03 09:12:09

Linux中断软件

2020-08-04 14:20:20

数据湖Hadoop数据仓库

2010-04-22 14:14:29

Live-USB
点赞
收藏

51CTO技术栈公众号