Привет, «Хабр»! Меня зовут Дмитрий Парфёнов, я технический директор в «Сравни.ру». Сегодня я расскажу, как в нашей компании выстроены процессы продуктовой разработки, какие метрики мы используем в работе и как происходит онбординг новых сотрудников. 

Базовые принципы

«Сравни.ру» на рынке с 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 – в планах подробная статья о работе с этими инструментами.

Мы активно растем и расширяем техническую команду. Сейчас у нас открыты десятки вакансий для инженеров – будем рады пообщаться!

***

В следующих материалах мои коллеги и я подробнее расскажем о конкретных продуктах и проектах «Сравни.ру. А пока буду рад ответить на ваши вопросы в комментариях!