最小可行产品（Minimum Viable Product，简称MVP）是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是，快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设[1]。该概念由Eric Ries在其著作《精益创业实战》中提出，用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。
举个形象的例子，就如下图所示的那样，MVP不是每个迭代做出产品功能的一部分，而是每次迭代都要交付一个可用的最小功能集合，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。然后逐次迭代做出满足客户预期的产品，直至最后完全满足客户需求。
MVP是最符合敏捷思想的产品迭代开发方法。MVP首先着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。部署之后，通过客户反馈，逐步修正产品设计和实现，最终达到完全满足客户需要。而最关键的是，在各个迭代过程中，做出来的产品始终是可为客户所用的产品，而不是只有一部分功能却不能让客户使用。
MVP也适用于初创企业在市场不确定的情况下，通过设计实验来快速检验你的产品或方向是否可行[2]。如果你的假设得到了验证，再投入资源大规模进入市场；如果没有通过，那这就是一次快速试错，尽快调整方向。创业企业可以通过做出最小可用产品，精简到不能再精简，发布之后收集市场反应，逐步调整产品战略，调整里程碑，尽快达成短期目标。MVP产品仅包含必要的功能，从而能从早期的用户得到初始的资金和用户反馈。而仅包含必要的功能点意味着最小成本，最能展现核心概念；MVP不一定是成品，也可以仅仅是理念；通常，构建MVP仅需要数天或数周时间。
MVP也是简约设计思想的生动体现。我们经常见到一个软件中包含了千千万万的功能，比如Windows操作系统。可是对很多用户来说，能用到的功能也就只有寥寥几个，绝大部分功能都在睡大觉，无法真正体现这些功能的价值。软件厂商与其花费大量人力、时间、金钱来做这些绝大多数用户不使用的功能，不如集中精力于用户真正需要的功能，首先从MVP做起，可定制、可选功能集合，不同的用户只需要安装或配置需要的最小功能集合即可。一个软件中有的，都是用户真正需要的。
当然，MVP也并不适用于任何时候。有人就曾提出[3]，MVP模式的问题在于，它并不总是开发颠覆性技术的最好办法。如果乔布斯发布的是最小可用的 iPhone，我们是不是会得出结论说大家更喜欢键盘？如果 Tesla（电动车）制造的是最小可用汽车，还有没有人去开它？因为与 web 服务不同，就好像不可能有人会花几万块买一辆最小可用的车一样，硬件不是免费的，而且不能快速方便更新。当然，这不是＂最小可用＂理念本身的问题，只是有些市场不合适。产品到底可以做到多好或者做到什么程度最好？答案或许永远也找不到。这种模式也不一定就是做大事情的最好方式。有些产品是小调，有的则是交响曲，而有时候你还是要先让音乐演奏起来。
参考文献：
[1] What is a Minimum Viable Product? http://www.quora.com/What-is-a-Minimum-Viable-Product
[2] 创业需要MVP(Minimum Viable Product，即“最小化可行产品”) http://column.iresearch.cn/u/zdiwbf/677071.shtml
[3] 做最小可用产品还是做最漂亮的产品？http://www.36kr.com/p/200474.html
————————————————
版权声明：本文为CSDN博主「wushxian」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wushxian/article/details/42028761