对讲的产品原则：以小步骤构建以提供最大的客户价值
已发表: 2022-09-07大的变化很难理解，也更难调试。
在 Intercom，我们通过一系列小型、可控、易于理解的步骤来提供复杂的更改。 小的更改更容易构建和更快地审查，使我们能够更快地为客户提供价值。
这是探索我们产品原理的系列文章中的第七篇。 在这里，Aidan 讨论了我们的工程原则“逐步构建”。
没有人总是正确的
错误发生在世界上的每一个团队、每家公司。 一旦你接受了你不会一直做对，你可以通过以下两种方式之一进行调整：
- 尝试在发货之前纠正错误，采取措施验证或检查您的工作。
- 允许自己犯错，从错误中吸取教训，并迅速调整以纠正错误。
如果您已经花费数周时间进行更改，那么出错的空间通常会更小。 这可能会导致您在发布更改时依赖验证来避免意外。 验证有它的位置，但它不是真正部署某些东西的糟糕替代品。 在发货前需要进行的验证越多，迭代或继续下一个功能所需的时间就越长——它最终会减慢你的速度。
在发送更改时，我们的目标是控制：
- 受影响的变量数量：变更过程中受影响的变量越多，就越难以确定变更的哪一部分导致了问题。 通过缩小每一步的大小，我们可以收紧反馈循环，并让自己在需要时更快地学习和调整。
- 更改的大小：通过缩小更改的大小，我们还减少了每次更改的爆炸半径。 测试更改很重要，但前期验证只能捕捉到这么多。 较小的更改让我们将注意力集中在逐步实现您的目标上，而不会太着迷于确保每个更改都是完美的。
- 哪些客户经历了变化：我们依靠功能标志来验证生产中的变化，并逐步将它们发布给客户。
我们不确定该功能是否会解决客户的问题，直到他们掌握它。 这种对交付小迭代的承诺很快与另一个对讲原则联系在一起：交付学习。
管理复杂性
在复杂系统中构建具有挑战性。 当在大的更改中出现错误，或者臃肿的功能错过了标记时，很难确定具体问题。 小步骤使验证、更改和继续前进变得更加容易——相信您正在坚实的基础上进行建设。
较大的变化包括许多假设：
- 关于您的更改将如何影响客户工作流程的外部假设。
- 关于变更的不同部分如何相互作用和相互依赖的内部假设。
虽然您可以尽最大努力检查外部假设，但交付更改并验证或调整通常会更快、更稳健。 内部假设是复杂性可能蔓延的地方。当您的更改变得足够大以包含多个相互依赖的构建块时，将它们一起测试可能会有风险。 以增量方式发布这些内容要安全得多，将一个构建在另一个之上并随时监控影响。
持久的速度创造动力
速度很棒但耐用，可靠的速度正在改变游戏规则。 与一系列小而快速的迭代相比，发布一个大的变化意味着它的成功有更多的依赖，并且出现意外的风险更高。
“交付小变更、学习和迭代的紧密循环建立了强大的动力”
交付小更改、学习和迭代的紧密循环建立了强大的动力。 它消除了第一次就正确的需要，鼓励更快的决策，并减少错误的爆炸半径。 此外，将工作分解为更小的单元意味着工程师可以并行进行工作，从而使团队作为一个整体移动得更快。
小步骤建设需要正确的团队文化
小步骤的建设不是偶然发生的，它需要刻意的意图和正确的环境。 我们的团队文化和基础设施堆栈在我们快速发布小更改的能力中发挥着至关重要的作用。
一旦团队认识到快速发布小更改的重要性，同行评审就会被优先考虑并更快地完成。 由于小的更改更容易理解和审查，因此在每个阶段都更有可能发现错误。 这种团队的理解和紧迫感加快了整个过程。
“我们已投入大量资金来确保一旦更改经过审核并合并到主文件中，只需不到 15 分钟即可投入生产，包括自动化测试和分段验证”
当部署时间变慢时，工程师更倾向于批量更改，从而导致更大的更改周期。 我们已经投入大量资金来确保一旦更改经过审核并合并到主文件中，包括自动化测试和分段验证在内的生产只需不到 15 分钟即可完成。 它完全无需干预，一旦更改生效，工程师就会自动收到 Slack 通知。
将“逐步构建”原则应用于 Intercom 的 Salesforce 集成
去年，我们希望将 Intercom 与 Salesforce 更深入地集成，允许客户从 Intercom 对话中自动创建 Salesforce 案例。 我们很快就理解了复杂性； 对话和案例并不总是直接映射，从工程和设计的角度来看，跨多对多关系同步数据将是一项挑战。 除此之外，客户希望如何使用此功能存在很大差异，并且需要适应客户严重依赖的现有集成。
在考虑了许多影响和设计权衡之后，我们将项目停在了我们认为会产生更可靠影响的东西上。 我们几乎没有构建它，因为我们将它视为一个大的变化，而不是一系列的小步骤。
我们用不同的方法重新审视了这个项目
没过多久，我们的销售团队就回来强调此功能对我们客户的重要性——我们决定重新审视它。 这一次我们采取了不同的方法，从尽可能小的版本开始，避开一些复杂性，直到我们能够了解客户真正需要什么。
“与我们合作的客户非常重视团队迭代的速度以及功能在日常基础上的发展方式，并以他们的反馈为指导”
在两周内，我和另一位工程师构建了这个功能的最基本版本，我们可以与客户分享。 我们在许多小步骤中做到了这一点，以确保我们不会破坏客户已经在使用的任何现有工作流程。 这使得该功能更加切实，客户能够就产品差距和改进提供具体反馈。
一旦客户使用它，团队就会以小步骤进行迭代，从而迅速使该功能更加灵活。 随着灵活性的增长，使用它的客户数量也在增加，我们迅速扩大了测试版。
事实证明，多对多关系并没有阻止客户使用该功能，我们成功地安全地启动了它，没有这种额外的复杂性，我们只是从小处着手并快速迭代才发现的。 与我们合作的客户非常重视团队迭代的速度以及功能在日常基础上的发展方式，并以他们的反馈为指导。
小步骤建造对每个人都有效
我们以小步骤进行构建，主要是因为它可以帮助我们以更安全、更持久的方式更快地交付客户价值。 但除此之外，作为一名工程师，这是一种更好的工作方式。 与交付重大更改相比，压力要小得多，因为您在第一次就正确的情况下需要做很多事情 - 每次您将正在处理的工作交付生产时，您都会定期获得多巴胺。
因此，如果这篇博文中没有任何内容可以说服您进行优化以降低风险并提供增量价值，那么您应该这样做，因为它更有趣。
有兴趣进一步了解我们在 Intercom 的工作方式吗？ 了解更多。
