🍚

如何管理优先级:RICE 方法

本文来自 Fibery 的产品博客 ,基于其 CEO 和产品经理 Anton Iokov 的总结。Fibery 的 CEO 说,启发于 Kevin Simler 的一篇《虚无主义者的意义探究指南》,耳听曾经撰文推荐过 Kevin Simler ,他也有一本畅销书《脑中的大象》。看本文的朋友,很大比例是产品经理岗位的吧,日常工作中遇到的常见的场景恐怕逃不过需求的 battle,优先级排序,你们日常的不满和妥协很大一部分来自于此吧。

今天这一篇是去年看到很想推荐的,是一种理念上的变化,但是可能落地到工作实践中比较难的案例。没关系,知道了还存在另一种经过认真思考的方法也是不错的,可以获得一个不同视角的观察你的工作。

需求的优先级排序,有时候是个玄学问题,是产品管理中最困难的问题之一。Fibery 的 CEO 说,有许多技巧可能会有帮助,他已经尝试了所有的方法,但都没有很大成功。简而言之,这些技术只是线性模型,和有经验的产品经理的直觉一样好(或一样坏)。他们 Fibery 团队借鉴 PageRank 引入了网络效应的特性来加强优先级排序的方法。他们的目标不是替换当前的优先级排序的逻辑 (RICE 模型),而是增强现有的优先排序方法。

传统上从客户反馈中收到繁多的线索,如何处理他们?你会注意到一些某些角色岗位的反馈重复出现,从中提炼普适的共性,凝练成features。下一步如何排序这些 features? 如何评估 feature 价值的时候到了,大家有了一致的价值评估原则的时候,就可以相对理性的探讨。

RICE 模型是产品经理常用的一种方法。

Reach 触达力: 反馈在每个功能将有多少人在一定的时间期限内影响和有多少人会注意到的变化。

定义

  • 估计每个项目在一定时间段内会影响多少用户。
  • 尽可能使用产品指标的实际测量结果,而不是随机去拍一个数。
  • 接触数量用每个时间段的用户数或事件数来衡量。
    • 这可能是「每季度客户数量」或「每月交易数量」。
      • 尽可能使用产品指标的实际测量结果,而不是随机去拍一个数。

举例

  • 项目 1:500 个客户每月在注册漏斗中达到此点,30% 选择此选项。
    • 每季度的接触数量是 500×30%×3=450 个客户。
  • 项目 2:每季度使用此功能的每个客户都将看到这一变化。
    • 每季度的接触数量是 2000 个客户。
  • 项目 3:这一变化将对 800 个现有客户产生一次性影响,而且没有持续的影响。
    • 每季度的接触数量是 800 个客户。
Impact 影响力:展示了该功能将如何为产品做出贡献以及该项目将如何影响您的客户。

定义

  • 要专注于那些能对你的目标产生可观影响的项目,预估这个项目对个人产生的影响。
    • 对于作者的团队来说,是「当客户遇到这个项目时,能够提高多少转换率?」。
    • 你的团队可能会用另一个目标,比如「提高采用率」,或者「最大化满意度」。

分数

  • 影响程度难以准确度量。
  • 因此,作者设置了一些选项来衡量:3 为「巨大影响」,2 为「高」,1 为「中」,0.5 为「低」,最后 0.25 为「最低」。

举例

  • 项目 1:对于每个看到它的客户,这将产生很大的影响。
    • 影响程度是 3。
  • 项目 2:这将对每个客户产生较小的影响。
    • 影响程度是 1。
  • 项目 3:这在影响方面处于中间位置。
    • 影响程度是 2。
Confidence 信心:表明了对所有估计的把握- 包括影响和工作量。

定义

  • 有些主意非常激动人心但是并不明确,为了遏制住马上去实践它们热情,在评估时请把信心指数考虑进去(我们认为这个功能能实现 R 和 I 的自信程度)。
  • 信心指数是一个百分比,作者设置了另一种选项来避免决策瘫痪。
    • 100% 是「高信心度」,80% 是「中等」,50% 是「低」。
    • 比这更低的信心指数都可以认为是「登月计划」

举例

  • 项目1:我们有定量指标来衡量接触数量,有用户研究来证明影响程度,还有工程预估会投入的精力。
    • 这个项目的信心指数是 100%。
  • 项目2:我有数据支撑接触数量和投入精力,但我不确定项目的影响会是什么程度。
    • 这个项目获的信心指数是 80%。
  • 项目3:这个项目的接触数量和影响程度可能低于预期,需要投入的精力则高于预期。
    • 这个项目的信心指数是 50%。
Effort 工作量:取决于需要的“人月”,周或小时。这是一个团队成员在特定月份可以完成的工作。

定义

  • 估算项目需要团队的所有成员(产品,设计和工程)的总时间。
  • 投入精力的预估单位是「人/月」
    • 一个团队成员可以在一个月内做的工作
    • 有很多未知数,所以考虑用整数来预估(一个月以下的任何事情都用 0.5 来预估)

举例

  • 项目 1:这个项目需要约一周时间做计划,1- 2 周的设计和 2-4 周的研发时间。
    • 预估的精力投入是 2 人/月。
  • 项目 2:这个项目需要几周时间做计划,大量的设计时间和一个工程师至少两个月的时间。
    • 预估的精力投入是 4 人/月。
  • 项目 3:这只需要一个星期的计划,不需要新的设计,几周的工程时间。
    • 预估的精力投入是 0.5 人/月。

您需要使用“Reach”,“Impact”,“Confidence”和“Effort”对建议的功能进行排名,并使用最终得出的分数来决定应首先实施的功能。

image

举例

其中红色圆圈是用户的场景用户的要解决的问题,绿色圆圈是需要开发的功能。

image

需求 A 和需求 B 如何评估价值进行排序?

按照 RICE ,似乎需求 A 能影响更多的人成本较小,似乎 A 更高优?

下面是一堆灵魂的拷问分析了

用户反馈之间的联系是什么?

  • 解决一堆不相关的用户反馈案例
  • 意味着为每个人而不是任何人构建一个产品。
  • 大多数情况下,这是一个糟糕的策略
  • 用户反馈的真正重要性在于他们之间的 connections

功能之间的后续影响是什么?

  • 一些功能开启了新的可能性并增强了现有的功能;
  • 其他的功能增加了复杂性并减慢了开发速度;
  • 虽然一些功能可以解决重要的用户反馈,但它们对整个业务的网络是有害的。

考虑了上面2个问题,再来看下图

需求 A 似乎没那么重要了,如果优先做了 A 似乎是笨蛋

image

那么这个过程该如何量化并实践到工作中去? 请看产品经理 Anton Iokov 的文章 《Enhancing prioritization with networks》。