一条功能请求，实际上很可能是一份缺陷报告
阅读约 1 分钟
“你们能不能加一个设置项，把导出上限调高一点？“读起来像是一条功能请求，大多数分诊系统也会当场就这么打标签。有时候确实是。但有时候，导出功能在低于文档里写明的上限的某个数字上就已经失败了，原因其实是一个缺陷，而看不到代码的客户，只能凭自己能想到的最合理的说法编出一个解决方案：给我一个更大的数字，说不定就能行了。哪些标签才真正值得打讲的是那个把 backlog 分成功能请求和缺陷的类型标签；而这正是客户自己的措辞把这个标签引向错误方向的一种情况，判断出错的代价，是慢慢滑向一个塞满了请求、可一旦挖到底下就会发现根本没人真心想要的 backlog。
一条实际上是缺陷的功能请求，看起来会是什么样子
它说出的是一个绕开问题的办法，而不是问题本身。一条真正的功能请求，通常描述的是产品目前完全不支持的一种结果：“让我把这个安排到以后再做”，“加一个深色模式”，诸如此类。而一个被分错类的缺陷，描述的是一个具体的数字、阈值或行为，听起来像是缺了某个设置，但其实是个症状：“把超时时间调长一点”，“加一个重试选项”，“让我一次能导出更多行”。它的信号在于，提出请求的人建议的是一种具体实现、一个设置、一个开关、一次覆盖，而不是描述一个目标，因为她已经按照文档所写去试过那个功能了，而它并没有做到文档说它应该做到的事。
| 信号 | 功能请求 | 伪装成功能请求的缺陷 |
|---|---|---|
| 提出请求的人描述的是什么 | 产品目前做不到的一个结果 | 她想改动的一个参数 |
| 文档记录的行为是否已经覆盖了这一点 | 没有，确实是缺失的 | 有，只是没有按文档所说的那样运作 |
| 投入更多精力，请求会不会自己消失 | 不会 | 有时候会，如果这个缺陷本来就依赖某个阈值 |
| 应该被路由到哪里 | 产品 backlog | 缺陷队列 |
这件事为什么比听起来更重要
因为这两条队列有着不同的负责人、不同的时间线、不同的成功标准，而一个被归档成功能请求的缺陷，会被拿去和其他功能请求一起排优先级，跟真正的产品缺口抢注意力，而不是按照一个缺陷本该得到的时间线被修复。怎么追踪功能请求讲过，把缺陷和功能混进同一条队列，会让最大声的抱怨挤到真正的请求前面去；而一条暗地里其实是缺陷的功能请求，造成的是反方向的伤害——它会一直留在产品 backlog 里，为一个”功能”不断积累投票，而这个”功能”本该在底层缺陷修好的那一刻就消失，结果白白浪费了每一个读这份 backlog 的人的优先级排序信号。
当客户自己的措辞把方向指错时，该怎么分辨
去问她原本期望发生什么，而不是问她想让你们加什么。“导出功能卡在 500 行，我需要 2000 行，你们能不能把上限调高一点”，听起来就是一条要求调高上限的功能请求，直到追问一句”500 是文档里写的上限吗”，才发现文档里记录的数字其实是 5000，而导出功能提前就失败了。光是这一个问题——她原本期望什么，对比实际发生了什么——就完成了分类工作的大部分，因为一条真正的功能请求根本没有一段它没达到的文档化行为；没有什么可以”期望”的，因为那种能力本来就还不存在。
应该由支持人员还是工程师来做这个判断
支持人员先做第一轮判断，因为工单最先到她们手里，但这个标签应该容易改、贴错了代价也小，而不该是一锤定音、把这一条永远钉死在错误队列里的一次性决定。一个轻量的二次检查——由一位工程师每周翻一遍新打上”功能请求”标签的条目，找那些闻起来像是缺陷伪装的——就能抓住那些没有代码库背景的支持人员根本认不出来的情况。这不需要走正式流程，更像是花五分钟扫一眼，而不是一整套评审流程。
找到真正的缺陷之后，闭环的方式会变吗
会，而且能发出一条更好的消息。闭合客户反馈循环讲的是在一个请求上线时通知提出请求的人；一个被重新归类的缺陷，能得到这条消息的一个更好版本，因为”我们找到并修复了背后的那个缺陷”听起来像是有能力的表现，而”我们做出了你要求的那个功能”却只有在纯属巧合的情况下才会是真的——因为那条真正的功能请求，也就是一个真正更高的导出上限，一旦缺陷消失、原本 5000 行的上限已经够用了，可能就永远不会被真正做出来了。
如果这种误判从来没被发现，会发生什么
Backlog 会被那些看起来像真实需求、实际上并不是的请求填满，而基于这份 backlog 做出的优先级决策，会连带继承这种扭曲。一个有四十票的”功能”，实际上很可能是四十个人碰到了同一个缺陷，而如果真的把这条字面意思上的请求做出来——一个用来调高一个从来就不是真正约束的上限的设置——只会带来一堆不解决任何问题的复杂度，与此同时，那个底层缺陷还会继续从那些尚未找到这个话题的客户那里，源源不断地制造出新的”功能请求”。
FAQ
值不值得加一个正式步骤，把每一条功能请求都拿去和已知缺陷对照一遍? 不需要一个正式步骤，更像是一种习惯：不管是谁在给一条新的功能请求分诊，都应该在打标签之前先问一句”文档记录的行为是不是已经声称自己在做这件事了”，因为光是这一个问题，就能在不增加流程负担的前提下，抓住大多数分类错误。
如果找到缺陷之后，客户依然坚持这是一条功能请求，该怎么办? 向她解释你们发现了什么，以及为什么她提议的那个设置项，在缺陷修好之后就不再需要了。大多数客户请求一个绕开办法，是因为她们以为真正的修复根本不存在，而不是因为她们特别想要那个设置项本身。
一条被重新归类的条目，会不会丢掉它作为功能请求积累下来的投票或评论? 应该保留下来，并且保持可见，因为那些投票正是当初牵引出这个缺陷的证据，而把这条痕迹藏起来，只会让下一次、在另一张工单上，同样的误判更难被发现。
这种情况会反过来发生吗，一份实际上是功能请求的缺陷报告? 比较少见，但确实会发生：“这个东西坏了”有时候意味着”这个东西没有按我以为它该有的方式运作”，而这其实是一种缺失的能力，不是一个缺陷。同样的那个问题——她原本期望什么，对比文档实际写的是什么——在这个方向上也同样能起到分类的作用。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。