最近在思考需求的解决方案的时候，总是会纠结于需求的范围该如何确定，而在寻求出路的过程中接触到了mvp的概念，发现mvp的思维不只可以应用在需求范围的考虑上，更可以应用在生活中的各个角落。于是决定自我总结归纳一下mvp思维。

好了，下面进入正文，什么是MVP？

MVP即是最小化的可执行产品。主要的特点是低成本。主要的应用场景还是在需求不明确或者个人思路不够清晰的时候，能够以低成本进行试错，摸清需求，清晰思路。

而针对mvp的定义，可以拆分出2个点是需要明确清晰的。

1. 怎么算最小化？

2. 怎么算可执行产品？

明确了这2个点，要做什么，怎么做。也自然会有了一个大概的思路。

1. 怎么算最小化？

怎么样才能做到最小化，我认为这是mvp思维最核心的部分吧。而贯穿于“最小化”的核心要点则是闭环。你的方案和你的方案产物(支路)是否能够完整地走完一个生命周期，同时还能推动新一轮生命周期的开始。所以，这里的最小化其实真正的意思是，最小生命周期🤔

1.1 那怎么算一个生命周期？

就好像武侠小说里的大侠运气，都需要完整地走完一个小周天/大周天，若是功法有错或者运行过程中被打岔，无法形成闭环，轻则内伤吐血，重则走火入魔，甚至暴毙。所以，一定要保证你的方案和产物能有始有终，生有来处，去有归途。

我举两个栗子:

1. 我登录全民k歌，领取登录奖励1朵鲜花。

2.我登录全民k歌，领取登录奖励1朵鲜花。然后我把这朵鲜花送了给我一个朋友。

这两个哪个是完整的生命周期呢？

-------密封线内禁止答题--------

在我的理解，这两个都是一个完整的生命周期。只要它能针对你的目的有始有终，就可以算是一个周期了。

对于获取鲜花这个事情来说，1和2就是一个周期。对于一个完整的礼物系统来说，2才是一个周期。

1.2那怎么才算是最小的呢？

因为我个人对生命周期的定义是相对广泛的，而过于广泛的生命周期其实对我们要做的事情没有任何帮助，所以我们需要根据目的，判断出我们的最小生命周期。这里的最小，我把它分为绝对最小和相对最小。

1. 绝对最小，就是周期中每一个流程，每一个步骤都是为了我们的目的而存在的，没有多余的存在。

2. 相对最小，是在绝对最小的基础上，增加了一定的流程，以增强原周期的可扩展性。

还是用刚刚的栗子来说明，如果你是想检验用户如果做某个操作后受到了正向反馈，是否能提高他做这个操作的积极性和频率。那绝对最小周期就是:执行操作→获得反馈，就可以了。具体的设计方案只需要是:

用户登录全民k歌，提示:你已连续登录x天，超越xx%的用户。

但是如果你考虑到，公司后期可能会做积分系统。那这个方案其实就很难挂靠到积分上去。还是换一个设计方案吧

用户登录全民k歌，提示:登录第x天，获得x朵鲜花。然后增加一个地方去记录和存储用户的鲜花数。

这里的第一个方案其实就是绝对最小，第二个方案就是相对最小。对比起来，第二个方案会增加一定的成本，但是对于后期的扩展会更有帮助。如何权衡，那就要根据实际情况来进行判断了，大部分情况我还是推荐以相对最小的方式来考虑问题。关于这个我也提供一个我自己的小方法:

当你基于一个目的去想最小方案时，先逼着自己去往上想一层，分析出更高层次的目的，想到以后扩展的一些可能性，再去做当前目的的最小方案。如运营最基础的AARRR模型，可能我当前的目的只是获客，但是往上一层的目的其实是为了增加盈利，然后有获客，激活，留存等环节。了解了整体的规划和框架后，再去构思当前目的的相对最小方案，自然会考虑到以后的一些扩展性了。

另外，这里最忌讳的就是贪。做了这个好像很顺便就做了那个，然后又很顺便地带上了另一个。一定要约束住自己的决定，想的时候可以想全面一点，但是做的时候一定要克制。要克制。要克制。

2. 怎么算可执行产品？

关于这一点，就不用太着重解释了。我的理解其实就是实现的方式和载体，不需要太受约束，可以是配合程序员开发出来的demo，也可以是一份文字报告，甚至可以是一段话。只要能满足你的目的，那就是一个合格的产品了。这里的选择以实际情况为准，尽可能地低成本去实现。如果是比较有把握的，那就可以选择成本更高一点的方案；如果是不确定的，比较模糊的，那就选择最低成本的方案先检验出发点的正确性。

总结:

mvp思维对于生活中的许多事情都有不错的作用，核心思路是在于用尽可能低的成本去实现你的目的，无所谓实现的方式和表现的载体，对于满足你目的起不到帮助的功能/环节，都是相对多余的，需要尽可能地减少，一定要控制好界限，避免需求滚雪球，偏离了出发点。

最后，也希望大家能指出我的观点的不足之处！共同进步！