背包问题 最小价值_最小价值问题

背包问题 最小价值

定义和构建良好的最低可行产品要比听起来困难得多。 找到人们想要的“一件事”实际上比挑选一件事情要重要得多。 它是解决最低价值的问题以及随之而来的所有其他事情的组合。 解决由内而外的需求和由内而外的目标都是至关重要的。

从冰山开始

里奇·米罗诺夫（Rich Mironov）的精彩文章《 DIY幻觉 》（ DIY Illusion ）谈到了使团队专注于构建重要内容的重要性（而不是构建以其他方式更容易获得的内容）。 想象一下，您的团队正在构建一个移动应用程序。 现在，假设您的团队正在从头开始构建CRM系统，以使您能够跟踪安装该应用程序的所有用户。 或者想象他们正在从头开始构建票务系统，以使您可以跟踪开发团队在功能请求和错误修复方面的进度。

去年，我在有关路线图和功能列表的文章中介绍了Andy Polaine在不同上下文中进行设计的概念。 相同的模式/概念在这里适用。

Rich的文章描述了经典购买，构建，合作伙伴决策的微观版本。 当您的团队就所需的开发人员或其他基础设施做出决策时，这正是感觉和外观。

弹出到更广泛的组织级上下文中，现在它是经典的MBA版本–我们是否开发新产品来完善我们的产品组合？ 还是我们与其他人合作以包含他们的产品？ 也许收购那个合作伙伴（或仅仅是产品）最有意义。

这两个决定都坚定地在考虑产品的内在方面。 外部框架如何？ 您的客户正在做出有关您产品的购买，建造，合作伙伴决定。 您如何确定对他们来说正确的答案是“购买”？

Rich的文章中的重要一点是，您需要做的工作（在这里滚动您自己的<插入系统>）要比浅浅的分析使您相信的要大得多。 定义最低限度可行的产品也是如此。 您的客户将需要解决的不仅仅是您开始关注的单个问题。

最小价值问题

接下来的几周，我将只讨论最小的有价值的问题，而不是最小的可行产品，以此作为实验，看看它是否能加快我团队的思维转变。 [昨天（在我打字时，我在与高管的会面中我首先删除了该词，解释说我们的产品专注于完全解决最小的有价值的问题，并得到了一些人的点头，但没有直接评论。）如果您想要知道结果，请在此帖子的评论中提问。

在我的脑海中，我记得读过史蒂夫·约翰逊（Steve Johnson）引用赛义德·汗 （ Saeed Khan ）的话说，最低限度的可行产品实际上是“您可以做的至少”。 我希望这是真的，我喜欢那句话。 我不知道那是我真正听到的地方，但是让我们引用一下它，看看是否有一些推文使原始作者神奇地出现了。 实际上，MVP是您对#product所做的最少的选择 。

为什么要区分产品和问题 ？ 两种原因-一种是哲学的，一种是实践的。

哲学肥皂盒

客户经常从我这里得到的一件事是，我以“崭新的眼光”加入他们的团队，而我带来的一件事是对他们的工作和计划​​做事的外部看法。 它为我提供了一个机会，可以帮助将团队的视角由内而外转变为由外而内 。 换句话说，受到市场需求的驱动。 在上下文的产品级别上，这通常意味着受到特定用户试图解决的问题的驱动。 在许多对话中引入“问题”作为图腾有助于随着时间的推移加强和巧妙地改变对话。 我与特定团队合作的时间越长，我看到的结果越多。

人们谈论产品时，通常是在谈论“我们（将）制造的东西”。 对于确保产品与市场的契合度而言，这对我而言并不像人们在谈论我们正在解决的问题那样有价值。 我在早期发现和定义阶段的团队中。

我们从关于为什么有人使用该产品的对话中获得的价值要比围绕该产品如何工作的讨论所获得的价值更大。 与围绕产品使用成本的讨论相比，与围绕产品使用方法的讨论相比，我们获得了更多的价值。

实践思维

杰夫·帕顿（Jeff Patton）在其《 用户故事映射 》（ User Story Mapping）一书中的素描很好地描述了沟通中的一项巨大挑战。

如果需要更大的版本，请购买Jeff的书 ]。

根据我的经验，当人们谈论“产品”时，会议室中的每个人都会很高兴地进行对话，每个人都提到“产品”，而没有人明确说明其含义。

当人们谈论“问题”时，我们打算使用该产品来帮助解决问题，通常是在对话中重申，完善或至少引用我们正在谈论的问题。

我不知道为什么它们会以不同的方式发挥作用，但它们似乎是这样做的。 也许我们的听众中有一位认知心理学家可以阐明一些观点？

无论如何，最低限度的有价值的问题似乎是人们可以在谈话中轻松解决的问题 。

解决问题

我站在另一个巨人Gojko Adzic和他的书Impact Mapping的肩膀上，作为我的个人产品管理柔术。 Gojko的方法可帮助我快速定义对用户解决其问题的含义。

通过关注结果（事实上，有很多方法可以达到目的–我只是发现Gojko的方法引人注目），您发现解决最初打算解决的问题可能是不够的。

您的最低可行产品可能会解决一半的问题。 解决一半的问题就是创造一半的产品 。 在某些情况下，这是有道理的-拆分故事，增加交付等。但这在很长一段时间内没有意义。

您多久有兴趣购买一半解决方案来解决所面临的问题？ 当您的汽车上的刹车灯熄灭时，您是否想请机修工立即修理其中的一个，并安排下个月进行后续访问以修理另一个？

定义最小有价值的问题就是定义最小可行产品。

最小的有价值的问题是您完全解决的问题。 您只能在非常狭窄的环境或范围内解决它。 您可能只为一小部分用户或您最终市场的一部分解决此问题。 您可能只能解决适当的问题，而不能创建真正的竞争解决方案。 但是对于那种客户，在那种情况下，您已经完全解决了。

切记–您一次增加一位客户的收入。 这听起来像是陈词滥调，但却颠倒了观点。 那个客户正在考虑同一笔交易的多个供应商。 客户会选择平庸的供应商（对于其他客户也是平庸的），还是会选择对他们最合适的供应商（即使对其他客户而言并不完美）？

问题背后的问题

上图是产品生态系统依赖性的真实视图。 因为它是真实的，所以它被模糊了。 它显示的是左上角的要解决的“目标问题”。 这个目标是最小有价值问题的候选者。

红色的每个连接都表示“需要”，因为对于给定的用户来说，解决其模糊框内的问题需要其他用户的帮助。 然后，另一个用户必须解决“帮助第一个用户”的问题。 或者可能存在一个操作上下文，例如“ [第一个用户组]的监视器性能解决了他们的问题，因此我们可以对解决方案进行微调。” 当您进行服务工作或设计整体产品时，您会在每次参与中看到（或应该看到）这一点。

在复杂的问题空间的生态系统中，我们发现存在多个与充分解决用户问题相关的各方。 用户的每种不同颜色反映了针对焦点用户解决焦点问题所涉及的不同用户。 相互依存的问题是冰山的其余部分。

通过针对同一问题空间的洋葱图 ，我们也可以非常快速地看到（即使是经过编辑的版本）存在三个系统（或系统接口），通过这些系统，不同的用户可以直接或间接地使用我们的产品来解决他们的问题。

缩小流程差距

这些对问题空间的看法有助于我们确保我们正在解决一个有价值的问题，这是我对可行产品的首选定义。 作为奖励，它们有助于弥合产品管理团队的抽象思维与将创建解决方案的工程团队和想要“知道它是什么”的执行团队之间的具体思维之间的鸿沟。

翻译自: https://www.javacodegeeks.com/2016/07/minimum-valuable-problem.html

背包问题 最小价值