科技猎MVP产品设计思路在实际项目中的意义与方法
【 2021年原创计划第10篇 】
笔者个人观点，只作一家之言
本文目的： 简单了解mvp的概念和 意义，然后再通过 案例阐述， 理解在各种开发项目中 ， 如何用mvp理念推动项目 进度。
1、 MVP起源
MVP的概念是Eric Ries《精益创业》里提出的概念。简单地说，就是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP对于创业团队来说是很重要的，可以快速验证团队的目标，快速试错。
与常规产品不同，MVP更侧重于对未知市场的勘测，用最小的代价来验证商业可行性。举个例子： 如果你希望做一个资源分享网站，那么作为产品原型，MVP仅仅包含最基础的功能，形态或许就是一个提交上传的按钮以及图片的展示。借助MVP，经过一系列实践，产品的设计思路将被一次次整改，最终完成正式版的开发。
2、概念定义
Minimum Viable Product，简称MVP，中文名称叫最小化可行性产品，是指将产品用最简洁的形式展现或者开发出来，保留能够帮助用户完成任务的最小功能，去除掉冗余杂音，对我们需要确认和认知的内容无关的一切流程或功能都要摒弃的一款微小的产品。主要核心是 短频快的产品开发思维，并围绕这点给出了如何衡量成果最后作出转型或者坚持决定的一系列方法。
通俗的理解MVP是一种产品理论，即最小化可行性分析，可以把它想像成是一部电影的剧情大纲，或是一篇短文（类似本文也是一个小的mvp产品）。它的关键点就是降低产品开发成本，但是却能展示最终产品的主要功能。
MVP不是每个迭代做出产品功能的一部分，而是每次迭代都要交付一个可用的最小功能集合，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。然后逐次迭代做出满足客户预期的产品，直至最后完全满足客户需求。
3、 MVP的意义
我们需要注意：MVP不代表着便宜、难看、功能残破，MVP代表着船小好调头、节约成本，敏锐。
1、MVP的重要意义：
MVP产品存在是为了验证两件事：
（1） 价值假设 ：我们构想的这款产品是否真的满足了需求
（2） 增值假设 ：用户是否真的愿意为其买单
最后根据市场的反馈，我们可以决定产品未来的走向，用最小的成本验证市场，对我们的产品决策会起到很很好的帮助作用。
2、MVP的承载形式：
MVP可以是产品界面的设计图，可以是带有简单交互的原型、可以是一个粗糙的模型、可以是一段视频、一个公众号、甚至是一篇文章，亦或是一段简单表演等多种形式。
4、 结合业务建模方法推动MVP
在实际项目中，MVP本身只是一种设计理念和思维，想要实践就需要结合更加具体的方法和策略。如此，我们就可以根据用例建模的方法践行MVP模式。
我们在项目推进过程中，会经历多个阶段，首先就是需求阶段，也可以理解为业务分析阶段。我们首先应该在业务分析阶段花费更多时间，这样后期能够避免的问题就越多。
我们一般在项目启动之前先进行业务建模，首先发现和定义系统会涉及到的各种角色和相关用例，然后再根据 业务用例 梳理 业务流程 和 功能架构 ，在这个过程中，我们还需要判断当前的业务目标是否合理？业务流程是否闭环？功能架构是否稳定？然后就会进入产品原型设计阶段，最后再通过以用例为基础的系统开发。
开发实施过程中我们会发现一些问题，就是在一般系统中都会有公共代码，它们之间是有交互的。如果我们按照基础用例建立起了一个可运行的小系统，但是有的类可能只完成了部分代码，未来第二批用例开始进入迭代周期时，怎么保证这些代码还能用？如果修改甚至重写，那不是白费力气了吗？
确实，这样的分工方法可能会导致代码的重新修改。但笔者可以肯定的说，即使设计再仔细，考虑再周全，即便把现有信息已经考虑的十全十美，但是如何能肯定客户不会变更需求？ 这是一个不可回避的现实问题，所以代码的修改甚至重写都是无法避免的。 所以这样做看上去会带来重复的工作量，但是认真考虑下，先看看一个快速实现了用例的微小系统可以为我们带来什么，再看看花费在重构代码上的时间是否值得。
首先 ，用例代表了客户的需求，它达成了客户的一个系统目标，并且描述了客户如何使用它的全部细节。因此，当这个小系统完成的时候，我们可以交付给客户作为需求验证。验证结果可以带来客户的反馈，以避免在大量工作完成以后才得到反馈，甚至是需求变更从而导致更大范围的返工。
其次 ，用例场景描述了该用例应当完成的全部功能。我们可以根据用例场景设计开发、测试用例。当这个小系统完成时，我们可以用测试用例来测试它，包括功能测试和系统测试。在每一次迭代过程中，也许原先的代码会被重构。每次重构后，我们都可以再次运行测试用例。只要通过了测试，便不用担心重构带来了麻烦。每一次迭代，都能得到一个保证实现了需求的可执行的系统。多次迭代结果会使得系统越来越强壮，至少，它经历了更多次的测试和验证。
尤其是根据用例对客户的重要程度排出了优先级之后，将对客户最为重要的用例安排在早期的迭代，这样，等到系统最终交付客户时，那些最为重要的用例已经经历了很多次的测试、验证和重构，它们理应是最为稳定和强壮的。毋需多言，我们也知道核心业务的稳定对一个系统意味着什么。
第三 ，项目时间应该总是不够的，按照传统的项目运作模式。当距离项目期限越来越近的时候，项目经理（ 产品经理 ）可能会为无法交出一个满意系统而焦头烂额。赶工的结果通常是以降低质量为代价的。而按用例的方式推进，即使没有完成全部系统，也至少完成了核心业务，项目经理不必过于担心客户（老板）会暴跳如雷。想象一下，在项目期限到来的时候，是交付客户 （ 老板 ） 一个虽然看上去全部完成但千疮百孔几乎不可使用的系统，还是交付给客户一个虽然没有全部完成，但核心模块已经稳定和强壮的系统会让客户 （ 老板 ） 更容易接受？
第四 ，人们在工作中总需要一些 成就感 来激发他们工作的热情。尤其是对于程序员来说，如果他们要在辛苦工作半年以后才能看到可运行的成果，那么顶多两个月以后工作热情就将大为下降；如果每隔一两个月就有一个 可运行系统 面世，这伸手可及的希望将不断激发他们的工作热情。
所以对于中小型项目，结合用例建模方法进行MVP产品开发，可以很好的兼顾外部需求和内部环境的统一，更加高效的推进项目。
参考资料：
— end —
你好，我是明远，做过游戏、写过代码。我认为 产品经理不只是一个岗位，也是一种思维方式的载体；每个人都是产品，一款产品有生命周期，一个人也有生老病死；从产品经理的角度观察这个世界，可能会发现一些有意思的事情。在这里不只有各种互联网工具和资料，更有对这个世界不断思考和探索的认知分享。
