Принципы продукта Intercom: Построение небольшими шагами для обеспечения максимальной ценности для клиента

Большие изменения трудно понять и сложнее отлаживать.

В Intercom мы вносим сложные изменения в серию небольших, контролируемых и простых для понимания шагов. Небольшие изменения легче вносить и быстрее проверять, что позволяет нам быстрее приносить пользу клиентам.

Это седьмой пост из серии, посвященной принципам работы с нашими продуктами . Здесь Эйдан обсуждает наш инженерный принцип «Строим маленькими шагами».

Никто не понимает это правильно все время

Ошибки случаются в каждой команде, в каждой компании в мире. Как только вы признаете, что не всегда будете делать все правильно, вы можете приспособиться одним из двух способов:

• Старайтесь исправлять ошибки до их отправки, принимая меры для подтверждения или проверки своей работы.
• Дайте себе право ошибаться, учитесь на ошибках и быстро приспосабливайтесь, чтобы исправить их.

Если вы уже потратили недели на изменения, у вас меньше шансов ошибиться. Это может привести к тому, что вы будете полагаться на проверку, чтобы избежать неожиданностей при отправке изменений. У валидации есть свое место, но это плохая замена реальному развертыванию чего-либо. Чем больше проверок вам нужно выполнить перед отправкой, тем больше времени потребуется, прежде чем вы сможете выполнить итерацию или перейти к следующей функции — в конечном итоге это замедлит вашу работу.

При отправке изменения мы стремимся контролировать:

• Количество затронутых переменных: чем больше переменных затронуто во время изменения, тем сложнее выяснить, какая часть изменения вызвала проблему. Уменьшая размер каждого шага, мы сужаем петлю обратной связи и настраиваемся на то, чтобы учиться и приспосабливаться гораздо быстрее, если нам это нужно.
• Размер изменения: уменьшая размер наших изменений, мы также уменьшаем радиус взрыва каждого изменения. Важно тестировать изменения, но их не так много, чтобы уловить предварительную проверку. Небольшие изменения позволяют нам сосредоточить наше внимание на постепенном достижении вашей цели и не слишком зацикливаться на том, чтобы каждое изменение было идеальным.
• Какие клиенты испытывают изменения: мы полагаемся на флаги функций для проверки изменений в рабочей среде и поэтапного выпуска их для клиентов.

Мы не знаем наверняка, решит ли эта функция проблему клиента, пока она не окажется у него в руках. Это обязательство выпускать небольшие итерации быстро увязывается с другим принципом Intercom: отправляйте, чтобы учиться.

Управление сложностью

Строить внутри сложных систем сложно. Когда в больших изменениях обнаруживаются ошибки или раздутые функции не достигают цели, трудно точно определить конкретную проблему. Небольшие шаги упрощают проверку, изменение и движение вперед — будьте уверены, что вы строите на прочной основе.

Большие изменения включают в себя множество допущений:

• Внешние предположения о том, как ваше изменение повлияет на рабочие процессы ваших клиентов.
• Внутренние предположения о том, как различные части вашего изменения взаимодействуют и зависят друг от друга.

Несмотря на то, что вы можете сделать все возможное, чтобы проверить внешние предположения, зачастую быстрее и надежнее отправить изменения, а также проверить их или скорректировать. Внутренние предположения — вот где может возникнуть сложность. Когда ваше изменение становится достаточно большим, чтобы охватить несколько строительных блоков, которые все зависят друг от друга, их совместное тестирование может быть рискованным. Гораздо безопаснее выпускать их постепенно, надстраивая одно поверх другого и отслеживая влияние по ходу дела.

Устойчивая скорость создает импульс

Скорость отличная, но надежная, надежная скорость меняет правила игры. Внедрение крупного изменения означает, что от его успеха зависит гораздо больше, и более высокий риск неожиданностей по сравнению с серией небольших, быстрых итераций.

« Напряженный цикл внесения небольших изменений, обучения и итерации создает сильный импульс»

Плотный цикл внесения небольших изменений, обучения и итерации создает сильный импульс. Это избавляет от необходимости быть правым с первого раза, способствует более быстрому принятию решений и уменьшает радиус взрыва ошибок. Кроме того, разделение работы на более мелкие блоки означает, что инженеры могут выполнять работу параллельно, что позволяет команде двигаться быстрее в целом.

Построение небольшими шагами требует правильной командной культуры

Строительство небольшими шагами не происходит случайно, для этого требуется обдуманное намерение и правильная среда. Наша командная культура и стек инфраструктуры играют решающую роль в нашей способности быстро вносить небольшие изменения.

Как только команды осознают важность быстрой доставки небольших изменений, коллегиальные проверки становятся приоритетными и выполняются быстрее. Поскольку небольшие изменения легче понять и просмотреть, вероятность обнаружения ошибок на каждом этапе выше. Это командное понимание и срочность ускоряют весь процесс.

« Мы вложили значительные средства в обеспечение того, чтобы после того, как изменение проверено и объединено с мастером, переход в производство занял менее 15 минут, включая автоматическое тестирование и промежуточную проверку»

Когда время развертывания замедляется, инженеры более склонны вносить пакетные изменения, что приводит к циклу более крупных изменений. Мы вложили значительные средства в обеспечение того, чтобы после того, как изменение проверено и объединено с мастером, переход в рабочую среду занял менее 15 минут, включая автоматическое тестирование и промежуточную проверку. Это полностью автоматизировано, и инженеры получают автоматическое уведомление Slack, когда изменение вступает в силу.

Применение принципа «создавать небольшими шагами» к интеграции Intercom с Salesforce

В прошлом году мы стремились к более глубокой интеграции Intercom с Salesforce, что позволило клиентам автоматически создавать обращения Salesforce из диалогов Intercom. Мы быстро поняли сложность; разговоры и дела не всегда отображаются напрямую, и синхронизация данных в отношениях «многие ко многим» будет сложной задачей как с точки зрения проектирования, так и с точки зрения проектирования. Вдобавок к этому существовали большие различия в том, как клиенты хотели использовать эту функцию, и она должна была вписаться в существующую интеграцию, от которой клиенты сильно зависят.

Проработав множество последствий и конструктивных компромиссов, мы приостановили проект в пользу чего-то, что, по нашему мнению, окажет более надежное воздействие. Мы почти не строили его, потому что подошли к нему как к большому изменению, а не к серии маленьких шагов.

Мы пересмотрели проект с другим подходом

Вскоре наш отдел продаж вернулся, чтобы подчеркнуть, насколько важна эта функция для наших клиентов, и мы решили взглянуть на нее по-новому. На этот раз мы использовали другой подход, начав с минимально возможной версии и уйдя от некоторых сложностей, пока не узнали, что действительно нужно клиентам.

« Клиенты, с которыми мы работали, очень ценили скорость работы команды и то, как функция развивалась изо дня в день, руководствуясь их отзывами».

За две недели мы с другим инженером создали самую простую версию этой функции, которой мы могли поделиться с клиентами. Мы сделали это несколькими небольшими шагами, гарантируя, что не нарушим ни один из существующих рабочих процессов, которые уже использовали клиенты. Это сделало функцию гораздо более осязаемой, и клиенты могли давать конкретные отзывы о недостатках и улучшениях продукта.

После того, как клиенты начали использовать его, команда начала итерацию небольшими шагами, быстро сделав эту функцию более гибкой. По мере роста гибкости росло и число клиентов, использующих его, и мы быстро расширили бета-версию.

Оказалось, что отношение «многие ко многим» не мешало клиентам использовать эту функцию, и мы успешно запустили ее безопасно и без дополнительных сложностей, что мы обнаружили, только начав с малого и быстро повторяя итерации. Клиенты, с которыми мы работали, очень ценили скорость работы команды и то, как функция развивалась изо дня в день, руководствуясь их отзывами.

Строительство небольшими шагами работает для всех

Мы строим небольшими шагами в первую очередь потому, что это помогает нам быстрее приносить пользу клиентам более безопасным и долговечным способом. Но кроме того, для инженера это более приятный способ работы. Это гораздо менее напряжно, чем вносить большие изменения, когда многое зависит от того, окажетесь ли вы правы с первого раза, и вы получаете регулярный выброс дофамина каждый раз, когда отправляете то, над чем работаете, в производство.

Так что, если ничто из этого сообщения в блоге не убедит вас в оптимизации для снижения рисков и получения дополнительной ценности, вам следует это сделать, потому что это просто веселее.

Хотите узнать больше о том, как мы работаем в Intercom? Узнать больше.