Привет, Хабр! Меня зовут Виктор Кононенко, я CTO Food.ru (X5 Медиа). Мы в X5 Group запустили новый ресурс, посвящённый еде и кулинарии. Расскажу про команду, технологический стек и наши рабочие процессы.
Идея
Когда вам говорят о корпоративном медиа, что вы себе представляете? Правильно, скучный тред о своих достижениях и прорывах. Настоящее медиа, даже и созданное компанией, должно приносить пользу читателям. Поэтому на Food.ru мы говорим о здоровом питании, пищевых привычках, делимся рецептами. Затрагиваем и смежные тематики — например, обсуждаем бытовую технику для кулинарии.
Еще до реализации проекта мы подробно изучили рынок. В российском сегменте есть несколько аналогичных ресурсов, и большинство из них работают более десяти лет. Срок не малый, поэтому они и работают до сих пор на устаревших технологиях, а качество размещенного визуального контента иногда оставляет желать лучшего [с тех пор фотокамеры проделали большой путь]. Мы также задались вопросом, а стоит ли нам, крупному ритейлеру, говорить о таких простых вещах, как рецепты. Международный опыт показывает – да, стоит. Например, одна торговая сеть в Германии позволяет своим клиентам сформировать товарную корзину по рецепту и заказать доставку на дом.
С самого начала мы поняли, что хорошее медиа - это не только качественный контент, но и передовые технологии «под капотом».
Технологии
По сути, Food.ru — это стартап внутри X5 Group. Мы видим в этом преимущества. У «старшего брата» есть множество цифровых решений, из которых мы, как из кубиков, собрали основу собственной инфраструктуры — использовали облако, настроили CI/CD, сделали интеграцию мониторингом, системой централизованного логирования и многими другими централизованными платформами. После того как фундамент был положен, мы перешли к выбору архитектурных решений непосредственно на уровне разрабатываемого ПО.
В случае с мобильными платформами мы пошли по пути нативной разработки, чтобы обеспечить дополнительную стабильность и производительность приложений, упростить последующее добавление новых функций, а также поиск сотрудников. Выбрать архитектуру для веб-версии Food.ru было сложнее. Мы хотели использовать модель SPA. Она позволяет реализовать максимально дружелюбный пользовательский интерфейс и быструю работу витрины даже на слабой скорости соединения, но нас останавливали потенциальные проблемы с SEO-оптимизацией. В итоге «плюсы» перевесили «минусы» — строить SPA решили на React с применением Next.Js для серверного рендеринга. В остальном постарались взять максимально стандартный набор. Такой как PostgreSQL в качестве основной СУБД и Python (для бэкенда).
Спойлер, несколько неприятных моментов от Next.js мы всё-таки за год работы получили. Даже в какой-то момент начали обсуждать альтернативы. Но в итоге продолжаем с ним работать.
В процессе разработки мы столкнулись с рядом сложностей. Интеграция с инфраструктурой X5 Group упростила старт, но на дистанции нам все же пришлось бороться с бюрократическими процессами. Согласование отдельных вопросов со службой безопасности и отделом закупок могли тянуться месяцами. Это нормально для корпорации с огромными ресурсами, но недопустимо для стартапа. Решить проблему удалось благодаря поддержке коллег. Они в кратчайшие сроки помогли разработать, согласовать и реализовать не типовое на тот момент архитектурное решение. В последующем оно стало прообразом одной из типовых архитектур доступных для всех проектов, размещенных в контуре X5.
Суть решения заключалась в формировании не стандартной конфигурации DMZ. Она позволяла минимизировать количество ресурсов инфраструктуры, требуемых для прохождения большого объема трафика. А еще давала команде разработки максимальный уровень свободы на этапе реализации. Позволяла решить проблемы с базовым уровнем безопасности, хранения персональных данных и максимально простым доступом к инфраструктурным сервисам X5.
В своем контуре мы могли решать любые локальные вопросы, не требующие глобального пересмотра архитектуры и дополнительного процесса согласования. Например, нам не хватило гибкости в управлении базами данных и S3-совместимом хранилищем. Мы развернули их самостоятельно. Хотя первоначально планировали использовать централизованные решения, которые на первом этапе могли значительно ускорить процесс запуска проекта.
Много внимания на проекте мы уделяем качеству фотоматериалов. Сейчас у нас сотни тысяч картинок. Мы храним их в максимально доступном качестве. На этапе проектирования мы сразу закладывали использование CDN и несколько уровней кэширования контента. Вопрос с форматированием изображений решили с применением imgproxy. Решение на тот момент казалось спорным, но полностью себя оправдало в процессе эксплуатации.
В качестве CDN мы взяли одно из решений подрядчиков, которые уже в тот момент работали в X5. Это позволило сэкономить много сил на заведение нового договора. Что в реалиях большой корпорации задача может и не очень сложная, но точно не быстрая. Кто пробовал, знает, о чем я говорю.
Определенные сложности возникли и с набором команды, так как мы делали это в авральном режиме — параллельно с обсуждением архитектуры и написанием кода. Немного расскажу о том, как у нас устроен этот процесс.
Люди
Специалистов в команду мы ищем всеми доступными способами (конечно, только легальными). В данном случае сильно помогают возможности корпорации, наработанные практики и связи. Используем все – нетворкинг, агентства, а несколько ключевых сотрудников устроили даже по модели аутстафинга. Времена сейчас непростые. Рынок высококонкурентный, поэтому ведем работу сразу по всем фронтам.
Отношение ко всем одинаковое — кандидаты проходят до трех этапов отбора. На первом собеседовании мы оцениваем софт-скиллы и проводим верхнеуровневое техническое интервью. Если по его итогам остаются вопросы, проводим второй этап – техническое интервью. Третья встреча проходит по желанию соискателя. Не только мы ищем себе людей в команду, но и люди стараются найти себе комфортное место для работы. Мы даем кандидату возможность выбрать несколько ролей из команды и организовываем встречу. На ней они могут познакомиться с будущими коллегами. Задать интересующие их вопросы и принять финальное решение.
На рынке последнее время набирает популярность техника odo [one day offer]. Мы тоже практикуем этот подход. Если уже на первом этапе диалог складывается и становится понятно, что проводить дополнительные этапы смысла нет, - мы сразу переходим к этапу обсуждения оффера. Наша практика показывает, что такой подход дает хорошие результаты, хотя и везение тут тоже немаловажно.
Сейчас над Food.ru работает более 70 человек — это маркетологи, контент-мейкеры, продакт-менеджеры и дизайнеры, но самую большую категорию составляют разработчики.
В технической части команды мы придерживаемся концепции – все необходимые роли должны быть внутри команды разработки. Их можно разделить на следующие составляющие:
Команда мобильной разработки. Отвечает за развитие приложений под iOS и Android. Сейчас это руководитель команды и по три инженера на каждую из платформ. Планируем увеличить до 4. Далее будет зависеть от развития продукта. Но уже сейчас мы видим, что мобильное приложение имеет значительно более качественные пользовательские метрики чем веб.
Относительно большая команда Back и Front разработки. Сейчас это 12 человек, и мы продолжаем расти. Команда отвечает за разработку основой веб витрины, общего API и системы управления контентом [CMS]. В основе лежит сервисно-ориентированная архитектура. Неожиданным моментом для многих может показаться факт, что самой ресурсоемкой и сложной частью проекта оказалась разработка именно CMS. Она создана не просто для хранения и управления отображением, но и для создания контента. Причем, учитывая потребности в создании десятков тысяч материалов с возможностью их адаптивного отображения на различных витринах. Механизмом импорта материалов в пакетном режиме, который на первом этапе позволит решить практически фантастическую задачу запустить в короткие сроки проект с десятками тысяч материалов несколькими редакторами и армией подрядчиков, помогающей создавать материалы. И делая все это одновременно.
Команда QA. Не столь многочисленная часть нашей команды, но именно ее подход позволит решить поставленные задачи. Мы используем стандартную схему 20%. На четыре инженера в разработке один инженер по качеству. На первом этапе мы сконцентрировались на ручном тестировании и четком разделении критичных багов и того, что не влияет на пользовательский опыт и можно исправить в дальнейшем. Или не исправлять и оставить как есть, но пусть история об этом умалчивает... Постепенно мы начали двигаться в направлении автоматизации, но и на текущем этапе ручное тестирование для нас приоритет.
Команда DevOps инженеров. Точнее пока, к нашему сожалению, он один. Но это настоящий ниндзя! Ловко решающий как задачи разворачивания инфраструктуры, так и помогающий командам с CI/CD. Попутно решающий вопросы не самой простой инфраструктуры X5. Но мы в активном поиске людей для расширения этой команды. Возможно, ты тот, кто нам нужен!
Внутри команды мы четко разделяем продуктовый и проектный менеджмент. По нашему мнению, это дает нам возможность эффективно синхронизировать два мира. Мир пользовательского опыта, метрик, продуктовых требований и коммерческой выгоды с миром реализации всего задуманного с концентрацией на доставку пользовательской ценности на коротком временном интервале [Sprint]. Для этого в команде у нас есть несколько деливери менеджеров и аналитиков. Мы уделяем много времени проработке требований до этапа разработки. Без аналитиков никуда. Все знают, что поправить спецификацию и дизайн дело нескольких минут, а готовый продукт - в лучшем случае дней. Но почему-то не все идут по этому пути.
Работа
Вся команда — на удаленке [в офис ходит лишь несколько человек по желанию]. Проблем с этим нет, так как мы сразу ориентировались на такой формат и нанимаем специалистов, способных контролировать собственное время. Мы работаем по Scrum. Но оптимизировали его под наши нужды. Добавили обязательные офлайн ревью артефактов [спецификации и дизайн] до их попадания на груминг. Это значительно улучшило качество артефактов, дало возможность команде заранее дать обратную связь владельцам артефактов и время внести требуемые правки.
Все процессы - живые. Мы часто экспериментируем, добавляя новые и убирая не оправдавшие надежд проектные практики. Одним из примеров полезной прижившейся практики можно назвать «кофе-брейк». Мы все работаем на удаленке, что накладывает некоторые сложности на процессы командообразования. Перед 15-минутными дейли мы добавили для каждой команды необязательные 15-минутные «кофе-брейки». На них можно обсудить любые вопросы. Послушать интересные истории от коллег. Намного лучше понять людей, с которыми ты работаешь. Практика появилась как попытка улучшить качество стендап митинга. Но в итоге оказалось, что мы получили намного большее. Площадку для не формального общения, закрывшую вакуум общения удаленной работы.
Мы постарались убрать лишнюю бюрократию и сократить число совещаний. Так, за двухнедельный спринт на митинги уходит не более восьми часов. Это не значит, что митингов больше нет, это значит, что все остальное, это локальные встречи для решения конкретной задачи. В них не требуется участие всей команды. Это позволяет выделить максимум времени на работу. Митинги – важная часть процесса. Но на них код не пишется, дизайн не рисуется, релизы не катятся. А делать «работу» после «работы» - не лучшая затея с точки зрения производительности.
Мы много времени уделяем планированию. Весь процесс сконцентрирован возле трех основных артефактов: глобальной дорожной карты на горизонте 6-12 месяцев, разбитой на двух-месячные секции, планирования пользовательских историй на два спринта вперед для каждой команды и самого спринта реализованного через доски в Jira. В него попадают конкретные задачи с декомпозицией не более одно человека-дня. Чтобы объяснить, как это работает и почему все сделано именно так, нужно написать целую статью. Если будет много комментариев на эту тему, обязательно напишем. Если кратко, то мы делим стратегию, тактику и операционный уровень. Над каждым работает по большей части разная часть команды. Это минимизирует количество участников и не позволяет размывать зоны ответственности. Дает возможность учитывать пожелания всех заинтересованных сторон. И самое главное отвечает на самый сложный вопрос для любого стартапа – что НЕ нужно делать именно сейчас.
С этого года мы планируем деление на сервисные и PoC команды. Выделить команду развития основного продукта и много другие преобразований задача которых позволить нам сохранить высокий темп разработки. Что в итоге получится, покажет время. Мы собрали крутую команду, теперь дело за малым - реализовать ее потенциал на все 100%.
Перспективы
С момента запуска Food.ru наша аудитория ежемесячно удваивалась. На декабрь 2021 года было более 15 млн уникальных пользователей. Это позволило выйти на требуемые показатели охвата пользовательской аудитории менее чем за год после появления идеи запуска проекта. Еще на старте мы заложили в инфраструктуру дополнительный «запас прочности», поэтому легко выдержим нагрузку 20 миллионов (и более!) пользователей. Хотя в перспективе нам могут потребоваться значительные обновления, когда мы добавим возможность стриминга видео контента.
В 2022 году мы планируем реализовать десятки новых фичей. Проверить несколько больших продуктовых гипотез. Каждая из которых может стать одним из ключевых векторов роста проекта.
Дадим возможность пользователю быстрого заказа продуктов для приготовления блюда прямо из рецепта. Интеграции уже на подходе.
Сделаем упор и на новые контентные форматы. Одна из продуктовых гипотез к развитию в рамках Food.ru - полноценная образовательная платформа, где пользователи могут прокачивать свои кулинарные навыки. Например, освоить новые для себя техники работы с ножом или узнать больше о блюдах итальянской кухни. Сейчас тренинги такого уровня стоят дорого и зачастую доступны лишь жителям двух столиц, в регионах мало кто может себе их позволить. Мы планируем исправить ситуацию — первые ролики загрузили уже в конце октября.
В целом команда Food.ru растет достаточно быстро, и нам нужны маркетологи, авторы, и все специалисты задействованные в процессе разработки. Тех, кто хочет работать не по корпоративным стандартам, а в формате foodtech-стартапа. Если вам интересно наше направление и хотите попробовать свои силы, добро пожаловать на нашу страницу вакансий. Всегда рады новым знакомствам!
