|
|---|
|
|
|
|
|
|
N*******g
发帖数: 370 | 1 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产品上限制住独立功能的数量。专注于可行的功能，但是记住保持最低
。太多相互依存的功能会限制你在可行性方面的能力。 |
|
|
|
|
|
|
