这种小米加步枪的状态下,负责技术的老师傅就比较惨:
今天A团队为了把这堆数据捞回来,要请技术老师傅写一堆代码;明天B团队要把那堆数据捞回来,又得请老师傅重新写一堆代码。。。
老师傅长期被“请”,疲于奔命,秀发早晚不保啊。。。
不行,老师傅们一合计,得赶快开发出一套“A/B测试工具”——甭管是哪个团队,想测啥事儿,直接把系统拿去用,最好别霸占俺们的“肉身”。
Albert,就在这个“秀发保卫战”前不久加入字节,负责开发这个名叫“Libra”(天平)的A/B测试工具。
造这个工具的难点是啥呢?
你看,A/B测试最早是用在推荐算法的改进上,推荐算法团队的同学肯定是懂代码的,所以设计给他们用的A/B测试系统并不难;
可是后来,App 的设计团队也想用A/B测试来改进 App 的外观和逻辑,他们就不是那么懂底层代码了;
再后来,运营推广团队也想用A/B测试,决定哪种推广策略拉新效果更好,他们就完全不懂代码了。。。
所以,为了照顾所有人的使用,Libra 的界面就得尽量傻瓜,最好用鼠标拖拽的方式就能创造一个实验。
Albert 回忆。
于是,一群搞底层代码开发出身的老师傅坐在一起,把数据接入、实验设置这些核心功能搞定后,还得围成一圈开始研究怎样做出一个易用的界面。毕竟不是科班出身,搞出来的第一版界面蠢萌蠢萌的。
当时的界面找不到了,给你们看看现在的界面吧(局部)
很快,各个团队就七嘴八舌地对界面和逻辑提出了各种改进意见——底层数据怎么调度他们不太关心,但是界面和逻辑改进他们很有心得。
在各个团队的“威逼”下,Albert 他们只好硬着头皮继续改进,甚至还专门招聘了前端工程师。
一个给内部用的产品,真的值得在易用性上下这么大功夫么?
可能连 Libra 团队自己也没想到,这恰恰会演变成为后来故事的一个重要伏笔,我们一会儿再说。