前言
大家好，我是大S 。
熟悉的朋友一定都知道，我算是一个相当务实的作者。一般来讲，我的文章都会针对某一个细节展开，讲清、讲透。
同时，我在某一个时间段里，都特别讨厌务虚，讨厌老领导之前每天挂在嘴边的 颗粒度、MECE原则、紧急重要四象限、MVP 原则 。
但随着在行业里的时间越来越长，开始慢慢理解这些我们所讨厌的 互联网黑话 的意义。同时也感觉到，在开发领域真正具有宏观思维的人真是少之又少。
因此，这篇文章并不是一篇 "务实" 的文章，整篇文章遵循发散的逻辑，聊一聊 MVP 对开发的重要性。
务虚也是另一种抽象的务实。
血液循环系统
一上来就讲 MVP 本身，可能会让大家感觉迷茫。因此先拿血液循环系统打个样，让大家感受一下它的魅力。
想象一下，我们是一个造物主，现在想创造一个生物。生物一定离不开血液循环。我们应该怎么设计一个血液循环系统？
最传统的方案：我们先造一个心脏，然后搭建动脉静脉毛细血管，最后开始血液流通测试，确定没问题了这套系统就搭建好了。
但这样的设计会有几个问题：
- 我们的血液系统变了怎么办？原来两条胳膊变成三条了怎么办？
- 我们的血液系统到时间没做完怎么办？胳膊的保质期只有两个月，过期了就不能用了怎么办？
- 我们的血液系统在测试完成之后，发现血流不通全身怎么办？
这时候就体现出来一个好的设计的重要性了，我们可以做一个分步的设计：
- 先创建一个心脏，然后构建到一个手臂的动脉静脉
- 通血测试手臂血液循环是否可用
- 构建另一个手臂的动脉静脉
- 构建双脚的动脉静脉
- 逐个补充毛细血管，提升血液功能完善程度
这样我们就会发现我们每一步都是可控的，在每一步出现问题，都可以快速修复。如果第一步时，心脏出现问题了，我们可以快速更换心脏；如果第二步测试出问题了，我们可以更快的找到问题来源（测试范围变小）；如果第三步有些东西优先级更高，比如先做大脑，我们可以快速调整；如果这个血液系统做了一半，来了别的事情，我们也可以快速切换。
这就是 MVP 的魅力。
MVP
MVP 全称： Minimum Viable Product ，也就是 "最小可行性产品" 。
展开的意思就是：在开发产品或者新功能时，以最小的工作量推出拥有核心功能的产品，让团队快速验证产品概念、收集用户反馈。
这是第一层 MVP ，也是产品层 MVP 。在开发层，我们可以拆出开发级别的 MVP。
比如我们需要开发一个 QQ，产品层的 MVP 第一层是具有聊天功能、添加好友、群聊功能的 APP。而在开发层面，我们第一版可能只有好友+聊天即可让产品试运行。
MVP 的优势
MVP 的主要优势还是集中在时间成本和开发成本上，同时也附带着降低风险、快速掉头的特点。
时间成本：对于软件而言，很多时候时间就是金钱，如果有一个明确的风向标，你比别人早上线，可能就有 50% 甚至超过 90% 的优势，因为一个用户大概率不喜欢同时下载两个功能基本雷同的 APP（补贴的力量除外）
开发成本：相较于传统的开发流程，它可以让你想清楚自己究竟想要什么、产品的核心功能是什么，进而避免浪费时间在无用的功能上（可能一个功能开发成本很高，但收益很低）
降低风险：大家都知道，船小好掉头。在开发中，如果我们整个开发完成再投入市场，但市场并未认可产品；这时候如果我们调整核心功能，将会大范围的影响我们的开发速度。但我们如果推出的只包含核心功能，那么在接收到反馈时，可以快速调整
我们应该怎么用 MVP？
- 明确产品价值
- 明确产品功能
- 明确核心功能
- 明确其他功能优先级
- 确认开发顺序（MVP 版本）
- 快速开发核心功能并上线
- 基于 MVP 版本逐个开发其他功能
- 补充细枝末节
基于以上的流程，我们需要按照以下的顺序进行操作。
- 首先我们要明确产品价值，知道我们的产品是给谁用的，应该怎么用，这些人在我们的产品中可能会做什么。
- 基于产品价值开始整理核心功能，明确整个产品到底都需要哪些功能，整理出需求文档。
- 基于需求文档拆解，确定哪些是核心功能，确定非核心功能的优先级，并确定每个 MVP 版本都要完成什么功能。
- 基于 MVP 版本控制，开始进行开发。
实际使用案例
首先，我们明确掘金是一个技术分享类的社区。且明确我们的产品是给程序员用的。那我们的社区大概需要以下功能：
- 账号系统（登录、掘力值、用户等级系统、VIP、黑名单..）
- 文章系统（文章、分类、标签、评论、收藏、专栏）
- 排行系统（作者、文章、专栏）
- 广告系统（广告发布、广告展示）
- 朋友圈系统（沸点）
- 课程系统（购买、阅读、发布、分类）
- 直播系统
- 活动系统
- 商城系统
- 插件系统
这么一看，小小的掘金，一个技术社区，竟然包含了这么多模块。如果不进行分解，大家也能感觉到开发难度（如果毕业设计、课程设计做过 blog 相关的设计，一定能感觉到）。
第一步一定是让程序能跑起来，产品能进行试运行，确保功能完善以及思考设计是否合理。那我们就着这些内容进行拆解。
MVP1.0：
- 账号系统（登录）
- 文章系统（文章发布、文章查看）
第二步我们就需要考虑开放给小批量用户体验，debug 等问题，我们优先满足基本功能完善，让系统在一个 blog 中是一个基本完善的功能。因此我们 MVP2.0 以用户为主，补充需要功能。
MVP2.0：
- 账号系统（掘力值、用户等级）
- 文章系统（分类、标签、评论、收藏）
第三步是我们的系统开始正式上线了，正式上线需要考虑大量用户的大量文章用户怎么看？因此我们需要补充排行、推荐、专栏 等功能。
MVP3.0：
- 排行系统
- 文章系统（推荐逻辑、专栏）
这里核心功能就基本完成了，其他的模块其实都是点缀，这一步基本上用户体验是基本完整的。我们还剩 朋友圈、直播、广告、活动、商城、插件。
这里其实分为两种情况，一种是掘金这种背靠字节的大厂，另一种是一个小公司，两者的模块优先级不同。如果是现在掘金这种，一定是以用户体验为主，先开发朋友圈、活动 等系统，增强用户粘性；而另一种由于资金原因，需要优先考虑盈利问题，可能优先考虑广告、商城、直播、课程。
我们还是以掘金现状为例， 以增强用户粘性为主，设计 4.0 版本的 MVP。
MVP4.0：
- 朋友圈系统（沸点）
- 活动系统
- 直播系统
接下来我们就直接将剩下的模块以优先级排序，慢慢开发即可。
MVP5.0:
- 课程系统
- 商城系统
- 插件系统
通过以上拆解可以感觉到，我们的项目每一步都是很多小功能的集合。我们可以快速的 迭代、下线、上线、调整 功能能力；同时在不符合预期的情况下快速掉头，这也正是 MVP 的优势。
总结
接下来我会出一个互联网黑话的合集，讲讲互联网黑话到底都说了什么，以及这些对我们开发的帮助。
文章讲的比较发散，大家有不懂的可以评论区问一下。整体主要讲 MVP 是什么以及对团队的影响。同时也提醒各位组建团队及面试的时候，记着考虑颗粒度的协调度，以便于我们更好的完成开发任务。
MVP的优势在于它能够显著降低时间和开发成本，同时减少风险。它鼓励我们明确产品价值、功能和核心功能，然后按照优先级顺序开发，这样可以确保即使在资源有限的情况下，也能推出一个功能完整的产品。
MVP 拆解时，常常需要遵循 MECE 原则，保持相互独立、完全穷尽。下一篇文章我会专门讲 MECE 原则。后续则考虑写一些方法论，PDCA 之类的。
关注 带大家看更多互联网黑话的意义~
大家动动小手，点赞、收藏、评论~