约书亚·利维（Joshua Levy）已经好几天没有睡觉了。他和他的20人团队刚刚发布了Cuil（发音为“酷”），这是一款被寄予厚望的隐形搜索引擎，被誉为潜在的“谷歌杀手”。Cuil的网络索引中有超过1200亿个页面，它声称其抓取的索引规模是谷歌的3倍，而基础设施的成本只有谷歌的1/10。2008年7月28日，数百万用户终于可以尝试利维和他的团队在过去几年里的研发成果。但这位工程总监并没能开香槟庆祝，而是忙于灭火，在巨大流量的冲击下，竭尽全力维持一切正常运转。
在高负载的重压下，运行抓取、索引以及其他服务的1000多台服务器所依赖的基础设施崩溃了。而且由于Cuil 在AWS（Amazon Web Services）普及云计算之前就已经建立了自己的数据中心，因此工程团队并没有太多可以提供闲置容量的多余的机器。用户会输入不同的搜索条件，比如他们自己的姓名，这种搜索的多样性使常见查询结果的内存缓存不堪重负，减慢了搜索引擎的速度。索引的分片崩溃了，在搜索结果中留下了巨大的漏洞，而且PB级数据的大量计算出现了很难定位的错误，使得系统难以保持稳定，更不用说进行修复或升级了。利维回忆说：“那种感觉就像是你坐在一辆汽车里，知道自己要掉下悬崖，然后想：‘好吧，也许我把油门踩到底就能冲过去。’”
最重要的是，用户很明显对Cuil的服务不满意。《个人电脑》杂志的一位编辑称Cuil“质量低下”、“缓慢”且“可悲”。CNet将其搜索结果描述为“不完整、怪异和缺失的”。《时代》杂志称其“乏善可陈”，《赫芬顿邮报》评价它“愚蠢”。用户批评Cuil的搜索结果质量差，并抱怨该搜索引擎缺乏拼写错误纠正等基本功能。最糟糕的是，对于大多数查询，尽管Cuil的索引规模比谷歌的更大，返回的结果却比谷歌少。这次发布成了一场公关灾难。
最终，Cuil成为一个失败的实验，耗尽了3300多万美元的风险投资和数十人年的工程时间。利维表示：“如此努力地工作，然后眼睁睁看着一切化为乌有，这绝对是一段令人沮丧、心生卑微的经历。”作为一名早期加入Cuil的软件工程师，利维接受了创始人改变行业规则的愿景——打造一个更好的谷歌。他告诉我，“公司有一批非常优秀的软件工程师”。其中两位创始人甚至还带着来自谷歌搜索团队的闪亮背景。到底什么地方出了问题？Cuil怎么会无视这么多科技博客都写过的如此明显的产品缺点呢？
当我问利维从这次经历中学到了什么重要的教训时，他强调了尽早验证产品的重要性。因为Cuil想在产品发布时大放异彩，担心向媒体泄露了细节，所以他们没有聘请任何α测试人员来测试这个产品。在发布之前，没有外部反馈指出：搜索质量不高；搜索引擎没有返回足够多的结果；而且如果索引实际上没有带来更高质量的搜索结果，用户其实不关心索引的规模。Cuil甚至没有人专职处理垃圾网页，而谷歌有一个工程师团队专门对付垃圾网页，还有一个专注于搜索质量的组织。没有尽早验证产品，导致Cuil在本该节约成本的索引方面投入太多，而在质量方面投入不足。这是一个非常惨痛的教训。
利维离开Cuil后，成为创业公司BloomReach的第二名员工，他记住了这个教训。BloomReach建立了一个营销平台来帮助电子商务网站优化搜索流量，并最大限度地增加在线收入。这里面有很多未知因素，比如产品的外观应该是什么样子，什么会起作用，什么不起作用等。利维和他的团队没有重蹈Cuil的覆辙——花数年时间开发一个无人问津的产品，而是采取了截然不同的方法。他们构建了一个非常简约但实用的系统，并在4个月内将其发布给测试版客户。这些客户分享了他们喜欢的、不喜欢的以及关心的内容，这些反馈有助于团队确定下一步工作的优先级。
根据反馈尽早优化，或者换句话说，了解客户的实际需求，然后根据反馈进行迭代，这对BloomReach的发展至关重要。该公司现有员工超过135人，客户包括尼曼百货商店（Nieman Marcus）和Crate & Barrel连锁商店等顶级品牌。平均而言，它帮助线上品牌产生了80%以上的非品牌搜索流量，显著增加了他们的收入。“不要拖延……要获取反馈，弄清楚是什么在起作用”，最终成为BloomReach运营主管的利维告诉我，“这远比试图创造一些东西，然后相信自己把所有事情都做对了要好得多，因为你不可能把所有事情都做对。”
在第4章，我们了解到投资迭代速度可以帮助我们完成更多的事情。在本章，我们将学习如何尽早地、经常性地验证想法，以帮助我们做正确的事情。我们将讨论寻找低成本和迭代的方法来验证我们是否走在正确的道路上，减少无用功的重要性。我们将学习如何使用A/B测试，以定量数据持续验证产品的变更，并将看到这种测试会产生多大的影响。我们将研究一种常见的反模式——一人团队，它有时会阻碍我们获取反馈的能力，我们将讨论处理这种情况的方法。最后，我们将看到构建反馈和验证循环的思想是如何应用于我们做出的每一个决策的。
寻找验证工作成果的低成本方法
在麻省理工学院读大三的时候，我和三个朋友参加了MASLab机器人大赛。我们要制作一个1英尺高的自动驾驶机器人，它能够在场地内导航并收集红球。13我们教给机器人的第一项技能是如何向着目的地前进。我们觉得这很简单。我们最初的程序是用机器人的摄像头扫描红球，然后让机器人转向球所在的位置，再给电机供电，机器人到达这个位置后再停下来。很可惜，前后轴电机转速的微小变化、轮胎胎面花纹的差异以及场地表面的轻微颠簸，都会导致我们这个头脑简单的机器人以某个角度偏离目的地。路径越长，这些小错误带来的问题就越多，机器人到达目的地的可能性就越小。我们很快意识到有一个更可靠的方法，就是让机器人先向前移动一点点，然后重新扫描，重新调整电机的方向，不断重复这个过程，直到机器人到达目的地。
这个小机器人前进的过程和我们推进工作的过程并没有太大区别。采用迭代的方式可以减少代价高昂的错误，并且在每次迭代之间，我们还有机会收集数据以纠正路线。迭代的周期越短，就能越快地从错误中吸取教训。相反，迭代的周期越长，不正确的假设和错误就越有可能混在一起，导致我们偏离正轨，浪费时间和精力。这就是提升迭代速度（第4章讨论过）如此重要的一个关键原因。
通常，在开发产品和设定目标时，一开始方向可能并不明确。我们可能对目标有一个大致的想法，但不知道达成目标的最佳方式。或者，我们可能缺乏足够的数据来做出明智的决定。越早了解前进路上的风险，我们就能越早解决它们，增加成功的机会，或者转向更有前景的道路。Square公司的工程经理扎克·布洛克（Zach Brock）经常给他的团队这样建议：“这个项目最可怕的部分是什么？是未知因素最多、风险最大的部分。那就先做那部分。”先处理风险最大的领域，这样我们就能主动更新计划，避免出现讨厌的意外，这些意外可能会使我们之后的努力付诸东流。在第7章讨论如何提高项目估算能力时，我们将重新讨论尽早降低风险这个主题。
在做项目，尤其是大型项目时，我们应该不断地问自己：是否可以花一小部分精力来收集一些数据，验证当前的工作是否可行？我们常常犹豫是否要增加这10%的额外开销，因为我们急于完成项目，或者对自己的实施计划过于自信。诚然，这10%的精力最终可能无法带来任何有用的见解或可复用的工作成果；但另一方面，如果它暴露出我们计划中的一个巨大缺陷，就可以节省剩下90%的精力，以免浪费。
创业公司的企业家和软件工程师经常思考这些问题，特别是当他们在构建“最小可行产品”（MVP）时。《精益创业》（The Lean Startup）一书的作者埃里克·里斯将MVP定义为“新产品的第一个版本，它可以使团队以最小的工作量收集关于客户的最大数量的有效信息。”如果你觉得这个定义类似于我们对杠杆率的定义，那就对了。在构建MVP时，要将重点放在高杠杆率的活动上，因为这些工作可以尽可能多地验证关于用户的假设，消耗最少的成本，并最大限度增加产品成功的机会。
有时候，建立MVP需要有点创造性。德鲁·休斯顿（Drew Houston）起初开始构建 Dropbox这个易于使用的文件共享工具时，市场上已经有无数其他的文件共享应用程序。休斯顿相信，用户会更喜欢他的产品所能提供的无缝体验，但如何验证这个信念呢？他的解决办法是制作一个4分钟的短视频作为他的MVP。休斯顿演示了他的产品的一个功能受限版，展示了文件在Mac、Windows PC 和网络间的无缝同步。一夜之间，Dropbox的测试版邮件列表用户从5000增加到了7.5万，于是休斯顿知道他的方向是正确的。Dropbox使用MVP来建立信心并验证其假设，而不必做太多工作。截至2014年2月，Dropbox拥有超过2亿的用户，市值达到100亿美元，而且仍在继续增长。
我们并非都在创业公司开发产品，但投入小部分精力来验证工作的可行性，这一原则适用于许多工程项目。假设你正在考虑从一种软件架构迁移到另一种。也许你的产品已经达到MySQL数据库的扩展极限，你可能正在考虑切换到一个声称扩展性更好的NoSQL架构。或者，你可能正在用另一种编程语言重写服务，目的是简化代码的维护工作，提高性能或提升迭代速度。迁移架构需要投入大量的精力，如何才能使自己坚信，这项工作不会是浪费时间，而且确实有助于实现目标呢？
验证想法的一种方法是花10%的精力去构建一个小型的、信息丰富的原型。根据项目目标，可以用原型做各种事情：测量在典型工作负载下的性能，将重写的功能模块与原始模块的代码路径进行比较，评估添加新功能的难易程度。对大型项目的方案而言，构建快速原型的成本并不高，但是如果它能及早暴露问题，或者使我们相信更大规模的迁移是不值得的，那么它产生的数据就可以为我们省去大量精力。
假设你正在重新设计产品的用户界面，使其更快、更友好。如何才能增加信心，认为新的用户界面将提高用户转化率，而且不需要投入所有的精力全面地重新设计？42Floors是一家为办公场所租赁和商业地产挂牌销售建立搜索引擎的公司，他们遇到了同样的问题。当用户在他们的网站上搜索办公场所时，他们会通过谷歌地图界面显示出所有可用的房源。但如果搜索结果太多，可能需要12 s以上的时间才能全部加载。42Floors第一次尝试改进时，软件工程师花了三个月的时间，用大照片、无限滚动条和迷你地图构建了一个更快的办公场所房源视图。他们以为要求参观办公室的用户的转化率会上升。然而，在项目发布之后，他们的指标没有任何变化。
这个团队还有其他一些想法，但是没有人愿意将太多的精力投入到一个可能再次失败的设计上。如何在更短的时间内验证这些想法？他们想出了一个聪明的解决方案：他们决定伪造自己的重新设计。他们用Photoshop设计了8个界面原型，让一个外包团队将其转换为HTML页面，并通过谷歌AdWords活动，将一些搜索“纽约办公场所”的用户引到这些假页面。由于这些页面预先填充了静态测试数据，对于第一次访问的人来说看起来非常真实。然后，他们度量了要求去8个界面原型实地参观的用户的比例。这次团队只投入了第一次重新设计时所花精力的一小部分，就使用转换率验证出重新设计的8个方案的优劣。最后他们采用了获胜的那个设计方案，并将其发布到生产环境，并最终用户转化率达到了他们想要的水平。
要验证某个想法是否可行，有一个非常有效的策略：假装全面实施这个想法。Asana是一家开发办公协同和任务管理软件的公司，正在考虑是否在其主页上增加一个新的谷歌注册按钮，目标是增加注册人数。他们并没有马上建立整个注册流程，而是通过添加一个假的注册按钮来验证这个想法，当访客点击按钮时，会弹出一条消息，上面写着：“感谢您的关注，这项功能即将推出。”Asana 的软件工程师们收集了几天内的点击率数据，在数据证实此举有助于增加注册人数后，才建立起完整的注册流程。
小型验证可以节省时间，这一类场景不胜枚举。也许你有一个关于评分算法的想法，认为它会提高新闻的排名，你可以用一小部分数据来验证新的评分指标，而不是花费数周时间构建一个产品质量系统并在生产环境的全量数据上运行；你可能有一个绝妙的产品设计想法，与其用代码来实现它，不如快速做出一个纸上原型或低保真度模型，向团队或用户研究的参与者展示；如果有人问你是否能在原本就很紧张的10周项目日程内发布一个新功能，你可以先推算出一个时间表，验证一周后能否走上正轨，并且在评估最初的时间计划是否可行时纳入这些数据；或者你正在考虑解决一个棘手的bug，在修复它之前，你可以使用日志中的数据来验证这个bug是否真的影响了足够多的用户，证明你花时间和精力修复它是合理的。
所有这些例子都说明了一个共同的结论：做少量的工作来收集数据，以验证项目假设和目标，从长远来看，这会减少很多无谓的浪费。
用A/B测试持续验证产品变化
2012年6月，美国总统巴拉克·奥巴马（Barack Obama）的连任竞选急需更多资金。奥巴马的数字团队决定给他的捐赠者邮件列表中的人发送电子邮件，并解释说，除非他的支持者团结起来提高支持率，否则奥巴马有可能被他的对手米特·罗姆尼（Mitt Romney）超过。这封邮件拟议的标题是“最后关头：与我和米歇尔站在一起”，这个标题看起来是完全合理的。但随后，团队开始集思广益，讨论其他可能的标题，从“变革”到“为米歇尔而努力”，再到“如果你信任我们的努力”，以更好地吸引捐赠者的注意。
最终，这封发给440万订阅者的邮件使用了一个完全不同的标题：“我将落于人后”。这句话是特意设计的。团队在小范围的订阅者身上测试了17个样本标题，发现这个特定的措辞可以筹集到比其他标题多6倍的资金——超过200万美元。事实上，这封竞选邮件筹集到了惊人的260万美元。为邮件标题调整几个字就带来了如此巨大的回报。
ps：小范围的订阅者，是多大？
奥巴马的竞选邮件标题的测试是一个很好的例子，说明了使用数据来验证我们的想法，即使是那些看起来非常合理的想法，也能有极高的杠杆率。更重要的是，这封邮件并不是一次性的测试。它是团队建立的系统化流程的一部分，这样他们就可以用真实的数据而不是自己的直觉来验证和优化每一次的邮件活动。因为这些测试非常有效，所以他们聘请了一个工程团队来构建度量和改善邮件活动效果的工具，并组建了一个由20名专业作家组成的团队，他们的唯一工作就是进行头脑风暴，起草不同的电子邮件。
2012年，该团队发送了400多封全国性的募捐邮件，测试了10,000种不同的标题、邮件正文、捐赠金额、格式、高亮显示的内容、字体和按钮。23奥巴马竞选团队的每封电子邮件都在多达18个分组中进行了测试，效果最好的邮件募集到的捐款通常比最差的邮件多5到7倍。在20个月的时间里，奥巴马竞选团队的6.9亿美元资金中的大部分都是由这些经过严格测试的筹款邮件通过网络筹集到的，对这些测试的投入非常划算。
用数据测试想法，这种做法不仅仅适用于电子邮件，也适用于产品开发。如果用户不参与或客户不购买，即使是一个经过良好测试、设计简洁、可扩展的软件产品也不会带来太大的价值。产品的变更通常会出现这样一个问题：团队观察到指标的变化（你已经为自己的目标选择了正确的指标，对吗？），但无法确定产品发布会使指标数据提升（或下降）多少。这些变化是由于当天的流量波动、媒体报道、正在进行的产品变更、性能问题、未解决的bug或其他因素所造成的吗？A/B测试就是用来隔离这些影响并验证某些东西是否有效的一个强大工具。
在A/B测试中，一组随机的用户会看到产品的一个变更或一个新的功能；而对照组里的用户则看不到。A/B测试框架通常根据用户浏览器的cookie、用户ID或一个随机数将用户分配到一个特定的组里，这个分组决定了用户看到的产品的版本。假设分组没有偏差，每个组都会以相同的方式受到流量波动的影响。因此，通过比较实验组和对照组的指标，任何统计上的显著差异都可以完全归因于产品变更导致的差异。A/B测试提供了一种科学的方法，在控制其他变量的同时度量产品变更所产生的影响，从而帮助我们评估其对所有用户的影响。
A/B测试不仅可以帮助我们决定发布哪个产品版本，而且即使我们完全相信某个变更会改进指标，A/B测试也能告诉我们这个变更到底有多好。对这个改进进行量化，我们就可以知道继续在这个领域投资是否有意义。例如，对一项大型产品的投资只提高了1%的用户留存率，这意味着我们可能需要找到杠杆率更高的其他方向；而如果它能提高10%，就可以在这个方向加倍投资。如果不衡量影响，我们就不会知道自己处于什么状况。
A/B测试还鼓励采用迭代的方式开发产品，这样团队就可以验证他们的理论，并对有效果的变更进行迭代。我们在第5章讨论过手工艺品在线销售公司Etsy，这家公司由指标驱动的文化促使他们构建了自己的A/B测试框架。因此，他们能够不断对产品做实验，并衡量这些实验的效果。Etsy的产品开发和工程前高级副总裁马克·赫德伦（Marc Hedlund）向我讲述了他的团队为一个卖家销售的商品重新设计商品列表页面的过程。这个特殊的页面展示了商品的大幅照片、商品详情、卖家信息，上面还有一个将商品添加到购物车的按钮。在Etsy的网站上，手工制品和复古商品的列表页面每天有近1500万次的访问量，这些页面通常是网站给访问者留下的第一印象。27在重新设计之前，近22% 的访问者一般是通过点击谷歌的搜索结果，经由列表页进入网站的，但其中53%的人会立即跳出页面并离开。28作为重新设计的一部分，Etsy的工程师希望降低跳出率，向购物者说明那些商品的卖家都是独立设计师、制造商和策展人，使客户能更方便地购物和快速结账。
Etsy就在这个环节采用了非传统的方法。许多其他的工程和产品团队在向用户发布产品或功能之前，会将其设计并完全构建出来。然后他们可能会发现，干了几个月，他们所构建的东西实际上并没有像期望的那样推动核心指标变化。而Etsy的商品列表页面是团队以迭代的方式重新设计的。他们会先提出一个假设，再构造一个A/B测试来验证，然后根据A/B测试得出的结论进行迭代。例如，他们假设“向访问者展示更多的商品会降低跳出率”，然后对此进行一项实验：在商品列表页面的顶部展示相关商品的图片，并分析指标的变化是否支持或否定这个假设（事实上，这项举措降低了近10%的跳出率）。基于该实验，该团队认识到应该在最终的设计中加入更多商品的图片。
就像奥巴马竞选团队琢磨邮件的写法一样，Etsy的工程师使用反馈循环反复测试不同的假设，直到形成一种基于数据的直觉，知道最终设计中哪些做法是可行的，哪些不是。“他们重新设计了这个页面，花了大约8个月的时间。这是非常严格地由A/B测试驱动的，” 赫德伦解释说，“发布之后，数据好极了——在业绩表现方面，这绝对是我们交付过的最好的项目。而且它是可以量化的，我们很清楚会产生什么样的效果。”2013年，Etsy的销售额突破10亿美元。29实验驱动的文化在这一增长中发挥了重要作用。
同样，我们在Quora所做的杠杆率最高的投资之一就是构建内部的A/B测试框架。我们构建了一个简单的抽象来定义实验，编写工具来帮助我们在开发过程中验证不同的产品版本，实现对这些测试的一键式部署，并自动收集实时分析数据——所有这些举措都有助于优化迭代循环，以便在面对实时流量之前获得新的想法。30该框架使我们能够进行数百个用户实验，测量由新注册流程、新界面功能和幕后排名调整等变化所产生的影响。如果没有A/B测试框架，我们就只能通过猜测来决定如何改进产品，而不是科学地处理这个问题。
构建自己的A/B测试框架可能会让人望而生畏。幸运的是，有许多现成的工具可以用来测试关于产品的假设。免费或开源的A/B测试框架包括Etsy的featureflagging API、Vanity、Genetify和Google Content Experiments。如果想要获取更多工具和支持，可以使用Optimizely、Apptimize36、Unbounce、和Visual Website Optimizer等按月付费的软件。鉴于通过A/B测试可以学到很多东西，所以这是一项非常值得的投资。
在决定A/B测试的内容时，要注意时间是你最有限的资源。仔细研究具有高杠杆率和有实际意义的差异，那些对你的特定指标真正重要的差异。谷歌有能力对微小的细节进行测试。例如，他们分析了应该用41种蓝色中的哪一种表示搜索结果链接，选择合适的色调为这家搜索公司每年带来2亿美元的额外广告收入。当然，谷歌有足够的流量在合理的时间内完成统计分析；而且，更重要的是，对于一家年收入为310亿美元的公司来说，即使收入增长区区0.01%，也有310万美元。然而，对于大多数其他公司来说，这种测试的时间和流量成本都非常昂贵，即使能够检测到这样的结果，也没有什么意义。一开始很难确定哪些测试具有重大的实际意义，但随着所做的测试越来越多，你将能够更好地确定优先级，并确定哪些测试可能会带来巨大的回报。
正确地执行A/B测试，能够帮助我们验证产品理念，并将原本令人困惑的用户行为数据黑匣子转化为可理解、可操作的知识。它使我们能够迭代地验证对产品所做的变更，确保我们的时间和精力得到了合理利用，并且确定我们没有偏离目标。然而，即使无法通过A/B测试获得定量数据，我们仍然可以通过定性反馈来验证想法。我们将在下面的两节讨论具体如何实施。
当心“一人团队”
鉴于尽早且频繁验证的重要性，我们需要注意一个常见的反模式：一人团队。有一个非常具有代表性的硅谷故事，讲述的是一名软件工程师独自设计并构建一个规模宏大的系统。他期待项目尽快发布，并提交了大量代码请一位团队成员评审，结果得知他忽略了一个重大的设计缺陷，最终，他被告知应该以完全不同的方式构建这个系统。
有一年夏天，我在谷歌实习时，为Orkut（谷歌早期的社交网站之一）构建了一个搜索功能。我在这个项目上努力工作，调整了搜索结果中用户资料的索引、排名和过滤功能。我和其他工程师一起检查了我的初始设计，但是因为每天的工作越来越多，而且没有太多的代码评审经验，所以我觉得自己不需要把实际代码到处拿给人看。在实习的最后一周，我将暑期中编写的数千行代码打包后提交，进行代码审查。谷歌会根据变更的代码行数对提交的代码进行分类。于是我导师的收件箱收到了一封邮件，上面写着：“埃德蒙给你发了一个超大号的代码包请求评审。”
午餐时，我不经意间向其他实习生提到了这个“代码炸弹”。我为自己在那个夏天所取得的成就而沾沾自喜，但他们都吓坏了：“你说什么？！如果你的导师发现了一个明显的设计问题怎么办？你的导师真的有时间评审所有内容吗？如果他确实发现了一些问题，你还有时间解决所有问题吗？如果他不允许你的巨型代码提交合并怎么办？”我的心沉了下去。难道整个夏天的努力都会白费吗？在谷歌的最后一周我一直都在担心事情会如何发展。
幸运的是，我的导师很通情达理，愿意帮我处理实习之后出现的任何问题。因此，我最终提交了代码，在我离开后的几个月内，这个功能就发布了。但这个过程中有太多运气的成分，我的整个项目是有可能会被废弃的。事后来看，如果以更多的迭代和分块的方式提交代码，我的工作内容就不会孤立存在这么久，也就消除了大量风险。我的导师可以更轻松地审查我的代码，而我也会在这个过程中收到宝贵的反馈，并将这些反馈应用到未来的代码中。最后还有一点：我很幸运，在职业生涯的早期，就用很低的成本学到了关于一人团队的教训。
在很多情况下，我们必须独立完成一个项目。有时，为了降低沟通成本，管理人员或技术负责人会让员工一个人开发项目。有的时候，某些团队会将成员分成若干个一个人的子团队，这样大家就可以独立处理较小的任务，协调起来也更容易。一些组织在他们的晋升流程中强调，软件工程师必须证明自己对项目的所有权，以此激励员工独立工作，因为大家都希望能最大限度地增加自己的晋升机会。此外，有些人只是单纯喜欢更独立地工作。
虽然从事单人项目本身并没有什么问题，但它确实会带来额外的风险，如果不予处理，就可能会降低个人成功的概率。首先也是最重要的一点，它增加了获得反馈过程中的阻力，而我们需要借助反馈来验证自己所做的事情是否可行。例如，除非评审人在你的团队中工作，而且有共同的项目背景，否则在代码评审中很难获得有质量的反馈。如果你不注意建立反馈循环，那么很可能会推迟到自认为所做的工作已经近乎完美才会寻求他人的反馈。如果直到最后才发现走错了方向，就会浪费很多精力。
单人项目还存在其他风险。独自工作时，项目的低谷会让人更加沮丧。如果有人能分担这份痛苦，工作的困境、单调的工作、毫无头绪的bug等问题就会变得不那么令人心力交瘁，更容易忍受下去。单独一个人的拖延会使整个项目停滞不前，导致截止日期推迟（我们将在第7章讲解如何解决这个问题）。我遇到过这种情况，也曾看到这种情况发生在其他软件工程师身上。然而，如果项目中至少还有另一个人，即使你被卡住，团队仍然可以维持整体势头并保持士气。
同样，独自工作时，成就感也会降低。与队友一起庆祝成就是鼓舞士气的好方法。如果独自工作，当你最终修复了那个令人沮丧的数据损坏bug时，能够和谁击掌庆祝呢？此外，知道队友依赖自己，会增加我们的责任感。渴望帮助团队成功的愿望，可以克服个人偶尔出现的动力不足问题。
即使发现自己是一个人在做项目，也不要绝望。这些风险是可以避免的。史蒂夫·沃兹尼亚克（Steve Wozniak）发明了Apple I和 Apple II电脑，最开始他在自己家里设计硬件和软件，后来换到史蒂夫·乔布斯的车库里工作。他的发明是如何从家酿计算机俱乐部（The Homebrew Computer Club）的业余玩具转变为个人电脑革命的支柱的？对沃兹尼亚克来说，一个关键因素是乔布斯为他提供了平衡和反馈循环来验证他的想法。尽管沃兹尼亚克性格内向，表面上只管做自己的事情，但他并没有将自己孤立起来。在乔布斯的远见和雄心的激励下，两人最终创立了苹果公司。
像沃兹尼亚克一样，我们也可以建立必要的反馈渠道，增加项目成功的机会。以下是一些策略：
开诚布公，乐于接受反馈。如果我们对自己的工作抱着防御性心态，就很难听取反馈意见，而且人们以后也不会愿意给我们提供反馈。相反，要优化我们的学习方式。不要把反馈和批评看作人身攻击，而要看作改进的机会。
尽早并经常提交代码进行评审。大批量的代码变更是很难评审的，需要更长的时间才能获得反馈，如果最后发现其中存在设计上的缺陷，那就是对时间和精力的极大浪费。专注于通过迭代取得进展，并将这种小步提交代码的方式作为持续获得反馈的必选项。不要发起大型代码审查。
请求严厉的批评者审查代码。不同的人审查代码时的严格程度存在很大差异。如果你急于交付某些东西，可能会倾向于将代码评审请求发送给那些略读代码就轻易放行的人。但如果你的目的是优化代码质量，或者想确认方法的可行性，那么杠杆率更高的方式是请求那些能够在深入思考后给予批评的人审查你的代码。最好尽早从队友那里得到严厉的反馈，而不是等后来出现问题时从用户那里获得反馈。
征求团队成员的反馈。获得反馈最直接的途径就是向他人请求反馈。可以询问在饮水机旁闲逛的同事，是否愿意抽出几分钟时间和你在白板上讨论一些想法。研究表明，向别人解释一个想法是自我学习的最好方法之一；此外，在解释的过程中可能会暴露出自己理解上的漏洞。大多数人都希望自己能帮上忙，也很愿意暂时休息一下，去解决一个不同的、可能很有意思的问题。也就是说，如果你希望在未来保持反馈渠道畅通，就要尊重同事的时间。事先做好准备，确保自己能清楚地表达想要解决的问题，以及尝试过的方法。讨论结束后，作为回报，我们可以主动为他们的想法提出意见。
先设计新系统的界面或API。设计界面之后，做出原型，以此展示功能齐全的客户端的样子。创建具体的交互式场景，能够发现错误的假设或缺失的需求，从长远来看可以节省时间。
在编写代码前先展示设计文档。虽然看起来可能会增加额外的成本，但这是一个以10%的工作量来验证你计划做的其余90%的工作的例子。这份文件不需要特别正式，可以只是一封详细的电子邮件，但信息应该足够全面，让看的人了解你要做什么，能够提出需要你澄清的问题。
如有可能，重新安排正在进行的项目，以便与同事共享一些上下文。与其和他人各自做自己的项目，不如考虑大家一起先完成一个项目，再一起处理另一个项目。或者，考虑和同事做同一领域的工作。这样做可以为大家创造一个共同的背景，从而减少讨论和评审代码时的摩擦。将团队的项目序列化而不是独立、并行地进行，可以增强协作，还可以提供更多学习的机会：完成每个项目所需的时间更短，因此在给定的时间范围内，你可以接触到更多不同领域的项目。
在投入太多时间之前，征求对有争议的功能的支持。这可能意味着需要在对话中提出想法，并构建原型来帮助说服利益相关者。有时，软件工程师会将这种类型的自我推销和游说误解为办公室政治，但从杠杆率的角度来看，这是一个相当合理的决定。如果通过对话获得反馈只需要几个小时，而项目的实施需要几个星期，那么为获得早期反馈所投入的时间就非常有价值。如果无法从该领域的专家那里获得支持，可能说明项目走上了错误的道路。然而，即使你认为他们是错的，这样的对话至少会让他人关心的问题显现出来，如果你决定继续完成自己的项目，就应该解决这些问题。
所有这些策略的目标都是消除独自工作时收集反馈时的阻力，以便更早、更频繁地验证自己的想法。如果你正在从事单人项目，这些策略就特别重要，因为除非你是主动要求的，否则默认的行为就是孤立地工作。但是，即使是在团队中工作，这些策略也同样有价值。布莱恩·菲茨帕特里克（Brian Fitzpatrick）和本·柯林斯-萨斯曼（Ben Collins-Sussman）这两位谷歌员工创立了谷歌芝加哥工程办公室，他们在《极客与团队》（Team Geek）这本书中写的一句话很好地捕捉了这种心态：“软件开发是一种团队活动。”43即使你更喜欢独立工作，如果能把工作概念化为团队活动，并建立反馈循环，你就会更有成效。
建立决策反馈循环
无论你是为某个大型实现编写代码，研发产品，还是在团队中工作，建立反馈循环以验证想法都是很重要的。更宽泛地说，这条验证的原则也适用于我们所做的任何决定。
有时，要进行验证是很困难的，因为数据可能不多，或者只有定性数据可用。应该使用哪种编程语言来编写新服务？抽象或接口应该是什么样的？这个设计对你要做的事情而言是否足够简单？现在为可扩展性投入更多的资源是否值得？
此外，工程师的级别越高（尤其是在进入管理层后），做决策就会变得越艰难、越模糊。应该如何协调团队的工作？团队能否暂停（或不暂停）功能的开发以减少技术债？绩效评估和反馈应该是匿名、直接的，还是在公开环境中进行？应该如何设置薪酬结构以改善人员招聘和留任情况？
我采访Facebook的工程总监宁录·胡斐恩时，他表示建立反馈循环对工作的各个方面都是必要的。“它适用于招聘，适用于组建团队，适用于建立团队文化，适用于设定薪酬结构，”胡斐恩解释说，“你所做的任何决定……都应该有一个反馈循环。否则，你就只是在……猜测。”
此前，胡斐恩担任Ooyala的工程高级副总裁时，对组建高效工程团队的各个方面进行了实验，并建立了反馈循环，以便从这些实验中学习经验和吸取教训。例如，在确定团队成员的最佳人数以最大限度地提高效率时，胡斐恩尝试了几种不同的团队规模，并寻找团队机能明显失调的地方。“最常见的是团队开始表现得像两个团队一样，”胡斐恩观察到，“而且这两个团队只会各行其是。”另一个实验是将奖金与可靠性等工程范围的指标紧密联系在一起。由于奖金的计算方式很明确，此举一经推出就引发了非常积极的反响，但一个季度后就被取消了，原因是工程师们不高兴，因为他们无法完全控制这些指标。
胡斐恩在Ooyala研究高效团队结构的基本问题时，也做了类似的实验：技术主管是否也应该是经理（是的）；是否应该将网站可靠性工程师、设计师和产品经理等职位嵌入开发团队（对产品经理而言，是的）；在什么情况下团队应该采用像 Scrum这样的方法论（各种情况都有）。胡斐恩在几周内进行了许多这样的实验，然后收集数据——有时只是通过与人交谈来了解哪些做法有效、哪些无效。然而，其他一些想法，例如将最好的工程师薪水翻倍以创建超级明星团队的激进提议，则是作为思想实验来进行的。胡斐恩召集工程技术负责人讨论了可能的后果（他们预测，能力一般的员工会成群结队地辞职，而且需要很长时间才能找到优秀的人来替代他们）。
验证的原则表明，许多我们认为理所当然的工作决策，或者那些盲目采纳他人意见的决策，实际上都是可以验证的假设。如何发现最有效的方法，取决于所涉及的情况与参与的人员，胡斐恩在团队管理上的经验可能与你的不同。但无论是编写代码、创建产品还是管理团队，做决策时采用的方法论都是一样的。从本质上讲，愿意进行实验就证明了科学方法的有效性。
验证意味着提出一个可能可行的假设，然后设计一个实验来测试它，了解好的和坏的结果是什么样子，做实验并从结果中学习。你可能无法像A/B测试那样用足够大的流量严格地测试一个想法，但仍然可以将猜测转变为科学的决策。只要有正确的心态——愿意验证自己的想法——就没有什么是不能通过反馈循环来验证的。
本章要点
迭代地处理问题以减少浪费。每一次迭代都为我们提供了验证新想法的机会，快速迭代才能快速学习。
通过小型实验验证想法，降低大型实现的风险。投入少许额外的精力，确认你的计划中的其余部分是否值得做。
使用A/B测试持续验证关于产品的假设。通过迭代的方式开发产品，并确定哪些可行、哪些不可行，就能让产品逐渐与用户需求一致。
在单人项目中工作时，要想办法定期征求反馈。一个人做独立项目可能很容易也很舒服，但也可能会忽略某些巨大的风险，如能及早发现，就可以避免浪费大量的精力。
养成及时验证决策的习惯。不要做出一个重要的决定后就继续前进，而应该建立反馈循环，以便收集数据并评估工作的价值和有效性。
本文选自《卓有成效的工程师》一书。
MIT、斯坦福大学讲师，Quora联合创始人、谷歌早期员工，《福布斯》《财富》《时代》等顶级媒体撰稿人Edmond Lau，先后与几十位软件工程领域的领导者进行了深入交谈，并花费大量时间阅读关于生产力、团队建设、个体心理学、商业和个人成长的书籍，从中提炼了出方法，进行实验，并把它们应用到软件工程场景中。
最终，Edmond Lau将自己的经验和教训总结成了《卓有成效的工程师》一书。
这本书问世以来在互联网世界引发讨论狂潮，被戏称为中国人最爱啃的英文原著，豆瓣评分很快破9，大量中外一线企业管理者成为这本书的首批读者，并组织内部员工学习、仿效。
《卓有成效的工程师》是一本写给软件工程师的书，但书中没有一行代码。因为技术知识只是卓有成效的工程师必备技能的一小部分，更重要但往往容易被软件工程师忽视的是元技能。
《卓有成效的工程师》详细介绍了这些元技能，提出、论证及应用了一个非常实用的框架——“杠杆率”，从而帮助工程师分析不同工作的影响力，进而将有限的时间和精力集中在成效更高的工作中，提高影响力，并深入了解软件工程中浪费我们宝贵时间和精力的常见陷阱。
《卓有成效的工程师》既面向工程师高效工作与成长实践，又面向工程师团队的管理与建设；既带来硅谷领风气之先的工程师文化，又直指其弊高举反硅谷套路大旗。
《卓有成效的工程师》将Effective与卓有成效双经典系列叠加，对人人重视却不得其解的效率、时间、成本、价值等高频词，给出一套真正有效的可落地实施方案。
作者Edmond Lau先后在微软、谷歌、Quora等明星公司工作，现投身创业并客座执教名校，足以确保书中有大量鲜活而有内涵的真实案例及其教训与收益。
福利来了，原价75，专属折扣价49，点击链接购买。
第二重福利，本文回复点赞top3的评论获得新书一本。
加入技术琐话读者群，请在公众号后台回复：读者群
往期推荐：
长按二维码关注
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。
1049
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
