昨天引发了一场有关 MVP（最小可行性产品）大战，到底哪种是对的？

• 主 資深大佬 : lulu7

  搬过来一些观点：
  1 、从功能角度看，忽略图形，赞成图 1 。作为一个代步工具，首先是能跑起来，然后在跑的基础上迭代增加其他功能，比如能坐人、解放人力、遮风挡雨等，最后形成一个完美并符合市场需求的产品。
  2 、我觉得图 2 是对的，因为在一个项目中，虽然途中会有需求的一些变化，但是大的目标在一开始的时候是确定的，所以应该在这个大目标的前提下去做 MVP 。而图 1 虽然形象地表述出了最小可行产品，但是步骤 1 和步骤 2 、3 、4 之间并不是在前一个迭代的基础上再进行功能扩充的过程，这就会导致每个迭代间产生很多浪费。

• 資深大佬 : libook

  判断是不是 MVP，需要更多的信息，只看图来判断 MVP 就好比我不告诉你场景然后问是 PHP 好还是 C#好。
  MVP 的目的也很重要，通常 MVP 是用于最小成本验证最大假设的。比如想验证某文案是否可以提升客户购买意愿，那么 MVP 可以只包含放文案+购买功能，然后用不同的文案做 AB 测试，此时如果方案来还涉及到购买送贴纸、用户评论等功能，虽然可以锦上添花，但与想验证的问题没有任何关系，所以不应加入到 MVP 方案里。但如果希望验证的问题是购买送贴纸是否能够增加用户购买意愿，那就是另一个 story 了。
  回到两张图，一个的目的可能是对于要不要轮子做假设，所以 MVP 只要有轮子就行，无所谓数量和大小；另一个的目的可能是对于要不要驾驶室做假设，所以 MVP 方案只要有驾驶室就行。对于不同的验证目的，各自都可能是合理的 MVP 。

• 資深大佬 : fov6363

  图 1 的 3 – 4 之间插入 图 2 的 1 、2 、3

• 資深大佬 : levelworm

  图 2 。我们公司的 MVP 基本上核心不会有什么变动了。换句话说都是汽车，只不过可能前面是货车，后头看看不对改成运客的。

• 資深大佬 : janxin

  没有对应的背景很难评价，主要是缺少背景评价：
  1. 如果需求是单人代步工具，那么 1 并没有什么问题，升级多人代步工具是场景的拓展和规划；
  2. 如果需求是多人代步工具，那么 1 最开始就没有完成 MVP ；

• 資深大佬 : yunye

  图 2

• 資深大佬 : ericls

  先看问题 再看答案
  这种需要预测未来的问题 基本上没有正确答案 也没有错误答案 你能做的 只有验证 只有控制风险

• 資深大佬 : yufeng0681

  你的经历决定了你认为 图 1 或者图 2 正确，或者图 1 图 2 都正确
  只要是比喻就有失真的地方，一个故事也很难把各种场景都囊括，只能看其主要意思，而不要太挑剔
  图 1 分析：
  主要表达功能够用就好。逐步满足客户日益增长的诉求。
  客户是中小学生，滑板车肯定就是失败的，白做了；
  客户是幼儿园小朋友，滑板车很合适 [够用的功能，就是好的 MVP]
  图 2 分析：
  最终目标清晰，分阶段实现。把最终目标能跑起来的部分先做好，其他非核心功能在迭代开发。 这样可以用更少的人交付完毕。
  图 2.1 客户是没法用的，只是能跑起来，能测试起来，让测试人员动起来；
  图 2.2 我认为是错误的，相当于设计了一个皮卡，最后改成了轿车，这个属于目标不明确；
  图 2.3 2.4 就是在过程中调整，在可用性方面的改造，没有对底层改动，最终客户的使用场景没有变化

• 資深大佬 : ericls

  你们玩儿的是的凭空想象的游戏

• 資深大佬 : LANB0

  首先要明确定义什么是最小，如上所说，如果一开始就是要开发汽车，你最小可运行版本搞了个自行车，那显然是需求分析有误

• 資深大佬 : no1xsyzy

  @libook 确实，我花了 750 万年得出答案是 42
  可我不知道问题是什么。

• 資深大佬 : onion83

  图 1 是重写
  图 2 是重构

• 資深大佬 : Vegetable

  图一体现「改造+升级」，图二体现了「纯升级」。哪个都不能算错吧

• 資深大佬 : xuanbg

  只要内在逻辑完备，能够形成闭环。就是 MVP

• 資深大佬 : xuanbg

  在真实场景中，既不是图 1 也不是图 2 。一般情况下大家都认同正确的做法是先搞出来自行车。然后一派要升级成摩托车，另一派要开始造轿车。两派经过血腥的政治斗争，如果保守派获胜，就开始升级摩托车的工程，激进派获胜则展开造轿车的工程。
  一开始就为造滑板车还是汽车而争吵不休的团队，没有不扑街的。

• 資深大佬 : peakmonkey

  在尝试走图一的路，https://memfiredb.com
  目前满足最原始需求，后面还有很多天花乱坠的想法，人少只能慢慢撸。
  资源有限，现在还需要码才能注册，大佬们轻拍：2KPLjZ 2KqFX3 2KPXBS 2KPHne 2KQnKv
  @xuanbg 希望不会扑街☺

• 資深大佬 : SaltyLeo

  @peakmonkey 首页看起来似乎还挺有趣的，但要手机号注册就没什么兴趣了。

• 資深大佬 : keivenliao

  我的理解。
  图一，为了什么而作
  图二，为了做什么
  所以，目的是什么很重要，图一明显是偏向业务的， 为载人这个业务服务，目的是要做一个能载人的工具。业务越来越复杂，工具自然也就越来越复杂。
  图二显然是产品导向的，要做一个产品，硬件也好，软件也罢，方向是确定的，围绕这个产品逐步迭代升级。
  另外，
  1 、图一是战略的，可能长期来说战略方针会发生变化，但某个明确的战略阶段内，套用图二。
  2 、图二建立在有明确的业务逻辑，明确的架构设计的情况下。

• 資深大佬 : peakmonkey

  @SaltyLeo 前两天被 v 站大佬们刚喷过，连夜把首页做出来，辛苦了我们前端的兄弟

• 資深大佬 : SaltyLeo

  @SaltyLeo 加油

• 資深大佬 : freakxx

  这个问题（图）是不明确的。
  按 MVP 来说，两种都是对的。
  如果错的话，或者比较的话，只能说是实现中的侧重点问题。
  只有明确 P 是什么，才能选择哪个是“对”的。
  如果直观理解，
  图 1 是侧重功能的实现；
  比如假如产品是支付
  那么类比过程就是
  线下支付 – 汇款验证 – 第三方转账支付 这样的升级路线；
  图 2 是侧重功能的完善；
  比如假如产品是支付
  那么类比过程就是
  密码验证支付 – 指纹支付 – 扫脸支付 这样的升级路线；
  换句话说，主要矛盾和矛盾的主要方面，是两个不同层面的东西；

• 資深大佬 : lldld

  MVP 是为了验证产品核心需求, 是否是用户需要的, 是否可行.
  站在未来看现在, 才知道现在做的 MVP 是否浪费. 我觉得 MVP 应该是从功能的角度来看.
  但是图 1 没有说服力. 这里罗列的产品并不是演化的关系, 它们都是满足不同场景的用户需求.

• 資深大佬 : lldld

  可以用摩拜单车到现在的美团单车的每一代产品的图片来做例子. 比上面的图 1 图 2 好的多.

• 資深大佬 : bnm965321

  塞尔达的 prototype 是一个 2D 的游戏

• 資深大佬 : jluyf

  从 PM 角度来看，一般立项初期对项目采用结构化分析的办法会采用图 2 的进程，采用对象分析的项目目标会使用图 1 。
  考虑成本和效率的话，对 MVP 的最佳解释应该是图 1

• 資深大佬 : kop1989

  首先，图 1 与图 2 之间是决策问题，不是对错问题。
  你说滋水枪和核弹那个是对哪个是错？
  如果脱离实际应用，只说狭义上的快速迭代、敏捷开发，必然是图 1 。
  只不过现实上来讲图 2 相对较多。虽然图 2 的场景并不是原教旨主义的敏捷开发，但图二相对而言成本更低，成功率更高，项目也更可控。

• 資深大佬 : chairuosen

  图 2 是穿越回来的人发明汽车的步骤

• 資深大佬 : mringg

  没有对和错吧，主要看目的。目的是想做“交通工具”呢，还是做“汽车”

• 資深大佬 : Jooooooooo

  当然是 1 啊
  快速验证产品可行性, 跑起来不需要汽车
  或者我举个例子, 最早外卖的下单模式是消费者下单, 这边运营人员手动打电话给商家下单, 商家再做餐. 这里验证消费者真的有外卖的需求并且整个链条是可以跑通的.

• 資深大佬 : ho121

  看目标，
  目标是单纯的交通运输，则为图一。
  目标是造一个汽车，则为图二