发布日期：2023 年 12 月 1 日。架构 (32)，创新 (1)
十多年前，我记下了几段笔记，标题是“建立技术杠杆”，此后我几乎把它忘在脑后。这些笔记记录的是我和 Kevin Scott 在 LinkedIn 担任 SVP 工程师期间的一次会议。那时，我们正在硅谷努力说服潜在买家收购 Digg 的过程中（了解更多）。直到今天早上，当我试图为这篇讨论相同主题的文章起名时，我才想起了那篇文章。
十年过去了，我对这个主题有了更深入的思考。首先，让我们来了解一些基本概念：
- 技术杠杆 在这里指的是“利用软件和软件系统解决问题”。这是 杠杆 的一部分，杠杆还包括用培训、流程改进、沟通等方式解决问题
- 在我看来，行业中有两种主要的技术杠杆：工作流程改进 和 产品能力
- 工作流程改进 主要是提升效率（比如，新代码部署更迅速，数据库迁移不太可能影响生产环境）
- 产品能力 则是让以前难以实现的事情变为可能，或者大大加快速度（例如，一个面向特定用户优化内容的机器学习优化的着陆页，而不是针对全体用户，或者是一个完全自动化的替代耗时手工上传内容的工具）
掌握了这些基本概念后，让我们深入探讨这个话题。
提升工作效率的策略
提升工作效率的策略 主要是为了提高团队或公司的工作效率。这可能体现在直接加快工作进程（比如减少构建时间），或者通过降低工作速度来减少人工干预的需求（例如，使用金丝雀部署虽然会放慢部署速度，但可以在不需要人工监控的情况下更安全地进行部署）。
通常，可以通过系统思维来寻找并改进工作流程。（例如，这里有一个使用系统思维对一个示例系统进行建模的案例。）
案例：
- 在 Calm 和 Stripe，我们尝试了金丝雀部署。这种方式虽然从机器的角度看会减慢部署速度，但它能让团队成员更快地从关注状态中解脱出来，因为他们知道如果出现问题，只会影响少量机器，并且系统会自动恢复。
- 在 Uber，我们开发了一个自助服务配置系统，替换了之前需要 SRE 亲自处理的服务请求和配置流程。我们保留了对生产环境中计算资源扩展的控制权，这样既保证了重要问题的控制，又不会阻碍创新实验的速度。
- 在 Calm，我们改用功能标志来控制用户访问权限，而不是通过部署来控制。这样我们可以立即发布或撤销功能，而不需要依赖相对较慢的部署过程。
常见失败模式：
- 换汤不换药：有时候，团队会错误地认为新方案更优，但实际上只是换了一种方式。这种情况通常发生在团队从一个预设目标出发（比如“我想用 Redis”），而不是从实际问题出发（比如“我们的主数据库因为频繁查询少变动数据而负载过重”）。
- 增加了更多的解决方案：新的方案在某些方面确实更好，但在许多其他方面并没有改善，结果是只有部分用户获得了更好的体验，而大多数用户并没有感受到差异，同时你还需要维护更多的解决方案。（这是迁移失败的众多情况之一。）
产品能力的创新
产品能力的创新 指的是在产品中实现以前无法实现的功能，或者大幅提升现有功能的效率。这种创新不仅需要发现具有重大意义的新事物，还要投入资源以实现它，并且说服用户（包括公司内部的用户）接受这一创新，这确实是一个难得的三重成就。
例如：
- 曾经，Calm 发布新内容需要内容、产品和工程团队的密切配合。这意味着新产品的开发往往会因为发布内容的工作而被打断。为了解决这个问题，我们开发了一套工具和工作流程，使产品和工程团队能够完全不参与新内容的发布，同时大幅提高内容团队的工作效率。在这个项目之前，公司的大部分精力都集中在内容的发布上。项目完成后，只有内容团队需要专注于内容的发布
- 之前，Calm 的增长、产品和内容团队就如何手动安排新内容的位置产生了分歧。内容的放置位置对其表现有显著影响，不同团队的目标不一致（所有内容的表现与特定内容的表现），这导致了关于内容定位的持续争论。我们用一个基于机器学习的系统来替代手动放置，该系统能够针对每个用户优化内容展示，并为新内容引入了一种内容测试机制。这样不仅能在不牺牲整体表现的前提下扩大好内容的影响力，而且避免了人为的争议。这使我们能够在各方面都取得更好的结果，同时消除了一个主要的协调和紧张的根源。
失败模式：
- 针对尚不存在的问题构建能力：这通常是因为平台想要为某个解决方案创造新的需求，而不是针对现有问题产生的需求（例如，在 Calm，内容管理是一个持续的难题，我们提出的解决方案立刻得到了需求响应；而在 SocialCode，我们开发了一个网络爬虫服务，但由于过于注重技术先行，误判了实际问题，关注了爬虫配置而非真正需求的 Token 管理）
- 在资金耗尽前未能实现交付：这通常是因为方案架构不佳，无法实现逐步支持。这种情况往往发生在没有明确用户对象时，我们无法用他们需要的特定功能来验证方案，而是试图构建一个全面支持未来可能采用的抽象产品
- 推广采用的失败：有许多有用的工具却未被市场接受。原因有好有坏，比如产品不可靠、成本过高，或是涉及高管间的个人不和。不论是哪种原因，未被采用都意味着产品能力的失败
工作流程与能力的选择
工作流程的改进和产品能力的提升都非常重要。团队应根据预期的投资回报和风险预算的真实评估来做出选择。如果你不能承担太多风险，那就专注于改善工作流程。即便能够承受一定风险，也不应同时尝试过多的产品能力改进——这些通常有很高的失败率，而我们需要快速学习并转向下一个尝试。
根据我的经验，大多数工程团队在启动产品能力时都很难同时完成识别机会、筹集资金和推动产品采用这三项关键任务。以下是一些有助于这方面的技术：
- 识别机会：产品发现的核心技术
- 资金支持：通过解决特定用户的有限用例来识别逐步可交付成果，从而为整个项目提供资金
- 推动采用：先为最难满足的客户设计产品，以降低解决方案不适用于他们的风险
我的经验法则是，只有在有强有力的技术领导、工程高级管理的支持以及更广泛的高管团队对工程高管的信任的情况下，才能成功推出产品能力。缺一不可，否则成功的可能性极小。
谨慎行事，权衡优先
对于工程组织来说，通常更多地投资于技术杠杆是明智的选择，但前提是他们有成功利用技术杠杆的经验。如果你还没有这方面的成功经验，那么最好是从小规模开始，逐步建立起完成这类工作的信心，并确保其成果具有实用价值。
如果在组织对如何选择和实施这些工作还不够了解的情况下过度投资，那么你可能不会给工具或产品带来变革性的提升，反而可能产生大量的技术债务。好在，改善这种情况的方法相对简单直接。这些项目常常因为一些平淡无奇的原因而失败，比如在获得反馈之前任务过重、为不存在的用户开发、制作有趣但非实用的东西。
对这些风险保持警觉，逐步增加预算，这样你会逐渐掌握其中的诀窍。如果你被那些看似有趣但实际上并不解决具体问题的项目分散了注意力，你可能会度过一个充满乐趣的季度，但随后却需要花费数年时间来清理这些混乱。
