关于MVP最小闭环

MVP最小闭环

MVP之所以能成为最小闭环，一定是经过化繁为简的过程。繁，是在每个流程上穷举过无数种可能，要达到这个效果，又需要查阅大量信息，咨询大量专业人士。简，是经过分析每种可能的利弊，最后不断删减得出的结果。我们当然要考虑完成闭环所需的时间，只是比时间更重要的因素是，删减后的结果是你要的业务最小闭环吗？

只看皮相，不究内里，终会活成糊涂人。

以下内容均为参考链接处文章，学习后整理的，作为个人学习笔记。
如有兴趣，可直接查看参考链接原文。侵删！

文章目录

这个最小闭环是炎大神提到的高级的东东。在关于思维啥的文章中略带提到了这个。

感觉是个好东东，需要单独好好研究一下。

以下内容，只是为了了解什么是MVP，以及使用它的栗子，由于这东东的说法版本很多，毕竟这是一种思维模式，在不同职业，不同需求，不同的人 得出的结果也都不一样，这里做个整理，与我个人的看法。

什么是MVP

百度：Minimum Viable Product – 最简化可实行产品。 MVP是一种产品理论，这个概念听起来复杂，不过你可以把它想像成是一部电影的剧情大纲，或是一部漫画的角色介绍。它的重点就是制作的成本要极低，但是却能展示最终产品的主要特色。

MVP：通过轻度的开发投入（最小的人力和资金），先验证市场，以最小的代价去试错，根据用户反映实时调整。

img

"最小"：就是投入足够小，成本足够低

"可行"：再小的试错方式，都要保证走完最小的业务流程，在一个小的场景下，形成小闭环。

误解的地方

在一些实操过程中， 最小化产品的定义没有被正确理解 ——很多人只是把它当成一个时髦词，或者直接曲解成是产品上线的1.0版本。

MVP就是边验证边学习，它应该完全以用户问题为中心，而不是以解决方案为中心。 因为用户不关心你的解决方案，就算你的方案有趣又好玩，与他也不直接相关。所以首先我们要明确“MVP”的定义。

所谓最小化可用产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。

这里最为重要的点在于了解和验证,而非其他，甚至这个产品本身就只是个假的页面。

即使是MVP，也是有成本的，不代表没有成本，只是比较小而已，但是累计多了，也是不小的成本。

但是有时候，市场可能不会有太多的时间给你去试错，窗口期可能很短，这就是商业现实的残酷性。
也是很多时候，对于需求主导的项目无法使用MVP的很大原因。

栗子1

假设你需要寄一百封信，每一份信都需要写地址、贴邮票、装信、缝合，怎么做是最快的。你或许想到拆分流程，先写好一百个地址，再贴一百张邮票，以此类推。这样的效率的确很快，但要我说，以贴完一封再贴另一封，这样的速度是最快的。为什么呢？

因为你拥有最及时的反馈，一旦有问题，你可以立马察觉，立马纠正，而如果你采取拆分流程的方法，当你最后一步缝合信封的时候才发现邮票贴错了，那就等于一百封信都错了，于是得重来，那将是一场噩梦。

以一封信为最小单位，而不是拆分流程，及时找到问题，及时解决，这就是最小闭环。

MVP中的核心：反馈循环

MVP作为最小可行的版本，是为了以最小的代价去试错，并边验证边学习，然后快速迭代。而这些所依赖的则就是反馈循环。

img

就像这个样子，【构建：开发，创建项目，测量：用户使用情况等，学习：迭代调整更新项目】“开发MVP-通过用户验证”是创造好产品的第一步。接下来就是用“构建-测量-学习”的方式，在限量测试或者正式运营中，对产品进行循环迭代。

作为产品的创造者，你可以是骄傲的、品位非凡的、目光长远的，但请不要忘记，在产品的成长旅程中，你的用户始终是旅程的重要部分。没有人用的话，弄的好也是个垃圾╮(╯_╰)╭

可以类比一下，程序员最快的学习方式是什么：coding。就是试错，反馈，调整，试错。。。
【由于代码运行是及时反馈的，这一次循环的时间非常的少。所以可以在很短的时间高速迭代，学习效率那是灰常的高的 [](￣▽￣)* 】

栗子2

假设你现在创业，你的产品目标是——有史以来最好的甜甜圈！

产品团队用最快的速度干了一张原型图，程序工程师快速吐出一团代码，编译工程师把原型图和代码揉成面团扔进锅里炸熟，开发出了一套味道普通的甜甜圈——这就是你们第一个最小化可用产品。能吃，能用 （谜之作用） ，但可能还不是有史以来最好的甜甜圈。这时候，你的产品团队就要抓紧时间，问用户一些问题。比如说：

你们觉得这款甜甜圈哪最好？
如果你可以选择加配料，你会加哪些？
你喜欢什么甜甜圈造型？切开的还是一体的？金黄炸透的还是脆嫩相间的？

……

有了这些通过种子用户得到的验证结果，产品团队精神大振，立马操刀做了一套更好的甜甜圈。根据用户的反馈，产品团队总结出了不少实施细节：

在一些特定情况下，用户会喜欢加一些七彩糖珠；
一些特定的市场和特定的用户更喜欢巧克力甜甜圈；
如果是海外用户，他们可能更喜欢草莓甜甜圈。

栗子3：

比如说，有一个手电筒工具软件，第一版做出来就需要实现：能快速打开，能亮。解决了基本的需求，这个思路不就是MVP吗？用户有需求的时候，第一反应是先实现我这个需求，使用了之后，才发现，这个电灯不能调节亮度啊，于是手电筒工具的开发者就增加了调节亮度的功能，然后不断的迭代，最终变为一个万能手电筒。

如果不采用MVP的设计思想，产品经理，不可能只是凭脑子就做出来一个万能手电筒。好的软件，不都是靠产品设计+用户反馈才累积出来的吗？

必要性分析

知乎的提问：
这几年，MVP（最小可行化产品）在互联网产品界，似乎被奉为经典。
但我之所以这么提问，是因为突然想起两位名人的话：
乔布斯：用户根本不知道自己要什么。
亨利福特：如果我最初问消费者他们想要什么，他们会告诉我要一匹更快的马，而不是汽车。

所以，如果是一个全新的产品，用户其实并不知道自己要的是什么，就算原本产品理念很出色，但MVP作为一个不成熟的产品，冒然呈现给消费者，可能带来的数据反馈是极其不理想的。
那MVP还有意义吗？我们真的需要去做MVP吗？

如果是以全新的产品进行分析的话，用户不了解自己的需求点的情况下。要考虑的就不是这个产品是否成熟，而是控制成本和控制风险啊！！！

是必须要做MVP。否则你准备一开始就把产品做到10.0再上线么？产品都是不断堆砌不断优化而来的，罗马不是一天建成的。

MVP 肯定不是必要的，不乏有大量商业在早期并没有什么 MVP。

但 MVP 绝对是成本与风险控制的最佳手段。

做一年才发现这个产品满足不了用户的需求，或者市场需求量很小，这是早期产品绝对存在的风险。推倒重来重新做，又要花费很多时间和金钱，这是成本。

想不犯错，要么运气很好，要么只能通过科学的方式来规避错误，提前发现道路上的陷阱。

MVP与完整项目对比

完整项目：

  • 试错的成本高【全功能开发消耗太多，周期太长，一旦出差错，就没法回头，补救代价大】
  • 试错的周期长【无法更快的跟上市场的变化】

MVP：

  • 成本低，周期短。甚至不一定要立项开发。
  • 你并不一定真正懂用户的需求，很多时候，只是“你以为”罢了。
  • 你并不知道市场的大小和未来走向。
  • 验证的的目标要明确，不一定非得是实际的开发产品。

栗子4：

以一个简单的资讯客户端App作为案例，大体来做个时间成本评估吧。

第一阶段：需求初步确定。 至少3天

第二阶段：从需求到产品原型 原型图，改几次，5天

第三阶段：产品原型到UI设计稿 UI确定风格，设计，调整，定稿 7天

第四阶段：从设计稿到能跑起来的程序 前端后端服务器，框架设计，第一版本，测试，修改，文档。最快一个月。不改需求的情况。

总体投入：

1.最少10万左右的钱

2.半年以上的时间

如果这个时候，产品投入到市场，发现效果不好，不是用户需要的，或者需要的用户很少，那么问题就大了。

这个APP如果是做MVP，小杭我个人的想法：

  • 确定核心需求内容
  • 已H5的形式直接制作demo，甚至只是贴图【与产品，设计一同】
  • 已H5APP的形式发布，内容甚至都是静态随机或公共数据接口的。
  • 看看下载使用的情况。

以上的情况所花费的时间，人力等成本都是不高的。

之后H5的内容转向小程序端进行开发，APP后续验证项目成立再开始开发。

栗子4，的完整开发的花费是很高的。辣么MVP呢？以上我个人的想法还是很片面的，毕竟作为程序员我也只能想到这么多了 ε=(´ο｀*)))唉

栗子5：

看看就好，这个我也看不懂

典型代表为生产销售集一体的企业，其进销存的基本业务流程，主要表现为物料的采购（进）—>入库（存）—>领料加工—>产品入库（存）—>销售（销）的动态过程。

这两种类型，基本可囊括现阶段各种企业类型的进销存产品的业务流程，但私以为仍不够简洁。细心对比业务流程，两者是具有共性通用的流程，在对物料加工的流程归纳到库存管理当中后，即可再度简化为「进-存-销」流程（见图）。

img

本业务流程图，适用且通用于任何企业一，甚至是周边的一家超市，一家夫妻店。

完整的进销存产品功能模块，一般涉及基础数据和业务数据两大方面的数据结构，涵括采购，库存（含生产加工），销售，结算在内的四大模块的业务流程化定制，解决供应链的问题。

img

看看图就可以了，对比一下，意思一下就可以了的。

辣么，下面看看常用的MVP方法吧，应该可以比较容易看出来，成本差在哪里了。

MVP的方法

重点：不一定非得是实际的开发产品

这些大多是产品方向的MVP，作为程序员，做个DEMO，做个静态页面试试，做个假的app啥的才是我们的MVP

作为程序员对项目的看法；
【不做为产品方向的观点】

【X】表示我认为不适用的方法
【√】表示我认为推荐使用的方法

1.问身边的人 【X】

准备好问题，询问身边的人，看是否有需求。如果有30个以上的人，有需求，那么就可以考虑进行下一步的产品试验工作。样本量不能太少，一两个人的需求，容易蒙蔽我们的眼睛。

2.A/B测试【√】

在产品方向不明确的时候，可以做两个甚至多个分支出来，让部分用户选择体验，也就是灰度测试。然后分析数据，做出决策。

3.众筹网站 【X】

利用众筹网，国内像京东众筹、淘宝众筹等，将自己的想法和思路，放在网站上，有没有人给你砸钱，就知道有没有需求了。

4.功能入口【√】

在现有的功能页面里面，增加一个并未开发的功能，但是提供一个入口。然后统计用户点击的比例，进行分析判断。当然，点击的时候，给用户一个友好的提示，也是很有必要的。

**5.微信公众号、博客等社交媒体 **【X】

利用公众号、博客等，写明自己的想法，收集用户的反馈。不过前提是，你已经有一定的流量了。否则样本用户太少，可能没有什么效果，达不到目标。

6.做个Demo 【√】

自己做个小Demo，尤其是有编程能力的人，是一个不错的方式。如果不具备开发能力，可以画出设计稿，不开发成产品。只需要在手机或者电脑上，能演示，能让人大体了解和体验，也是可以的。关键是收集用户反馈。

7.问卷调查 【X】

可以用问卷的形式，电子的或者纸质的都行，让用户做选择，然后根据数据，进行进一步的工作。

8.视频 【X】

如果你善于做视频，可以将产品的预期功能或者想法做成视频，然后放到视频网站上或者网站上，看有没有人跟你互动，有没有足够的浏览量，有没有人过来注册你的网站。

另外需要注意的地方：

真实性：获取到的反馈信息，必须是真实的。

有反馈：一个方案，一定要有反馈指标。

样本量：采集的样本要到一定量级，否则仅仅一两个人的需求，未必能形成市场，支撑起一家公司。当然样本是越多越好，自己根据实际情况做确定。

栗子6：

https://www.zhihu.com/question/315980175/answer/627932464 有哪些MVP案例（产品开发最小化）？ 灰常有借鉴价值 ，做个假的产品，收工后续操作就行了 哈哈啊啊

栗子7：

再举些最小闭环的例子。我不喜欢看长篇小说，因为太长了，看一部小说得花一个星期甚至更久，但我却很喜欢看短片或者几百字的文章，因为几分钟内就可以看完，看完还能有收获。再比如，最近抖音很火，其中一个原因是，抖音具有最小闭环的特性，它不像电视据那样冗长，内容也通俗易懂，你可以在短短几秒钟得到满足。

最小闭环的特点是：时间短，反馈快。这对于长期学习来说是不利的，因为有时人的进步很缓慢，缓慢到自己怀疑自己的付出。 【这不是跟写代码一样吗 哈哈哈哈 超级及时的反馈】

最后想法

MVP，学习最小闭环，项目最小闭环，好像还有个认知最小闭环的样子【太高级，延后学习】。

可以用到很多的地方，无论是哪个行业，职位，都可以学习一下。作为控制陈本，控制风险，提高效率等还是有很大帮助的！！！！！！

项目MVP方面，小公司可能会遇到的情况是：需求，反馈，成本，都不是产品经理决定的，这就很尴尬了 .

而作为普通的程序员，好像，额。。。。没有啥是我能决定的。 (╯‵□′)╯︵┻━┻

ε=(´ο｀*)))唉

资料

2020-02-29 小杭

posted @ 2022-05-21 23:31  小-杭  阅读(498)  评论(0)  编辑  收藏  举报