功能请求越堆越多的时候，到底该怎样排优先级
阅读约 1 分钟
把功能请求跟踪起来，解决的是它们该放在哪里这个问题。真正该先做哪一个，这个问题并没有因此被解决，而团队真正卡住的地方，恰恰就是这第二个问题。哪怕已经分好组、打好标签的三百条请求堆在待办列表里，依然需要一条决策规则，因为”做那个被要求得最多的东西”这条规则，只有在两条请求票数接近、而第三条又冒出一个嗓门特别大的支持者之前才管用，而这种情况几乎每周都会发生。下面这几种框架，并不是在争夺同一个问题的答案。每一种都恰好适合某一类特定的请求，而拿其中一种去套所有情况，往往才是真正的错误所在。
给功能请求排优先级，跟给路线图排优先级，到底有什么不一样
路线图上的决策，起点是战略，问的是该做什么。功能请求上的决策，起点则是已经真实存在的需求，问的是要不要针对它采取行动，而这两者足够经常地朝着相反的方向拉扯，以至于一条需求量很大的请求，完全可能依然不该被做；一条需求量很小的请求，也完全可能因为能打开一个战略性客户而依然值得去做。把每一条请求都当成路线图上的一张选票来对待，恰恰跳过了这一步检查。
| 框架 | 权衡的是什么 | 在哪里会失灵 |
|---|---|---|
| 原始请求数量 | 多少人提出过要求 | 奖励的是好记的名字，而不是真实需求 |
| RICE | 覆盖面、影响力、把握度、投入成本 | 需要没人对一条新请求真正掌握的估算数据 |
| 按收入加权 | 是谁提出的，按客户账户价值算 | 会忽略那些价值暂时还不高的账户提出的请求 |
| 公开投票 | 一个看得见、成本很低的信号 | 只能触达那些本来就知道该去哪里看的用户 |
RICE 到底是什么，它对功能请求真的管用吗
RICE 从覆盖面、影响力、把握度和投入成本这四个维度给一个想法打分，再用前三项除以第四项，得到一个可以互相比较的数字。它最初是为团队已经相信的路线图想法设计的，真正难的部分是把各种不一样的赌注互相拿来比较。功能请求本身就自带一个覆盖面数字，也就是提出请求的人数，这比一个刚冒出来的路线图想法通常自带的覆盖面要具体得多。RICE 在面对一条请求时真正会绷紧的地方，是把握度和影响力：一个团队完全可以确信某条请求是真实存在的，却依然没有任何依据，说清楚它到底会把某个指标推动多少，因为一条已经有名字、有真实用户留下痕迹的请求，它的”影响力”跟一个屋子外面还没人见过的想法的影响力，本来就是两种性质不同的估算。
把 RICE 用在那些正被认真考虑、但还没拍板的请求上。不要拿它去套每一条刚进来的请求；打分这件事本身的投入，只有在两条请求票数足够接近、真的需要一个东西来打破平局的时候，才算得上划算。
到底该按收入加权，还是该按提出请求的人加权
按提出请求的是谁加权，但不能只看收入。一个即将续约的账户、一个已经升级投诉过一次的账户、以及一个其请求正卡着某笔正在进行中的交易的账户，都带着一种单靠一个扁平的收入数字根本抓不住的紧迫性，而一条来自试用注册的请求，只要它正卡着一个很快就会变成收入的决策，依然可能非常重要。按收入加权是这几种方法里算起来最容易的一种，也正因为这一点，它才最容易被过度信任：它能正确地滤掉那些没有真实利害关系的账户带来的噪音，但同样轻易地，它也可能压低一条本能带来一个仍处在销售管道里、体量大得多的账户的请求。
投票到底扮演着什么样的真实角色
对已经存在的请求来说，投票是一个便宜、持续的信号，但用它来发现哪些请求原本就该存在，效果并不好。投票数只能触达那些已经找到这条请求、并且认为值得点一下的用户，这就意味着一个公开路线图上的投票总数，反映出来的可见度跟需求本身其实差不多多：一条排在列表靠前位置的老请求，会因为它更容易被找到这个原因，继续源源不断地积累投票，而一条同样真实、只是更新的请求，只能从零开始。公开路线图 一文主张把投票从路线图上完全拿掉。把投票当成一个需要分组、并按新鲜程度加权的信号来对待，而不是一份按顺序照单全收的排行榜。 支持工单对功能请求 讲的是投票数里的另一个盲点：如果遇 到某个真实缺口的用户根本找不到看板，这个缺口可能几乎产生不了投票，尽管它在支持渠道里其实 吵得很响。
声音最大的客户什么时候会赢，这算不算一个问题
有时候会赢，而这只有在没人注意到的时候，才真正算得上一个问题。一个经常升级投诉、写详细工单、或者跟团队里某个人有直接联系渠道的客户，他的请求被审视的速度，会比一个同样正当、但更安静的客户快得多，而一个从来不去核查这一点的优先级排序流程，只会系统性地偏向最坚持不懈的那个人，而不是理由最充分的那个人。声音大的客户本身并不是需要修正的问题；他们的请求往往真的很重要。真正该修正的是一种习惯：定期按来源把待办列表过一遍，检查是不是同一小撮账户解释了最近发布内容的大部分，再问问自己，这跟真实需求真正所在的位置是否吻合。
一个优先级决策，到底该怎样变成一句回复
这里做出的每一个决定，都会同时产生赢家和输家，而两者都应该得到一个说清楚真实理由的回复，而不是一次没有任何解释的状态变更。该怎样拒绝一个功能请求 讲解了该对一条落选的请求说些什么，才能让它听起来不像一句套话式的拒绝，同时把关系维护得完好无损。让这一切从一开始就变得可能的分组和打标签工作，功能请求追踪 里有完整讲解；排优先级这件事，只对那些已经被记录下来、并且分组分得足够好、可以拿来互相比较的请求才真正管用。
FAQ
给功能请求排优先级，最好的框架到底是哪一个? 没有哪一个能单独撑起全部工作。用原始数字去找出声音最大的信号，用 RICE 去比较一份认真挑出来的候选短名单，再用一次收入或账户层面的核查，去捕捉那些来自战略客户的安静需求，实际上比一个声音更大、却没那么重要的群体分量更重的情况。
功能请求是不是应该跟路线图想法用同一套方式排优先级? 不应该。路线图想法的起点是战略；功能请求的起点则是已经真实存在的需求。把两者放在一起打分，会让一个论证扎实、但现有需求不多的战略性赌注，持续输给一条仅仅因为提出的人数更多而胜出的请求。
公开路线图上的投票，是不是能准确反映真实需求? 只在那些已经找到这条请求的人当中才成立。更老、更显眼的请求，会更快地积累投票，跟一条更新的请求背后到底藏着多少真实需求完全无关，所以把投票总数当成一个需要分组、并按新鲜程度加权的信号来对待，而不是一份按顺序照单全收的排行榜。
功能请求的优先级，到底应该多久重新评估一次? 按一个固定的周期来做，而不是只在有人升级投诉的时候才做。一次每月或每季度进行的复盘，重新给请求分组、重新核查权重，能够捕捉到诸如”某一小撮账户主导了发布内容”这类漂移，而一个纯粹被动反应的流程，永远没法自己把这种情况暴露出来。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。