3
昨天引发了一场有关 MVP（最小可行性产品）大战，到底哪种是对的？
source link: https://www.v2ex.com/t/784144
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
关于敏捷 MVP 的示例图，到底哪个是对的，有没有大佬指点下？搜集国内外的资料上面的说法也都不统一。不会发图，就发个位置吧： https://www.zentao.net/redirect-index-19134.html
目前争论的有两个角度，一个是从功能上看，一个是从原型杜绝浪费角度看。在做相关内容，求高人指点。
29 条回复 • 2021-06-18 17:32:41 +08:00
lulu7 1 天前
搬过来一些观点：
1 、从功能角度看，忽略图形，赞成图 1 。作为一个代步工具，首先是能跑起来，然后在跑的基础上迭代增加其他功能，比如能坐人、解放人力、遮风挡雨等，最后形成一个完美并符合市场需求的产品。
2 、我觉得图 2 是对的，因为在一个项目中，虽然途中会有需求的一些变化，但是大的目标在一开始的时候是确定的，所以应该在这个大目标的前提下去做 MVP 。而图 1 虽然形象地表述出了最小可行产品，但是步骤 1 和步骤 2 、3 、4 之间并不是在前一个迭代的基础上再进行功能扩充的过程，这就会导致每个迭代间产生很多浪费。
1 、从功能角度看，忽略图形，赞成图 1 。作为一个代步工具，首先是能跑起来，然后在跑的基础上迭代增加其他功能，比如能坐人、解放人力、遮风挡雨等，最后形成一个完美并符合市场需求的产品。
2 、我觉得图 2 是对的，因为在一个项目中，虽然途中会有需求的一些变化，但是大的目标在一开始的时候是确定的，所以应该在这个大目标的前提下去做 MVP 。而图 1 虽然形象地表述出了最小可行产品，但是步骤 1 和步骤 2 、3 、4 之间并不是在前一个迭代的基础上再进行功能扩充的过程，这就会导致每个迭代间产生很多浪费。
libook 1 天前 
1
判断是不是 MVP，需要更多的信息，只看图来判断 MVP 就好比我不告诉你场景然后问是 PHP 好还是 C#好。
MVP 的目的也很重要，通常 MVP 是用于最小成本验证最大假设的。比如想验证某文案是否可以提升客户购买意愿，那么 MVP 可以只包含放文案+购买功能，然后用不同的文案做 AB 测试，此时如果方案来还涉及到购买送贴纸、用户评论等功能，虽然可以锦上添花，但与想验证的问题没有任何关系，所以不应加入到 MVP 方案里。但如果希望验证的问题是购买送贴纸是否能够增加用户购买意愿，那就是另一个 story 了。
回到两张图，一个的目的可能是对于要不要轮子做假设，所以 MVP 只要有轮子就行，无所谓数量和大小；另一个的目的可能是对于要不要驾驶室做假设，所以 MVP 方案只要有驾驶室就行。对于不同的验证目的，各自都可能是合理的 MVP 。
MVP 的目的也很重要，通常 MVP 是用于最小成本验证最大假设的。比如想验证某文案是否可以提升客户购买意愿，那么 MVP 可以只包含放文案+购买功能，然后用不同的文案做 AB 测试，此时如果方案来还涉及到购买送贴纸、用户评论等功能，虽然可以锦上添花，但与想验证的问题没有任何关系，所以不应加入到 MVP 方案里。但如果希望验证的问题是购买送贴纸是否能够增加用户购买意愿，那就是另一个 story 了。
回到两张图，一个的目的可能是对于要不要轮子做假设，所以 MVP 只要有轮子就行，无所谓数量和大小；另一个的目的可能是对于要不要驾驶室做假设，所以 MVP 方案只要有驾驶室就行。对于不同的验证目的，各自都可能是合理的 MVP 。
janxin 1 天前
没有对应的背景很难评价，主要是缺少背景评价：
1. 如果需求是单人代步工具，那么 1 并没有什么问题，升级多人代步工具是场景的拓展和规划；
2. 如果需求是多人代步工具，那么 1 最开始就没有完成 MVP ；
1. 如果需求是单人代步工具，那么 1 并没有什么问题，升级多人代步工具是场景的拓展和规划；
2. 如果需求是多人代步工具，那么 1 最开始就没有完成 MVP ；
yunye 1 天前
yufeng0681 1 天前
你的经历决定了你认为 图 1 或者图 2 正确，或者图 1 图 2 都正确
只要是比喻就有失真的地方，一个故事也很难把各种场景都囊括，只能看其主要意思，而不要太挑剔
图 1 分析：
主要表达功能够用就好。逐步满足客户日益增长的诉求。
客户是中小学生，滑板车肯定就是失败的，白做了；
客户是幼儿园小朋友，滑板车很合适 [够用的功能，就是好的 MVP]
图 2 分析：
最终目标清晰，分阶段实现。把最终目标能跑起来的部分先做好，其他非核心功能在迭代开发。 这样可以用更少的人交付完毕。
图 2.1 客户是没法用的，只是能跑起来，能测试起来，让测试人员动起来；
图 2.2 我认为是错误的，相当于设计了一个皮卡，最后改成了轿车，这个属于目标不明确；
图 2.3 2.4 就是在过程中调整，在可用性方面的改造，没有对底层改动，最终客户的使用场景没有变化
只要是比喻就有失真的地方，一个故事也很难把各种场景都囊括，只能看其主要意思，而不要太挑剔
图 1 分析：
主要表达功能够用就好。逐步满足客户日益增长的诉求。
客户是中小学生，滑板车肯定就是失败的，白做了；
客户是幼儿园小朋友，滑板车很合适 [够用的功能，就是好的 MVP]
图 2 分析：
最终目标清晰，分阶段实现。把最终目标能跑起来的部分先做好，其他非核心功能在迭代开发。 这样可以用更少的人交付完毕。
图 2.1 客户是没法用的，只是能跑起来，能测试起来，让测试人员动起来；
图 2.2 我认为是错误的，相当于设计了一个皮卡，最后改成了轿车，这个属于目标不明确；
图 2.3 2.4 就是在过程中调整，在可用性方面的改造，没有对底层改动，最终客户的使用场景没有变化
xuanbg 1 天前
在真实场景中，既不是图 1 也不是图 2 。一般情况下大家都认同正确的做法是先搞出来自行车。然后一派要升级成摩托车，另一派要开始造轿车。两派经过血腥的政治斗争，如果保守派获胜，就开始升级摩托车的工程，激进派获胜则展开造轿车的工程。
一开始就为造滑板车还是汽车而争吵不休的团队，没有不扑街的。
一开始就为造滑板车还是汽车而争吵不休的团队，没有不扑街的。
peakmonkey 1 天前
在尝试走图一的路，https://memfiredb.com
目前满足最原始需求，后面还有很多天花乱坠的想法，人少只能慢慢撸。
资源有限，现在还需要码才能注册，大佬们轻拍：2KPLjZ 2KqFX3 2KPXBS 2KPHne 2KQnKv
@xuanbg 希望不会扑街☺
目前满足最原始需求，后面还有很多天花乱坠的想法，人少只能慢慢撸。
资源有限，现在还需要码才能注册，大佬们轻拍：2KPLjZ 2KqFX3 2KPXBS 2KPHne 2KQnKv
@xuanbg 希望不会扑街☺
keivenliao 1 天前
我的理解。
图一，为了什么而作
图二，为了做什么
所以，目的是什么很重要，图一明显是偏向业务的， 为载人这个业务服务，目的是要做一个能载人的工具。业务越来越复杂，工具自然也就越来越复杂。
图二显然是产品导向的，要做一个产品，硬件也好，软件也罢，方向是确定的，围绕这个产品逐步迭代升级。
另外，
1 、图一是战略的，可能长期来说战略方针会发生变化，但某个明确的战略阶段内，套用图二。
2 、图二建立在有明确的业务逻辑，明确的架构设计的情况下。
图一，为了什么而作
图二，为了做什么
所以，目的是什么很重要，图一明显是偏向业务的， 为载人这个业务服务，目的是要做一个能载人的工具。业务越来越复杂，工具自然也就越来越复杂。
图二显然是产品导向的，要做一个产品，硬件也好，软件也罢，方向是确定的，围绕这个产品逐步迭代升级。
另外，
1 、图一是战略的，可能长期来说战略方针会发生变化，但某个明确的战略阶段内，套用图二。
2 、图二建立在有明确的业务逻辑，明确的架构设计的情况下。
freakxx 1 天前
这个问题（图）是不明确的。
按 MVP 来说，两种都是对的。
如果错的话，或者比较的话，只能说是实现中的侧重点问题。
只有明确 P 是什么，才能选择哪个是“对”的。
如果直观理解，
图 1 是侧重功能的实现；
比如假如产品是支付
那么类比过程就是
线下支付 - 汇款验证 - 第三方转账支付 这样的升级路线；
图 2 是侧重功能的完善；
比如假如产品是支付
那么类比过程就是
密码验证支付 - 指纹支付 - 扫脸支付 这样的升级路线；
换句话说，主要矛盾和矛盾的主要方面，是两个不同层面的东西；
按 MVP 来说，两种都是对的。
如果错的话，或者比较的话，只能说是实现中的侧重点问题。
只有明确 P 是什么，才能选择哪个是“对”的。
如果直观理解，
图 1 是侧重功能的实现；
比如假如产品是支付
那么类比过程就是
线下支付 - 汇款验证 - 第三方转账支付 这样的升级路线；
图 2 是侧重功能的完善；
比如假如产品是支付
那么类比过程就是
密码验证支付 - 指纹支付 - 扫脸支付 这样的升级路线；
换句话说，主要矛盾和矛盾的主要方面，是两个不同层面的东西；
lldld 1 天前
MVP 是为了验证产品核心需求, 是否是用户需要的, 是否可行.
站在未来看现在, 才知道现在做的 MVP 是否浪费. 我觉得 MVP 应该是从功能的角度来看.
但是图 1 没有说服力. 这里罗列的产品并不是演化的关系, 它们都是满足不同场景的用户需求.
站在未来看现在, 才知道现在做的 MVP 是否浪费. 我觉得 MVP 应该是从功能的角度来看.
但是图 1 没有说服力. 这里罗列的产品并不是演化的关系, 它们都是满足不同场景的用户需求.
kop1989 1 天前
首先，图 1 与图 2 之间是决策问题，不是对错问题。
你说滋水枪和核弹那个是对哪个是错？
如果脱离实际应用，只说狭义上的快速迭代、敏捷开发，必然是图 1 。
只不过现实上来讲图 2 相对较多。虽然图 2 的场景并不是原教旨主义的敏捷开发，但图二相对而言成本更低，成功率更高，项目也更可控。
你说滋水枪和核弹那个是对哪个是错？
如果脱离实际应用，只说狭义上的快速迭代、敏捷开发，必然是图 1 。
只不过现实上来讲图 2 相对较多。虽然图 2 的场景并不是原教旨主义的敏捷开发，但图二相对而言成本更低，成功率更高，项目也更可控。
Jooooooooo 1 天前
当然是 1 啊
快速验证产品可行性, 跑起来不需要汽车
或者我举个例子, 最早外卖的下单模式是消费者下单, 这边运营人员手动打电话给商家下单, 商家再做餐. 这里验证消费者真的有外卖的需求并且整个链条是可以跑通的.
快速验证产品可行性, 跑起来不需要汽车
或者我举个例子, 最早外卖的下单模式是消费者下单, 这边运营人员手动打电话给商家下单, 商家再做餐. 这里验证消费者真的有外卖的需求并且整个链条是可以跑通的.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK