2020年9月10日星期四09:46

定义最小可行产品

撰写者

当埃里克·里斯(Eric Ries)在他的《精益创业》一书中推广了最低限度可行产品(MVP)的概念时,

他将其定义为“新产品的版本,该版本使团队能够以最少的努力收集最大量的经过验证的客户了解信息”。这为拥有明确外部客户和预期收入来源的产品提供了支持;使团队可以专注于特定用户寻求的增强功能和功能,同时最大程度地减少了浪费时间和精力开发不需要的功能的风险。另一方面,如果该产品是供公司内部使用而开发的,那该怎么办?所需功能在何处得到充分界定和定义?开发MVP还是值得的吗?

在这种情况下,定义最小可行产品可以带来很多好处。例如,最重要的是,它使产品负责人能够:

  • 更好地优化产品待办事项并
  • 必要时更精确地显示用户故事。

那么,为什么很少为内部项目定义MVP?造成这种情况的原因有很多,并且因项目而异。我参与了许多未使用MVP的项目。出现这种情况有多种原因:

  • 该项目并非真正敏捷。代表客户工作的产品负责人已将用户案例定义为“必须”。
  • 难以获得客户的认可;尽管它们可能支持用户故事/需求优先级,但他们拒绝放弃本质上是MVP增强的功能。
  • 产品积压工作从未真正完成。如果MVP不断发展,那么一开始就不值得付出努力。

但是,并非必须如此。定义产品的MVP并不是一项繁重的工作。为了帮助我们开发内部产品或所需功能完全已知的任何产品的MVP,我们必须首先了解MVP的用途并对其进行定义。
MVP的目的是交付能够满足项目目标的有效产品。它不排除交付增加或增强MVP的功能,而是允许团队在需要评估用户故事或在测试和冲刺审核之后将新的用户故事添加到待办事项中时专注于核心功能。重要的是要记住,交付MVP可以获得用户反馈,这可以大大增强最终交付的产品。 MVP不是交付功能最少的产品。 


广告

Marek Hasa确定了MVP的关键要素如下:

  • 功能–一整套功能相互交织,可用于实现产品内的目标并获得特定价值
  • 设计–需要符合商业质量标准,以便目标用户的反馈不会因业余执行而产生偏差
  • 可靠性–需要经过全面测试并具有完整功能
  • 可用性–用户能够完成目标操作并从使用该产品中获得特定收益

问题在于确定核心功能是什么。

那么,识别核心功能和定义MVP的最佳方法是什么?传统上,这是通过对产品积压中的用户故事进行优先级排序或使用用户旅程图来完成的。由于它们的离散性,这两种方法都不能使分析师/产品所有者完全了解用户故事如何实现项目目标。这些方法还会错过MVP的系统功能。

为了确定产品的核心功能,必须了解所交付功能之间的关系。这种关系通常不仅仅是用户旅程图,还需要捕获实现项目目标,数据需求和非功能需求所需的操作。后两者支持实现MVP的设计和可靠性需求。对这种关系进行建模可以使业务分析师确定实现项目目标的核心功能,关键的端到端流程(尽管理想情况下,这只是一个流程)。通过将用户故事映射到该流程,业务分析师可以轻松地识别与这些流程不直接相关的功能/用户故事。他们还可以确定可以通过变通办法简化或交付并在以后的迭代中增强的功能。可能不视为MVP一部分的功能示例包括:

  • 通过FTP站点自动上传数据–临时解决方案可能是用户从电子邮件附件上传数据
  • 处理规范异常的计算–临时解决方案可能支持在产品外部进行的计算以及手动输入的结果

一旦确定了MVP,即可相应地确定用户故事的优先级。此关系的描述不应详细描述;它是高级理解,可以分析实现项目目标所需的条件。在包含在sprint中之前,将作为用户故事细化的一部分来扩展细节。这种方法使用户故事可以轻松地从MVP的定义中添加和删除,并可以评估这些更改的影响。

我们已经研究了MVP在敏捷项目中的作用,以及如何在交付内部使用软件的项目中使用MVP。我们还展示了如何在这种环境中识别MVP。

MVP应该成为任何敏捷项目的基石吗?为了更好地使用敏捷交付产品,必须做到这一点。识别MVP的好处是:

  • 更好的用户故事优先顺序;
  • 在不失去核心功能的情况下对用户故事进行脱机;以及
  • 允许用户对产品进行反馈,因此可以交付用户所寻求的特定增强功能

©BA Times.com 2020

麦格雷戈徽标白色网站