月刊（第25期）：爱具体的人

本篇是对二〇二四年一月至三月的生活记录与思考。

鸽了两期没有更新，从过年至今为止的假期和周末一直在准备着 T11 答辩，这周答完了算是暂时解脱了，空闲的周末又回来了。

前两天参加了一个司内的 TED 演讲，演讲前一晚准备了下 PPT，当天对着 PPT 练了两遍流畅性和节奏就直接上去讲了。我一直认为演讲不需要稿子，重要的是台风稳，需要根据听众的反应去动态调整要讲述的内容和节奏。但距离我上次在台上讲话已过去整整六年，刚开始上台还有些紧张，但随着状态渐入佳境，未曾想到最终居然拿了个冠军。意外之余，更多的是欣喜。

这期内容则是以文字的形式记录下我这次演讲的主题——《爱具体的人——研发质量保障的人文关怀》（已做脱敏处理）。

如果你现在面临一个选择，一边是个别的无法复现的用户反馈，另一边是亟待上线的 Feature。那么基于定语的限制与 ROI 的考虑，我想大多数人、也包括我，会毫不犹豫地选择优先做需求。那么希望听完这次演讲，大家可以对这个毫不犹豫的选择产生一点点的思考。

在我们业务场景下，用户的反馈率是相当低的，当然这一定程度上是因为业务体量大、分母大，但这并不意味着用户的反馈就不值得优先关注。如果用户的反馈不能及时得到解决，那么用户会极易暴躁。就像我这前两天刚截的图，但其实还有更多类似的反馈，言语实在难登大雅之堂。那么这个时候在我看来，这个用户和产品的纽带已经变得愈发僵硬了。

但其实只要认真去观察，可以发现绝大多数用户第一次反馈的言辞其实是友善且恳切的。因为用户喜欢这款产品，所以他遇到问题才会反馈。他的初衷是希望自己的问题得到解决，他希望去帮助我们改进这款产品，让它变成更好的样子。

我再举一个例子，前几天我灰度了一个技术容器，监控发现有个接口报错了几次。我赶紧去查了一下，因为这个接口的报错会导致用户直接进不了游戏，发现这两天这个错误只影响到了两个用户。针对其中一个用户捞日志上报，发现出现这个问题之后，他每天早上、中午、晚上每隔几个小时都会去尝试登录游戏。很遗憾，他每次都无法登录，但他依然在尝试。我可以感受到他焦急的心理，于是当天晚上优先处理了这个问题。

在这里我不是想说这个 Bug 多严重多隐蔽什么的，而关键的点在于，这个用户从始至终，他都没有反馈过。那我们可以想象，如果这个问题一直被忽略，我们就必然会流失这两个用户。而即便他们流失了，我们在大盘上也永远发现不了这个事实。因为这个分子，微乎其微，甚至还无法在转化率曲线上留下一丁点数值上的波动。

那么对于有反馈的人呢，如果我们解决了他们的问题，他们会回馈以我们感谢、表扬、鼓励。这个时候我能真正感受到屏幕后面的反馈是一个一个活生生的人，而不是 UID + UserAgent 的标签而已。其实我身边也有长辈使用我们的产品，那么想象下，当自己的长辈遇到送礼送不出去的问题、好不容易完成任务却无法领奖、想玩游戏却无法登录，我们又该会去怎么处理它呢？