DevOps 文字培训

如何借助 DevOps 改善假设，让组织由实验和学习驱动？

在你以往组建的典型 IT 组织中，你很可能仍在构建产品和功能的多个发布版本，却没有验证它们是否达到期望的业务成果，甚至没有确认到底有没有真实用户在使用它们。验证商业模式或产品和功能构想的最低效方式是，先构建完整的软件产品和服务，再去确认预期的业务需求是否已经存在，以及你的构想能否满足需求。

在构建功能齐备的产品和服务之前，你需要问：“我为什么要构建它？”, “它真的值得我投入时间和资源吗？”。你需要尽可能快速且低成本地设计和开展实验，以验证你的想法、产品和功能能否实现预期业务成果。

对各种企业产品套件长期开展统计实验和测量后发现，所有已实施的变更中，只有 1/3 能显著改善收入、转化、订单、订阅或新客户获取等关键业务指标。也就是说，另外 2/3 的变更没有带来改善，或者改善微乎其微，甚至让指标更糟。对于这 2/3 的变更，与其开发这些不能创造价值的功能，组织还不如给整个团队放假。

应对这个问题的方法是通过 A/B 测试开展用户研究。在构建功能前先验证其效果。把用户研究的反馈融入软件工程流程，既确保正确地运用 DevOps 方法进行开发，也确保开发的是正确的东西。实验、学习和将客户反馈纳入软件工程生命周期的速度越快，就越有能力在所在市场胜过竞争对手。

A/B 测试最初随邮寄直效营销而流行。营销人员通过改变措辞、配色、设计布局、标题和正文等，测试多种传单和明信片版本，找出效果更好、销量更高的版本。英国政府也一直在用 A/B 测试找出最能促使居民缴纳逾期税款的信函版本。如今，A/B 测试已是主流方法，既可用来测试营销和沟通内容，也可用于确定哪些想法、产品与功能有效，哪些无效。

要让 DevOps 团队采用 A/B 测试，需要能快速、轻松地部署不同版本的产品功能，并分别向不同的用户群展示。借助全面的遥测和业务层指标，可以判断功能是否带来了更好的业务成果；如果是，还能确定哪个版本表现最好。

举个例子：DevOps 组织想在电商门户推出新的结账流程。在新流程成为团队的重要工作之前，它只是一个有望改善业务成果的假设。只有先研究并验证假设，新结账流程才能成为需要团队投入大量时间、资源和精力的正式项目。DevOps 团队针对这个结账流程的首个工作包是：

验证假设： 我们相信 新版结账流程 可以带来 转化率的提升。 我们有把握 全面构建和交付这项功能的条件是：面向 1% 访客展示的某个实验结账流程版本，在接下来的 7 天中让销售额至少提高 5%。

总结

你和 DevOps 团队不应仅凭直觉和迄今学习、观察到的最佳实践作判断。重点是让真实的人在现实环境中真正参与实验。

DevOps 产品负责人应把关于产品和功能的想法视为有待验证的假设。只有理性地证明这些想法确实可行后，才能全面设计、构建和测试。