当我谈论最低限度可行的产品或最低限度可行的实验时,人们经常告诉我他们的最低限度是几周(或几个月)。 他们不做大量工作就不可能释放任何东西。
我问他们问题,看看他们是在谈论最小不可或缺的功能集还是最小可采用的功能集,而不是MVE或MVP。 通常是。
是的,在将其发布给整个客户群之前,可能需要一些故事来创建整个功能集。 而且,这不是MVP或MVE。
您知道Eric Ries的Build-Measure-Learn循环吗? 还是Cynefin的小型但可以通过失败的实验的想法? 这是这两个想法背后的想法:
- 您有可以在产品中实施的想法。 如果您像我的客户一样,您的想法比以往任何时候都多。 这是一件好事!
- 您建立一个产品的想法。
- 您用数据衡量结果。
- 您可以从这些数据中学习 ,以生成/减少/更改您的想法。
- 再做一次,直到学到足够的知识为止。
当我想到构建-学习-学习循环并将其应用于最小可行实验的想法时,我经常发现以下可能性:
- 我们现在有一个MVE。 我们需要定义如何测量和使用数据。
- 我们不必做很多事情来收集一些数据。
- 我们可以问一个问题:我们想知道什么,为什么? 收集这些数据有什么好处?
这是一个如何影响新客户的示例。 他们有一个嵌入式系统。 他们认为,如果嵌入式部分启动速度更快,他们将为系统找到更多应用程序。 在嵌入式软件中,速度通常是一个因素。
他们选择了一个拥有系统的客户。 产品经理拜访了客户,并询问了组织内的其他垂直应用程序。 他们是否需要这种系统?
是的,他们确实。 他们关心的不仅是启动速度,还包括应用程序处理速度。
产品经理询问他们是否愿意加入MVE。 他解释说,团队将观察他们如何实现和使用嵌入式系统。 是的,他们都会签署保密协议。 客户还必须知道,该团队可能实际上并未真正实施实验。
客户同意。 该团队实施了四个非常小的性能增强功能-仅通过快乐的路径,没有替代/错误的路径-并拜访了客户,以了解会发生什么。 团队花了三天时间来完成此任务。
团队拜访了一天,观察客户的工程师如何使用该产品。
他们大吃一惊。 引导速度无关紧要。 处理过程中的一条特定路径非常相关。 其他三个与该特定客户无关。
这个特殊的MVE有点贵。 开发,测量和学习花费了一周的团队时间。 双方必须管理一些文书工作。 如果您使用其他类型的产品,则可能会花费更少的时间。
而且,看看那一周有多便宜。 那个星期教会了团队一个垂直产品线需要什么,而不需要什么。 他们设法避免了所有这些“必需的”功能。 该客户不需要它们。 事实证明,另一种垂直行业需要其中两个,而似乎没有人需要剩下的一个。
产品经理能够针对此垂直市场修剪积压的许多想法。 产品负责人知道(并知道原因)哪些功能更重要,以及如何编写故事和对其进行排名。
这就是MVE的一个例子。 您的实验可能看起来会有所不同。 这里的关键是这个问题:您可以衡量的最小事物将为您提供价值,以便您做出产品决定吗?
翻译自: https://www.javacodegeeks.com/2017/01/whats-minimum-thinking-minimum-viable-experiments.html