功能请求应该怎样追踪，才不会把它们弄丢掉

功能请求的追踪，几乎总是以两种方式之一失败。要么请求根本没有地方可去，于是就散落在收件箱和 Slack 讨论串里，一条一条地被遗忘；要么有一个地方可以去，可是再也没有人回头去看，于是就一整批一起被遗忘。一套真正管用的机制，必须同时扛住这两种失败：它需要一个所有请求都会落地的单一地点，也需要一个下个月还会有人重新打开这个地点的理由。

功能请求到底是从哪些地方来的

来自比大多数追踪系统所设想的更多的渠道。一张包含了”要是能这样就好了”这句话的工单。一条留在公开路线图上的评论。一通销售电话，客户在电话里明确说出了阻碍成交的那一件事。产品内部的一个小组件。每个渠道都有各自的负责人，也有各自的工具，而正是因为这样，请求才会四处分散：工单队列和产品团队的待办清单，几乎从来都不是同一套系统，而一条只到达了其中一个渠道的请求，实际上也就只到达了一个部门而已。

为每一个渠道各自建一个接收表单是不管用的，因为根本没人会真正采用它。真正有用的做法，是让每一个渠道最终都汇入同一个目的地，哪怕一开始这种汇入方式，只是每天花五分钟做手动的复制粘贴，直到它被自动化为止。

到底是什么真正拖垮了功能请求追踪

几乎总是两件事。第一件，是缺少一个明确的去处：请求在它到达的那个渠道里就地得到了回应，却从来没有在任何地方被持久地记录下来，于是同一个请求即便来自三个不同的客户，看起来也只是三条互不相关、各自孤立的一次性回复，而不是一个明确的信号。第二件，出现得更频繁，是一个塞满了、也就没人再去读的去处。一份没有任何筛选机制、堆了 400 行的表格，早就已经不再是一套追踪系统了，它只是一个碰巧还能被编辑的档案库而已。

第二种失败反而更危险，因为它看起来就像追踪机制在正常运转。请求确实被记录下来了。表面上一切都没什么问题，直到有人问出”到底有多少人要求过 X”，而诚实的回答只能是”我们得把这 400 行全都读一遍才能知道”。

一条功能请求真正应该记录下来的是什么

要足够详细，才能让后来的人不用重新去读原始消息，就能回答三个问题：到底提出了什么请求，如果可能的话，尽量用提出请求的人自己的原话；是谁提出的，如果最后的答案是”我们已经把它做出来了”，又该怎么联系到她；以及需要知道些什么，才能判断这到底是一个普遍的请求，还是一次孤立的个案。逐字的引用，永远比转述更有价值，因为无论是谁负责分诊这条请求，他写出的转述里其实已经带上了他自己的理解，而恰恰正是这份理解，是六个月之后的第二个人再也无法核实的东西。

哪些标签才真正值得打

两种，各自回答不同的问题。类型标签把一条功能请求和一份缺陷报告区分开来，因为两者需要不同的负责人、不同的时间线，把它们混在同一条队列里，只会让最大声的抱怨挤到请求前面去。优先级标签保持在 low、medium、high 这样一个很小的集合里，把”正挡着某个人没法使用产品”和”有了会挺不错”区分开来，因为这两者本该获得截然不同的响应速度，而任何一方都不该继承另一方的节奏。把类型标签贴对，前提是这条请求真的就是它自称的那样；一条功能请求实际上可能是一份缺陷报告讲的正是客户自己的措辞把这个标签引向错误方向的情况。

自动分诊可以在请求到达的那一刻，同时打上这两种标签。在 changeloop 里，一条来自小组件的提交，会在同一个步骤里获得 feature-request 或 bug 标签，以及一个 priority:low|medium|high 标签，再加上一个 from-widget 标签，让来源不用打开这条记录就能被看到。光是这样，就足以把整个待办清单从要花一下午才能筛完，缩短到一分钟就能筛完：把这个月所有从小组件来的高优先级功能请求都给我列出来。

一旦有了公开路线图，第三种标签就开始变得值得使用了：一个提出请求的人自己就能查到的状态。公开路线图完整讲解了 planned、building、shipped 这几种状态；简单来说，这个标签会把一条私有的队列，变成提出请求的人不用再重新问一遍，就能自己查到的东西。

该怎么决定接下来要做什么

先分组，再计数。十条用不同措辞表达的、其实是同一种底层能力的请求，堆在表格里看起来就是十行散乱的数据，可一旦被归到同一组，它们就会变成一个很强的信号，而这种归类往往才是缺失的那一步，计数从来都不是。没有分组、只是简单堆出来的原始数字，往往会奖励那个名字最抓人眼球的功能，而不是那个背后真正有最大实际需求的功能。

按谁提出了请求来加权，而不只是按有多少人提出了请求。一个即将续约的客户提出的请求，和一个刚注册试用的账户提出的同一个请求，紧迫程度完全不一样，而一套为了追求一个干巴巴的数字，就把这层背景信息直接丢掉的追踪系统，优化的其实是那个最容易计算的数字，而不是那个最有用的数字。

这里做出的每一个决定，同样也会产生一批被淘汰的请求，而这些请求同样值得一个回应；该怎样拒绝一个功能请求 讲解了该对那些没能通过的请求，说些什么才合适。分组和加权只解决了”接下来该做什么”这个问题的一半；功能请求优先级排序 讲解了真正管用的几种框架、RICE、按收入加权、原始数字，以及每一种各自在哪里会失灵。

等到某个东西真正发布之后，该怎么闭环

这是追踪系统最常跳过的一步，也是提出请求的人真正会注意到的一步。闭环：从客户反馈到告知客户完整讲解了背后的机制；这里要说的重点是，闭环这件事，只有在原始请求始终和提出它的人保持关联的情况下，才能真正生效。一份从 GitHub issue 构建出来的功能请求模板，把提出请求的人的身份直接挂在这个 issue 本身上，而不是埋在某一条评论里，正是这一点，才让一条自动发出的”已发布”通知成为可能，而不必依赖某个人凭记忆去手动发送它。功能请求模板展示了具体的模板内容，也说明了每一个字段到底是做什么用的。

FAQ

追踪功能请求应该用什么工具? 团队本来就已经每天都在看的东西，胜过任何一个没人会打开的专用工具。如果工程团队本来就活跃在 GitHub 上，issue 追踪器就会用得很顺手；如果产品团队本来就活跃在某个地方，一块轻量级的看板也会用得很顺手。工具本身其实没有那么重要，重要的是它到底会不会被重新打开。

怎样才能避免功能请求被重复记录? 在按措辞分诊之前，先按底层能力分组。在创建一条新请求之前，先在已有的请求里搜索一遍，这一步能拦下大部分重复；再加上每月一次的分组整理，能把剩下的也清理掉。合并重复请求却不丢失原来的声音讲的是分组本身完成之后，该拿那些措辞怎么办，这样合并才不会悄悄把请求收窄成最先到达的那份提交问过的东西。

是不是每一条功能请求都应该得到回复? 每一条都应该得到一个确认，哪怕很简短，但并不是每一条都需要立刻做出决定。一个可见的状态，比如一个提出请求的人自己就能查到的路线图标签，就能替代掉团队原本需要一条一条单独回复的那大部分工作。

功能请求追踪和公开路线图之间有什么区别? 追踪是每一条请求的内部记录，包括那些永远不会被真正发布出来的请求。公开路线图则是团队愿意公开承诺的那一部分子集，并配有一个提出请求的人不用再重新问一遍，就能直接看到的状态。

本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。

changeloop 相关页面： 开发者文档, changelog 工具对比