从顺序表中删除具有最小值_考虑具有最小结果的产品选项

从顺序表中删除具有最小值

您是否难以将“所有”必要工作整合到迭代中？ 您的经理可能希望敦促您做更多的事情。 或者，产品负责人认为您可以做更多。 或者，团队希望做更多事情（请参阅实现团队目标） 。

敏捷方法并不是要做更多的事情。 敏捷方法鼓励我们尽我们最大的能力去做我们需要做的最少的事情，以获得反馈，所以我们可以再做一次。 （有关示例，请参阅敏捷转型：实践变更，第2部分 。）

目标不是“更多”。 目标是“有效成果”或对客户或团队有价值的东西。

现在可能是时候考虑您想要的结果，看看您能做些什么了。 我称这些最低限度的结果。

为什么结果而不是输出？ 因为输出有效。 结果以某种方式为团队或客户提供了价值。 Seb Rose在Agile 2019的演讲中说，价值在于：

• 知识增加，或
• 降低的风险，或
• 产生有用的反馈。

请注意，此值可以适用于客户，产品所有者，团队以及产品中涉及的任何其他人。

最低结果

我一直在用一堆“最小”字来形容我的意思。 他们全都聚集在一个地方：

• 最小可行实验（MVE）：我们可以学习的最小内容。
• 最低可行产品（MVP）：我们可以做的最小的事情来验证业务假设。
• 最低可销售特征（MMF）：对我们来说有价值的东西：获得收入或获得客户或将费用资本化。 也许全部三个。

注意：所有这些都是正在运行的功能 。 如果它们没有运行，没有经过测试以及不是功能，那么它们就不能是MVE，MVP或MMF。

以我的经验，我们使用MVE和MVP进行学习和验证，因此我们可以创建MMF。

MVP并不是整个产品。 我认为，这甚至不是大多数产品。 这是我可以用来验证业务假设的最小碎片：客户会点击，购买还是采取我们希望客户采取的措施？

满足客户的最低要求：最低必不可少的功能集

某些MMF集将满足客户需求。 而且，根据您的产品，您现在可以只发行几个MMF。

如果我们需要不止一个MMF才能向客户显示价值该怎么办？ 我在定制工作中看到了很多。 在这种情况下，Pawel Brodzinski的“ 最小必不可少的功能集”一词将起作用。 该产品不必具有最终将拥有的所有功能集。 该产品甚至可能在整个产品上都无法正常工作。

这是一个例子。 假设您要为市场的底部制造一部手机。 那部手机绝对需要做什么？ 拨打和接听电话。 也许我们会进一步限制它，并在网络内或在国内说。 手机需要发送和接收短信吗？ 我认同。 你可能不会。 这就是客户/产品所有者/产品价值团队需要决定产品的用途以及最低要求的原因。

这种廉价电话的MIFS拨打和接听电话的能力有限。 我会主张发送和接收文本作为该MIFS的一部分。 MIFS没有其他内容。

我们可以有更多功能。 也许我们应该。 但是MIFS是电话，也许是短信。

最少更换：最低可采用功能集

当您用新产品替换产品时该怎么办？ 或者，如果您要移植产品？ 那就是您需要MAFS：最低可采用功能集的时候。

多年前，我的一位客户从客户服务器转移到了基于云的产品。 他们不想重复来自客户端服务器的膨胀。 他们创建了MIFS，这是客户可以使用的最低数量。 大约一半的客户还不够。 （请注意，对于一半的客户来说就足够了！）

客户继续添加MMF，一次添加一次，直到90％以上的客户满意为止。 然后，产品价值团队做了一件非常聪明的事情-他们拜访了想要“更多”的客户。 他们发现了一种全新的潜在产品。 该产品将吸引不同的客户群。

成果很重要

这些最低要求中的每一项都为团队，客户和/或整个企业提供了特定的结果。 如果您将故事重点放在提供更多结果上，则也许不必将更多精力投入到迭代中。 （下一篇文章就是关于这个问题的。）

翻译自: https://www.javacodegeeks.com/2019/09/consider-product-options-minimum-outcomes.html

从顺序表中删除具有最小值