最小可行产品是和敏捷开发的理念一致的一个概念。下面是InfoQ的Shane Hastie对近日一次有关最小可行产品相关访谈的整理，看了这篇文章会对其大致的概念以及优点增进了解。
在Venture Hacks（Advice for Entrepreneurs）网站上最近的一次访谈里面，评论员Eric Ries讨论了最小可行产品（Minimum Viable Product，简写为MVP）的概念——只是“刚刚好”满足客户的需求，这样的产品人们乐意付费，而且可以尽快推向市场。正如Reis所言：
最小可行产品应该只包含那些足以让你交付产品的特性，早期的潜在客户可以查看该产品，而且至少有一部分人会认可、并愿意购买产品，开始向你提供反馈。
他把这种做法和非常典型的“构建所有能想到的特性”的“散射式”做法进行了对比：
“散射式”做法的问题在于：你只有在完成了所有不同的产品特性之后，才能获得反馈。为了满足那些不同的特性，你必须在产品中实现不计其数的特性。而且一般来说，等到产品完成的时候，一切已经太晚，根本无法确保你行进在正确的道路上。
只关注于最小可行产品是有益的，因为基本上你只用说“看，我们的愿景是构建一个产品，解决客户的这个核心问题，以及这些类型的一般特性领域”，我们认为：对于期冀这种解决方案的前期潜在客户而言，这些是可以接受的。
如果我们向他们交付了核心的、纲领性的特性，而这些特性可以指出我们下一步的方向，他们就能想象出产品现在暂时不具备但是将来会有的特性。
在访谈中，他举了一些他的公司如何通过关注于MVP从而达成良好结果的例子，并讲述了在没有这么做时他们所遇到的问题。
他建议使用MVP以真正地验证产品的愿景——如果你不能识别出MVP，你很可能正在构建一件错误的产品——趁早结束它！
将会有一些创业的人找到我，跟我说：“但是等等，我的客户并不知道他们想要什么。如果我问他们‘你需要这个东西吗？’虽然答案应该为‘是’，但他们却可能说‘不’。”
然而，这只是一个被滥用的借口而已，虽然在有些情况下的确是那样的。判断的关键在于：哪些才是最小的特性集合？在一些案例中，比如娱乐产品，也许你得先构建出一个早期的原型，或者一个图样，或者甚至产品的第一个版本，其中包括你认为可行的最小特性集合。
一个最小特性集合的好处是你有了一系列中间点，可以经常询问自己“我现在是在关注最小特性集合吗？我现在是在关注最小特性集合吗？”
只要你不害怕做错的负面评论，也就是说，假如你构建好了系统最初的纸质原型，并且向人们做了展示，但却没有人想要它，而你不会为此觉得沮丧。这并不意味着，你要因为“忘记它吧，我们永远做不好”的言论而放弃，你可以说：“好吧，让我们多重复几次。”
如果你坚持对产品进行迭代式的改善，你能一直让它进一步地经受考验。在这样反复10次之后的某个时候，你却仍然丝毫没有弄清楚，而且你从客户那里得到的反馈只是哈欠连连，你可能会告诉自己：“知道吗？我们走错了方向。事实上，我们超出了最小可行产品的边界。这已经不再是可行的产品了。”
他接着探讨了比如TDD、短迭代周期和最小设计这样的敏捷实践的应用如何允许了产品的不断演化，从而交付了价值和竞争优势。他比较了特性的流动和非线性的网络结构，比如互联网：
我现在觉得：与其把特性的流动看成是线性的顺序，我更倾向于认为把它看作一个很大的网络。问题是：对于给定的任何特性，它会在网络中沿着哪条路径传递？不同的特性应该沿不同路径传递，就好像互联网上我们在必要时沿着不同的路径传递包一样。
他举了一个例子，例子中的特性从来没有被真正地构建，没有获得客户反馈，也就无从得知它是否给客户添加了价值（如果我们构建它，客户真的想要它么？），一直到部署：
即使特性非常大而复杂，在某个关键页面上也要有一个链接，告诉用户可以去做其他的事情，或者用户在某个关键时刻会收到一封邮件。
一般来说，对特性的访问只能通过一个单一的入口。我们经常在分开的测试里面添加这样的入口点，看最初是否有人会去点击它们？这样我们就能看到相信那里存在这个特性的人们的点进率。
我们同样可以看到一个有趣的现象，有时只要特性存在，即使没有人点击，仍然会在其他方面影响人们的行为。
【编辑推荐】
