用于企业的最低可行产品

Eric Ries 在精益创业中将最低可行产品（MVP）的作用定义为，通过有限的精力和金钱来了解客户。在线营销人员 Paul Kortman 在其博客文章精益创业的问题：最低可行产品一文中分享了他关于制定一个最低可行产品的经验。他从解释什么是精益创业开始：

精益创业的基本哲学是得到用户的反馈，做用户测试，寻找是否有用户愿意（付费）使用你那尚未创造出来以及正在创造过程中的产品。

针对企业想要开发的产品，精益启动通过快速找到是否有对于该产品的需求，从而使得组织更加高效。但是有时候企业会发现很难对最低可行产品做出定义：

我们都知道产品意味着什么，然而最低却大有讲究：哪些是可以成功裸奔的最基本要素？

Paul 将他们尝试开发一个最低可行产品过程中遇到的问题描述如下：

• 在什么时候，我们的产品可以称为可行的？
• 我们何时能够达到临界点？
• 我们何时没有其它功能要开发？（哈，这永远不会发生。你不知道吗，我是一个有远见的人）
• 我们何时能取得收入？
• 我们何时能盈利？

Yammer 公司的企业战略总监 Brian Murray 在福布斯杂志上发表了一篇文章时代正在改变：企业软件的革命，其中解释了在采用了精益创业的企业软件开发过程中哪些是变化的，以及为什么这些变化是必须的：

传统企业软件开发技术在将产品发布给用户前试图创建出完美的产品，导致效率极其低下。（…）只要有可能，开发团队现在专注于开发 MVP。（…）使服务提供商能够有效地测试他们的设想，并最终创造出产品，同时缓慢而持续的发展成该产品实际应该成为的样子，而不是人们 _ 在想象中认为 _ 它应该成为的样子。

在博客文章最低可行的产品与最低令人愉快的产品一文中，Adam Berrey 就一个企业的最低可行的产品看起来应该是什么样子给出了他的观点：

（…）一个企业的业务系统通常会因为潜在的技术创新、功能、销售 / 市场而受益。如果你能得到足够的功能以展开销售，那么你就有一个可行的产品。你就有了一个良好的开始。

Jesus Rodriguez 在他的博客文章企业最低可行产品：专注于可行的而不是最低的，解释了当涉及到最低可行产品时，企业软件开发与消费类产品的开发是如何不同的。对于消费类市场，软件的用户同时也是购买者。而在企业领域，这种情况很少见，从而在获得产品反馈方面面临挑战。

（…）尝试 MVP 的人很少是做出最终购买决定的人。（…）企业软件创业公司需要仔细评估从 MVP 收到的反馈意见，将噪声从有些功能中过滤掉，从而使得产品更加适合潜在客户。

关于在企业软件中实施最低可行产品的另外一个挑战就是，企业是如何根据功能作出购买决定的。Jesus Rodriguez 将这种情况描述为“过份关注功能的文化”：

数十年来，企业软件开发发展出来一种文化就是更看重功能数，而忽视产品的简单性和可用性。通过对企业提出 MVP 版本的产品，你可能会因为企业倾向于将产品的功能数目等同于健壮性以及企业适用性。从而撞上偏见的南墙。

在 Sam Palani 的博客文章来自敏捷的教训——最小可行产品一文中描述了为何他们在一个复杂的企业初创过程中采用最小可行产品的：

是的，我们带来了成吨的数据，并且编写了非常复杂的 ETL 和接口程序来提取和处理数据，但是实际的业务功能却要在将来的版本甚至再之后的规划中发布。在一个理想的世界中，根据我们当前计划中的方法，我们仍然能够获得成功。然而在现实世界中，我们可以感受到潜在客户耐心​​耗尽的风险。

他解释到他是如何看待最小可行产品，以及你该如何运用它来开发并发布一个满足最低要求的产品：

一个最低满意产品（MDP，minimum desirable product）超越了单纯的可行性，其需求文档的范围更广，包含了更多特性。理想情况下，你应该规划一个敏捷发布或者短期发布，从一个 MVP 逐步过渡到 MDP 的状态，在接下来的迭代过程中能够产生最大的商业利益和客户满意度。

Sam 描述了识别以及定义一个企业最小可行产品的 5 个步骤。这些步骤为：识别潜在客户，识别范围，识别功能之间的关联，创作原型系统，以及调整最低可行产品以适应业务需求。其中步骤 3 是关于产品功能的：

在你的 MVP 产品上限制住独立功能的数量。专注于可行的功能，但是记住保持最低。太多相互依存的功能会限制你在可行性方面的能力。

查看英文原文： Minimum Viable Products for Enterprises

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。