可怕的不是那些人比你聪明比你努力，真正可怕的是他们比你有勇气试错并能迅速改错。
微信的研发团队一直信奉这样的一句话：在互联网开发里，如果能够有一个团队在更短的时间内尝试了更多机会，并能改进过来，就能获得更多胜出的机会。
《微信改变世界》里讲微信有四大法器：大系统小做、让一切可拓展、必须有基础组件和轻松上线。这里的轻松上线的关键就是黑白平衡，产品上线的黑白之间，必须先有小范围尝试的一步，然后再逐步放量，直至覆盖全量用户。黑白之间有个灰，那么实现灰的方式就是A/B测试。
Pony 曾说：“很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。”
灰度发布和A/B测试给了我们快速试验并改进的机会，并极大的减少了风险。
眼前的黑不是黑，你说的灰是什么灰
非黑即白从来不是一种普遍现象，从色彩角度讲，灰度指不饱和的黑色，我们把黑色定为基准色，每个灰度对象是从白色（0%）到黑色（100%）的中间值，这中间的98%都是灰。
互联网产品的几个特点：用户规模大、版本更新频繁。新版本的每次上线，产品都要承受极大的压力，而灰度发布很好的规避了这种风险。
产品发布的黑白之间存在一种平滑过渡的方式，就是灰度发布。从产品用户群中选取部分用户投放 A 版本，另一部分投放 B 版本，根据两个版本的用户数据反馈，逐步扩大范围，确定最终放量投放那个版本。
一套完整的灰度发布机制会包括下面这些阶段：
用户标识：主要是区分用户，同时也为数据分析做辅助。
目标用户/流量筛选：需要参考用户特征、用户流量、用户范围及用户体验的一致性，版本迭代针对全部用户还是部分用户，小流量试验通过再放量，一般来说按照内部用户-种子用户-活跃用户-所有用户的顺序就是一种典型的范围控制，体验一致性要求考虑新旧版本的跨度是否过大，用户能否接受。
实时数据监控：监测诸如新版本稳定性、服务器稳定性、使用次数、使用频率等数据与原有数据对比。
一键发布/回滚：从数据反馈结果决定是否发布/回滚。
有人质疑灰度发布是一种浪费。但与其说这是浪费不如说是冗余和弹性，灰度发布能避免新版本全量上线的风险，通过小流量验证的方式，在灰度阶段就能发现、调整并优化产品中的问题，平滑迭代。
灰度如何实现？
企业内部灰度发布的实现方式有两种：自建灰度发布系统和第三方工具。
自建
在这个案例里，通过前端灰度发布，后端数据即时转换，部分营业厅试行，用户无感知升级迭代，实现了前后端、系统层，以及实现过程的灰度发布。
对于开发团队富裕、内部沟通良好的团队可以尝试自建系统。一般自建系统会包括分流控制系统，业务监控系统，服务器负载均衡等，同时还要兼顾拓展性，以及大业务量支持。这也意味着开发和运维成本高昂，一般的企业难以承受。
第三方工具实现
可用的第三方灰度发布工具很多，国内的有吆喝科技，国外的有 Optimizely 、 ABTasty 、 Apptimize 等，使用这些工具可以使我们更加快速、高效的实现灰度发布。
这里以吆喝科技的灰度发布功能为例，对于 iOS 应用来说，新版本发布要先经过7天的审核，若产品上线出现问题会被退回，更新升级后又要经过7天的审核周期。任何版本发布直接面对全部用户，线上事故/Bug 对用户影响极大，解决问题周期长，用户体验较差。
接入 SDK 进行小批量用户测试，减少全用户发生线上事故/重大 Bug 概率，保护性开发，一键回滚，无再审核时间，实现绝大多数用户对 Bug 无感知。
第三方工具的优势在于快速上手，成本极低。在国内人口红利不再，人力成本高昂的今天，擅用合适的第三方工具能很大程度上提高企业的 ROI 。
PM：撕得了逼，用得了A/B
回到在文章开头讲的这句话：可怕的不是那些人比你聪明比你努力，真正可怕的是他们比你有勇气试错并能迅速改错。试错不是不成功便成仁，这中间也有一度灰，对于A/B测试来说，失败的试验很常见，因为在不会造成不良影响的情况下，你能尝试所有“想犯的错”。
对产品来说，使用A/B测试工具应该成为一种能力。A/B测试不是对产品经理 sense 的冲击，而是让一名优秀产品的灵感和决策更有依据。
本文由吆喝科技原创发布，转载请联系吆喝科技（微信：appadhoc）
吆喝科技：A/B 测试驱动产品优化，提升转化、留存和你想要的一切