所谓推理，不过就是把重要的细节放大。 —— 电影《唐人街探案2》

在日常产品工作中，可能占据相当多时间的一个工作就是：处理用户（内外部）反馈的问题，而这些问题大多属于Bug.

多数情况下，我们会快速地确认一遍，若确实是，则提到缺陷管理工具里，并转发给对应的测试或开发（紧急情况下）。

不过，我一直有个奇怪的念头，在产品上线或功能更新后，除了用户的反馈，那些埋在未知里又在某时某刻涌现出来的Bug，也可能掩藏着一些可能：或是后续迭代的思路、或是当前做法的反证… 如果是接手某个系统或产品，除了看交接过来的文档，亲自查反馈过来的Bug，也是个不错的加快熟悉方式。

有时候，如果没有考核、没有汇报，只是去查Bug，会有种探案的感觉，特别是遇到一些奇葩的、查到最后会“哦，原来tmd是这样”的Bug时，会有种额外的欣喜。 这不，不久前就遇到一个，正好可以来说说查Bug的一些思路。

复现过程，保留问题细节

如果你直接反馈Bug给测试，测试也会去复现一遍，会询问反馈者是怎么操作后出现的Bug. 所以出现Bug，要获取最多的现场信息，比如反馈者使用的系统版本、手机型号、浏览器名称、网络状态、操作路径、是否有操作日志等。

以上信息，无论是我们自己去查，还是测试去查，都需要明确的描述出：用户在哪个页面下，操作了什么，出现了什么，Bug是否严重，期望什么时间修复。然后附上其他对技术人员定位问题有帮助的系统、网络、日志等信息。

比如上面说的那个，是一个内部系统之间账号登录异常的问题。当接到反馈后，让使用者重现，并将整个页面截图（不要只截个报错massage）、记录下各种信息，并向反馈者初步确认账号密码是否输入正确、账号是否正常、最近一次成功登录是什么时间等。

要从头跟到尾

如果你有时间（最好有时间），那最好自己从头跟到尾。同样的内容，不同的人有不同的理解，特别还是你自己负责的部分，不是简单的转给测试或开发就完了。

逐一排除和深入

在了解问题后，产品可以先做力所能及的排查和梳理，将表现出来的问题，做进一步的展开和简洁的描述，这样能大大提高处理效率，也方便开发或测试同事快速了解。 账号登录的问题，在进一步确认后，具体问题如下：

  • 用a系统账号可以登录a系统

  • 用a系统账号登录b系统，报错

  • 前提或背景是：

    目前已经支持a系统账号直接登录b系统，是通过a系统鉴权的方式。 而之所以这样，是因为两个系统使用不同的数据库，内部账号体系也暂时未做融合。

接下来做了这几件事:

  • 先准确地向两个系统的开发传达报错的提示和相关报文
  • 再确认接口服务无问题（开发自查）
  • 再确认双方都未更换状态码相关表意（类似200表示正确）
  • 再确认用户账号密码无误，之前他都用记住密码方式登录的（这里有个坑，接口错误未明确区分，有些含混） 以上一切都无误后，我和开发同事陷入了暂时的无奈和懵逼中…

我们确认了信息输入无误，处理过程也无误，那就只能是系统用来判断的源信息有问题了：

跨系统鉴权用的源信息和直接登录鉴权的源信息不同。

然后，开发直接以用户名精确搜索用户表，发现：

该用户账号信息有两条记录 一条软删了，一条正常 ........

然后跨系统登录鉴权时，没有过滤掉那条删除的账号记录，wtmd......(好像不小心暴露了什么)

一点总结

查Bug，其实只是产品工作中的一小部分。

但，无论你是负责一个模块、还是一个系统、还是一条产品线，或者是产品管理者，也需要花一些时间，到一线调查。

抛开那些战略、方向，产品终究只是一个工匠，而工匠，手不能闲着。战略方向是引导细节，反过来，细节也反哺战略方向。