您是否难以将“所有”必要工作整合到迭代中? 您的经理可能希望敦促您做更多的事情。 或者,产品负责人认为您可以做更多。 或者,团队希望做更多事情(请参阅实现团队目标) 。
敏捷方法并不是要做更多的事情。 敏捷方法鼓励我们尽我们最大的能力去做我们需要做的最少的事情,以获得反馈,所以我们可以再做一次。 (有关示例,请参见敏捷转型:实践变更,第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