再看 MVP:对最近一些问题的观点

先用当年亨利·福特老先生的一句话镇一下:如果我当年去问顾客他们想要什么,他们肯定会告诉我:“一匹更快的马”。

现在把这句话放在这,既令人警醒,又有一丝讽刺的意味。但现代生活的节奏,已经不允许我们像福特老先生生活的时代那样,不断制造“成品”来验证。那么在当下的环境中,如果我们遇到了类似的问题,究竟应该培育更快的马,还是应该生产汽车呢?(先留着,后边给出我的答案。)

自从各种创业理念火起来之后,紧跟着各种概念也被炒起来。为了解决这类需求验证的问题,比较著名的方法论当属MVP。比较正式的接触到MVP的概念,是在精益创业的理念中。MVP告诉我们要尽快将“最小可行”的产品推向用户,来验证我们的想法。这种方法有诸多的成功案例,也因此受人追捧,人们开始广泛的讨论如何“做减法”并尽快交付。

不得不说,这样做好处多多。但这也导致的一个负面影响,就是我们开始完全站在需求的角度,随需求变化而变化,却忽略了技术研发本身带有的刚性工作量。这与先前的“功能视角”站在了两个极端:前者是见招拆招、各个击破;后者则是兵来将挡,以一敌百。既然是极端,不论哪种,都会有鲜明的优缺点,令人难以抉择。这不由得让我想起一个题外话:高考报志愿,究竟是报自己喜欢的专业,还是报热门专业呢?

由此可见,MVP不仅是一种产品层面的思维,它需要有架构的基础支持,就像持续交付需要有持续集成来支持。我们既需要从技术的层面做到应用的层面来形成闭环,又需要保证各个环节之间的松耦合,以应对不同的变化。如果缺少了这一点的考虑,特别是对于平台型的产品,将会是致命的缺陷。

换句话说,当面临多样性需求的时候(就平台型的产品),MVP是逻辑上的各个击破,而非逐个处理需求。这与面向终端用户的应用型产品具有很大差别。

举个具体的例子吧,未必准确:

e5e559d07ca64f8b8c62a414e07c9919.png

缺少架构支持的项目进度

当我们从需求出发,能够保证我们现有的需求接近令人满意的程度。但紧接着,更多的需求会接踵而至。由于缺少基础功能的支持,这些新需求的初始完成度就非常低(比如10%),再加上数量庞大,拉低了整体项目的完成度。由此,虽然我们在两个需求上做得出色,却会因为31.25%的整体进度而备受指责。

d086bc9a969140c5bc4bd6d5d7867280.png

保证架构支持的项目进度

但如果我们将松耦合的架构作为重点之一,确保模块之间的协议稳定性,并花更多时间,以不一样的模块切分方式来各个击破。虽然我们在每个需求上都没有太多亮点,但却能坐拥51.88%整体进度。并且每个新需求,都能从更高(假设50%)的初始完成度开始。

所以,回到最开始的问题,我们是养马还是做汽车呢?或许,我们应该设计更通用的车身、轮子和传动装置,管它是马还是汽油引擎。

What's more, my 数据思维 is coming soon.

作者:御豪

关键字:产品经理, MVP

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部