Как я перешел из продуктовой команды в инфраструктуру: итоги за год

Почти ровно год назад я сменил траекторию карьеры: из продуктовой команды, где я руководил двумя проектами в логистике, я перешел в инфраструктурную, став лидом команды в департаменте DBaaS.
Сейчас самое время подвести первые итоги.

Продуктовая разработка: скорость, highload и бесконечные встречи

В продуктовой команде я занимался двумя совершенно разными проектами:
1️⃣Highload-проект — ключевая часть логистики Ozon с жесткими требованиями:
🔍350k+ RPS, постоянные стресс-тесты, оптимизации и «танцы с бубном»
🔍минимальный Response Time (10-50ms 99q),
🔍высокая стабильность (особое внимание к тестированию и релизам),
🔍отсутствие downtime. Этот проект постоянно горел, и каждый день был похож на марафон: срочные задачи, дедлайны, стабильность любой ценой.
2️⃣Данные и аналитика — здесь highload сменился глубоким анализом. Нужно было переварить огромный бэклог от бизнеса, объединить данные из множества сервисов и создать стратегическое и уникальное решение, которое могло работать автоматизированно.

Работа была насыщенной: постоянные встречи с бизнесом, интеграции с соседними командами, контроль сроков. На одном дыхании мы запускали проекты и закрывали эпики. Но однажды я понял: все проекты для меня превратились в «перекладывание JSON -чиков из одного сервиса в другой». Завершение задач больше не приносило удовольствия.

Зачем я ушел в инфраструктуру?

На фоне выгорания мне вспомнился опыт работы с highload: Kafka, Redis, Postgres, Kubernetes, Go. Мне захотелось использовать этот опыт в более глубокой технической среде. Я поговорил с руководством, и мне предложили перейти в инфраструктурную команду, где предстояло:
🔍собрать команду с нуля,
🔍погрузиться в новые технологии,
🔍построить процессы с чистого листа.
Это был шанс выйти из зоны комфорта!

Чему пришлось учиться?
Мой продуктовый опыт оказался полезен, но этого было недостаточно. Мне пришлось:
🔍углубляться в Kubernetes, сети, Ansible;
🔍разбираться с CI/CD, observability;
🔍чтение документации, эксперименты, изучение чужого кода стали ежедневной рутиной.

Сбор команды занял чуть больше месяца. Этот процесс показал, насколько важно иметь сильную команду. В одиночку такие проекты реализовать почти невозможно.

Ключевые различия между продуктом и инфраструктурой

1️⃣Отсутствие формальных ролей
В инфраструктуре нет системных аналитиков, проектных менеджеров, скрам-мастеров. Ты делаешь всё сам: от сбора требований до проектирования. Это требует универсальности, четкого подхода к задаче и дисциплины, но одновременно дает большую свободу.
2️⃣Характер задач
В продукте сложнее понять, что конкретно хочет бизнес (он сам иногда не знает), а реализовать это — проще. Это похоже на игру в «Дженгу», где каждый новый блок должен не разрушить систему.
В инфраструктуре всё наоборот: ты знаешь, что нужно сделать, но реализация почти всегда — неизведанный путь. Приходится учиться на ошибках и жить с MVP.
3️⃣Роль команды
Инфраструктурные проекты требуют сильной синергии команды. Никто не знает всё, поэтому слаженная работа определяет успех. Также важно собрать экспертов своей области. Тут не получится уже взять джуна/мидла и научить его всему.
4️⃣Изменение фокуса
Появился баланс между встречами и временем на код. Ушли бесконечные митинги, зато добавились глубокие технические исследования.

Сложности и выводы

1️⃣Оценка результатов
В продукте успех проекта измеряется деньгами и масштабом влияния на пользователей. В инфраструктуре оценить значимость работы можно только спустя время, что добавляет неопределенности.
2️⃣Недостаток компетенций
Чувство, что ты знаешь недостаточно, никогда не покидает. Но я понял, что это нормально. Инфраструктура требует времени на освоение.
3️⃣Новая роль лидера
Быть тимлидом в инфраструктуре — это значит учиться у своей команды. Люди в команде часто знают больше, чем ты, и это правильно. Главное — уметь организовать их работу.

Итоги года

Год прошел стремительно. Чувствую ли я себя в своей тарелке? Скорее нет. Но я вижу перспективы и планирую 2025 год посвятить углублению экспертизы.