В современном мире как никогда важно выпускать качественные, конкурентоспособные продукты и на эту тему написано много статей и книг, придумано много практик. Я хотел бы остановиться на одной из них, простой в использовании и действенной, непосредственный опыт внедрения которой имею.
Сегодня мы поговорим о догфудинге.
Догфудинг (англ. 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, а затем и в других компаниях.
Преимущества и недостатки
Догфудинг открывает много возможностей для компаний, которые его используют, но как и любая другая практика имеет свои сильные и слабые стороны, и должна использоваться с умом.
Преимущества:
Помогает лучше отладить продукт, так как использование в реальных условиях позволяет найти неочевидные проблемы и «узкие места»;
Улучшает опыт взаимодействия пользователя с продуктом благодаря тому, что команда смотрит на продукт «глазами пользователя» и вносит необходимые улучшения;
Дает возможность выпускать новые функции, сначала для использования своей командой, с целью отладки и сбора обратной связи, а затем - для остальных пользователей;
Продуктовые менеджеры могут использовать эту догфудинг, чтобы проводить CustDev с командой;
Ну и как бонус: разработчики используют собственный продукт, понимают как он работает, зачем нужен, и уверены в его качестве.
Недостатки:
В какой-то мере эта практика ограничивает возможности развития продукта, так как команда не понимает, насколько ваш продукт хорош в сравнении с другими. Идеально - время от времени использовать и анализировать продукты конкурентов;
Не заменяет QA. Скорее даже не недостаток, а факт. Я бы насторожился, если бы какая-то компания использовала догфудинг вместо QA;
Сотрудники не платят за софт, что накладывает ограничения на то, насколько объективно можно воспринимать их обратную связь;
Подходит далеко не всем компаниям, например, если вы делаете софт для медицинских учреждений.
Как мы используем догфудинг в 8base
Мы делаем платформу для 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 с общими зависимостями.
Результат:
Каждая ветка занимает всего 200 мегабайт, и проблема с отсутствием места решена;
Каждый разработчик может создавать множество веток;
Сократилось время деплоя - раньше для проектов с большим количеством кастомных функци составляло 20 минут, теперь 60 сек.
До:
После:
Ну и конечно же улучшение сразу почувствовали наши кастомеры:
Выводы
В предыдущей статье я уже рассказывал о том, как создатели Airbnb бронировали апартаменты через свой сервис для того, чтобы лучше понять своих пользователей. В результате это помогло им улучшить платформу.
И вот спустя два года благодаря догфудингу мы существенно улучшили наш сервис и опыт взаимодействия с пользователями. Постепенно мы стали делать крупные проекты, в том числе хайлоад, и в данный момент мы оптимизируем узкие места в производительности, чтобы уверенно держать растущую нагрузку.
Бонусом от использования догфудинга оказалось то, что, нанимая людей сначала в команду 8base Labs, а затем предоставляя им возможность перейти в основную команду фронтенд или бэкенд разработки, мы получаем подготовленных, мотивированных профессионалов, которые работали с 8base, знают, для чего он нужен и как его использовать.
Подведем итоги:
Разработчики уверены в продукте, который делают, и в его качестве;
Тестируем быстродействие, отказоустойчивость, возможности платформы на различных кейсах;
Пробуем новые функции ограниченным числом пользователей в реальных условиях;
Улучшаем платформу на основании обратной связи от команды;
Готовим кадры - берем в команду продукта людей с опытом использования самого продукта, которые понимают, зачем он нужен и как устроен;
Собираем идеи для новых продуктов компании, делаем MVP и тестируем внутри;
И конечно же, разработка продуктов на заказ это живые деньги, которые так необходимы стартапу.
Надеюсь моя статья будет полезна, оставляйте ваши вопросы в комментариях, так же было бы интересно услышать об опыте использования догфудинга.
О компании
8base – это готовый к использованию GraphQL backend-as-a-service, созданный разработчиками для разработчиков. Платформа 8base позволяет разработчикам создавать потрясающие облачные приложения с использованием JavaScript и GraphQL. Узнайте больше о платформе 8base здесь.
