Работа

Подборка ситуаций из шестнадцати лет инженерной работы.

Подборка ситуаций из шестнадцати лет инженерной работы. Большинство начиналось хаотично. Все были доведены до конца.

Избранные кейсы
Кейс 01

Zeals — переписывание chat-commerce платформы и организационная трансформация (Токио, 2021–2023)

Контекст

Zeals был японским chat-commerce стартапом, входящим в фазу быстрого роста. Технологически это был Ruby on Rails монолит, который не тянул запланированный запуск на рынке США. Структура команды усугубляла проблему: frontend, backend и DevOps были организованы отдельными функциональными группами, а не кросс-функциональными продуктовыми командами, поэтому любая фича, затрагивающая больше одного слоя, тратила недели на координацию перед тем, как уехать в релиз.

Решение

Я пришёл четвёртым frontend-инженером и за несколько месяцев был повышен до Head of Frontend. Я представил инженерному департаменту новую структуру команды и получил buy-in от CTO и VP of Product. За следующий квартал я нанял десять инженеров и, вместе с небольшой группой из двух человек, спроектировал новую архитектуру платформы: микросервисы, micro-frontend и автогенерируемый API Gateway. Команда из трёх человек за два месяца сделала полный дизайн платформы и стратегию миграции.

Результат

Ритм релизов сдвинулся с примерно ежемесячного к еженедельному и там закрепился. Всех существующих клиентов мигрировали на новую платформу без окна даунтайма. Frontend-команда выросла с четырёх до двадцати пяти человек, распределённых по десяти странам. Две внутренние MVP-награды. Пять инженеров выросли в лидерские роли за время моей работы, один из них позже стал VP of Technology. Платформа, которую мы спроектировали, до сих пор держит этот бизнес.

Кейс 02

go2cloud — построение software-функции внутри компании, у которой её никогда не было (Ганновер, 2021–2023)

Контекст

go2cloud был немецкой компанией, которая бóльшую часть своей истории управляла дата-центрами для crypto mining. В конце 2021-го она купила французский VDI-стартап OmnyCloud и оказалась владельцем продукта, который пока не знала, как развивать дальше. Не было software engineering команды, не было процесса разработки и не было software-продуктовой культуры. Я был первым software engineering наймом после этой сделки.

Решение

За первый месяц я разобрался с приобретённой кодовой базой, онбордил сам себя в технологии и интегрировал VDI-продукт в существующую инфраструктуру дата-центров go2cloud. За следующие месяцы я нанял команду из семи человек во frontend, backend, DevOps и QA. Я переделал сетевую архитектуру под более низкие латентности в европейских регионах, выпустил прототип Cloud Gaming поверх VDI-стека и заменил стороннего вендора remote-desktop стриминга на WebRTC-протокол собственной разработки, что закрыло маржинальный риск, который компания несла с момента сделки.

Результат

Время provisioning кластера упало с недель примерно до двух дней. Первый enterprise-клиент подключился в течение шести месяцев после сделки. Платформа масштабировалась до десяти тысяч seats. Внутренняя идентичность компании сместилась — из инфраструктурного вендора с продуктовой проблемой в продуктовую компанию с инфраструктурой под ней.

Кейс 03

YoloPrice — Mobile SDK с gRPC server внутри приложения (Ницца, 2023–2024)

Контекст

YoloPrice строил AI-driven commerce продукт с конкретным ограничением по безопасности. Ключевые алгоритмы были запатентованы и не могли быть открыты для reverse engineering, но пользовательский опыт должен был оставаться плавным на iOS и Android, а SDK должен был быть достаточно компактным, чтобы B2B-интеграторы действительно его использовали.

Решение

Я сам написал Android MVP в первый же месяц — в значительной степени чтобы доказать, что продуктовая гипотеза вообще реализуема. Как только это подтвердилось, я спроектировал production SDK как Kotlin Multiplatform проект со встроенным gRPC server, работающим внутри самого мобильного приложения. Я реализовал шифрование на устройстве, обфускацию чувствительных путей в бинарнике и кастомный WebView для аутентификации на маркетплейсах, который оставлял все данные пользователя внутри приложения. Я нанял двух мобильных инженеров и вместе с DevOps-инженером разобрал узкое место в release pipeline.

Результат

Первая production-версия уехала через четыре месяца после концепта. Ритм релизов закрепился на еженедельном. Время deployment упало примерно в четыре раза после переработки pipeline. Архитектура SDK — backend-сервер, работающий внутри мобильного приложения — была по-настоящему нестандартной и выдержала production-нагрузку.

Кейс 04

Echo Analytics — редизайн платформы, урезание бюджета посреди проекта (Париж, 2024–2025)

Контекст

Echo Analytics был geospatial SaaS платформой. Её архитектура выросла в монолит, который больше не мог поддерживать продуктовый roadmap, и изначальный план состоял в том, чтобы заменить его полноценной микросервисной платформой. Посреди проекта компания существенно урезала инженерный бюджет. Старый дизайн стал нежизнеспособным.

Решение

Вместо того чтобы пропорционально ужать изначальный план, я предложил другую архитектуру целиком. Маленькие, сильно автоматизированные product-сервисы, которые команда из одного-двух инженеров могла довести от концепта до production за две-четыре недели. Я переделал ключевой модуль базы данных, обслуживающий больше ста миллионов записей, с лучшим partitioning, более агрессивным индексированием и Redis caching для горячих путей. Я разобрал DevOps-узкое место и перестроил процесс delivery под новый ресурсный профиль.

Результат

Инфраструктурные затраты упали примерно до трети от исходной оценки. Скорость delivery выросла втрое. Время deployment упало в четыре раза. Инженерная команда выросла с двух до семи человек. Архитектура, которая родилась из урезания бюджета, по нескольким параметрам оказалась лучше той, которую мы бы построили, если бы деньги остались.

Кейс 05

OneFactor — первый Kubernetes проект внутри pre-Kubernetes компании (Москва, 2018–2020)

Контекст

OneFactor был BigData и ML сервисной компанией, работающей в основном с телеком- и финансовыми клиентами. На тот момент это был pre-Kubernetes шоп, и компания искала первую команду, которая пилотно заведёт Kubernetes в организации. Новый продукт — SmartIndex, аналитическая платформа для out-of-home рекламы — был подходящим кандидатом.

Решение

Я собрал команду с нуля, доставил MVP за два месяца и спроектировал Kubernetes deployment-архитектуру с раздельными dev, UAT и production окружениями и blue-green deployments для production-релизов. Я написал CI/CD шаблоны, которые позже стали организационным стандартом. Сервисная архитектура, которую я спроектировал — stateless, горизонтально масштабируемая, с эффективным ресурсным профилем — держала тысячу запросов в секунду на двух небольших pods.

Результат

Все запланированные фичи были выпущены в двухлетнем scope проекта. Паттерны Kubernetes и CI/CD разошлись по остальной организации. Два члена команды перешли в лидерские роли во время проекта или вскоре после него.

Кейс 06

Sberbank — разморозка релизного цикла внутри регулируемого enterprise (Москва, 2020–2022)

Контекст

В департаменте SME B2B Banking Sberbank был внутренний продукт, который давал примерно тридцать процентов выручки департамента, и frontend-команда, которая несколько месяцев не выпускала релиз, потому что миграция фреймворка застряла. Продукт был критичным для бизнеса и не мог оставаться замороженным.

Решение

Я пришёл, разблокировал застрявший релиз в первые недели и получил в управление обе команды — frontend и backend, десять инженеров и двух лидов между ними. Я ввёл Scrum как настоящий ритм, а не как церемонию. Я провёл чистую миграцию Java 7 → Java 17 на backend и начал переход от монолита к микросервисам.

Результат

Ритм релизов стабилизировался примерно на одном релизе раз в один-полтора месяца. Следующий крупный апгрейд фреймворка, который раньше занимал больше шести месяцев, сделали за два. Команда стала референсной внутри департамента — другие команды приходили к нам смотреть, как устроен процесс. Мой backend lead в итоге стал моим преемником.

Это несколько ситуаций, а не резюме. Полная история — роли, даты и остальные шестнадцать лет — в LinkedIn.

Полная история в LinkedIn