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