如何玩转MVP（最小可行产品）？

《精益创业》是每一个创业者，或者创新者必读的书。书中提到了一个很重要的概念：MVP（Minimum Viable Product）——最小可行产品。可以说是精益创业的核心，用白话解释一下：

愿景不重要，最快速最低成本的找到市场痛点需求最重要

概念本身很好理解，但是实践起来却不是那么容易。甚至在实践过程中，有人会认为MVP过于理想，不切实际，或者是没有必要。我们这里，就结合我们自己的经验，和大家一起聊聊MVP的重要性，以及在实施过程中会遇到的问题。这里要先强调一点，精益创业不是只适合创业公司，在大公司中同样适用。当你的团队要做一个新的产品，要在一个未知领域开拓的时候，就可以考虑精益创业的实践了。
我们做的产品是互联网领域的，所以就以一个互联网产品举例，要做出一款互联网产品，从调研、产品规划、设计、开发、到测试，再到推向市场，往往周期都比较长。参与过这其中变数太多，大家对于需求的理解多种多样，做出来的产品满足需求的可能性很小，成功率非常低。这里有很多失败的经典例子，大家可以搜一下，引以为戒。但做一个产品，确实需要这么多步骤，产品经理、设计师、开发测试、市场推广。一个一个步骤走下来，是不是很无奈？所以是时候转变一下思路：开发产品时先做出一个简单的原型——最小化可行产品，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。甚至在很多时候，并不需要原型，就可以测试产品的设计是否能够满足大家的需要。我想这个时候，有同学应该会想起来Dropbox的例子了。
如何降低风险，提高速度，就应该尽可能的缩短每一次的迭代。那其实很简单，尽量每一次循环、迭代，只验证少量的核心功能，整个过程就会快起来，如果在一开始，就想做很多，一个迭代下来的时间，相应会长。

那么，在实践的过程当中，会面临哪些问题呢？

最大的问题，就是愿景。这是公司战略层的问题。愿景这个东西很美好，也很可怕。美好在于可以鼓舞大家的士气，激发大家的斗志。可怕在于，这个愿景不一定能够实现，并不是你希望，或者强烈希望，你的产品就成了。很多公司的管理层觉得我的战略规划很好，愿景非常清晰，你们产品研发就按照这个目标，进行产品设计，之后就得天下了。这里有点一厢情愿，并且忽略了战略和实施之间的鸿沟。也许战略上确实很正确、很明确，但是产品的设计，能否实现这个战略也是一个很大的问题，我们要一步到位么？还是说把战略目标进行分解，得到一个个可行的目标，不断的迭代，到市场上验证？哪一种风险更低，收益更高，显然是后者，可以随时调整，并且可以使得战略上越来越清晰。试想我们设计了一个产品，做了一年上线。用户的需求，还和一年之前一样么？一年中竞争对手，也没有变化么？风险大大的。

解决了公司高层的问题，其次就是产品设计的问题。一个MVP的实践过程中，就怕产品经理不能够辨别真伪的需求，进而不断的加功能，导致上线的时间一而再、再而三的延期。然而这个过程中，产出的功能，都没有经过用户的验证，当用户拿到产品的时候，一脸懵逼，我该怎么用呢？所以产品经理在MVP的过程当中，起到了至关重要的作用。在这个过程当中，产品经理甚至要牺牲某些方面的追求：细节的追求、用户体验的追求等。快速设计功能，解决主要问题，满足用户需求之后，在后续版本中迭代改进。一个产品最好的体验是什么，就是解决问题。至于用户的操作感受，并不是第一位的。MVP适用的并不仅仅是C端产品，需要较大创新的B端产品，也同样适合。众所周知，B端产品的功能很多，逻辑很多，似乎难以削减。那么怎么办呢？回归当前的需求、回归要解决的问题，梳理出主要逻辑，去掉伪需求，规划出来功能点的优先级。按照顺序来。

技术研发这边，首先要从技术架构上，支持快速试错。选择轻量的架构，适当追求技术的完美。工程师接触的是细节，也容易陷入细节之中。某一个点可以优化一下，或者另外一个点可以通用一些，这样的点多了，进度就慢了下来。技术的负责人、或者架构师在细节的把握上，要有度。比如说，要实现一个搜索的功能，验证产品的可行性，没必要从头做一个搜索引擎，展示自己高超的技术，通过使用开源的技术，就可以很好的解决。另外，架构上也要轻量。举例来说，从一些大公司出来的技术专家，容易做什么都想着画架构图，做分层、做高可用、做分片、做负载均衡。实际上，在试错的过程中，需要这些么？同学们一定要记住一点，架构是演化出来的，不是一开始就设计好的。比方说，大的架构，一定要分层，可以很好的扩展，具有很强的灵活性。但是在产品还比较小的时候，就是浪费时间，所以再合适的阶段，设计合适的架构，留着可以扩展的点就好。没必要一开始就设计得很好。

上面提到的三个问题，是实施MVP过程中，比较大的障碍。其实说明清楚了问题，就很好解决了问题。总结起来，如何玩转MVP？就一点：

快速实践是检验功能的唯一标准。

祝：大家创业成功！ by良辰乐