点赞
收藏
请用微信扫码分享哦~
分享

勿删,用于自定义目录加锚点,隐藏即可

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

+ 关注
+ 关注
Shape Up

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

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

通过解决问题来确定产品功能的优先级

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

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

功能请求

01. 无积压订单

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

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

02. 问题重于解决方案

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

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

立即登录阅读全文
登录或注册即可解锁全站内容,即表示你理解并同意 服务协议 与 隐私政策

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

积压的功能类型过多

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

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

03. 有问题的自由

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

工程师和设计师是各自领域的专家,更重要的是,他们是您产品的专家。如果您作为产品经理、客户支持专家或 C 级利益相关者要求这些专家实施您想到的解决方案,那么您就不允许他们按照自己的级别进行设计或开发;你是在强迫他们按照你的方式去做。这不是他们被雇用的目的。

大家首先想到的是解决办法。当您遇到任何不符合您预期的产品时,您会立即想到他们应该实现的功能。没关系。作为设计师和工程师,我们应该接受这样一个事实:这就是我们的思维方式。但我们也应该推动自己看到功能背后的原因。我们需要考虑我们想要解决的问题,然后将其交给我们的团队,以便他们能够设计出有效的方法来解决它。如果您在解决问题的同时也给他们带来限制(例如,我们需要在三周内交付一些东西),您将获得您所见过的最具创意的解决方案。

这就是基于问题的路线图为我们团队解锁的东西,但仍然有一条路要一起走。

2

04. 伪装成问题的解决方案

我向利益相关者展示了路线图,并利用“即将推出的新大项目”的机会举办了一个研讨会,要求他们思考问题而不是解决方案。我给了他们提示和解决这些问题的基本结构:

(用户)与(要解决的问题)作斗争

几分钟后,我得到了很好的问题陈述,例如:

我们的患者很难加入咨询,因为他们忘记了如何从应用程序开始咨询

但我也得到了:

患者因没有优惠券而苦苦挣扎

正如您所看到的,第一个是开放的、描述性的;第二个是开放的、描述性的。第二个是具体的和规定性的。第二个不是问题。这是一个伪装成问题的解决方案。创建它的人使用了我提供的结构,但仍然在声明中引入了解决方案。这背后并没有什么恶意,只是日复一日难以改变的旧习惯。我们只需要问几个问题就可以理解背后的问题并正确地构建它。

此时,我明白,当人们习惯这种新的表达想法的方式时,我的工作就是在路线图中解决这些问题,我对此表示同意。

05. 连接两个进程

从那时起,对我们所有人来说,确定优先顺序就变得容易多了。利益相关者不再问自己下一步应该构建什么,而是问现在需要解决哪些问题。令人惊讶的是,我们对我们优先考虑的问题更有信心,因为它们感觉真实——提出想象的问题比想象的解决方案更困难

在每个周期结束时,我会将这些问题提交给产品团队,我们将一起构思和制定可行且实用的解决方案,并在投注表中进行讨论。我们不仅为他们提供了一个贡献自己想法的空间,而且将贡献行为作为我们核心流程的一部分,从高层开始,他们感到更多的所有权,因为这些解决方案来自他们的想法。

使用 Shape Up 集成问题解决流程

流程至关重要。它们提供结构和秩序,并提高我们的工件的质量。但是,当所有重大决策都提前做出并且团队成员仅仅扮演执行其他人的想法的战术角色时,他们也会感到受到限制。

点个赞鼓励一下作者吧~

发表回复

加入社群
创新战略交流群创新战略交流群
扫码进群
扫码加我拉你入群
TOC业务增长群TOC业务增长群
扫码进群
扫码加我拉你入群
TOB业务增长群TOB业务增长群
扫码进群
扫码加我拉你入群~
相关文章推荐
点赞
收藏
请用微信扫码分享哦~
分享
关闭按钮
欢迎来到Runwise即能创新社区!
登录装饰图,三个人围坐在电脑前,对某个灵感进行沟通和讨论
已有账号?