MVP模型是最小可行产品（Minimum Viabe Product）的简称，由Eric Ries在《精益创业实战》中提出，指的是用最快、最简明的方式建立一个可用的产品模型，推向市场，测试用户是否喜欢这个产品，进而迭代完善细节。
功能背景
本人任职于一家CRM公司，负责的是BI产品线，本文举例的导出需求是大客户的需求。之前的导出能力只支持到了10000条，而大客户的数据量普遍在10万条以上，因此决定增加『大批量跨对象数据导出』的能力。
虽然客户只提了把导出数量加上去，但是从产品角度出发，这肯定是不够的，长远看，这必然得做成一个完整的功能。把功能一步做到位不现实，而且，客户要求的实施交付期限也不允许。
这个时候，就需要有一个既能敏捷的满足客户需求，又可以满足后期扩展的MVP方案。
开始设计一个MVP方案
1. 会议前
首先，先对系统现有的导出能力进行调研，明确我们的导出功能最终目标是做到什么程度；
然后，对当前正在实施的客户进行调研，清楚知道客户想要用导出实现什么，它的使用场景是什么；
最后，上面问题有结论之后，开始预订日程、会议室，召集相关的同事进行讨论，并准备便签纸、笔、白板等。
2. 会议中
会上，首先确定一个主讲人，先对背景、会议目的进行阐述。
然后，将调研结果分享给大家，目的是画出用户画像，这个过程里，需要其他的人提问或者补充，以防漏掉一些信息，逐步完善用户画像。
这里的用户画像并不是标准意义上的，更多的目的是让所有人了解什么样的公司、什么样的职位、什么样的场景对该功能有需求
随后，在用户画像完成之后，开始用便签纸头脑风暴，写下『如果你是客户，你想要用导出实现什么功能』，目的是发现客户没提但不排除以后提的点，这也是后续版本迭代的方案来源之一。
一张便签纸只记录一个观点，便于后续的分类与整理。
之后，收集所有卡片，讨论出『用户使用导出功能必须经历的大步骤』，写在白板上，并把所有卡片贴在相应的步骤下。然后，挨个卡片进行讨论，选出哪些点是『如果不做，就没办法满足客户这版本的需求』，选出来的这些点就是MVP。
在对卡片进行分类的过程中，以下情况是正常的：
- 不是所有的卡片都有效。参会人员岗位不同，头脑风暴的时候可能会带一些各自的职业习惯，还有可能会有一些主观性太强的想法，是否有效，需要斟酌；
- 不是所有卡片都能进行归类。有些不属于本功能承担的能力等，也有可能出现在记录的卡片上，需要判断是步骤划分不合理，还是卡片上的想法不合理。
3. 会议后
及时整理会议记录，在电脑端上选一个软件进行输出，我用的是axure，这比纸上记录更容易进行整理和分类，control+F不要太好用。还有一个目的是功能实现是分多个版本迭代的，哪些功能点在哪个版本实现了，软件里记录更容易。我在输出的时候是模仿项目管理的那种卡片式记录的，拖拽排列是很方便。
到此为止，产品设计阶段的MVP方案基本确定了，剩下的就出原型、出视觉稿、技术评审……
前期的调研、收集反馈所耗费的时间都是碎片进行的，MVP方案的讨论不到两个半小时完成，然后半小时内完成了原型……
总结这样做的好处
- 加深对项目的理解。在无法面见客户、了解客户需求的时候，产品设计进行输出时要么按客户成功的反馈做，要么自我感觉良好，自嗨型输出，最后的结果是要的你没有，给的不想用；
- 节省沟通成本。在参与的过程中，会有各种各样的问题抛出，然后得到回答、讨论等，这比看PRD印象更深刻，也会大大节省沟通和信息传递所耗费的时间成本；
- 更多的成功参与感。推导MVP的过程可以让一些非核心岗位的同事有更深的参与感，任何产品的成功都是团队的成功，只有大家觉得这个产品值得我付出，并且一起努力了，才会有好的结果。
写在最后
MVP方案确定了之后，在产品后续迭代的时候，只考虑会上讨论出的功能点还是不够的，还需要综合产品、技术层面输出一些内容才能进行下一步的设计。
比如：会上无人提到编码格式，但技术上有限制，这是用户在填写表单时必须填的。
最后说点小废话，MVP是产品设计中非常好用的一个方法，但是如果你的团队中有人对你的方案持怀疑态度的时候，不妨挑选一些业务逻辑没那么复杂的需求，来进行一次MVP的推导，成本不大，还会有意向不到的效果，比如，信任感、认同感~~
