编辑导语:数据分析中的MVP就是在数据正式产生之前，提前对数据进行测试，以确认准确性。因此，这种方法常用于数据分析领域，提前根据输出进行更改，以保证后续结果；笔者分享一下数据分析中的MVP方法。让我们来看看吧。

许多学生雄心勃勃，想在工作中做出成绩。这里推荐数据分析的MVP方法，可以保护大家的工作。

一、数据分析的MVP是什么？

MVP(最小可行产品)原本是一种应用于产品设计的方法，是指在产品正式推出之前，推出一个具有核心功能的简单版本，测试用户的需求和反馈，从而快速判断产品是否符合市场需求并做出调整。

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

这个方法在数据分析领域非常有用！因为它可以解决数据分析的核心问题:做久了没用。数据分析背后的统计学、数学、运筹学、博弈论、机器学习……理论如此之多，很容易引起自鸣得意。

我自己不会做数据，各种理论计算跌宕起伏，直达用户:

一个关键，三个环节，这个项目一定会失败。

数据分析的MVP方法旨在提前梳理清楚:数据如何对商业有用的逻辑，从而避免上述悲剧的发生；而且看似牛逼，但其实现实中有大量的数据分析…

二。版本1.0 MVP

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

这时候我该怎么办？

如果用MVP的思路，不要急着去统计或者罗列一大堆“用户画像的标准指标”。而是从业务端拿最初的需求:“性别、年龄、行为、转化率提升业绩”直接给出一个虚拟的结果，然后确认:“如果我真的提供这些东西，你真的能提升业绩吗？”-让他确认。

?????

至少基于这句话，数据分析可以输出的结论是完全没有用的。如果1.0版本的MVP测试失败，要么放弃这个需求，要么继续思考如何更好的抓住用户的痛点。这会将数据推送到2.0版。

三。版本2.0 MVP

进一步看，1.0版本的问题是没有明确的目标。有很多所谓的画像指标，但是我看了之后也没有想清楚该怎么做。如果聚集目标，比如找一个业绩好的业务员。这是更清晰的一步。

这里需要引入更多的分析，因为“好”和“坏”本身也需要分析:

在这个阶段，做MVP的时候，可以直接提前抛出一些可预见的、纠结的问题，提前和业务方想好应对方案；我不是等着一大堆数据跑完，而是经过几轮计算再讨论；我们讨论得越早，就越能提前疲惫，避免徒劳无功。

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

比如性能不稳定的问题(如下图):

至于和这个阶段无关的指标，可以大胆做减法，丢掉。

当一个新的目标出现时，围绕新的目标组织数据。避免先赚大钱后再说的滥竽充数的做法——数据分析师不能按时下班，都被这些破事折腾得够呛。

把这些整理清楚之后，就有了MVP 2.0版本。(如下图所示)

似乎比1.0版本清晰很多，删除了很多无效指标，专注于一个明确的目标。

注意，此时还没有运行任何数据，只是基于经验的虚拟。但它已经能够把“早就知道的”数据暴露出来，把“实际上没用的”指标过滤掉，把可能存在的歧义以具体案例的形式讨论出来，从而大大规避了问题。

但是，这不是一个合格的MVP，因为我们知道谁好谁坏，那我们能怎么办？知道李四真的很好，是不是每个人都能成为李四？还是说李四根本无法复制，我得多找几个李四这样的人进来？

这些问题没有答案。所以这个时候我们还不能直接断定这个数据可以提升我们的业绩。MVP测试失败，继续！

四。版本3.0 MVP

只分谁好谁坏，并不能提高业绩。业绩是一线做出来的，一线需要的是SOP，不是弹药，所以数据要进一步做，比如:

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

注意，这已经不仅仅是数据的范畴了，数据只能被贴上标签，列为指标。但用词、语气、时机需要培训/业务部门提供；所以在这个阶段做MVP的时候，可以直接跟业务部门说清楚:只输出数据是否能满足需求；如果做不到，那就让其他部门一起努力，否则就太晚了。不要把自己埋在数据里。

动词 （verb的缩写）版本4.0 MVP

看来3.0版本已经很强大了。但是，有一个隐藏的BUG，就是别人能不能学会。

注意，这种不可知会极大地阻碍业务对数据分析结果的认知——落地是无效的。是因为数据分析结论错误还是执行不到位？这个一定要提前安排明白，不然就是事后分分钟的事情。

所以需要在当前版本的基础上增加测试链接，检查是否有用。

这样，它涉及到:

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

把这些东西想透，就有了4.0版本。

在这个阶段，数据需求最终可以指向一个业务所期望的“提高性能”的结果；并且最终结果是测试数据恢复验证，即使测试不成立，底层也有备份方案；这时候你可以大胆的数一数，用完了会有用的。

六。MVP测试的广泛应用

注意MVP测试是紧密围绕用户需求的。

之所以做了上面例子的几个版本，是因为用户的期望值很高，期望直接看到性能。如果用户的期望值不高，MVP测试可以简单一些。

例如:

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

这些只要事先做好虚拟数据，做出图来确认需求就可以解决。

再复杂一点，比如用户的需求是:准确预测销量。可能只需要两三个步骤就可以细化范围，提高有用性(如下所示)。

七。为什么要推MVP法？

在数据分析领域，一直有一个章鱼派在流行，就是不管有用没用，不管合不符合逻辑，像章鱼一样抛出一大堆指标(如下图):

这种做法，张牙舞爪，看起来很伟大，实际上却是项目失败的根源；让做数据的人误以为工作就是作业，不顾实际效果，一味贪多，最后累到无法取悦。

相比之下:

多研究业务数据的基本形态；多发现业务对数据实际需求；多测试数据有用的点；剔除无用的，空洞的，高大全的指标。

这样可以更快的积累分析经验，让数据更好的发挥作用。

#专栏作家#

陈老师，接地气，微信微信官方账号:接地气的学校，人人都是产品经理专栏作家。资深顾问，在互联网、金融、快消、零售、耐久、美妆等15个行业拥有丰富的数据相关经验。

本文由人人作为产品经理原创发布。未经许可，禁止复制。

题目来自Unsplash，基于CC0协议。