Как улучшать продукт с помощью догфудинга

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

Сегодня мы поговорим о догфудинге.

Догфудинг (англ. Dogfooding, Eating your own dog food) - это практика использования сотрудниками компании собственных продуктов и сервисов.

Чувствую, как у читателя начинают возникать вопросы «Что???», «Причем тут собачий корм?». Однажды мне даже сказали, что этот термин вызывает неприятные ассоциации.

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

В 2006 году редактор журнала IEEE Software Уоррен Харрисон провел собственное мини-расследование, чтобы найти первоисточник термина «Догфудинг». В результате он обнаружил первое упоминание рекламной кампании собачьего корма Aplo 1976 года, где актер Лорн Грин говорит о том, что и в самом деле кормит своих собак кормом, который рекламирует.

Второе упоминание, которое нашел Уоррен Харрисон, было основано на слухах, что президент компании Kal Kan Pet Food съедает банку собачьего корма на ежегодном собрании акционеров.

В IT кругах термин впервые использовал менеджер компании Microsoft Пол Мариц в 1988 году, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager Брайану Валентайну, электронное письмо с заголовком «Eating our own dog food», призывая увеличить использование продукта внутри компании.

Вскоре термин «догфудинг» стал активно использоваться внутри Microsoft, а затем и в других компаниях.

Догфудинг открывает много возможностей для компаний, которые его используют, но как и любая другая практика имеет свои сильные и слабые стороны, и должна использоваться с умом.

Преимущества:

Недостатки:

Мы делаем платформу для low-code разработки, и наш основной продукт на данный момент - GraphQL Backend-as-a-Service, который должен работать стабильно и быстро. Пользователи могут создавать любые бэкенды, что создает сложности для отладки абсолютно во всех кейсах использования.

Для нас догфудинг начался просто: в 2019 году, вскоре после того как мы запустились, нам требовались пользователи, чтобы попробовать 8base в «боевых условиях».

В тот момент мы проводили маркетинговую кампанию, направленную на предпринимателей, и к нам пришли несколько стартапов, которые хотели сделать свои проекты, используя наш сервис. У них не было разработчиков, способных работать с нашей платформой, поэтому мы решили, что поможем. Так появилось подразделение 8base Labs.

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

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

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

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

Здесь наверное лучше рассказать случай из жизни.

В 8base мы даем пользователям возможность расширять функциональность бэкенда с помощью пользовательских(кастомных) функций, например: вам нужно написать бизнес-логику или расширить возможности GraphQL API.

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

Если одна функция имеет папку node_modules размером 200 мегабайт и деплоится за 60 секунд, то проект из 20 таких функций использует уже 4 гигабайта места, и деплой длится 20 минут, а что если функций 80…

Проблему усугубило появление функции CI/CD, которая позволяла создавать множество веток основного воркспейса, таким образом мы умножали количество используемого места на количество веток, что в результате привело к тому, что у нас закончилось свободное место. А за время деплоя можно было пообедать.

Так как мы разрабатываем проекты на 8base, то мы активно пользуемся деплоем наших кастомных функций, и мы первыми почувствовали боль. Мы ввели ограничение - 6 веток на один воркспейс, но это не помогло. Доходило до смешного - сначала нам пришлось удалять неиспользуемые ветки, чтобы выполнить деплой нового функционала, под конец уже приходилось забыть про ветку на каждого разработчика и ждать своей очереди, чтобы использовать общую ветку. Талоны в очередь на деплой, чем не коммунизм в худших его проявлениях?

Мы знали, что рано или поздно мы упремся в лимиты, и в момент когда команда 8base Labs испытывала самые критичные проблемы с деплоем, бэкенд команда уже тестировала фикс, добавляющий общий switch case для кастомной логики, таким образом весь код деплоился как одна AWS Lambda с общими зависимостями.

Результат:

До:

После:

Ну и конечно же улучшение сразу почувствовали наши кастомеры:

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

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

Бонусом от использования догфудинга оказалось то, что, нанимая людей сначала в команду 8base Labs, а затем предоставляя им возможность перейти в основную команду фронтенд или бэкенд разработки, мы получаем подготовленных, мотивированных профессионалов, которые работали с 8base, знают, для чего он нужен и как его использовать.

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

8base – это готовый к использованию GraphQL backend-as-a-service, созданный разработчиками для разработчиков. Платформа 8base позволяет разработчикам создавать потрясающие облачные приложения с использованием JavaScript и GraphQL. Узнайте больше о платформе 8base здесь.