Привет, «Хабр»! Меня зовут Дмитрий Парфёнов, я технический директор в «Сравни.ру». Сегодня я расскажу, как в нашей компании выстроены процессы продуктовой разработки, какие метрики мы используем в работе и как происходит онбординг новых сотрудников.
Базовые принципы
«Сравни.ру» на рынке с 2009 года, поэтому все процессы в компании уже давно устаканены, хотя с течением времени они постепенно эволюционируют, подстраиваясь под нужды бизнеса по мере его развития. Но не будем углубляться в историю и посмотрим, как обстоят дела сейчас.
Сейчас в IT-команде «Сравни.ру» около 150 человек. Два основных направления разработки, которые мы активно развиваем, — это веб-сайт и мобильное приложение, с ними ежемесячно взаимодействуют 11 млн пользователей. Глобально компания работает по методологии agile, а вся разработка происходит на базе микросервисной архитектуры.
Технологический стек
Наш проект существует уже много лет, за это время инфраструктура разрослась и стала довольно сложной. Вот лишь краткий обзор того, какие технологии мы применяем сегодня:
Инфраструктура: managed облачные решения Azure и Yandex Cloud, Kubernetes, RabbitMQ, Kafka, Redis, Consul
Базы данных: MongoDB, Postgres, MySQL, MSSQL
Observability: Grafana, Elastic, Kibana, Jaeger, Amixer
Фронтенд: React Nextjs (веб), Swift, Kotlin, React Native (мобайл)
Бэкенд: Node.js, java, nestjs, .Net, PHP, Python, Go
ML: H2O.ai
VCS: GitHub
CI/CD: Teamcity, GitHub actions
Теперь поговорим о том, как вообще устроена работа инженерных команд в компании.
Продуктовые команды
Под каждый продукт формируется отдельная команда, в которую входят бэкендеры, фронтендеры, тестировщики, дизайнеры, проджект-менеджеры; развёртыванием занимается команда devops, но в целевом варианте команды и эту функцию берут на себя. Кроме технических специалистов, в каждой команде есть product owner, который отвечает за бизнес-показатели, выручку, клиентов, прогнозирование, постановку целей по OKR, аналитику, CJM (Сustomer Journey Map).
Каждая команда должна полностью закрывать все потребности продукта, в том числе интеграции с партнёрами, поставщиками данных, внешними системами (типа реестра Бюро кредитных историй).
Помимо продуктовых, у нас есть платформенная команда, которая занимается созданием общебизнесовых решений и core-сервисов, разрабатывает сервисную архитектуру, задаёт технические стандарты и метрики — короче говоря, формирует некий структурный подход ко всему процессу разработки в компании.
Планирование работ в среднесрочной перспективе выполняется по итогам ежеквартальных встреч с бизнес-руководством. Впрочем, взаимодействие с бизнесом происходит постоянно, так как это неотъемлемая часть процесса разработки.
Собственно, весь процесс продуктовой разработки мы делим на две стадии, которые непрерывно перетекают друг в друга в повторяющемся цикле развития продукта, — это product discovery и product delivery.
Product discovery: выявление потребностей и постановка задач
Product discovery — это процесс исследования потребностей пользователей, на основе которого принимаются решения о доработке существующих и запуске новых продуктов. Причём это не единичные мероприятия, а система непрерывного сбора и анализа данных, позволяющая делать максимально релевантный и удовлетворяющий нужды пользователей продукт.
Для проведения глубинных исследований у нас есть своя UX-лаборатория, специалисты которой тестируют гипотезы, проводят интервью с пользователями, проходят по различным сценариям CJM, делают аналитику и делятся своими находками с product owner.
На основе этой информации продакты формируют пул высокоуровневых задач для продуктовых команд. Затем эти задачи проходят ревью, во время которого технические специалисты проверяют их на адекватность и реализуемость.
В случае удачного прохождения ревью задачи декомпозируются на более мелкие, на основе чего для продакта рисуется горизонт событий — то есть примерные сроки и трудозатраты. И если бизнес даёт добро, то запускается процесс product delivery.
Product delivery: непрерывный процесс улучшения
Product delivery — это непосредственно процесс разработки продукта, который опирается на те цели и задачи, которые были сформулированы на стадии исследования. Руководит им специальный деливери-менеджер: собирает команду, участвует в грумингах («причёсывании» бэклога), декомпозирует и прорабатывает задачи, следит за сроками и в целом отвечает за конечный результат.
Разработчики задействованы в спринтах, для каждого из которых берётся несколько приоритетных задач из бэклога. По итогам каждого спринта проводится ретроспективный анализ, цель которого — выявить слабые места в процессах, недоработки и способы их устранения. Ретроспективы проводят скрам-мастера, которые в нашей компании выполняют также роль коучей или фасилитаторов для команд.
После каждой ретроспективы формируется список выявленных проблем, который преобразуется в чекбокс для следующих спринтов. Главный челлендж — полностью закрыть чекбокс, чтобы эти проблемы не перетекали из спринта в спринт.
В целом в product delivery у нас задействованы все канонические «обряды» скрама: декомпозиция, планирование, оценка задач в сторипоинтах, анализ метрик, ретроспективы. Для управления всеми этими процессами мы используем облачную Jira с кучей аддонов (например, Scrum Poker, Easy BI).
Метрики и оценка эффективности
Для оценки эффективности работы команд у нас действует система метрик, которые делятся на общие, командные и индивидуальные. Разработкой метрик занимается отдельный специалист, для этого он в том числе использует опыт командных ретроспектив. Вот пара примеров:
Сapacity — сколько сторипоинтов команда сжигает за спринт. В частности, отслеживается увеличение выработки команды с течением времени (история позволяет нам планировать будущие спринты).
Статистика по эпикам (большим фичам) — высокоуровневые отчёты, помогающие оценить, как продвигается разработка в целом.
Статистика по зависшим задачам — помогает не терять из вида приостановленные задачи, а также насторожиться, когда их становится слишком много.
Что касается подвешенных задач, то иногда возникают так называемые влёты (внезапные новые срочные фичи), из-за которых разработка предыдущих фич приостанавливается. Но все эти влёты должны быть обоснованы и верифицированы технической и бизнес-командами.
Нужно отметить, что некоторые команды, особенно сервисные или проектные, работают по канбану и в меньшей степени завязаны на метрики.
Из инструментов аналитики мы используем готовые решения PowerBI, Snowflake, Amplitude, Appsflyer, Google Analytics – в планах подробная статья о работе с этими инструментами.
Мы активно растем и расширяем техническую команду. Сейчас у нас открыты десятки вакансий для инженеров – будем рады пообщаться!
***
В следующих материалах мои коллеги и я подробнее расскажем о конкретных продуктах и проектах «Сравни.ру. А пока буду рад ответить на ваши вопросы в комментариях!