如何决定产品功能的优先顺序：从 Scrum 过渡到 Shape Up

领导者应该决定要解决的问题的“内容”和“时间”（而不是要实施的解决方案）。产品团队成员应该可以自由地通过他们只能根据自己的专业知识和知识构思和执行的解决方案来定义“如何”。本文将指导我们从 Scrum 转向Shape Up，立即开始按时交货，没有任何延误。并以灵活的范围和固定的期限来制定和执行项目，产品团队感到更有成就感，因为取得了更多进展，并且以增量方式更快、更频繁地将功能推向生产。

功能请求是一个要实施的解决方案，尽管它是在这种情况下构思想法的更自然的方式，但它是规范性的，因为它阻止产品团队成员探索其他可能更好的解决方案。当这些功能请求来自不了解产品的限制和可能性的利益相关者时（大多数情况下自然是这种情况），他们会让团队在试图在短时间内构建超出必要的功能时陷入困境。一段时间，这会导致错过最后期限并使团队、利益相关者和用户不满意。

我见过并读到许多团队实施这种方法；有些人声称使用了Shape Up 的改编版本。我理解为什么 – 这种方法需要改变思维方式，不仅对于产品团队，而且对于为下一步将优先考虑的项目做出贡献或提供输入的利益相关者。

在MiSalud，通过医疗团队、客户支持以及首席执行官不断收到来自患者的反馈，首席执行官一直在与潜在买家交谈。收到的反馈有不同的形式，但最常见的是功能请求的形式。

01. 无积压订单

形状很明确：没有积压。他们说：“如果它很重要，你就会记住”。我同意。但从一开始就让每个人都参与进来是非常具有挑战性的。人们希望在纸上看到他们的想法。

我从事咨询工作多年，我明白这些变化，特别是工作方式的这些深刻变化必须如何逐步实施。您需要迈出第一步，通过结果赢得信任，并一次引入一项新的变革。改变需要是渐进的，而且通常，你需要找到中间步骤。

02. 问题重于解决方案

我查看了我们的积压工作，其中充满了不再相关或在路线图中过于超前的解决方案。添加其中一些只是为了让人们可以在纸上看到它们。有时，在会议期间，我们会向列表中添加一项功能，以便我们可以继续下一个主题。

积压的工作是一大堆想法。有些是基于良好的反馈、指标或定性研究，有些是基于个人偏好和疯狂的假设。有些是基于统计相关问题，有些是基于一个人发表的评论，不代表我们的目标市场。作为我们的主要文件之一，积压的工作很难查看并确定优先顺序。

然后我遇到了这篇关于精益路线图的文章，它对我来说很有意义：每个想法都来自于需要解决的问题，每个新项目都是一个实验。

我处理了积压的工作，并将每个解决方案转化为需要解决的问题。我丢弃了那些不能解决任何问题、不相关或不能为我们的目标市场解决问题的解决方案，并将其余的扔进看板。我将此看板称为路线图，这一行动减轻了我肩上的巨大负担，原因有两个：

• 路线图不再是甘特图。未来两年的功能不再是不可能的截止日期。只是一个三栏板，其中包含现在、下一个或以后需要解决的问题。
• 没有积压。无数要实现的功能列表消失了。是的，现在我们有无穷无尽的问题需要解决，但感觉不一样了。问题会带来可能性，而不是增加任务。充满可能性的路线图不会让您感觉落后于计划。

03. 有问题的自由

当您向设计师或工程师提供要实施的解决方案时，您就告诉他们要做什么。你实际上是在给他们下命令。这不仅限制了他们的能力，也限制了产品和公司在市场上推出更好、更快的解决方案。

由于文章篇幅有限，原文可以点击：

入门指南｜通过解决问题来确定产品功能的优先级-从 Scrum 转向Shape Up