✍️ 数据说了算，但数据不是一切——我对「好与不好」的认知转变

我最近加入某家公司做软件开发实习，在初来乍到的几天，产生了：为什么一切变更都要「开实验」？为什么一个十几行代码的小需求可能会等几个月才定型，只为了等「数据回收」？本文就来记录一下，我从学校、个人开发到参与真实世界实习工作中，最重要的三次认知转变。

「什么是好的」其实并没有统一的标准

在学校应对一场考试时，课本就是唯一的真理。拿最基础的 C 语言举例，课本中还在教的 register 关键字，现实世界开发早已不用，但考试前还要突击背那古旧的语法。why？因为在考试面前，课本就是「好」的，按照课本所述去答就是「对」的。
在学校生活的课本之外，我也自己写过一些小项目，有些是为了练手，为未来工作做准备，而有些则只是为了用自己的软件技术解决我生活中遇到的需求。在这些实践中，我发现了课本上的 register 变量、Servlet / JSP 等技术、MIPS 架构处理器其实并没有什么人在用，课本上的「好」变成了「不好」。
现实世界为什么不用 Servlet / JSP？互联网公司开发软件时为什么不采用 waterfall 模型？因为现实世界中它们是被淘汰的技术，是「不好」的。教学场景中，它们为什么「好」？因为教学需要可控的成本，考试需要稳定的考点和统一的标准。现实世界中它们又为什么「不好」？因为现实世界中需求高速变化，而且技术需要解决的问题本身变了 —— 从「能写出来」到「能高效、稳定地写出来」。

「谁认为是好的」其实也都没有什么用

如果说从学校到个人开发的冲击是「原来课本不是真理」，那进入企业后的第二层冲击，就是「原来我自己的经验也不是真理」。
个人开发中，经验主义是极为高效的。自己用过某种写法，觉得好用，就会当作「公式化打法」一直用，并认为它是「好」的。但顾全大局的企业开发里，个人认为的「好用」只是偏见。比如，你觉得「这个交互更顺手」，可能只是因为你是开发者，你知道每个功能藏在哪，而普通用户根本找不到。又比如，一位同学觉得「这个页面应该预加载，点起来会更顺手」，而你觉得「这里没必要上预加载，手机会发烫」，类似这种问题每个人都有自己的经验。如果每天都把时间浪费在个人 flavor 的辩论中，将会造成旷日持久的骂战，那还如何维持软件产品的高效迭代呢？今年三月份我就因为这个，尝到了血的教训。

所以，为什么要用数据和实验说话？

现实世界中，在「用户到底喜欢什么」或者「哪种性能优化方案跑起来更优」这个问题上，谁说了都不算。 你的经验不算，上级的经验不算，甚至整个团队的经验加起来也不算。那谁说了算？用户说了算。怎么知道用户怎么想呢？这就需要用数据说话。数据是最可感知的用户声音。
你可能觉得数据看板上 1% 的涨落不算什么，但真实世界的软件规模太大了。个人项目里，一个按钮放左边还是右边，可能只是几个朋友用起来顺不顺手的问题。即使做错了，也不过是我自己多点两下，或者少几个朋友愿意继续用。但对于月活有上亿规模的企业软件产品，一个百分点就不再是抽象的数字，而是真实的几十万甚至上百万用户，对应着软件的真实口碑。如果工程师的个人决策造成指标跌了 1%，那背后对应着数十万对着手机骂街的用户，软件的口碑会在这些人的社交圈中一落千丈。
正因为如此巨大的用户规模，数据和 A/B 实验在这种情况下是极其有效的。实验的意义，就在于把这种研发 / 产品「个人 flavor」的不确定性控制在现实世界中可观察、可比较的范围内。

用一个开发过程中的例子说明 …

假设某个页面的下一级页面加载比较慢，有同事提出：我们可以在用户进入当前页面后，提前 300ms 请求并载入下一个页面。从直觉上看，这个方案当然是「好」的。谁会不喜欢更快的页面呢？但另一个同学可能会立刻提出反对：用户不一定会去下一级页面，预加载很可能会浪费流量，还可能让低端机发热、卡顿。对于用户来说，这未必是好的体验。
两边说的其实都对，但也都不完整。因为真正的问题不是「预加载好不好」，而是在这个具体场景下，对这批用户、这个页面、这个触发时机，「预加载带来的收益是否大于成本」。这就是数据和实验最有价值的地方。
设计 A/B 实验，把预加载先推给一小部分用户。然后同时观察多个指标：下一级页面是否会更流畅，当前页面卡顿率有没有变化，流量和耗电是否可接受，用户是否更频繁地退出或投诉。如果实验结果显示，预加载的优化是显著正面的，那它就是「好」的，是值得推给所有用户的优化，但如果实验结果显示低端机卡顿率上升，那预加载与否的策略就需要调整，再重开实验。
由于实验还未固化，策略是可以随时调整和回滚的。试想一下，如果这个预加载策略的代码真的固定到了软件包体里，那会造成多少低端机用户的流失？

数据观测需要合理，不能捡了芝麻丢了西瓜

说到这里，好像数据就是一切，什么都要等数据说话。但我在工作中遇到的一个真实案例，让我对这件事有了新的思考。
公司软件产品的某个页面最近采用了跨端技术重写，该版本没有对接系统返回键，侧滑返回并不能像 native 版本一样生效，只能点击左上角的（x）图标。数据上看，指标确实变好看了 —— 用户如进入该页面，如果想返回，必须（而且可能在设备卡顿的情况下）用大拇指点击小得可怜的（x）键，并（可能在设备卡顿的情况下）过掉一个挽留弹窗，才能退掉。但我提出了疑问：这对体验真的好吗？
讨论到最后，团队的共识是：不能为了成功率牺牲用户体验。不支持系统返回，客观上短期数据确实好看了，但这本质上是在「堵用户的退路」，靠限制用户操作来抬升指标，只是某种数字游戏。团队决定先继续做小范围实验，采集数据，量化侧滑返回对指标的影响，但长期来看，还是会推动接入系统返回，在保证体验一致性的前提下，再通过精准的数据分析和优秀的功能设计，去提升总体指标。
这件事给我很大的启发：数据很重要，但它只是用户体验的一种量化表现。让数据增长不是目的，留住用户的心才是目的。
如果你只盯着你关心的那个指标，很容易做出短期数据上好看，但长远来讲可能影响体验和口碑的决策。这只是陷入了「局部最优」，而不是「全局最优」。好的数据驱动，是用数据找到「既提升指标、又不损害体验」的路径；而不是为了你关心的那单个指标，什么都敢做。应当合理且谨慎。

回过头看，从学校到个人开发，再到真正参与企业中的软件开发实习，我对「好与不好」的理解经历了三次坍塌又重建：先是发现课本定义的「好」只服务于考试，然后发现自己经验定义的「好」只服务于个人偏见，最后发现哪怕是数据定义的「好」，如果只盯着单一指标，也可能是一种新的偏见。
实验的真正价值，是把「好」的选择权还给用户：把原本无法验证的直觉和分歧，通过相对可控的用户规模进行真实验证，最后浓缩为数据 。但数据终究是手段而不是目的。让指标好看不是终点，让用户真正愿意留下来、用得舒心，才是企业开发中做这一切实验和分析的初心。