Станкин Петр

Технические

Go · gRPC · Protobuf · Node.js · TypeScript · NestJS · Kafka · RabbitMQ · MongoDB · PostgreSQL · ClickHouse · Redis · Docker · GitLab CI · Grafana · Kibana · Clean Architecture (Robert Martin) · DDD

Управленческие

people management · найм · one-to-one · ИПР · Scrum · квартальное планирование · управление бэклогом · event storming · организация дежурств · внедрение ИИ-агентов в разработку

Полная версия

Руководство командой курьерского направления: найм курьеров, программа лояльности и рейтинг курьеров, регуляторная отчетность, распил курьерского монолита. Команда одна из первых в компании переходит с Node.js на Go, все новые сервисы пишем на Go по DDD и Clean Architecture. С нуля запустили 7 сервисов.

Команда team-lead, 3 Backend developers, 1 Frontend developer, 1 Android developer, 1 QA

Управление командой

• Пересобрал backend-команду и перевел ее на Go. Нанял сильного Go-разработчика, переучил backend-разработчика с Node.js на Go, вырастил системного аналитика в backend-разработчика на Node.js, после чего она без проблем перешла на Go. Сейчас на Go пишет вся backend-команда.
• Делегирование технических решений. Передал разработчикам ответственность за код-ревью и архитектуру, команда принимает технические решения самостоятельно. Сам сосредоточен на people management и выстраивании процессов.
• Процессы. Перевел команду с канбана на двухнедельные спринты с грумингом и оценкой задач до начала спринта. Вместе с продуктовой командой ведем квартальное планирование с учетом капасити, крупные проекты сопровождаются диаграммами Ганта по этапам (проектирование, разработка, тестирование, адаптация). Заново выстроил процесс дежурств под новые сервисы.
• Работа с требованиями. Внедрил DDD-подход к проработке задач с продуктовой командой: event storming и моделирование домена, сценарии в формате Given/When/Then. Встречи записываются и транскрибируются, артефакты моделирования обрабатываются с помощью ИИ. Time-to-market от идеи до запуска сократился со 120-150 до 60 дней, команда стабильно в него укладывается.
• Тестирование. Практически отказались от ручного регресса: благодаря Clean Architecture сократился скоуп регрессионного тестирования, проверки переведены на автотесты на внутреннем фреймворке компании. Регресс сократился с 2 дней до 15-20 минут прогона pipeline в MR. QA валидирует сценарии на этапе моделирования и проверяет автотесты в MR, сами тесты пишут QA или разработчики с помощью ИИ-агента.
• AI-агенты в разработке. Внедрил работу с ИИ-агентами во всей команде. По моей постановке senior-разработчик сделал внутренний фреймворк: репозиторий с Docker Compose, доступом к корпоративным LLM, open source агентом Letta и подключенными MCP к таск-трекеру, Grafana, Kibana и GitLab. Подключение нового сотрудника занимает 1 день: он разворачивает окружение, получает доступы, и дальше агент сам ищет нужное в Confluence и по инфраструктуре. Опытным сотрудникам почти не приходится отвлекаться на онбординг. Весь код пишется через агента, первое ревью делает агент, финальное делает человек.
• Contract first. Перешли на подход, при котором сначала описываются и согласуются контракты (proto для gRPC, OpenAPI для REST), а уже потом стартует разработка. По готовому контракту backend, frontend, Android и смежные команды начинают работу параллельно и не ждут друг друга.
• Инженерные практики. Одними из первых в компании внедрили фиче-флаги и обкатали их на переводе трафика при распиле монолита. Вынесли бизнес-логику из Android-приложения на бэкенд: приложение отрисовывает то, что пришло с сервера, вплоть до текстов и цветов элементов. Это первые шаги к backend-driven UI. Ошибки исправляются на бэкенде без релиза через стор, а нагрузка на единственного Android-разработчика снижается. Go-сервисы собраны на общих библиотеках компании, unit-тесты с контролем покрытия запускаются в CI, дашборды Grafana хранятся в репозитории вместе с кодом, на MR настроены обязательные апрувы и проверки веток.
• Развитие людей. Ввел в команде индивидуальные планы развития (в компании такой практики нет), продолжаю регулярные one-to-one. Веду звездную карту команды и распределяю задачи по уровню: senior-разработчик ведет архитектуру кода и фреймворк для ИИ-агентов с памятью, уверенного middle+ развиваю до тимлида, сейчас он фактически мой заместитель.

Реализованные проекты

• Программа лояльности и рейтинг курьеров (Go, gRPC). Самый крупный сервис направления: в программе 50 тысяч курьеров, по каждому сервис обрабатывает до 100 событий в день. Вынесли рейтинг из курьерского монолита в отдельный сервис и построили на нем программу лояльности. Программа раскатана на всех курьеров и дает положительный эффект на удержание.
  • Лояльность: курьеры получают бенефиты (промокоды, сертификаты, скидки партнеров) в зависимости от уровня рейтинга и города. Промокоды, сертификаты и списки курьеров загружаются потоковым импортом из CSV, о новых бенефитах курьеры получают пуш-уведомления.
  • Рейтинг 2.0 (готовится к раскатке): новая модель на DDD-агрегатах. Учитывает доставленные заказы, слотовые смены и биржевые сессии, внешние инциденты из Kafka, смены без нарушений. Рейтинг активируется после первой доставки и набора порога заказов, есть пересчет дня задним числом.
  • Управление из CRM: конфигурации рейтинга, уровни, онбординг и справка настраиваются в админке, новая конфигурация публикуется автоматически по расписанию.
  • Раскатка: программа лояльности включалась поэтапно по полигонам с A/B-тестированием и динамическими фиче-флагами через Kafka. Рейтинги из монолита перенесены отдельным инструментом миграции.
  • Надежность: идемпотентная обработка событий, пул воркеров для пересчета, сервисная JWT-авторизация, поддержка всех часовых поясов России.
• Распил курьерского монолита (Go). Монолиту много лет, распил ведется силами моей команды. Вынесено уже 50% логики, она работает на проде в Go-сервисах на новой архитектуре, самая сложная часть работы позади. Новая логика строится рядом с работающей, трафик переводится на новые сервисы процентными фиче-флагами с возможностью отката. Плавное переключение проверено на проде, ничего не ломается. Первым вынесен контекст договоров-оферт курьеров: подписание, правила доступности оферты по компаниям, события нерезидентов. Данные из MongoDB и файлы из объектного хранилища переносятся отдельными командами миграции с режимом dry-run и runbook'ом.
• BFF для мобильного приложения курьера и админ-панели (Go). Раньше трафик от клиентов шел через старые прокси-сервисы, отдельных BFF в направлении не было. Моя команда первой сделала оба BFF, дальше их будут использовать все команды направления доставки. Клиенты изолированы от внутренних gRPC-контрактов, авторизация в одной точке.
  • BFF приложения курьера проверяет токен приложения, определяет курьера и ходит во внутренние сервисы по gRPC. Отдает в приложение рейтинг, бенефиты и материалы онбординга с кэшированием.
  • BFF админ-панели переводит запросы CRM в gRPC-вызовы и проверяет права пользователя на каждый метод.
• Саморегистрация курьеров (Vue 3). Новый для команды домен найма. Веб-приложение встраивается в мобильное приложение через WebView. Кандидат проходит многошаговую анкету (город, вакансия, личные данные, паспорт, выплаты и самозанятость, фото документов), входит по SMS и видит статус своей анкеты. Есть карта вакансий с кластеризацией точек, ее раскатили после A/B-теста. Кандидат регистрируется без участия рекрутера.
• Интеграция с внешней системой подбора персонала (NestJS, сервис достался в наследство). Провели рефакторинг, расширили контракт с внешней системой, добавили ретраи, перевели уведомления на email и маскирование телефонов в логах.
• Сервис опросов курьеров (NestJS, новая архитектура). Конструктор опросов: создание, публикация и завершение по расписанию, таргетинг на курьеров по загруженному списку, сбор ответов и выгрузка результатов в CSV. Все use cases покрыты unit-тестами.
• Сервис передачи данных о курьерах для регуляторной отчетности (NestJS). Собирает события заказов и геометки курьеров из Kafka, дополняет их данными из курьерских сервисов и отправляет в витрину для регулятора. Состояние доставки отслеживается машиной состояний, персональные данные хешируются.

Ключевое достижение Перевел команду на Go и сократил time-to-market со 120-150 до 60 дней.

Стек Go · gRPC · Protobuf (buf) · OpenAPI (ogen) · Node.js · TypeScript · NestJS · Kafka · MongoDB · Redis · MinIO · Vue 3 · Grafana · VictoriaMetrics · Kibana · Docker · GitLab CI · Letta · MCP

Полная версия

Руководство командой сервиса интеграции со сторонними службами доставки (3PL). Сервис передает заказы внешним партнерам, когда собственных курьеров не хватает, и обрабатывает более 300 тысяч заказов в день. Подробное описание сервиса приведено в предыдущей должности (Backend Developer).

Играющий тимлид: совмещал управление командой с разработкой ключевых фич сервиса.

Команда team-lead, 1 Backend developer, 1 QA, 1 Системный аналитик, 1 Product manager

Управление командой

• Декомпозиция продуктовых задач и постановка их команде, код-ревью, написание технических требований, контроль архитектуры сервиса.
• Квартальное планирование проектов, ведение бэклога, планирование отпусков команды.
• Найм в команду. Закрыл вакансию backend-разработчика, но нанятый сотрудник не справлялся с задачами, и я расстался с ним в течение испытательного срока. После этого нанял на его место сильного разработчика.
• Внедрил регулярные one-to-one раз в две недели со всеми участниками команды. До этого такой практики в команде не было.
• Организовал процесс дежурств по сервису.
• Работа со смежными командами в рамках реализованных проектов.
• Передача сервиса другой команде: подготовил документацию и базу знаний, провел передачу знаний.

Реализованные проекты

• Трекинг движения курьеров партнеров.
• Отсечка курьеров по прогнозу ML-модели.
• Работа с техдолгом и надежностью: рефакторинг архитектуры на слои, внедрение unit-тестов, единый стандарт алертинга, оптимизация работы с MongoDB.

Ключевое достижение Удержал поддержку и развитие сервиса на 300+ тысяч заказов в день в условиях неполной команды и передал его другой команде с документацией и базой знаний.

Полная версия

Разработка и поддержка сервиса интеграции со сторонними службами доставки (3PL). Когда собственных курьеров не хватает, заказ передается внешнему партнеру, и сервис ведет его от начала до конца: получает заказ из другого сервиса, выбирает службу доставки, создает у нее заявку, отслеживает статус и обрабатывает отмены.

Через сервис проходило более 300 тысяч заказов в день. Сервис работал с пятью службами доставки, у каждой свой API и свой способ обмена данными. Часть партнеров присылала статусы заявок через вебхуки, остальных сервис опрашивал сам: по крону из базы поднимались все активные заказы (новые, на распределении, в пути), и через RabbitMQ задачи распределялись между подами, так обработка масштабировалась горизонтально. Обмен событиями с другими сервисами компании шел через Kafka.

Основная сложность была в нестабильности внешних интеграций. Партнер мог отвалиться, отвечать по таймауту или с ошибками, и тогда было непонятно, в каком статусе находится заказ: партнер уже назначен, а дальше от него ничего не приходит. Такие ситуации нужно было корректно обрабатывать, чтобы заказ не зависал и доезжал до клиента.

Команда team-lead, 2 Backend developers, 1 QA, 1 Системный аналитик, 1 Product manager

Задачи

• Стабилизация сервиса. На момент моего прихода сервис регулярно падал на проде. Провел рефакторинг и переработал архитектуру, после чего на сервисе стало возможно вести продуктовую разработку. Запросы к партнерам переведены на параллельную обработку, для запросов актуализации заявок сделан батчинг и дедупликация. Все внешние вызовы покрыты трассировкой, добавлены метрики времени поиска курьера и платных отмен, алерты на ошибки создания заявок, глобальная обработка исключений. Обновил версию Node.js и общие библиотеки для работы с очередями, метриками и Redis.
• Рейтинг партнеров. Раньше очередность вызова служб доставки была захардкожена в коде. Теперь сервис собирает события по заявкам (найден курьер, отмена, опоздание) и по крону пересчитывает рейтинг каждого партнера в разрезе полигона. Веса событий и глубина рейтинга настраиваются, есть blacklist и API для управления. Перед созданием заявки сервис запрашивает у партнеров стоимость и время доставки. Под поток событий подобраны индексы и оптимизированы запросы к MongoDB. Выяснилось, что на разных полигонах партнеры работают по-разному, поэтому заказ теперь уходит тому, кто лучше справляется на конкретном полигоне.
• Универсальный API для подключения партнеров. Раньше под каждую службу доставки писалась отдельная интеграция. Реализован единый контракт, через который подключается новый партнер, с поддержкой рейтинга и маскирования персональных данных. Через него уже подключена новая служба доставки.

Ключевое достижение Стабилизировал сервис на 300+ тысяч заказов в день, который регулярно падал на проде, и запустил на нем рейтинг партнеров.

Стек Node.js · TypeScript · NestJS · MongoDB · Kafka · RabbitMQ · Redis · APM · Grafana · Graphite · Kibana · Moira

Middle Backend Developer · АО «Системы управления Северо-Запад»

Март 2023 - Апрель 2024

Разработка ядра BI-системы. На основе ядра проектные команды собирают дашборды (таблицы, графики) под конкретных заказчиков. Данные загружаются через ETL-процесс в ClickHouse.

• Переписал логику выдачи данных: обработка перенесена с фронтенда на бэкенд, большие таблицы стали отображаться заметно быстрее.
• Генерация SQL-запросов на основе JSON-конфигов дашбордов, без ORM.
• Переработал типизацию и валидацию конфигов, чтобы разработчики дашбордов сразу видели, где ошибка.
• Сервис логирования с хранением в ClickHouse, новая авторизация на JWT, unit-тесты, GitLab CI.

Стек NestJS · PostgreSQL · ClickHouse · Jest · Zod · Docker · GitLab

Backend Node.js developer · Индивидуальное предпринимательство / фриланс

Январь 2021 - Март 2023

Backend для коммерческих проектов на микросервисной архитектуре: интернет-магазин импортных товаров, NFT-маркетплейс, платформа поиска недвижимости с Telegram-ботами. Проектирование БД, REST API, интеграции с платежными системами, CRM и внешними API, упаковка в Docker.

Стек NestJS · Express.js · TypeScript · MySQL · MongoDB · Docker · Nginx

Генеральный директор · ООО «ПТК 47»

Ноябрь 2019 - Январь 2021

Руководство компанией: ценовая политика, переговоры с ключевыми клиентами, обучение менеджеров.

Менеджер по продажам · ООО «ОБИ ФЦ»

Август 2016 - Февраль 2019

• 2026Управление командой разработки, Яндекс Практикум (март 2026 - сентябрь 2026)
• 2025HighLoad++ 2025, участник
• 2025TeamLead Conf 2025, участник
• 2022Backend Node.js-разработчик, Нетология
• 2021Fullstack-разработчик на Python, Нетология