RICE 框架：使用定量的方法来决定需求优先级

by Max Zhang

对我来说，产品设计有两种方法：一种是根据产品所在的领域和模型的自上而下的设计，称之为概念模型设计；另外一种是根据具体的业务指标而进行的自下而上的设计，称之为假设驱动设计。两种方法的使用场景各有不同，本文介绍的 RICE 框架主要是应用在后者当中，可以帮助团队定义需求优先级。

概念模型设计是从产品自身所在的行业和用户场景出发，找出在用户场景中出现的所有概念以及这些概念之间的联系，当中的概念和概念之间的关系与产品的商业模式和形态无关。例如设计一个自动贩卖机的系统，当中一定有「订单」「商品」「买家」这些概念，一笔订单一定由买家创建，并且包含了至少一个商品，买家付款后拿走商品，商品的库存要对应的减少。可以说这些概念和逻辑在现实世界中已经存在，不需要去发明创造，也没有定制化，无论这台贩卖机是面向国内还是国外的人群，是放在学校还是小区，卖到是零食还是玩具，其概念和逻辑都是一致的，你可能会想到「中台」这样的概念，确实如此。概念模型设计也会涉及到需求优先级的定义，与假设驱动的设计不同，概念设计通常不需要「假设」，因为产品最初要解决的问题就已经给需求定义了范围了，自动贩卖机的系统大概率是不会加入像「代言人」这样的概念的。这样的设计更多是从产品的战略层驱动的，战略决定了产品的方向，也就是概念延伸的方向，概念延伸的路线就是需求的优先级。

假设驱动的设计更多的是针对更加具体和细节的目标，这些目标与产品的概念无关，而是在已有的概念中不断优化，例如提升用户转化率或者功能渗透率这样的指标。如果说概念设计的推进是相对比较稳健，像是正规部队作战那样，那假设驱动的产品设计更像是游击战，虽然目标是固定的，但是达成的方式却有很多种，有时候可能只是改个文案，或者换个标题颜色就可以。所以对于这类型的需求，主要关注的是战术上是否有效，效果更好的需求优先级自然就更高，那么问题就是如何判断哪个需求的效果更好。

在互联网行业，你可以也会常常看到团队中产品经理之间为了谁的需求先做而争吵的面红耳赤。很大的原因是大家都没有办法说服对方，或者说没有找到一个团队内都认同的机制来合理的评估每个人的需求。在没有合理的制度规范下，每个人都会认为自己站在用户的这一边。而 RICE 就是通过一种量化需求优先级的模型，通过 4 个纬度给需求打分，然后计算出最终的得分，通过比较每个需求的得分来计算优先级。RICE 这个框架由 Intercom 提出，最开始的版本只有 ICE，之后的演进中又增加了 R，RICE 代表的意思是：

  • (R)each：触达的广度；
  • (I)mpact：影响的深度；
  • (C)onfidence：对需求的信心；
  • (E)ffort：研发成本；

Reach 代表这个需求覆盖的广度；Impact 代表影响的深度；Confidence 则代表你对问题的理解程度；Effort 就是开发成本；对于每个需求我们都要去通过这四个方面给它打分（0–10 分的范围），最后通过公式 (reach x impact x confidence) / effort 计算一个结果分 score，再通过 Score 从大到小来对需求进行排序。而这当中最关键的，就是如何给每个参数进行打分。

并非任何需求都可以直接拿来进行对比，参与对比的需求其最终目标应当是一致的。如果一个需求的目标是提升功能 A 的渗透率，而另外一个需求的目标是提升用户留存率，虽然说提升功能 A 的渗透率有助于提升用户留存率，但要记住这只是一个假设，不能作为依据，而且间接指标通常有很多其他的影响因素，也难以作为最终的观测指标。因此所有的需求都是为了相同的指标，而且这个指标一定是该需求的最直接可以影响的指标。你可以说所有的需求都是为了提升功能 A 的渗透率；或者所有的需求都是为了提升用户留存率。

Reach：影响的广度

Reach 是用来评估这个需求上线一段时候之后能够影响到的用户数量。「影响」的意思是不仅仅是让用户看到，而是能够让用户使用这个功能，这样才能直接评价由这个需求产生的影响，如果用户只是看到了这个功能，但是没有使用，最终也产生了转化，这样的结果不能直接用来判断是因为这个功能带来的转化。例如上线一个新功能，可以覆盖 1000 个用户，但实际上只有 100 个人使用了这个功能，那么 Reach 的效果就是 100 人。评估 Reach 的效果要同时考虑流量和转化率以及时间周期。

评估广度的时间周期

时间周期的设定要依据需求的类型而定和达成目标所需的时间而定。从时间周期上来划分大致有两种需求：一种是长期运营的需求；一种是短时间的季节性的需求。

前者我们评估的周期通常是按照距离目标结束的时长，通常团队都会设定每个季度的目标，那么距离需求上线到这个季度结束的时长就是时间周期，其目的是评估这个需求能够为季度目标带来多大的影响，如果这个目标是月度或者年度也是相同的计算方式。

后者因为需求本身是季节性的，上线一段时间可能几天也可能几个月或者几周，最终我们还是以月度/季度目标来计算，如果需求早于季度结束时间，则以需求上线的时长来计算；如果活动可能要跨多个季度，则按照季度结束的时间来计算。

预估流量和转化率

如果是拉新的需求，此时流量都是从外部而来，需要去估算渠道的流量。有些渠道的流量是显而易见的，上线之后立即可以看到效果，例如在某个外部网站的首页明显位置添加广告，这样就可以通过预估这个广告位的点击率和以及观察该页面的流量来计算，因为流量通常是由周期性的，有些网站周末的流量更多，有些反之，因此我们通常会观察至少过去 7 天的平均值，或者过去 30 天。

另外一些渠道例如通过 SEO/SME 很难在短期内看到效果，竞价广告的流量也不好预估，时间可以放长一点到 1 个月左右。SEO 的流量估算可以借助 Google Adwords 中的 Keyword planner 工具来进行估算。在 Keyword planner 中输入对应的关键词，就可以大致判断出该关键词每月被搜索的次数。要注意的是 SEO/SME 的前提是你的内容或者广告能够出现在搜索引擎的首页，Keyword planner 中会展示该关键词 SME 的价格区间，可以帮助判断这个关键词的竞争激烈程度，价格越高意味着竞争越激烈，那么 SEO/SME 出现在首页的难度也就更大，时间也会需要相应的拉长。

转化率相对比较难估算，如果之前有过类似的需求，可以参考历史数据，如果没有，也可以参考一些行业数据来作为支撑。

相对评分机制

在估算完每个需求可以影响的人群数量之后，接下来的问题就是如何对这些数量进行打分。这里并没有一套标准的评估方法，毕竟每个产品所面向的人群不同，所处的阶段也不同，例如 to C 产品的影响范围一定比 to B 的要大很多。

GitLab 在内部的 Handbook 中有提到一种基于对已有用户进行覆盖的打分方法，这种打分主要是面向产品已有的用户：

  • 10.0: 如果能够覆盖绝大多数已有用户（>=80%）的已有用户或者潜在用户；
  • 6.0: 能够覆盖 50%-80% 的已有用户或者潜在用户；
  • 3.0: 能够覆盖 25%-50% 的已有用户或者潜在用户；
  • 1.5: 能够覆盖 5%-25% 的已有用户或者潜在用户；
  • 0.5: 能够覆盖 <5% 的已有用户或者潜在用户；

GitLab 只是给出了 5 个等级，而且等级越大的分值会高很多，之所以这样评分是因为网络效的作用，能够影响的用户越多，越可能产生网络效应让需求自发的扩散出去。但 GitLab 的基础以已有用户为基础，如果是用在拉新上，这样的评分方式可能不太合适，我更倾向于使用一种相对的评分机制，我们也在 Sprint Grooming 中使用这样的评分机制来给 Story 评估点数。

例如我们有五个 Story 分别可以触达到这样的用户量：

  • A：13 万用户；
  • B：15 万用户；
  • C：17 万用户；
  • D：8 万用户；
  • E：14 万用户；

列出所有的 Story 之后我们要做的就是使用其中的一个 Story 来作为基准，然后与其他的 Story 进行比较。

  1. 首先选择 A 作为一个基准，给 A 设置一个分值为 5 分，你也可以设置为 4 分，只是一个选择，并不重要；
  2. 拿出 B 和 A 来做比较，因为 B > A，所以我们给 B 为的分值要比 A 大，我们先给 B 设置为 6 分；
  3. 拿出 C 和 A 做比较，得出 C > A，所以我们需要再次比较 C 和 B，然后发现 C > B，所以我们可以给 C 设置为 7 分；
  4. 拿出 D 和 A 做比较，得出 D < A，所以我们给 D 设置为 4 分，或者 3 分，因为你觉的 A 和 D 的距离还挺大，不过不重要，因为 D 大概率也不会上榜；
  5. 拿出 E 和 A 做比较，得出 E > A，然后再拿出 E 和 B 做比较，得出 E < B，此时可以对 B 和 C 的分值作出调整，因为 E 介于 AB 直接，所以可以把 B 设置为 7 分，C 设置为 8 分，然后给 E 设置为 6 分，或者你也可以给 E 设置为 5.5 分；

通过这种相对的打分机制，不需要一个固定的标准我们可以得出一个具体的分数，这样的方法还可以应用在很多没有标准的打分机制中，其他几个参数的评分方式也都是如此。而关于分值，因为 Reach 会受到网络效应的影响，也不一定需要按照 0–10 或者以 1 为跨度来评分，可以借鉴敏感开发的故事点，使用菲波纳切数列作为分值来进行打分。

Impact：影响的深度

Reach 来衡量需求影响的广度，Impact 则用来衡量需求影响的深度，也就是这个需求对每一个用户的影响。例如你的目标是提升收入，那么 Impact 就是计算对客单价的影响。Impact 取决于两方面，这两个方面其实也取决于产品经理对用户和需求的理解。如果有定性或者定量的数据来支撑用户对这个需求有提出过，并且当前人群也符合目标用户，那么影响深度就相对会比较大。

例如我们曾经有一个目标时提升付费用户的流失率，包括付费用户直接取消继续付费，或者付费用户转变成免费用户。那么第一个问题就是用户为什么流失，针对定性的问题，最好的方法就是直接跟用户交谈，深度用户访谈的成本比较高，我们也会配合简单的问卷调查，在用户准备取消的时候询问原因。问卷调查的结果展示有 50% 左右的用户流失是因为价格太贵，另外 30% 的用户是因为某些功能的缺失。这里的 50% 和 30% 实际上对应的是 Reach 的评分，而要评估 Impact 我们需要去深入了解用户。通过对用户分层，我们因为价格原因流失的用户基本上都是买便宜版本的用户，这部分用户都是入门用户，客单价在十多块钱，对价格也会比较敏感；而选择因为功能确实流失的用户则是更高级的用户，客单价都是在上百块，这些用户对价格不敏感，而更在意产品的功能能否真正解决自己的问题。这里的客单价就很适合用来给 Impact 评分。

因为 Impact 是针对个人影响深度的评分，这部分相对更加主观一些，但即便是主观也需要有证据来作为支撑。Intercom 的文章 中也为这种主观的评判提供一种评分机制：

  • 3: 意味着对用户的影响非常大；
  • 2: 意味着对用户的影响一般大；
  • 1: 意味着对用户的影响很一般；
  • 0.5: 意味着对用户的影响比较小；
  • 0.25: 意味着对用户的影响非常小；

大份的工程同样是对过两两比较的方式来进行，选定一个需求作为标准，然后使用其他需求来与之对比。

Confidence：对需求的自信

信心实际上更多的描述的是产品经理对需求和用户痛点的理解程度，这个需求是否真的可以提升用户不转化或者不点击广告，我们是否了解用户不转化的原因。我们通常使用数据来作为评估信心的指标，如果一个需求有充分的数据来佐证，那么我们的信心就会给很高；但几乎所有情况下我们都没有 100% 的把握，总会有一些猜想在里面，这也是为什么这种产品设计方式叫「假设驱动设计」，因为在这样的场景中，每个需求都是有待验证的假设，没有人可以保证用户一定想要这样的东西。在假设的验证中，数据是能够证明其有效的唯一方式，数据越多假设就越少。

这个过程中我们需要列出如果要验证这个需求有效我们需要哪些数据作为支撑，然后标记出哪些数据是已知的，哪些是未知的。未知的数据就是我们需要通过实验来进行验证的，未知数越多，信心越低，未知数获取的难度越大，信心越低。对于难度，我们简单的评估标准是获取定量数据的难度小于定性的数据，而定性的数据则通过分析所需的样本量来评估，样本量越大，难度越大。如果没有数据支撑，Confidence 可能会给到很低 10% 这样。

Intercom 同样也提出评估 Confidence 的 3 个级别：

  • 100%：有定量的数据支撑 Reach，定性的数据支撑 Impact，并且开发评估了 Effort，那么 Confidence 就是 100%；
  • 80%：有定量的数据支撑 Reach，开发也评估了 Effort，但是 Impact 没有数据支撑；
  • 50%：有数据支撑，但是数据的可信度较低，Effort 的波动也可能较大。

Effort：研发成本

Effort 是评估研发成本的，但这里并不单单是指开发和设计的成本，假设驱动的需求中通常需要进行多团队的协作，通常会需要与市场、品牌和商务等多个团队配合，而所涉及到的团队越多，成本越高。简单的研发成本可以通过人天也打分，人天越多，分值就越低，也可以敏捷开发中的故事点的方式来评分，无论如何估算，最终也是通过相对的评分机制来进行打分。

假设验证的设计第一步永远是验证假设，因为没有人能够确定这个需求是否真实有效，所以我们通常不会去做超过 10 个人天的需求，一般最多是 5 天，因为需要快速验证数据，如果一个不确定的东西需要花 10 个人天来开发，成本是相当大的。所以我们就简单的给每个人天加 1 分，如果需求超过 10 天就会超过 10 分，我们直接给 0 分（不可除）。

正如一开始所说的，RICE 并不适合所有的情况，越是底层和基础的功能，在 RICE 的 PK 中的得分可能会更低，尤其是人们可能会提出反对声音「用户根本不知道他们想要什么」，那么用户研究和数据不都是没有用了？显然这种声音会出现概念模型设计的方式中，这种需求的优先级很多时候是靠勇气而非数字来排序。但是在产品的需求更加精细的时候，RICE 实际上是在降低试错成本。也有人会提到做这些调研需要花费大量的时间，这些时间也是成本，我的看法是，如果没有足够的数据，那么应该先把经历放在数据体系的搭建中，然后再来讨论 RICE。