最小化mvp案例_使用MVP最大化ROI

最小化mvp案例

我更喜欢写一些以前没有写过的东西，或者我认为仍然没有价值的地方。 考虑到“最小可行产品”一词是在2001年提出的，因此本文是后一个标准（ 根据Wikipedia ）。 像许多与技术相关的模式和过程一样，“ MVP”的使用比名称所暗示的更多。

最低要求是针对性的

“ MVP”中的“ M”通常被误认为是在工作开始时投入市场的最低要求，尽管它更适合于工作结束时。 “最小”的定义应在设计和开发的整个生命周期中不断发展。

如果您将接受所有功能都将某物从一个点或状态转移到另一点或状态，那么绝对最低限度就是能够从头到尾获得。 因此，在功能或产品的迭代设计和开发过程开始时，这应该是首要目标，在产品所有者和/或用户对结果进行审查之前，不要再进一步了。 查看最小值的第一个值的另一种方法足以进行演示和讨论。

一旦达到绝对最小值，就可以添加其他条件。这些其他条件将超出最低要求以完成值或状态的更改，其中可能会有很多这样的要求。 除非（在极少数情况下）多个需求是相互依存的，否则这些需求必须由主要利益相关者确定优先级，然后单独交付。 相互依赖性很少的原因是需求应该是独立的。 它们可能需要按照特定的顺序进行，确定优先级时应予以考虑。

在最近的设计会议中，呼叫中心用户需要一种新功能来遵循脚本并记录响应，并且脚本会根据过程中的答案在各个点进行分支。 有些参与者希望从这种功能可以在其他流程中重用的假设开始，并从通用方法开始，即使期望这种重用将在未来遥遥无期。 重要的是要认识到重用的潜力，并避免会阻止重用或使其过于复杂的方法。 就是说，它在不知道未来需求是什么的情况下，没有为初始解决方案增加任何东西。 它只会增加制作第一个MVP以供利益相关者审查并达到第一个准备就绪的MVP的工作水平。 在这种情况下，本来已经落后于计划的项目要相差几周。

可行性必须基于协议

我可以想到几种具有糟糕用户体验的著名企业技术产品。 就我个人而言，我觉得他们错过了最佳可行性，尽管我不得不承认它们在功能上几乎没有可行性。 就是说，我既不是产品所有者，也不是主要利益相关者（让我们承认，这是为许可证付款的人，而不是实际用户），并且不能诚实地说出是否满足了可行性标准。

关于上一段最重要的部分是，确认生存能力不是我的职责。 我可以（并且应该）提供有关我认为对生存能力至关重要的内容的信息，但是所有权属于产品所有者，并且（有时，而且可能不应该是经常的）所有者是关键利益相关者。

硬币的另一面经常被遗忘有生存能力。 该产品必须可维护。 产品负责人经常坚持难以维护的功能。 在某些情况下，这是一个可以接受的折衷，而在其他情况下，维护成本超过了业务价值，从任何人的角度来看，这都会影响生存能力。 我的经验是，要求高维护性功能的产品所有者通常不知道这是他们所要的，而且通常是时间表，而不是使解决方案成为维护问题的解决方案。 使用MVP设计方法交付产品还涉及所有者，设计师和开发人员之间的持续沟通。 如果这些角色中的任何一个在没有提供和接收输入的情况下都能正常工作，则该项目将面临危险。

产品应为复数

因为最小是不断发展的标准，可行是共识的结果，所以单个结果（即在第一次迭代中可交付的产品）极为罕见，但可能会例外，即该产品是对现有产品的非常简单的添加。

通过愿意迭代和重构，最低可行产品的每个版本都将变得更好，直到至少达到可以交付的最低水平为止。

最小有效后记

这里描述的最小可行产品方法听起来是否与其他方法一样？ 想到敏捷？ 大多数好的方法都有相似之处。 当他们不这样做时，这是例外。

这在很大程度上取决于“完美世界”场景。 在现实世界中，有时在等待利益相关者审查的同时，工作需要在假设方面取得进展。 这是源代码管理开始发挥作用的地方。 要记住的重要一点是不要过分喜欢假设，因为在利益相关者审查和输入后，它们可能会证明是不完整或无效的。 新团队甚至可能经常发生这种情况，但是随着产品所有者和生产商继续合作，差距将越来越小。 同样，我提醒您避免自满，因为这些鸿沟会缩小，因为遗嘱很少会完全消失。 所有目标都是在给定可用功能的情况下可以创建功能最好的产品，即使这意味着偶尔进行解决方案重构。

翻译自: https://www.infoworld.com/article/3308379/maximize-roi-with-mvp.html

最小化mvp案例