精益开发 – MVP的误解怪圈

MVP是一个让人非常振奋的词。 对体育迷来说,MVP指的是这个:

对游戏迷来说,MVP指的是这个:

但对于每一个从事敏捷精益开发的小伙伴们来说,MVP指的是这个: 最小化可行性产品 (Minimum Viable Product )在精益开发中,开发团队通过最小的努力提供可行性产品,并根据用户反馈进行不断迭代,最终做出成熟产品的过程。

 

作为《精益企业》中的网红词汇,越来越多的产品经理开始张口闭口的把MVP这个词挂在嘴边。但是,这些产品大大们,以及大部分的程序员爸爸们,其实并不清楚MVP到底指的是什么东西. 于是,便出现了这样的对话:

产品经理:“咱们把这个产品的MVP先做出来,就做的和淘宝差不多就可以了,先不加会员系统。”

程序员:”你知道淘宝的UI有多复杂吗?要不咱们把购买功能也先不做吧,MVP原则嘛。” 

什么?你并没有发现以上的对话有什么问题?那么恭喜啦,这篇文章便是写给你的,因为你已经陷入了对于MVP的”误解怪圈”。

误解怪圈1: MVP就是先做优先级高的功能

对于没有系统了解过精益开发的小伙伴们来说,上面这个怪圈几乎是一个避不开的地雷。在小马哥经历过的项目里,不少有着长时间敏捷开发经验的团队成员甚至都对这一概念深信不疑。 为什么会产生这样一个误解呢?因为他们忽视了精益开发的第一大原则:商业设想的快速验证。MVP强调的是产品的完整流程,它力求用最小的effort去实现这个流程。而往往在互联网产品的语境下,一个完整的产品流程通常都包含了几大不同模块的功能。 比如咱们的淘宝Like的电商网站,如果你从用户的角度出发,一个用户想要在这个网站上实现他购买的目的,是必须至少包含浏览,下单,付款,运送这几个过程的。这也就意味着,缺少了这些功能中的任何一个,都会让用户的使用目的无法达到,从而无法去验证你的商业设想是否被用户所接受。下面这个被反复使用的经典图正好说明了这个问题,大家感受一下:

那如何去避免这一个误区呢?小马哥提供一个精益开发的经典思路:从用户角度出发去划分功能,纵向切割用户故事。相比于传统的”浏览,下单,购买“这样传统的功能划分方式,如果你的团队足够敏捷的话,可以尝试着纵向划分功能。纵向划分功能可以对每一个传统功能点都进行适当的阉割,只保留最核心的部分,而着重于用户旅程的完整度。 比如”用户可以浏览单个商品,在线输入地址和电话下单,并使用支付宝购买”就是一个常见的纵向切割的例子,它在每一个传统功能点都只保留了一个选项,但却能支持用户走完完整的流程,实现他的目的。

 

误解怪圈2: MVP一定是一个实际的产品

相比于第一个怪圈,第二个误解怪圈对于很多常年做交付的团队来说更是一个理所当然的理解。在他们看来,MVP必须是一个需要付出实际开发成本去真正做出来的东西,是看得见摸得着的。实际上,MVP作为精益创业强烈推荐的快速试错工具,反而更提倡低保真的原型,而且越简陋越好, “Minimum Viable”便是对这一概念最直接的解释。 举个例子,如果你想做一个基于地理位置的旅游推荐app,你可以花费几个月的时间做出一个集成了GPS,大数据处理,外观简陋的的web app, 也可以做一个这个:

前者可能需要你花费10万+的开销,而后者…三块钱都嫌多好吧。那实际效果如何呢? 小马哥通过亲身经历的众多用户体验项目告诉你:效果是差不多的,甚至后者还更好一些。因为它可以根据用户的及时反馈快速的对产品原型做出调整 (重新画一张图),并迅速得到用户的二次反馈。怎么样,是不是开始顿悟为什么之前自己经历的创业项目会失败了?花了冤枉钱了吧!

 

误解怪圈3: MVP就是拍脑袋做,然后再去向用户进行验证

不得不说,自从MVP概念大火以来,越来越多的产品经理和创业者们把MVP当作了自己信仰创业的鸡毛令箭。他们有了一个想法,便大胆的让开发们去迅速做出一个原型,拿到市场上去做验证,如果失败了果断放弃,又开始了第二轮的拍脑袋之旅…在他们看来,这是精益开发的精髓,是“快速试错”的直接体现,然后……公司就破产了。

小马哥在这里必须要警醒大家的是,精益开发是一个减少浪费的轻量级开发方式,但它并没有“消除浪费”。这也就意味着,一切能够真正消除浪费的行为都是比直接开发MVP要来的更有价值的。比如说市场调研,适当的市场调研可以将一个不切实际的商业创业扼杀在摇篮,从源头避免任何开发成本的浪费。从另一个角度来看,市场调研可以为MVP的设计提供思路和角度,是产品设计上必不可少的一环。 如果大家能真的做到合理的市场调研,我们便不会看到下面这样尴尬的创业奇观了:

 

好了,讲了这么多,你是不是对MVP的概念有了更正确的理解了呢? 什么?还是没有,那你还是看看这个小马哥心中的MVP吧:

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注