原则.快速反馈

12009

概述

当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。

应用

在代码审查过程中，开发者提交的代码会被其他开发者审查。审查者会提供反馈，指出可能的错误或改进之处。这种及时的反馈可以帮助开发者尽早发现和修复问题，提高代码质量。

在持续集成/持续部署（CI/CD）中，每次代码提交都会触发自动化的构建和测试过程。如果构建或测试失败，开发者会立即收到反馈，从而可以尽快地修复问题。这种快速反馈机制可以避免问题在开发过程中积累，降低了解决问题的成本。

在产品开发过程中，快速反馈原则也常常体现在用户反馈上。开发团队会尽快将新的功能或产品推向市场，然后收集用户的反馈，以便及时调整和改进。这种方法被称为最小可行产品（MVP）策略，它可以帮助团队尽早验证产品的价值和方向，避免在错误的路径上浪费时间和资源。

一次只验证一点

一次只验证一个需求假设。在执行整个试验方案过程中，我们仍旧要保持开放心态，不断优化这些试验方案。时刻提醒自己，我们的目标是验证我们的假设，试验方案只是我们验证假设的手段，而不是我们的目标。

例如，一个电商网站对其商品的搜索结果页进行彻底地大改造，将商品列表的展示效果改为瀑布流式，这个功能类似于百度图片搜索结果页的无限下拉效果。也就是说，当返回多于一页的商品结果时，所有商品可以依据一定的排序规则形成一个瀑布流。用户只要向下滑动页面，商品就会持续不断地展示出来，直到所有搜索结果全部显示出来。

团队撸起袖子，闷头干了好长时间，这个改造终于可以与用户见面了。谨慎起见，他们做了一个A/B试验，结果令他们大吃一惊。因为在瀑布流的“实验组”中，有连续浏览行为的人数是40，而在“对照组”中，这一人数为80。商品点击率下降了约10%，购买率下降了约22.5%，物品收藏率下降了约8%。这个“瀑布流”根本没有达到预期的效果，反而更糟糕。

当刚刚得到这样的结果时，团队所有人都认为一定是软件中存在缺陷，才会导致这个结果。于是，团队进行了各种排查，例如将用户按浏览器和地理位置进行分片。派人到公共图书馆使用古老的计算机登录网站。团队确实发现了一些软件缺陷，但修复它们后也没有改变整体结果。

大家又怀疑是因为不同浏览器的体验不同，就针对不同的浏览器进行优化。每个优化在不同的浏览器上表现不一致。能够想到的优化都改完以后，情况也没有什么好转。最终团队接受了这样一个事实，即瀑布流方式让产品变得更糟。在这个过程中，团队一次性改变了太多的东西，很难发现任何线索，找出“罪魁祸首”。

事实上，如果仔细分析，我们会发现，在“瀑布流”这个功能背后的假设是：更快地为用户展示更多的商品，会让用户的购物体验更好，用户会购买更多的商品。而这个假设由两部分组成，分别是（1）显示越多的搜索结果给用户，页面的转化率指标越好；（2）用户越快地看到商品，页面的转化率指标越好。

事实上，我们可以找到更快速的验证方法来检验这两个假设。对于第一个假设，在现有页面上展示出当前显示数量两倍的商品数量，看是否提高了详情页的转化率。这个验证方案的实现成本应该比原来无限瀑布流的设计要少很多。事实的结论是：浏览商品落地页的用户只增加了一点点，而且这个增加量也不稳定，而在商品购买转化率上并没有变化。

对于第二个假设，可能会稍显困难。因为在原有性能的前提下，再次提升商品显示速度，可能是一个更大的技术挑战。但是，我们可以反其道而行之，也就是说，人为地在页面上增加延迟时间（如200 ms），以验证用户的购买率会下降。当然，这并不是一个完美的试验方案。不过，只要做好小流量测试，使其不大幅影响整个网站的收入，作为对“延迟时间影响用户购买行为”这一假设的验证方法，还是可以接受的。试验的最终结果是“对数据没有任何影响”。