支持工单对功能请求：你到底应该相信哪一个
阅读约 1 分钟
功能请求看板捕捉的是用户有时间坐下来、把自己想要什么说清楚的时候，主动提出的东西。支持工单 捕捉的是用户此时此刻卡在哪里，往往还带着一点恼火，往往还缺乏把背后那个真实诉求干净利落地表 达出来的词汇。这两者都是真实的信号，而只盯着其中一个看的团队，最终会自信满满地去解决一个 错误的问题，因为每一个渠道都会系统性地过度代表某一类用户和某一类需求。给功能请求排优先 级讲的是给已经上了看板的东西排名；这篇文章讲的是那 个介于”到底有没有上看板”和”只会以支持工单的形式出现”之间的差距。
为什么同一个底层问题会出现在一个渠道里，却不出现在另一个渠道里
因为这两个渠道的激活成本不一样，而这个成本的高低，决定了谁能跨过它。提交一条功能请求需要 主动性：用户必须相信这个请求值得被说清楚，还要找到那个看板，写点条理清楚的东西，这个过程 本身就筛选出了那些已经投入到产品里、既参与又有耐心的用户。相比之下，提交一张支持工单几乎 不需要任何主动性，往往只是在一项任务进行到一半时点一下”帮助”而已，这意味着它捕捉到的是当下 就感到沮丧的用户，包括那些永远都懒得去碰一个功能请求看板的人。产品里一个真实存在的缺口， 完全可能在功能看板上悄无声息，却在支持渠道里吵得沸沸扬扬，仅仅是因为遇到它的那批用户，恰 恰是最不可能去提交一条正式请求的人。
一个缺失功能的工单量，跟它得到的投票数，意味着同一件事吗
不，因为它们衡量的是不同条件下的不同群体。一条获得一百票的功能请求，代表的是一百个愿意花 时间去找到并支持一条已有请求的人，这是一个持久、深思熟虑的需求的强烈信号。而在同一时期内， 关于同一个底层缺口提交的一百张支持工单，代表的很可能是一批当下正撞上一堵墙的用户，其中有 些人一旦当下这点摩擦过去了，可能就会把这件事彻底忘掉。把这两者都当成同等的”一百个人想要 这个”信号来对待，会高估工单量的分量，因为工单生成起来很便宜，而投票不是。
| 功能请求看板 | 支持工单 |
|---|---|
| 提交需要主动性 | 几乎不需要 |
| 捕捉深思熟虑、持久的需求 | 捕捉当下这一刻的沮丧 |
| 偏向那些既参与又有耐心的用户 | 捕捉那些永远都不会去用看板的用户 |
| 投票数是一个真实的承诺信号 | 工单数反映的是摩擦，未必总是渴望 |
一个功能有支持工单、但看板上几乎没有投票，这意味着什么
往往意味着这个请求确实存在，只是遇到它的那批用户不知道有这个看板，不相信投票会改变什么， 或者遇到这个问题的频率太低，懒得为了正式登记它而换个渠道。这恰恰就是一个功能请求看板在结 构上会漏掉的那批人群，这里低下的投票数是一种测量缺口的证据，而不是需求低的证据。与其不信 任工单，不如把围绕一个缺失功能形成的一批支持工单集群，当成一个独立的信号，由你自己代表用 户把它登记到看板上，这样它就不会对那些只凭投票数排优先级的人保持不可见。
看板上读起来是低优先级：
"Export to CSV"：6 个月里 4 票
支持渠道讲的是另一个故事：
"Export to CSV"：同一时期 31 张工单，每一张来自
不同的账户，每一张都以"目前尚不支持，我们会转达
这条反馈"关闭支持工单的激增，是不是总是意味着底层问题就是一个缺失的功能
不是，而这正是两个渠道有可能朝相反方向误导你的地方。工单激增同样常常是由一个围绕着某个已 有功能的、令人困惑的界面，一个 bug，或者一次没有配上足够说明就上线的变更所引起的，而这些 情况没有一个能靠造一个新东西来解决。把每一次工单激增都读成”用户想要一个我们没有的功能”， 会做出一份塞满了各种东西的路线图，而那些东西其实原本只是文档缺口或者伪装成别的样子的易用 性问题。支持工单会告诉你摩擦在哪里；但它本身并不会告诉你解决方案到底是一个新功能、一次界 面改动，还是一篇更好的帮助文章，而把这些混为一谈，只会把工程时间浪费在错误的解决方案上。
在决定要构建什么的时候，这两种信号到底应该怎么真正结合起来使用
用工单去找出摩擦到底在哪里，再用功能请求看板，加上在看板信息稀薄的地方做一些直接接触，去 确认那个真正想要的结果到底长什么样。一批工单集群能识别出一个真实的、被切身感受到的问题； 但它很少能精确到足以据此直接开工构建的程度，因为一个在支持对话里感到沮丧的用户描述的是症 状，而不是规格。而功能请求看板，当它在同一个底层问题上积累了足够多的投票时，往往能承载更 多”这东西到底怎样才算真正满足了需求”这方面的细节，因为写一条请求本身，就已经是在明确表达 自己想要什么，而不只是报告哪里出了问题。
支持坐席是否应该自己把工单登记成功能请求
应该，而这正是弥合这两个渠道之间那道缺口，杠杆效应最大的单一改进。一个能认出某张工单其实 是一条伪装过的功能请求的坐席，与其只是把它解决掉然后继续往下处理，不如代表客户把它登记到 看板上，这样就直接弥合了那道测量缺口，而不必要求客户自己去发现并使用第二个渠道。但这只有 在登记这件事对坐席来说只需要几秒钟、而不是几分钟的时候才能成立，这样做这件事的摩擦，才会 低于干脆关掉工单、转向下一张的摩擦。
FAQ
如果功能请求的投票全都来自同一个账户或同一个团队，是否应该打折计算? 应该，按不同的账户或组织来加权，而不是按原始投票数来算，因为来自同一家公司五个人的五票， 代表的是一个客户的优先级，而不是五个独立的需求确认。
一个在工单里大量出现、但几乎没有投票的功能，值得去构建吗? 往往值得，前提是这些工单量确实来自不同的账户，而且那个底层需求已经被确认过，而不是被假设 出来的；把低投票数当成看板激活成本带来的一种测量产物，而不是需求不真实的证据。
怎样才能一眼分辨出一张界面困惑工单和一张真正缺失功能的工单? 看看它的解决方式，到底是在解释一个已有的能力，还是在为一个缺失的能力道歉。“哦，其实它就在 那里”这种解决模式，指向的是一个界面或可发现性的问题；而”这个我们目前还不支持”这种模式，指 向的才是一个真实的缺口。
在支持量非常小的情况下，这个区分同样那么重要吗? 机械意义上没那么重要了，因为少量的工单本来就很容易一张张单独去读，用不着做汇总分析；但那 个底层的偏差，工单会过度代表沮丧的用户、而低估有耐心的用户，在任何规模下都是存在的，即便 你自己亲自读每一张工单，这一点也依然值得记在心里。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。