Ivan DolgovTech Lead / Full-Stack Engineer

Проектирую и довожу до продакшена сложные веб-системы — от требований и архитектуры до эксплуатации.

Веб-системы · архитектура · облако · корпоративное ПО

Сейчас
Tech Lead — WMS нового поколенияFrameworx, Daiwa House Group
Опыт
5+ лет
Город
Токио, ЯпонияJST (UTC+9)
Языки
  • Родной
  • Свободный рабочий уровень (JLPT N1)
  • Свободный рабочий уровень
Статус
Рассматриваю отдельные проекты — консалтинг и работа по контракту: удалённо из Токио или с зарубежными командами.
Рис. 1Где я работаю в жизненном цикле системы и какие проекты это показывают.

  1. Требования

    Определить и зафиксировать вместе с клиентом, что система должна делать

    P04

  2. Архитектура

    Выбрать технический подход и сначала проверить рискованные места

    P01P02

  3. Реализация

    Собрать клиентские приложения, сервисы и инфраструктуру

    P02P03P04

  4. Релиз

    Код-ревью, инженерные стандарты и выпуск в продакшен

    P02P03

  5. Эксплуатация

    Держать систему живой: производительность, миграции, поддержка в продакшене

    P03P04

Избранные проекты

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

P01В работе

WMS нового поколения

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

Роль
Tech Lead
Орг.
Frameworx, Daiwa House Group
Период
2026/09–наст. вр. · 2 мес.
Открыть справку

  1. A1Приложение

    • Фронтенд
    • Бэкенд

  2. A2Платформа

    • Облако
    • Безопасность

  3. A3Интеграция

    • Интеграция WMS/WCS

  4. A4Технологическое управление

    • Выбор технологий
    • Архитектурные стандарты
    • Инженерные гайдлайны
    • Архитектурные решения
    • Технические PoC
Области технической ответственности. Это карта охвата работ, а не архитектура системы: архитектура не раскрывается.

P02Завершён

Игровая платформа AI-чатов

Разработка 0→1 игровой B2C-платформы AI-чатов; я вёл её как Project Lead и full-stack инженер в кросс-функциональной команде из 20 человек.

Роль
Project Lead / Full-Stack Engineer
Орг.
Ikigai Co., Ltd.
Период
2025/07–2026/05 · 11 мес.
Команда
Кросс-функциональная команда из 20 человек
Читать кейс

  1. L1Клиент

    • React
    • TypeScript
    • Vite
    • TanStack

  2. L2Идентификация · отдельный домен

    • Keycloak

  3. L3API и вычисления

    • API Gateway
    • Lambda
    • Go

  4. L4Данные · общие

    • PostgreSQL

  5. L5Инфраструктура как код

    • Terraform
Путь запроса сверху вниз. Вход в систему идёт через сервер Keycloak на отдельном домене — он задумывался как общая точка входа для планировавшегося семейства приложений. Упрощённая реконструкция, а не продакшен-схема архитектуры.

P03Завершён

SaaS для упаковочной отрасли

Full-stack работа над веб- и мобильным SaaS в продакшене для упаковочной отрасли, где растущий объём данных ухудшил отзывчивость для всех клиентов.

Роль
Full-Stack Engineer
Орг.
Nagashima Konpo Co., Ltd.
Период
2024/12–2025/12 · 1 г. 1 мес.
Команда
Около 10 человек
Читать кейс

  1. L1Клиенты

    • React
    • Next.js
    • React Native
    • Expo

  2. L2API · GraphQL

    • AWS AppSync

  3. L3Тяжёлая обработка

    • Lambda

  4. L4Данные и хранилище

    • DynamoDB
    • S3

  5. L5Платформа · на каждый репозиторий

    • AWS Amplify
Веб- и мобильный клиент поверх одного общего бэкенда в AWS. Реконструкция по моему собственному описанию, а не продакшен-схема архитектуры.

P04Завершён

Клиентские проекты

Пять клиентских проектов в пяти отраслях: от корпоративного сайта за два месяца, который я вёл от начала до конца, до страховой системы с командой примерно в сорок человек — веб-разработка, CRM и корпоративный бэкенд.

Роль
Software Engineer / Project Lead
Орг.
Flaretech Co., Ltd. (formerly Marvel)
Период
2023/03–2025/05 · 2 г. 3 мес.
Команда
От 5 до 40 человек, в зависимости от проекта
Открыть справку

  1. S1Требования

    • Переговоры с клиентом
    • Определение требований
    • Документация

  2. S2Разработка

    • React
    • Next.js
    • Java/Spring
    • PHP/Laravel

  3. S3Развёртывание

    • Развёртывание в AWS

  4. S4Эксплуатация

    • Поддержка в продакшене
    • SEO и улучшения в эксплуатации
Этапы, которые я закрывал в этих проектах. Какие именно — зависело от проекта: в небольших все четыре, в самом крупном только два средних.

Все проектыПолная хронология

Компетенции и подтверждения

Каждая отметка указывает на проект, где эта зона ответственности документирована. Отсутствие отметки не означает неумения — только то, что здесь это не показано.

КомпетенцияP01P02P03P04
Требования и работа с клиентомОпределить и задокументировать вместе с клиентом, что система должна делать
Архитектура и выбор технологийТехническое планирование и технологические решения
Руководство проектомПланирование и координация команд разработки
Фронтенд-разработкаВеб- и мобильные клиентские приложения
Бэкенд и APIСерверные сервисы и API
Облачная инфраструктураИнфраструктура и развёртывание в AWS
Аутентификация и безопасностьАутентификация, авторизация и безопасность как часть архитектуры
Системная интеграцияПланирование интеграции WMS/WCS
Стандарты и код-ревьюИнженерные гайдлайны, архитектурные стандарты и код-ревью
Релизы и поддержка продакшенаДовести изменения до продакшена и поддерживать их там

Принципы работы

  1. P-01

    Фиксируйте решения там, где команда их найдёт

    Архитектурные решения, гайдлайны и стандарты записаны, поэтому выбор, сделанный один раз, не приходится заново отстаивать на каждом ревью.

    На практике: Стандартизация архитектуры, инженерные гайдлайны и архитектурные решения — WMS нового поколения.

  2. P-02

    Проверяйте рискованный выбор небольшим прототипом

    Когда технология или интеграция под вопросом, ограниченный по объёму PoC обходится дешевле, чем обнаружить ограничение уже в продакшене.

    На практике: Технические PoC — WMS нового поколения и SaaS для упаковочной отрасли.

  3. P-03

    Код-ревью распространяет стандарты, а не только ловит дефекты

    Именно на ревью договорённости становятся общей практикой команды — включая внешних разработчиков.

    На практике: Код-ревью и стандарты — платформа AI-чат-игры; ревью и поддержка внешних разработчиков — SaaS для упаковочной отрасли.

  4. P-04

    Требования — это инженерная работа

    Выяснить, что нужно клиенту или оператору, — часть проектирования системы, а не этап, который кто-то закрывает до него.

    На практике: Определение требований и работа с клиентом — клиентские проекты Flaretech и фриланс.