From Enterprise to Cloud (1)
From Enterprise to Cloud (2) --- A/B Testing I
From Enterprise to Cloud (3) --- A/B Testing II
From Enterprise to Cloud (4) --- A/B Testing III
From Enterprise to Cloud (5) --- A/B Testing IV
From Enterprise to Cloud (6) --- 测量术 I

 

我想先说说A/B Testing。 不是因为它是从Enterprise 到Cloud的第一步，而恰恰相反，我们一共用了3年时间才具备了做A/B Testing的能力。我想先说A/B Testing，只是因为我觉得它有趣。

什么是A/B Testing?

wikipedia（http://en.wikipedia.org/wiki/A/B_testing）上有很好的解释。 如下图所示(此图网络抓取，勿怪)，有两个功能A和B，按照比例随机选取用户来使用这两个功能，进而通过记录数据的方法来评判A与B的优劣。

image

 

听起来很简单，对吧？但它带来的变化很有趣。有趣在哪儿呢？它强调了一种数据驱动的文化。

之前的产品设计的驱动力多半是几个来源，a.) 客户，尤其是大客户的直接反馈，b.) 支持工程师的反馈，c.) 用户学习 (user study)，d.) 项目组的一些”创新”或技术跟进。这些来源汇总后项目组会挑选高优先级的反馈，并针对它们进行下一个周期的产品迭代。设计成什么样子，很大程度上依赖于UX/PM 个人的能力以及HiPPO (Highest paid person’s opinion)。我相信大家应该深有体会。

但这样的模式用来做Service就有很多弊端了。毕竟，Cloud面向非常多的个人用户和中小企业，只听有限的反馈来源不一定能找到需求演变的共性。同时，设计依赖于个人的灵感和对需求的透彻理解也变得越来越不靠谱了。没有人一直可以是对的，而互联网时代留给我们犯错误的机会并不会很多。

A/B Testing可以缓解这个问题。

  • 它可以测量真实环境下的用户行为。覆盖面比User Study要广得多，而且某种程度上更加可靠；
  • 它能够用统计的方法抓到较小的性能提升。把一个按钮换个颜色也许就能帮助公司提高3%的营业收入，以前的模式是非常难得出这样的结论并进行改变的；
  • 它更加有效率，并有助于创新。有了A/B Testing, 我们可以很容易的去实验不同的想法，并在短时间能去芜存菁。这在3年为周期的企业开发中是不可想象的；

有很多cases可以证明A/B Testing的有效性。曾经有PM/UX在第一个Milestone的时候力推一种新的界面模式，1年半之后，在产品发布beta的时候才发现客户非常不喜欢这个功能，不得已只好在最后发布前拿掉。如果有机会做A/B Testing，也许早在第三个月这个很sexy但不实用的主意就被远远地抛在脑后了。也有开发人员在项目中期做了很多算法的优化，但是发布之后却发现在绝大多数的用户环境中这些优化都是无效的。同样的，如果有A/B Testing，我们也许每年可以剩出成百上千的人月来专注于给用户提供价值。

我从来都不相信软件开发有什么银弹。A/B Testing 必然也有很多它的不足。比如，很多项目并没有一个可量化的目标或者目标不可用数据测量；比如，它只能告诉你结果，但不能告诉你原因；再比如，很多长期目标难于测量和量化，会导致短视。但它不可否认，仍然是一个有效的实践。

它对我们更多的意义在于，它培养了数据驱动的文化，"迫使"项目组里的每一个成员都去思考数据的价值和意义。以前，没有A/B Testing，我们仍然会采集数据。但绝大多数的人并没有真的去分析数据，项目仍然按照原有的流程。这种阶段只是有了big data，但却不是数据驱动。自从有了A/B Testing之后，每一个功能，我们都会问和数据相关的问题，这样迫使项目组中的每一个人都去采集数据，分析数据，并用数据去验证设计。

数据驱动是我个人觉得从Enterprise到Cloud的最大的改变之一。