如何划定MVP的产品范围？

　　本文探讨了在构建最小化可行产品时，应该如何思考产品的范围，进一步有效控制产品开发成本和时间。
　　任何在过去五年中从事软件开发工作的人，都可能听说过MVP（MinimumViableProduct，最小化可行产品）一词。
　　如果您是负责用户体验的，那么您经常会对这三个字母感到沮丧。可能是因为您通常在项目结束时遇到它们，比如有人会这样说：“这是个好主意，但我们现在没法做。先发布一个MVP，以后再添加它。”这成为一些人的说辞，即使并没有未来迭代的计划。
　　这个本来可以帮助我们快速打造客户喜爱的产品的概念，反而成为了发布并不优秀产品的借口，这不是很讽刺吗？
　　最小可行产品的最常见定义是，产品具有足够的功能足以满足早期客户的需求，并为未来的开发提供反馈。
　　不幸的是，有时这种说法会被误解，团队认为构建“刚刚好”的产品意味着纯粹专注于功能。然而，产品不仅仅等于是功能的堆砌，不能只是发布有一些功能的产品，然后等待下一次迭代再使其可用。用户的信任是非常脆弱的，一旦被打破，就很难重建。
　　下面的模型最初由JussiPasanen提出（后来成为关于该主题的任何博客文章的产物），该模型解释了如何在尽快使用户获得产品的同时不让用户失望。它建议您应该在每一层上创建最小的块，而不是逐层构建。
　　任何MVP都必须具有一系列为用户提供的价值特征：足够的价值，赢得用户信任的可靠性层，以及用户不必过多地理解产品设计的可用性层，和可以获取到一些欢乐的顶层部分。
　　构建最低可行产品的方法：建立一个切片，而不是一次构建一个层（来自JussiPasanen的图表）。
　　缺了点什么？
　　这张图还很好地表达了另一个观点：产品层是堆叠在底层的，如果您扩展了一层的范围，则需要增加它上面所有层的范围。
　　例如，添加的新功能越多，就需要更多的工作来保持产品的可靠性和易用性。如果想要缩小范围，最合理的起点是这个金字塔的基础功能。
　　那么应该要包含哪些功能？如何进行决定？我知道您的“UX触觉”（译者注：原文为‘蜘蛛侠的触感’）现在开始感觉到了什么。
　　我的也一样，直到我意识到“功能层”并非这座金字塔的真实底层。上图仅涵盖了产品本身的特征，但产品并非存在于真空中。我们构建它们是为了帮助希望对我们所提供的价值给予回报的人们，产品的真正基础层应该是受众及其需求。
　　缩小受众范围
　　假设我们需要一种能够为用户解决问题X的产品，我们应该为哪部分用户构建MVP的来验证我们的方法？
　　有关项目范围的讨论应该由此驱动：
　　选择“产品的受众”（谁将在最初阶段从产品中获得最大的价值），并向其他所有人说“不”（或“现在暂时不”），最能显著缩短开发时间。产品的受众范围越广，其需求和问题就越多，必须构建的功能就越多，产品将变得越复杂和难于使用。
　　没有什么比划定“受众”范围，更能显著地减少开发时间了。也有人这样说，您的MVP不一定要像最终产品那样酷，但是使用它的体验仍然应该令人愉快：“汽车的MVP是三轮车，而不是四个车轮。”
　　受众范围越广，需求和问题就越多，产品将越复杂。
　　但是，仔细看看这个MVP的本质，就会发现它与最终产品的最大区别在于它所服务的用户的广度。
　　汽车适合所有人，老少皆宜，无论是独自旅行或成群结队旅行，还是上下班通勤或拼车前往下一个城镇。但是，三轮车专门满足幼儿的运输需求。
　　对用户进行细分，并选择要满足的每个细分市场的需求，可以让您的团队事半功倍地为这些用户创造出色的体验，并且得到他们的喜爱。
　　当您缩小金字塔的底层时，其他每一层也会缩小。
　　了解用户的期望
　　让我们回到金字塔，看一看横切所有层次并将“最小值”与产品其余部划分开的那条线。它很重要，因为它概述了您的工作范围。
　　如何知道在哪里画这条线？
　　我认为这条线代表了用户的期望，无论选择哪种受众群体，他们都会对产品是什么、应该做什么有自己的看法，不应该辜负他们的期望。
　　MVP的范围基本上取决于产品受众和他们的期望。
　　认识到用户想要什么与期望什么之间的差异至关重要。
　　“期望”是人们认为某事应该如何运作的方式，而“想要”是人们对当前事物状态进行改进的愿望。缺少想要的东西可能是不好的，但不能达到期望可能是一场灾难。
　　例如，如果通常的上班通勤时间是30分钟，那么您会期望明天花的时间差不多。
　　人们会想要缩短旅行时间吗？
　　当然！但是大家都知道并不一定总能得到想要的东西。然而，如果您的电车明天晚15分钟出现，而乘车时间变成45分钟，您可能会暴跳如雷。
　　不仅是MVP版本，任何产品都不可能满足所有用户的愿望，什么产品都总是有改进的空间。但是，当您的产品达不到用户期望时，这是一条快速的失败之路。在尝试确定用户期望时，应牢记一些注意事项。
　　用户的期望来自于他们对类似产品的体验
　　只要没有开发出绝对新颖的产品（例如飞行汽车），就必须考虑竞争对手（甚至是间接竞争对手）提供的体验。如果他们可以立即同步用户数据，而您的应用程序会延迟4小时就完全不及格了。它可能会迫使您在图上向右移动划线，扩大项目的范围。
　　用户的期望基于现代标准
　　十年前，您可以开发一款只能在台式机上使用的产品，但如今，必须能在移动设备上对其进行访问。
　　如果产品无法在移动中为用户提供支持，那么按照今天的标准，该产品可能就无法获得“可靠性”标签。
　　用户的期望基于他们今天使用的解决方案
　　我很喜欢JaredSpool在他的博客中关于用户期望的示例。他的团队在GoogleSpreadsheets上进行了可用性研究，并观察到当簿记员找不到双下划线时，她就会感到非常沮丧。
　　她可以使用普通的单下划线吗？理论上当然可以。但是，电脑和电子表格出现之前，人们就已经在使用双下划线了，通过限制MVP的范围并不是一个忽略它的充分理由。
　　总结
　　构建MVP并不是单纯削减功能，而是划定最小的受众群体，为他们构建最低可用的产品范围。
　　缩小用户类型的范围将会大有帮助，因为它将减少产品必须满足的需求。
　　受众对产品的期望将定义产品的范围，理清这些用户期望，几乎就可以明白要做些什么了。