大厂的产品，出 bug？
共 2595字，需浏览 6分钟
·
2023-10-08 22:11
前阵子我写了篇文章说了下某厂产品的一个 bug，结果当天人家的产品技术团队加班到半夜修复上线了。
赶巧不巧，昨天我又发现了另一个大厂产品的 bug，只不过这次没公开说，因为我认识他们产品负责人，所以直接把问题发过去了。
他们测试后可复现，确定是一个技术逻辑上的 bug。
其他公开说的也不是对他们有敌意，而是我也不知道该找谁去反馈问题，拿出来晒晒更有利于问题的快速解决。
至于为什么这种速度更快，你们懂的。
不过我也因此认识了不少朋友，可以说是不打不相识，我认识的很多产品负责人其实都是从我吐槽他们产品开始的。
可能有读者会好奇，为什么人家那么大个厂这么多人都没发现的问题你发现了？
说实话，我也好奇，为什么我都能发现而他们这么多人发现不了？
这里要说一个大前提，凡是软件，皆有 bug。
包括你们现在手机里装的各种 App，可能 99% 的场景下使用都是没问题的，但谁也无法保证自己的产品 100% 没 bug。
另外，软件开发团队人数规模的大小并不直接决定软件本身是否出问题，只能说规模越大，出问题的概率相对小一点。
做产品的读者都知道，其实绝大多数的 bug 都不是出在主干流程的关键路径上，而是分布在各种分支流程和低频场景中。
虽然有测试人员的覆盖，但如果测试用例不全面的话也会遗漏很多细节。
我想了下，我之所以能发现这些大厂产品的 bug，其实主要源于两个原因。
第一，对产品细节的敏感。
我是个有强迫症的人，对于产品设计和流程上的细节非常敏感，以至于两个按钮大小是否一样、有没有对齐、颜色是否有差异我都能看出来。
前几天我们在北京举办了线下产品训练营，参加了的同学看过我画的产品原型设计稿，有一位同学说，这加上颜色就是高保真设计了。
确实是这样，我画原型有比较高的要求和执念，所以尽可能还原每一个细节。
虽然这种方式会让视觉设计师有点受不了，但我还是比较坚持自己的想法。当然，也会积极听取他们的专业建议。
因此，我在使用产品的过程中会特别注意每一个环节的信息、流程、逻辑以及数据，并且对每一个异常也会非常敏感。
可能也是出于职业的原因，虽然我是以用户视角去用别家的产品，但依然会用专业视角去观察和研究每个细节。
之前有人问我，你是怎么练出来的？
我说，没啥窍门，就是经常使用不同的产品，我手机里装了几百款 App，而且会不定期从 AppStore 去找新品试用。
第二，到真实场景中去使用产品。
这句话虽然看起来像句废话，但的确阻碍了很多产品技术团队发现问题。
可以说，绝大多数线上 bug 都是在真实场景中被发现的，而不是在测试场景。
在开发过程中以及测试阶段，产品会运行在公司搭建的测试服务器上，通过模拟数据和测试用例进行问题排查，这是所有产品技术团队的通用做法。
但这么做有一个缺陷，那就是对真实场景的覆盖不足。
这种不足可能是数据全面性的不足，也可能是测试用例覆盖度的不足。一旦上线到生产环境，在大规模用户和实际数据的侵袭下就容易暴露问题。
我发现的那些问题基本上都是在真实场景使用过程中发现的，可能有些问题并不严重也不影响主干流程的进行，但 bug 也确实存在。
为了解决这种缺陷，现在很多团队会采取灰度发布的策略，或者是线上热修复的技术手段。
比如微信团队，他们就经常采用灰度发布的方式来对新功能进行内测，跑一段时间场景和数据并发现没问题后再全量上线。
还有一家我知道的大厂会采用热修复的手段来应对线上 bug，这么做的好处就是不用重新发布 App 版本并提审更新。
即便如此，也无法保证上线后的产品 100% 没 bug。
还是那句话，凡是软件，皆有 bug。
除非一款产品开发到一定阶段进入稳定态，把所有已发现的问题全部解决并不再更新，那这种情况下可能的确没有 bug。
但凡产品处于迭代和更新状态，那出 bug 的几率就会一直存在。随着产品复杂度的提升，出 bug 的概率也会增大。
对于产品经理来说，我的建议是平时多用用自己的产品，更多从真实场景出发去使用，而不是测试。
使用和测试，是两种完全不同的视角。
最后，希望你做的产品没有 bug！
我在线下产品训练营中有一个章节是重点讲产品视角的，其中有很多方法和案例会帮助产品经理提升自己发现问题、需求和机会的能力。
昨天还有人问我们下一场线下产品训练营在哪里举办，其实在哪里办不是我定，而是目标城市的报名同学自己定，哪里先报满，哪里就先开，同步举行星球线下聚会。
上海、杭州、深圳、广州以及北京的同学，占座的联系我。没加我的可以直接加 tangren0517
