V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lulu7
V2EX  ›  程序员

昨天引发了一场有关 MVP(最小可行性产品)大战,到底哪种是对的?

  •  3
     
  •   lulu7 · 2021-06-18 09:57:26 +08:00 · 2997 次点击
    这是一个创建于 1014 天前的主题,其中的信息可能已经有所发展或是发生改变。

    关于敏捷 MVP 的示例图,到底哪个是对的,有没有大佬指点下?搜集国内外的资料上面的说法也都不统一。不会发图,就发个位置吧: https://www.zentao.net/redirect-index-19134.html

    目前争论的有两个角度,一个是从功能上看,一个是从原型杜绝浪费角度看。在做相关内容,求高人指点。

    30 条回复    2021-06-20 09:33:57 +08:00
    lulu7
        1
    lulu7  
    OP
       2021-06-18 10:08:42 +08:00
    搬过来一些观点:
    1 、从功能角度看,忽略图形,赞成图 1 。作为一个代步工具,首先是能跑起来,然后在跑的基础上迭代增加其他功能,比如能坐人、解放人力、遮风挡雨等,最后形成一个完美并符合市场需求的产品。

    2 、我觉得图 2 是对的,因为在一个项目中,虽然途中会有需求的一些变化,但是大的目标在一开始的时候是确定的,所以应该在这个大目标的前提下去做 MVP 。而图 1 虽然形象地表述出了最小可行产品,但是步骤 1 和步骤 2 、3 、4 之间并不是在前一个迭代的基础上再进行功能扩充的过程,这就会导致每个迭代间产生很多浪费。
    libook
        2
    libook  
       2021-06-18 10:16:06 +08:00   ❤️ 1
    判断是不是 MVP,需要更多的信息,只看图来判断 MVP 就好比我不告诉你场景然后问是 PHP 好还是 C#好。

    MVP 的目的也很重要,通常 MVP 是用于最小成本验证最大假设的。比如想验证某文案是否可以提升客户购买意愿,那么 MVP 可以只包含放文案+购买功能,然后用不同的文案做 AB 测试,此时如果方案来还涉及到购买送贴纸、用户评论等功能,虽然可以锦上添花,但与想验证的问题没有任何关系,所以不应加入到 MVP 方案里。但如果希望验证的问题是购买送贴纸是否能够增加用户购买意愿,那就是另一个 story 了。

    回到两张图,一个的目的可能是对于要不要轮子做假设,所以 MVP 只要有轮子就行,无所谓数量和大小;另一个的目的可能是对于要不要驾驶室做假设,所以 MVP 方案只要有驾驶室就行。对于不同的验证目的,各自都可能是合理的 MVP 。
    fov6363
        3
    fov6363  
       2021-06-18 10:48:25 +08:00   ❤️ 1
    图 1 的 3 - 4 之间插入 图 2 的 1 、2 、3
    levelworm
        4
    levelworm  
       2021-06-18 11:19:28 +08:00 via Android
    图 2 。我们公司的 MVP 基本上核心不会有什么变动了。换句话说都是汽车,只不过可能前面是货车,后头看看不对改成运客的。
    janxin
        5
    janxin  
       2021-06-18 11:26:12 +08:00
    没有对应的背景很难评价,主要是缺少背景评价:

    1. 如果需求是单人代步工具,那么 1 并没有什么问题,升级多人代步工具是场景的拓展和规划;
    2. 如果需求是多人代步工具,那么 1 最开始就没有完成 MVP ;
    yunye
        6
    yunye  
       2021-06-18 11:36:28 +08:00
    图 2
    ericls
        7
    ericls  
       2021-06-18 11:39:25 +08:00 via iPhone
    先看问题 再看答案
    这种需要预测未来的问题 基本上没有正确答案 也没有错误答案 你能做的 只有验证 只有控制风险
    yufeng0681
        8
    yufeng0681  
       2021-06-18 11:40:50 +08:00   ❤️ 1
    你的经历决定了你认为 图 1 或者图 2 正确,或者图 1 图 2 都正确
    只要是比喻就有失真的地方,一个故事也很难把各种场景都囊括,只能看其主要意思,而不要太挑剔
    图 1 分析:
    主要表达功能够用就好。逐步满足客户日益增长的诉求。
    客户是中小学生,滑板车肯定就是失败的,白做了;
    客户是幼儿园小朋友,滑板车很合适 [够用的功能,就是好的 MVP]

    图 2 分析:
    最终目标清晰,分阶段实现。把最终目标能跑起来的部分先做好,其他非核心功能在迭代开发。 这样可以用更少的人交付完毕。
    图 2.1 客户是没法用的,只是能跑起来,能测试起来,让测试人员动起来;
    图 2.2 我认为是错误的,相当于设计了一个皮卡,最后改成了轿车,这个属于目标不明确;
    图 2.3 2.4 就是在过程中调整,在可用性方面的改造,没有对底层改动,最终客户的使用场景没有变化
    ericls
        9
    ericls  
       2021-06-18 11:41:03 +08:00 via iPhone
    你们玩儿的是的凭空想象的游戏
    LANB0
        10
    LANB0  
       2021-06-18 12:16:54 +08:00
    首先要明确定义什么是最小,如楼上所说,如果一开始就是要开发汽车,你最小可运行版本搞了个自行车,那显然是需求分析有误
    no1xsyzy
        11
    no1xsyzy  
       2021-06-18 12:36:10 +08:00
    @libook 确实,我花了 750 万年得出答案是 42
    可我不知道问题是什么。
    onion83
        12
    onion83  
       2021-06-18 12:41:12 +08:00
    图 1 是重写
    图 2 是重构
    Vegetable
        13
    Vegetable  
       2021-06-18 12:44:34 +08:00
    图一体现「改造+升级」,图二体现了「纯升级」。哪个都不能算错吧
    xuanbg
        14
    xuanbg  
       2021-06-18 13:05:35 +08:00
    只要内在逻辑完备,能够形成闭环。就是 MVP
    xuanbg
        15
    xuanbg  
       2021-06-18 13:18:10 +08:00
    在真实场景中,既不是图 1 也不是图 2 。一般情况下大家都认同正确的做法是先搞出来自行车。然后一派要升级成摩托车,另一派要开始造轿车。两派经过血腥的政治斗争,如果保守派获胜,就开始升级摩托车的工程,激进派获胜则展开造轿车的工程。

    一开始就为造滑板车还是汽车而争吵不休的团队,没有不扑街的。
    peakmonkey
        16
    peakmonkey  
       2021-06-18 15:31:12 +08:00
    在尝试走图一的路,https://memfiredb.com

    目前满足最原始需求,后面还有很多天花乱坠的想法,人少只能慢慢撸。

    资源有限,现在还需要码才能注册,大佬们轻拍:2KPLjZ 2KqFX3 2KPXBS 2KPHne 2KQnKv

    @xuanbg 希望不会扑街☺
    SaltyLeo
        17
    SaltyLeo  
       2021-06-18 15:43:14 +08:00
    @peakmonkey 首页看起来似乎还挺有趣的,但要手机号注册就没什么兴趣了。
    keivenliao
        18
    keivenliao  
       2021-06-18 15:52:38 +08:00
    我的理解。
    图一,为了什么而作
    图二,为了做什么
    所以,目的是什么很重要,图一明显是偏向业务的, 为载人这个业务服务,目的是要做一个能载人的工具。业务越来越复杂,工具自然也就越来越复杂。

    图二显然是产品导向的,要做一个产品,硬件也好,软件也罢,方向是确定的,围绕这个产品逐步迭代升级。

    另外,
    1 、图一是战略的,可能长期来说战略方针会发生变化,但某个明确的战略阶段内,套用图二。
    2 、图二建立在有明确的业务逻辑,明确的架构设计的情况下。
    peakmonkey
        19
    peakmonkey  
       2021-06-18 15:54:11 +08:00
    @SaltyLeo 前两天被 v 站大佬们刚喷过,连夜把首页做出来,辛苦了我们前端的兄弟
    SaltyLeo
        20
    SaltyLeo  
       2021-06-18 16:06:09 +08:00
    @SaltyLeo 加油💪,理解国内服务商需要实名认证的硬性规定。但如果要做大做强,希望能够允许境外手机号注册和敏感操作 2FA 认证。
    freakxx
        21
    freakxx  
       2021-06-18 16:32:02 +08:00
    这个问题(图)是不明确的。
    按 MVP 来说,两种都是对的。
    如果错的话,或者比较的话,只能说是实现中的侧重点问题。

    只有明确 P 是什么,才能选择哪个是“对”的。


    如果直观理解,
    图 1 是侧重功能的实现;
    比如假如产品是支付
    那么类比过程就是
    线下支付 - 汇款验证 - 第三方转账支付 这样的升级路线;

    图 2 是侧重功能的完善;
    比如假如产品是支付
    那么类比过程就是
    密码验证支付 - 指纹支付 - 扫脸支付 这样的升级路线;


    换句话说,主要矛盾和矛盾的主要方面,是两个不同层面的东西;
    lldld
        22
    lldld  
       2021-06-18 16:41:41 +08:00
    MVP 是为了验证产品核心需求, 是否是用户需要的, 是否可行.

    站在未来看现在, 才知道现在做的 MVP 是否浪费. 我觉得 MVP 应该是从功能的角度来看.

    但是图 1 没有说服力. 这里罗列的产品并不是演化的关系, 它们都是满足不同场景的用户需求.
    lldld
        23
    lldld  
       2021-06-18 16:45:16 +08:00
    可以用摩拜单车到现在的美团单车的每一代产品的图片来做例子. 比上面的图 1 图 2 好的多.
    bnm965321
        24
    bnm965321  
       2021-06-18 16:50:02 +08:00
    塞尔达的 prototype 是一个 2D 的游戏
    jluyf
        25
    jluyf  
       2021-06-18 17:10:56 +08:00
    从 PM 角度来看,一般立项初期对项目采用结构化分析的办法会采用图 2 的进程,采用对象分析的项目目标会使用图 1 。
    考虑成本和效率的话,对 MVP 的最佳解释应该是图 1
    kop1989
        26
    kop1989  
       2021-06-18 17:17:50 +08:00
    首先,图 1 与图 2 之间是决策问题,不是对错问题。
    你说滋水枪和核弹那个是对哪个是错?

    如果脱离实际应用,只说狭义上的快速迭代、敏捷开发,必然是图 1 。
    只不过现实上来讲图 2 相对较多。虽然图 2 的场景并不是原教旨主义的敏捷开发,但图二相对而言成本更低,成功率更高,项目也更可控。
    chairuosen
        27
    chairuosen  
       2021-06-18 17:24:17 +08:00   ❤️ 1
    图 2 是穿越回来的人发明汽车的步骤
    mringg
        28
    mringg  
       2021-06-18 17:29:53 +08:00
    没有对和错吧,主要看目的。目的是想做“交通工具”呢,还是做“汽车”
    Jooooooooo
        29
    Jooooooooo  
       2021-06-18 17:32:41 +08:00
    当然是 1 啊

    快速验证产品可行性, 跑起来不需要汽车

    或者我举个例子, 最早外卖的下单模式是消费者下单, 这边运营人员手动打电话给商家下单, 商家再做餐. 这里验证消费者真的有外卖的需求并且整个链条是可以跑通的.
    ho121
        30
    ho121  
       2021-06-20 09:33:57 +08:00 via Android
    看目标,
    目标是单纯的交通运输,则为图一。
    目标是造一个汽车,则为图二
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3503 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 11:06 · PVG 19:06 · LAX 04:06 · JFK 07:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.