最低要求：考虑最少可行的实验

当我谈论最低限度可行的产品或最低限度可行的实验时，人们经常告诉我他们的最低限度是几周（或几个月）。 他们不做大量工作就不可能释放任何东西。

我问他们问题，看看他们是在谈论最小不可或缺的功能集还是最小可采用的功能集，而不是MVE或MVP。 通常是。

是的，在将其发布给整个客户群之前，可能需要一些故事来创建整个功能集。 而且，这不是MVP或MVE。

您知道Eric Ries的Build-Measure-Learn循环吗？ 还是Cynefin的小型但可以通过失败的实验的想法？ 这是这两个想法背后的想法：

• 您有可以在产品中实施的想法。 如果您像我的客户一样，您的想法比以往任何时候都多。 这是一件好事！
• 您建立一个产品的想法。
• 您用数据衡量结果。
• 您可以从这些数据中学习 ，以生成/减少/更改您的想法。
• 再做一次，直到学到足够的知识为止。

当我想到构建-学习-学习循环并将其应用于最小可行实验的想法时，我经常发现以下可能性：

1. 我们现在有一个MVE。 我们需要定义如何测量和使用数据。
2. 我们不必做很多事情来收集一些数据。
3. 我们可以问一个问题：我们想知道什么，为什么？ 收集这些数据有什么好处？

这是一个如何影响新客户的示例。 他们有一个嵌入式系统。 他们认为，如果嵌入式部分启动速度更快，他们将为系统找到更多应用程序。 在嵌入式软件中，速度通常是一个因素。

他们选择了一个拥有系统的客户。 产品经理拜访了客户，并询问了组织内的其他垂直应用程序。 他们是否需要这种系统？

是的，他们确实。 他们关心的不仅是启动速度，还包括应用程序处理速度。

产品经理询问他们是否愿意加入MVE。 他解释说，团队将观察他们如何实现和使用嵌入式系统。 是的，他们都会签署保密协议。 客户还必须知道，该团队可能实际上并未真正实施实验。

客户同意。 该团队实施了四个非常小的性能增强功能-仅通过快乐的路径，没有替代/错误的路径-并拜访了客户，以了解会发生什么。 团队花了三天时间来完成此任务。

团队拜访了一天，观察客户的工程师如何使用该产品。

他们大吃一惊。 引导速度无关紧要。 处理过程中的一条特定路径非常相关。 其他三个与该特定客户无关。

这个特殊的MVE有点贵。 开发，测量和学习花费了一周的团队时间。 双方必须管理一些文书工作。 如果您使用其他类型的产品，则可能会花费更少的时间。

而且，看看那一周有多便宜。 那个星期教会了团队一个垂直产品线需要什么，而不需要什么。 他们设法避免了所有这些“必需的”功能。 该客户不需要它们。 事实证明，另一种垂直行业需要其中两个，而似乎没有人需要剩下的一个。

产品经理能够针对此垂直市场修剪积压的许多想法。 产品负责人知道（并知道原因）哪些功能更重要，以及如何编写故事和对其进行排名。

这就是MVE的一个例子。 您的实验可能看起来会有所不同。 这里的关键是这个问题：您可以衡量的最小事物将为您提供价值，以便您做出产品决定吗？

翻译自: https://www.javacodegeeks.com/2017/01/whats-minimum-thinking-minimum-viable-experiments.html