🧪 Контрактное тестирование:
• Пример использования Pact: позволяет проверять, что контракт между сервисами не нарушен.
• Работает как для consumer- (клиентских) тестов, так и для provider- (серверных).

⸻

📦 Инфраструктура:
• K8s, Terraform, AWS — всё это работает, но важно не перегружать проект.
• В начале часто достаточно docker-compose и одного сервера.

⸻

📍 Ключевые советы:
1. Начинай с простого монолита.
2. Понимай бизнес-домен.
3. Пиши код, как будто он будет расти.
4. Не делай premature optimization.
5. Строй архитектуру, основываясь на реальных ограничениях.
Записи:
https://youtu.be/BDsXinRRtPg
https://rutube.ru/video/265d0b9c71d37264f2f34e8cb663cd5a/

Всем привет!
Вчера провели встречу посвященая системному дизайну — зачем он нужен, как проводить интервью по нему, какие подходы считаются хорошими, а какие — не очень.


🔍 Основные тезисы:
• Системный дизайн — не про создание YouTube с нуля, а про умение подходить к архитектуре решений адекватно: понимать, зачем ты проектируешь, какие есть ограничения, сколько пользователей и как это будет масштабироваться.
• Неправильный подход — сразу делать «миллиард пользователей и микросервисы».
• Правильный подход — начать с MVP, понимать, что будет меняться, где узкие места, и проектировать с возможностью постепенного роста.

⸻

🧪 Пример с телеграм-ботом:
• Сделан за 2 часа, с SQLite под капотом, без вебхуков (используется long polling).
• Простая реализация, которая работает, справляется со своей задачей. Когда нагрузка вырастет — заменят SQLite на PostgreSQL.
• Главный месседж: если знаешь, где слабые места, это окей — мониторь и улучшай по мере необходимости.

⸻

📈 Скейлинг и автоскейлинг:
• Что такое горизонтальное масштабирование (новые инстансы).
• Как определить, когда надо скейлиться — метрики (CPU, кол-во соединений).
• Примеры настройки автоскейлинга на AWS.

⸻

💬 Обсуждение API и архитектуры:
• Клиент-серверная модель: браузер — клиент, сервер — отвечает.
• API — это контракт взаимодействия, желательно публичный и документированный.
• SQLite хорош для простых приложений, но не для больших нагрузок.

⸻

🧵 Асинхронность, очереди, шины:
• Асинхронная обработка запроса: клиент отправил — сервер положил задачу в очередь.
• Уведомление о завершении задачи — через почту, пуш, или API polling.
• Шины сообщений (RabbitMQ, Kafka) — удобны для микросервисов и снижения связанности.
• Kafka используется для логирования и анализа, Rabbit — для событий и коммуникаций между сервисами.

⸻

🔄 Eventual Consistency и проблемы шины:
• Данные не синхронны — это нормально.
• Нужны механизмы переигрывания (реплей), контроля доставки, обработки неудачных сообщений.
• Сага — шаблон управления распределёнными транзакциями: как откатить, если шаг провалился.

⸻

🧱 Монолит vs микросервисы:
• Не надо уходить в микросервисы просто потому что модно.
• Сначала вырастите монолит, поймите, где границы, потом уже выносите в сервисы.
• Закон Конвея: архитектура повторяет оргструктуру.
• Проблема распределённого монолита — усложнение без выигрыша в независимости.
🧭 Domain-Driven Design (DDD):
• DDD — это про мышление бизнес-доменами, а не про базы данных.
• Разделение логики по бизнес-смыслу: в одной системе может быть понятие «пользователь» в разных контекстах (например, в биллинге и в доступах).
• Bounded Context — ключевое понятие: внутри него — свои модели, вне — взаимодействие через контракты (например, API).

“Нельзя взять модель одного сервиса и напрямую использовать в другом — лучше через API.”

⸻

🧩 Модульность и выделение сервисов:
• Пример: систему делят на сервис заказов, пользователей, биллинга и т.д.
• Между сервисами — минимальные связи, общение через API/шину событий.
• Вынос сервисов логичен, когда они эволюционно становятся самостоятельными.
• Не нужно «микросервисить» с самого начала — это усложнит всё.

⸻

🛑 Антипаттерны распределённых систем:
• Распределённый монолит: вроде бы микросервисы, но при этом жёсткие связи между сервисами, деплой одного влияет на другой.
• Отсутствие автономии — главный враг микросервисов.
• Ошибка начинающих: каждый микросервис имеет свою базу, но по сути — всё равно связан жёстко через логику.

⸻

💥 Разграничение ответственности:
• Надо разделять: кто отвечает за сохранение данных, кто за их обработку, кто за их показ.
• Важно, чтобы команды были привязаны к сервисам, а не к слоям (как фронтенд, бекенд, база).

⸻

🎨 Микрофронтенды:
• Очень больная тема. Теоретически позволяют разным командам независимо пилить фронт.
• На практике — огромная сложность:
• Конфликты версий библиотек
• Разные подходы к сборке, роутингу
• Долгие загрузки и проблемы UX

“Проще использовать условно iframe, чем пытаться сшить всё красиво.”

⸻

Товарищи, а если вы не регистрировались и не планировали идти, можете поделиться мнением, почему в опросе ниже?

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

🧠 Зачем вообще System Design?

Начнём с того, что мы вообще понимаем под этим словом, и почему это нужно не только тем, кто готовится к интервью в Google.
Спокойный заход, без академической боли — чтобы стало понятно, зачем это всё нам с вами в реальной жизни.

Когда: 21 апреля, 20.00 по Москве

Бесплатно, но надо зарегистрироваться!

Полный анонс и регистрация в боте!
Зарегистрироваться!

👆👆👆👆👆👆👆

Всем доброго утра понедельника. И начинаем неделю с анонса эфира с Максом Корейченко. Макс крутой разработчик и тим лид, мы с ним уже делали доклад "Как описать задачу, чтобы разработчики не считали идиотом", а еще он честно рассказывает про разработку у себя на канале.
🧠 Зачем вообще System Design?

Начнём с того, что мы вообще понимаем под этим словом, и почему это нужно не только тем, кто готовится к интервью в Google.
Спокойный заход, без академической боли — чтобы стало понятно, зачем это всё нам с вами в реальной жизни.

⸻

🧩 Что вообще бывает в веб-разработке

Пробежимся по базовым сущностям, чтобы у всех были одинаковые карты мира:
• Клиенты, серверы, API, БД, кеш
• Синхрон против асинхрона: когда ждать, а когда пихать в очередь
• Что такое latency и почему 200 ОК — не всегда ок

💡 Дисклеймер: всё, что обсуждаем — про веб, не лезем в десктоп или embedded.

⸻

⚙️ Как мы держим нагрузку (и не умираем)

Поговорим про:
• Балансировку (L4 vs L7)
• Масштабирование (вертикальное и горизонтальное)
• Кеши, реплики, шардирование
• Очереди и фоновые задачи
• Что обычно взрывается, когда трафика становится слишком много

⸻

🔧 Как мы это всё говно разрабатываем

Про архитектурные подходы:
• Монолит — не всегда зло
• Микросервисы — не всегда спасение
• Монорепа vs Полирепа (и почему вечный холивар)
• Независимые релизы и shared-nothing-ад

И про процесс:
• Feature branches, trunk-based, CI/CD
• GitOps и автотесты
• “Сломали прод — и что дальше?”

⸻

🔍 Как требования влияют на архитектуру
• Функциональные: что система должна уметь
• Нефункциональные: SLA, безопасность, масштаб, отказоустойчивость

Пример:
Если у тебя 3 пользователя, и 2 из них — мама и папа,
ты не прикручиваешь Kafka и Istio.
А если у тебя 3 миллиона пользователей — SQLite не поможет 😅

21 апреля, 20.00 по Москве
Регистрация вот тут в боте

🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Это будет пятница. Доклады по 10 минут, на которых —
каждый спикер отдаст в руки инструмент: фреймворк, методику или конкретный шаблон, которые можно применить уже в понедельник.

Поговорим о системном мышлении через архитектурные ката, превращении документации в то, чем реально хочется пользоваться, генеративном ИИ как новом мультитуле аналитика, и JBTD как подходе, который помогает фокусироваться на задачах, а не хотелках.

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

Обязательно приходите — тут регистрация.

Всем привет! В следующую пятницу ребята из ВИ.Тех (Все инструменты) проводят оффлайновые посиделки. Собрали топовых спикеров с экспериментальным форматом докладов в 10 минут, чтобы все было коротко и по делу. Приглашаю вас поучаствовать.

Год назад рассказывал про новый, но уже довольно любопытный курса по API. За год его автор, тимлид команды аналитиков Глеб Учитель, проделал огромную работу: на курс записалось более 1300 человек. И сейчас его знают многие.

Если вы тоже хотите расти по хардам в IT —
добро пожаловать!

🔹🔹 🔹🔹
Начните с бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите и знакомьтесь.
👇
@studyit_help_bot

Скидка на курс от канала —
1 000₽ по промокоду SPHERI до конца апреля

Для тех, кто тут аналитик: делимся ссылками на запись вебинара Из аналитика в продакта #004 c Натальей Семеновой и Иннокентием Бодровым!

Смотрите на удобной платформе и обязательно подписывайтесь - так вы будете получать оповещения о новых видео автоматически при их публикации:

YouTube | RuTube | VK

И как обещали - рекомендации от Иннокентия Бодрова по ресурсам для молодых продактов:

На кого подписаться:
📁 Папка с каналами продактов

Где поучиться:
🧿 Продукт. и точка (курс Ани Подображных)
🧿 Advanced JTBD (тренинг Вани Замесина)
🧿 Heroes (курс Ильи Красинского)

Что почитать:
📘 Р. Фитцпатрик. Спроси маму
📘 М. Каган. Вдохновленные
📘 Э. Голдрадт. Цель
📘 Э. Голдрадт. Цель 2
📘 M. Cagan Empowered

PS: а мы уже открыли запись на следующий вебинар с Костей Семеновым! Анонс в канале будет через неделю, но тем, кто зарегистрируйся до анонса - дарим 50% скидку на мастер-класс для спикеров

Если пропустили наш с Наташей эфир во вторник - вот записи на разных платформах!

IKEA как центр культурного заземления

Сегодня хочется поговорить не совсем про технологии и не совсем про миграцию.
Хотя, если честно, это именно про миграцию, только немного с другого угла.

Когда ты переезжаешь в другую страну — есть объективные сложности: язык, документы, работа, быт. Но есть и неочевидные, которые никто тебе в чек-лист не запишет.

Это:
🔹 незнакомые запахи,
🔹 странные растения,
🔹 другая архитектура,
🔹 другие цвета, материалы, ритмы, бытовая логика.

И если в России мозг эти вещи даже не замечал, то в новой среде он постоянно что-то обрабатывает.
Процессит, тревожится, сравнивает, подсказывает: “Ой, что-то не то”.

📍 И вот на этом фоне мы с удивлением заметили, что IKEA стала нашей точкой заземления.

Ты заходишь туда — и всё привычно:
🛋️ те же стеллажи,
🍽️ те же кухонные зоны,
🧴 те же запахи свечей и разделочных досок,
👨‍👩‍👧 те же семьи, катающие тележки по привычному маршруту.

Мозгу не надо напрягаться. Он выдыхает: “О, знакомое, безопасное, моё.”

И что интересно — мы далеко не одни такие.
В IKEA в Португалии много русскоязычных, и я почти уверен, что для многих она стала островком предсказуемости в новой реальности.

💬 И вот тут становится особенно ясно:
IKEA — это не просто мебель. Это бренд, который выравнивает культурный ландшафт, где бы ты ни оказался.
Такой вот маленький мостик между “где я был” и “где я теперь”.

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

🔥🔥🔥 НОВЫЙ ВЕБИНАР
ИЗ АНАЛИТИКА В ПРОДАКТА #004!

Cпециальный гость нашего следующего выпуска: Иннокентий Бодров - основатель Аналитической мастерской и продакт в западной финтех-компании

В новом выпуске раскрываем вопросы с нового ракурса:

💡 Какие еще карьерные треки должен попробовать аналитик, чтоб остановить свой выбор на управлении продуктом?

💡 Продакт внутренних продуктов - какие скиллы выходят на первый план, а какие остаются невостребованными?

💡 А западный продакт-менеджмент - правильный? похож ли он на то, как описывают в учебниках? Или только у нас все не так, как надо?

💡 Совмещение роли аналитика и продакта - естественный переход или кринж, внутренний конфликт, биполярка и прочие радости?


🔥 02 апреля (среда) 18:00 🔥
РЕГИСТРАЦИЯ ➡️

_________________
Приходи сам и пересылай пост коллегам - вдруг им это важно? Приноси с собой свои вопросы и сомнения - на все ответим. Записи прошлых вебинаров ищи тут

Smart Speaker / Smart Effect
#smarteffect #smart_speaker

А я напомню, что завтра мы с Наташей будем общаться про путь из аналитика в продукты. Приходите позадавать вопросы

Разогрелся — теперь ваша очередь!

Буквально во вторник заходил в гости к Андрею Буракову и школе Nextway, где рассказывал про DDD и немного разогревал публику перед их конференцией.

А уже завтра — та самая конференция, на которую, к сожалению, я не попадаю: ни как спикер, ни как участник.
Но вот вам — настоятельно рекомендую её посетить, особенно если вы работаете с проектированием информационных систем.

🔹 Будет куча полезных докладов,
🔹 Крутые воркшопы,
🔹 И эксперты, которые реально понимают, о чём говорят.

Так что если вы в теме, не проходите мимо — это точно стоит вашего времени.
Мой рекомендацион. Увидимся в эфире где-нибудь в следующий раз! 😉

🔔 Слышите звон, там, недалеко? Да, это он - last call

Завтра встречаемся на NextConf, где будем говорить о проектировании систем от бизнес-потребностей до технического дизайна. Наши спикеры настолько заряжены, что пытаются подключиться к выступлению уже сегодня! 😁
Что вас ждет:

Бизнес и архитектура

 • Воркшоп по Event Storming — Екатерина Пантелей

 • DDD и ES для декомпозиции системы на сервисы - Кирилл Ветчинкин

Технический дизайн

 • Считаем нагрузку и подстилаем соломку — Никта Ерилин

 • Проектируем распределенные системы с фокусом на хранение данных — воркшоп Анны Вичуговой и Зои Степчевой

Интеграция

 • Data Integration: загружаем данные из одной системы в другую — Татьяна Бунто

 • Паттерны отказоустойчивости для интеграции — Илья Голушко

Управление архитектурой

 • С4 и инструменты Structurizr для документирования архитектуры — Евгений Фатевв

 • Переведем архитектуру в as code и проверим качество тестами — Руслан Сафин

И это еще не все!
Смотрите полную программу и регистрируйтесь на сайте конференции

📅 29 марта, суббота

Почему на Западе платят за мышление, а у нас — за умение писать код

Сегодня случайно наткнулся в LinkedIn на интересный пост от моего бывшего коллеги, Лёши Сучилина. Лёша сравнил подходы к обучению аналитиков (в первую очередь — дата-аналитиков) в Яндексе и в Google, и картина получилась… показательная.

📊 Что в Яндексе?
Фокус почти целиком на харды: Python, SQL, API, визуализация, библиотеки и прочее по списку.

🧠 Что в Google?
Около трети программы — на харды, а всё остальное — на критическое мышление, problem solving, системность мышления и вообще — как думать и решать задачи, а не просто применять инструменты.

И вот в этот момент у меня картина мира стала чуть яснее.
Лёша правильно подметил:
👉 На Западе нанимают людей, которые решают задачи и приносят бизнесу результат.
👉 В России — часто ищут тех, кто умеет “просто делать задачи”, не задавая лишних вопросов.

👔 В вертикальных компаниях, где есть “большой белый вождь”, не нужен тот, кто думает. Потому что думать уже за тебя решили.
Надо просто взять, и реализовать.

Именно поэтому:
🔹 У нас в приоритете — харды: «построй нам REST API, настрой Kafka».
🔹 А вопрос “зачем?” — часто считается лишним.

💬 А ведь это то, о чём я регулярно говорю:
👉 В ИТ платят не за код. Платят за решение бизнес-проблем.
За мышление, за влияние на результат, за способность понять, что нужно, а не просто делать “как сказали”.

Так что, если вы хотите расти — прокачивайте не только харды, но и голову. Потому что в будущем останутся те, кто умеет думать. А не только писать на SQL.

Весна, ураганы и новое вдохновение

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

📍 Португалия сейчас ощущается как Питер 2.0 — последние полтора месяца идут сплошные дожди. Холодно, мокро, и погода меняется ещё быстрее, чем в Питере.
5 минут солнце, 5 минут ливень, потом снова солнце, а потом затяжная морось на несколько часов.
Очень питерское настроение, но на фоне южного ландшафта выглядит… неожиданно.

🌪️ На прошлой неделе прошёл ураган Мартинио — говорят, самый сильный за последние 10 лет.
Поваленные деревья, пострадавшие машины и, к сожалению, люди. Было действительно жёстко.

Но вот сегодня — первый по-настоящему солнечный день. И хочется сказать: Португалию как будто отмыли из Керхера.
Цвета стали яркими до нереальности. Всё зазеленело, зацвело, наступила весна. Настоящая, тёплая, вдохновляющая.

💭 И вместе с этим в голову начинают приходить новые мысли. Хочется делать, хочется планировать.
Уходит это зимнее серое настроение, и появляется ощущение обновления.

🌸 Кстати, совсем недавно был день весеннего равноденствия — день стал длиннее ночи. И это прям чувствуется.
Сезон обновлений, свежего воздуха и новых свершений открыт.

Даже несмотря на то, что рука ещё не даёт писать в полную силу — я настроен делать много нового и интересного.
И вам того же желаю: пусть весна принесёт вам энергию, идеи и классные перемены.

Не стесняйтесь жить и творить! 😊

Из аналитиков в продукты: как, зачем и стоит ли вообще?

Итак, ну что ж — вашу маму и тут, и там передают 😁
Как и говорил — возвращаюсь в публичное пространство. Рука всё ещё болит, поэтому пока больше говорю, чем пишу.

📅 2 апреля вместе с Наташей Семёновой будем говорить про путь из аналитиков в продукты.

Примерно год назад я выступал на Analyst Days с докладом «Почему из аналитиков получаются плохие продукты». Теперь будет немного другой ракурс:
🔹 Как меня самого унесло из аналитики в продакт-менеджмент,
🔹 Какие направления я рассматривал,
🔹 Почему не выбрал архитектуру или консалтинг как основной путь,
🔹 И почему сейчас я рад, что стал продуктом, несмотря на весь стресс, неопределённость и ответственность.

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

Наташа — отличный интервьюер, я — вроде тоже ничего как спикер, так что должно получиться живенько и по делу.

📌 Подключайтесь 2 апреля — будет интересно!

🔥🔥🔥 НОВЫЙ ВЕБИНАР
ИЗ АНАЛИТИКА В ПРОДАКТА #004!

Cпециальный гость нашего следующего выпуска: Иннокентий Бодров - основатель Аналитической мастерской и продакт в западной финтех-компании

В новом выпуске раскрываем вопросы с нового ракурса:

💡 Какие еще карьерные треки должен попробовать аналитик, чтоб остановить свой выбор на управлении продуктом?

💡 Продакт внутренних продуктов - какие скиллы выходят на первый план, а какие остаются невостребованными?

💡 А западный продакт-менеджмент - правильный? похож ли он на то, как описывают в учебниках? Или только у нас все не так, как надо?

💡 Совмещение роли аналитика и продакта - естественный переход или кринж, внутренний конфликт, биполярка и прочие радости?


🔥 02 апреля (среда) 18:00 🔥
РЕГИСТРАЦИЯ ➡️

_________________
Приходи сам и пересылай пост коллегам - вдруг им это важно? Приноси с собой свои вопросы и сомнения - на все ответим. Записи прошлых вебинаров ищи тут

Smart Speaker / Smart Effect
#smarteffect #smart_speaker

Возвращаюсь в инфопространство — начнём с DDD!

Итак, всем привет!

На этой неделе мне таки сделали операцию на руке, сейчас потихонечку восстанавливаюсь. Поэтому практически ничего не пишу — но это временно. Уже на следующей неделе планирую вернуться в актив.

🚀 Стартуем со вторника!
Во вторник иду в гости к Nextway и Андрею Буракову, где мы поговорим про DDD — Domain-Driven Design:
🔹 Что это не только про разработку,
🔹 Как аналитик может применять DDD в своей работе,
🔹 Почему DDD — это про коллаборацию, коммуникацию и сильные команды,
🔹 Как аналитик может стать сильно более ценным для компании, если выходит за рамки “писать задачки”.

📅 Во вторник
📍 Будет интересно и полезно
🔗 Ссылка на регистрацию ниже — присоединяйтесь!

До встречи! 😊

Разогреваемся перед NextConf с Иннокентием Бодровым!

🥷 Domain Driven Design - это не только подход к исследованию предметной области и проектированию архитектуры, но и существенные изменения в процессе разработки и функциях в команде. При умелом использовании DDD помогает аналитику погрузиться в предметную область самим, погрузить в нее команду разработки и настроиться с заказчиками на одну волну.

Как это сделать?

Во вторник, 25 марта, Иннокентий поделится опытом применения DDD в продуктовых командах, своими фейлами и успехами.

🔗 Регистрируйтесь, чтобы не пропустить.

Сегодня наткнулся в нескольких ТГ каналах на скриншот.
То, о чем пишет ITшник у меня закончилось году так в 19, когда я перешел на удаленку. Я в плане офисов и кофе. Хорошо, хоть зарплата осталась 😀

А вот токсичных коллег хватало, но в последнее время, когда я вступил в секту осознанных людей, ходящих к психологу, я научился отбиваться от токса и говорить, что мне это не нравится и не очень хочется так работать. И тут два варианта - либо тебя воспринимают, либо ты уходишь.
Потому что внезапно, если тебе не комфортно с токсичными коллегами и непонятным менеджментов - это не обязатально терпеть, так не везде 💜)

А какой опыт у вас?

Почему я пропал и что дальше?

Всем привет! Последние две недели не было особой активности, и на это есть причина – я сломал руку. Так что пока не до долгих текстов, но это не мешает мне развиваться и разгонять новые темы.

💡 Что удалось посмотреть?
Недавно посмотрел очень сильный доклад Владимира Маслова (X5) про System Design. В последнее время я активно погружаюсь в эту тему, делал мастер-класс, и могу сказать, что этот доклад – реально годный материал.

✅ Что в нём ценного?
• Фундаментальные принципы System Design – не только для интервью, но и для реальной работы.
• Структурированный подход – Маслов собрал ключевые методологии и лучшие практики.
• Огромный список источников – книги, статьи, блоги, видео, начиная от Сюя и Кабанчика (must-read по System Design) до менее известных, но очень полезных материалов.

Рекомендую к просмотру! 🎯

🔥 Готовим открытый эфир про System Design

И ещё одна новость!

Мы с Максимом Корейченко (вместе делали доклад на Flow про постановку задач разработчикам, а еще ведет канал про проду) решили глубже разобрать тему System Design.

📌 Что будет?
• Как понять, какуб систему вообще надо проектировать и рискуете ли вы дойти хотя бы до 1000 пользователей?
• Как System Design реально применяется в жизни?
• Что делать, если ты проектируешь не Netflix или YouTube, а что то более приземленное?
• Как системное мышление помогает решать реальные бизнес-задачи?

🎥 Формат – открытый эфир.
Говорить про это в одиночку сложно, поэтому будем разгонять тему вместе.

📅 Скоро анонс! Следите за новостями.

Всем отличного дня и классного конца недели! 🚀

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


Уважаемые коллеги, приглашаем Вас на интересную апрельскую конференцию для SА\BA, состоящую из блоков ВА- практик/Инструменты и SOFT Skill ВА/SA

Ждем вас 05 апреля, в субботу, на онлайн-конференции Analyst Marathon #13.

Некоторые темы докладов:

✅ Системный и бизнес-аналитик: как совмещать две роли в одном лице
✅ Арсенал инструментов для экспресс бизнес-анализа
✅ Автономность или функциональная определенность в работе аналитика. Стратегии в контексте 2025
✅ Путеводитель по океану знаний: как аналитикам учиться эффективно
✅ Техники и инструменты менторства

Программа ЗДЕСЬ
Где проходит: онлайн
Когда: 05 февраля, с 10 до 17 ч.
Что потом: видеозаписи, презентации, материалы докладов
Для моих подписчиков скидка 15% по промокоду IB15AM13

Регистрация физ лиц ЗДЕСЬ
С оплатой для юр лиц, можно ознакомится ЗДЕСЬ

Представление докладов и общение со спикерами в чате конференции (https://t.me/Analyst_Marathon_chat)

Use Case — незаслуженно забываемая классика: как систематизировать требования и избежать ошибок в реализации проекта

❓Хотите научиться создавать четкие и структурированные требования, которые помогут избежать ошибок и недопонимания в проектах?

Присоединяйтесь к воркшопу Use Case — незаслуженно забываемая классика, который пройдет 3, 5 и 7 марта!

🧑🏻‍💻 Ведущий — Иннокентий Бодров, Head of data products and integration в цифровом банке Finom.

На воркшопе:
🔹 Получите опыт создания Use Case диаграмм в группах и получите обратную связь от ведущего.
🔹 Научитесь избегать типичных ошибок при создании Use Case.
🔹 Узнаете об обновлениях методологии в Use Case 3.0 .

Это ваш шанс вернуть в арсенал проверенный метод, который сделает вашу работу проще и результативнее.

Регистрируйтесь и гарантируйте себе место на воркшопе: https://nextway.pro/use_case

А я напомню, что сегодня я буду рассказывать про работу с use case у ребят из Next Way. Еще есть пара мест.

Через полтора часа стартуем наш мастер класс, есть еще пара мест и возможность запрыгнуть в последний вагон!

Эфир удался! Запись уже на YouTube и RuTube

🔥 Как и обещал, выкладываю запись эфира, где мы обсудили рынок труда в РФ и частично затронули Европу.

📌 Основные выводы:

📉 Рынок РФ движется в сторону рынка работодателя, но пока это только тенденция, а не реальность. Компании стали разборчивее, больше времени тратят на поиск кандидатов, но хотят нанимать более качественных специалистов.

💡 Что действительно важно?
Главное – ориентация на результаты для бизнеса. Неважно, кто ты – архитектор, системный аналитик, продакт или бизнес-аналитик. Если ты решаешь проблемы бизнеса, приносишь компании деньги и пользу – тебя будут держать.

❌ Если ты просто «работаешь работу» – риски сокращения выше.

✔ Хорошие, качественные сотрудники тоже нужны, и если ты лоялен, ответственно выполняешь задачи и работаешь в срок, то вероятность сокращения значительно ниже. Как справедливо заметила Аня, таких специалистов ценят, и их постараются оставить.

📺 Запись эфира – на YouTube и RuTube!
Смотрите, делайте выводы и готовьтесь к изменениям на рынке. 🚀


P.S. На запись влезали спаммеры, пытался их вырезать, но получалось еще хуже, так что извините, но пару раз нас там прерывали.

И снова привет!
Ссылка на эфир про состояние рынка в РФ, который начнется уже через час
https://us06web.zoom.us/j/83166589737?pwd=MLhAlCIJayDeXUaABuhMbQ2YJllIaI.1

Доброго всем денечка.
Меня многие знают, как противника подробной документации, я считаю, что дока должна быть минимально необходимой. И дописываться только под запрос. Но это в первую очередь вопрос экономии ресурсов, при наличии которых, я бы тоже не против был подробной доки.

Но есть ребята, которые активно продвигают концепцию шаринга знаний через базы знаний, стараясь в минимальные усилия впихнуть максимальную пользу, и их Катя Лысенко собирает на круглый стол в эту пятницу в 18.00 по Москве.

Я искренне рекомендую вам сходить и послушать, сам тоже собираюсь присоединиться в качестве слушателя!

📚 ГОСТ или нет? А что, если это справочник?

Вчера мы говорили про подходы к документации в компаниях. И под постом всплыл закономерный комментарий: «Зачем придумывать что-то новое, если есть ГОСТ?»

С одной стороны, да, ГОСТ — рабочая штука. Но рабочая ли она везде?

Давайте будем честны ГОСТ, а чаще (в срезе документации) это именно ЕСКД, ЕСПД — это подходы, которые разработали около 50 лет назад, когда ритм разработки был совершенно другим. Сегодня мы живем в мире, где:
✔️ Продукты обновляются быстрее.
✔️ Требуется постоянная актуализация данных.
✔️ Документация не может быть зацементированной.

📌 И тут ГОСТ начинает нас ограничивать. Он хорош, когда нужно сдать проект или запаковать документацию под поставку железа. Но в динамично развивающемся ПО — вызывает вопросы. А главное, если предлагать разработчикам писать документацию по ГОСТу, они взвоют и начнут прятаться.

Но окей, с этим более-менее разобрались. А что делать экспертам, которые хотят передать знания?

В компаниях хотя бы понятны правила игры: продуктовая документация, база знаний, регламенты. А если ты сам по себе и хочешь написать что-то полезное для других?

Например, мы с Мишей сейчас работаем над справочником по финтеху. И столкнулись с двумя большими проблемами:
1️⃣ Как передавать знания, если читатель не может задать уточняющие вопросы?
Когда ты консультируешь, всегда есть диалог. Но в справочнике нет места вопросам. Значит, надо формулировать материал так, чтобы он был однозначно понятен и применим.
2️⃣ Как структурировать накопленные знания, если они изначально записывались "для себя"?
Если у вас когда-нибудь была папка с заметками, в которой вроде бы есть ВСЁ, но ничего нельзя найти — вы понимаете боль. 🤯

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

И тут спасибо компании ОНТИКО за наше счастливое детство 😂: я осознала, что сама с этим не справлюсь и пошла к ПК KnowledgeConf — ребятам, которые как раз занимаются систематизацией знаний.

🔔 Уже в эту пятницу в 18:00 (МСК) мы стартуем, возможно, целую серию встреч, где будем разбираться:
✔️ Как экспертам правильно выстраивать личные базы знаний?
✔️ Как систематизировать контент, чтобы его можно было использовать вне контекста создателя?
✔️ С чего вообще начинать, если хочется написать свой справочник?

Если вам это важно и интересно — welcome, присоединяйтесь! 📝✨

❗️PS Ссылка на эфир будет за час до мероприятия. Встреча будет в GoogleMeet.

Обзор книги «System design. Подготовка к сложному интервью» – Алекс Сюй

Раз уж мы заговорили про System Design, самое время сделать обзор на книгу Алекса Сюэ «Подготовка к интервью по системному дизайну».

📌 Почему стоит читать?
Хотя книга в первую очередь ориентирована на подготовку к интервью, она отлично подходит и для общего понимания верхнеуровневого проектирования систем.

💡 Чем полезна книга?
✅ Учит ограничивать время на дизайн – системный дизайн можно улучшать бесконечно, но в реальных условиях важно не утонуть в деталях.
✅ Тренирует чётко формулировать вопросы – короткие, но точные вопросы помогают быстро выяснить скоуп и основные требования, особенно нефункциональные, которые напрямую влияют на архитектуру.
✅ Демонстрирует влияние нагрузки на архитектуру – даже одна и та же функциональность для 10K и 10M пользователей реализуется абсолютно по-разному.

📚 Что внутри?
Книга разбирает 15+ кейсов – от базовых (например, согласованное хэширование и хранилища данных) до масштабных решений вроде YouTube, Google Drive и многопользовательских систем.

🔹 Как распределять нагрузку?
🔹 Как изменяется архитектура при росте пользователей?
🔹 Какие паттерны применять в разных ситуациях?

🔥 Рекомендую всем системным аналитикам и архитекторам!

Где разбирать на практике?

Кстати, эти же подходы будем разбирать на мастер-классе уже в этот четверг.
📅 Осталось несколько мест – присоединяйтесь!
🔗 Ссылка на регистрацию

Эфир про рынок труда: что происходит и как оставаться востребованным?

Всем привет!

Думаю, многие из вас уже видели новости о сокращениях в российских IT-компаниях – официальных и не очень. Рынок меняется, и это нельзя игнорировать.

Я живу в Европе, и здесь рынок полностью принадлежит работодателям. Среднее время поиска работы – 4-6 месяцев. В США и ЕС сокращения прошли ещё раньше, и теперь вопрос: ждёт ли Россия такой же сценарий?

📌 Что обсудим?
🔹 Будет ли российский IT-рынок двигаться в сторону рынка работодателя?
🔹 Как защититься от сокращения и оставаться нужным компании?
🔹 Что делать, если всё-таки попал под сокращение – как быстрее найти новую работу?

Кто в эфире?

✅Иннокентий Бодров (я) – продакт в европейском финтехе, поделюсь наблюдениями о том, как работает рынок в Европе и какие тенденции могут ожидать нас.
✅ Михаил Максимов – опытный бизнес-аналитик и бизнес-архитектор, расскажет, как адаптироваться к изменениям.
✅ Константин Семёнов – автор канала «Аналитик на галере», продакт в крупной российской компании, поделится ситуацией с аналитиками в продуктах в РФ.
✅ Анна Вязанкина – лидер компетенции анализа в крупном интеграторе, ex-преподаватель курса «Системный аналитик», расскажет про ситуацию около крупного Enterprise.

📅 Когда?
Вторник, 25 февраля, 19.00
Участие бесплатное, ссылка будет в канале в день эфира!

🚀 Если хотите понимать, что происходит на рынке и как оставаться востребованным – приходите. Будет полезно!

А вот и еще одна активность с моим участием - мастер класс по работе с Use Case в школе NextWay! Три дня плотной работы над пользовательскими требованиями в камерной обстановке.

Требования размыты, команда в недоумении, сроки горят? Решение есть!

Если ваши требования постоянно пересматриваются, команда не понимает, что делать, а продукт превращается в хаос – значит, пора прокачать навык их формализации.

🎯 Приходите на практические воркшопы, где разберем две эффективные техники:

🔹 User Story & User Story Map – научимся фиксировать требования так, чтобы разработчики сразу понимали задачу, а планирование фич стало предсказуемым.
📅 22, 23 февраля → Записаться
👨🏻‍💻 Ведущий: Константин Семенов, Lead Product Manager VK

🔹 Use Case – незаслуженно забываемая классика – структурируем пользовательские сценарии, чтобы избежать двусмысленности и исключить ошибки на этапе реализации.
📅 3, 5, 7 марта → Записаться
👨🏻‍💻 Ведущий: Иннокентий Бодров, Head of data products and integration в Finom

📌 Оставьте хаос в прошлом – научитесь формализовать требования четко и без лишних правок. Бронируйте место на воркшопах 👇

nextway.pro

Мастер-класс по System Design – 27 февраля в 20.00 по Москве
Всем привет! 🔥

Я пересмотрел своё расписание, прикинул, когда смогу провести мастер-класс по System Design, и определился – встречаемся 27 февраля.

💡 Что будет?
Разберёмся, как правильно подходить к проектированию систем, что учитывать, на что обращать внимание и как в целом с этим жить.

📌 Формат
🔹 Камерная группа – максимум 12-13 человек, чтобы у нас была возможность нормально пообщаться и разобрать все вопросы.
🔹 Разбор реального кейса – в ближайшие дни выберу тему, чтобы мы не просто говорили о теории, а проектировали на практике.
🔹 Про систем-дизайн нет одного «правильного» варианта – есть совсем неподходящие и чуть менее неподходящие. Будем разбирать, как оценивать решения и находить лучшее.

💰 Стоимость участия – 5000 ₽

🚀 Если хотите разобраться в System Design и понять, как применять его в работе – присоединяйтесь. Будет полезно!

Регистрация тут

До встречи 27 февраля. 🎯

Отдых – это нормально. Ещё раз для себя и для вас

Недавно я писал пост про отдых, и тут Дима ответил на него с очень классной мыслью: отдыха никогда не бывает достаточно.

Мы то погружаемся в работу с головой, забывая обо всём, то уходим в полное расслабление, и эти периоды идут волнами. Баланс? Не, не слышали.

🔄 Работа vs отдых
Смотрю на себя – и понимаю, что действительно так и есть. Иногда нужно просто отключиться, потому что иначе никак. А иногда ты готов фигачить днями и ночами, и это тоже нормально.

Мой пост был скорее о том, что в последнее время уходить в отдых у меня получается всё реже. Но спасибо зиме (и Диме 😁) за то, что ещё раз напомнили: отдыхать – это не лень, а необходимость.

📌 Главное – не корить себя
Нет, ты не упускаешь возможности, если даёшь себе передышку.
Нет, ты не деградируешь, если не работаешь 24/7.
Пока ты не набрал энергию, ты всё равно не сможешь нормально работать.

Так что ещё раз для всех, кто, как и я, забывает: отдых – это тоже часть процесса. И это нормально.

Отдых это проблема

Навеяно постом моего товарища Иннокентия "Учусь отдыхать. Сложнее, чем кажется".

За свою жизнь, я мало у кого видел гармоничные отношения с такой категорией жизни как "отдых". Чаще всего реализуется один из двух сценариев:

1) По отдыху существенный перебор,
2) По отдыху существенный недобор.

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

По итогу оба сценария приводят похожему результату — страдает качество жизни и эффективность.

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

И поскольку предлагается выбрать только из двух значений "перебор" и "недобор", то оптимальной стратегией выходит чередовать периоды перебора и недобора, желательно более-менее регулярно и без крайностей.

Более того, по ощущениям, такое волнообразное чередование очень подходит человеческой природе. В широком смысле человеческой — как четыре сезона в году. С отдыхом та же история, сезон перебора, сезон недобора.

ps. Разумеется есть еще такое понятие как "качество отдыха", от него тоже много чего зависит, но в целях сокращения размера поста от этих абзацев пришлось избавиться.

Системный дизайн для аналитиков: почему это важно?

После предыдущего поста о разнице между Software Architect и Solution Architect пришёл к ещё одной мысли: для полноценного развития архитектора важно уметь проектировать систему целиком.

Этот навык известен как System Design, и он уже давно является отдельным этапом собеседований на сеньорные позиции – не только для разработчиков, но и для аналитиков.

💡 Почему System Design важен аналитикам?
Потому что аналитик должен уметь мыслить системно, понимать, как связаны компоненты, какие решения оправданы в конкретных кейсах и как проектировать верхнеуровневую архитектуру.

🔹 Что мы разберём на мастер-классе?
Я не хочу делать его про «как пройти интервью», а именно про суть подходов в System Design:
✅ Как правильно формулировать верхнеуровневые требования – какие вопросы нужно задавать, чтобы понять, что от тебя хотят.
✅ Как за 10-15 вопросов выстроить картину системы, её ограничений и ключевых элементов.
✅ Когда можно обойтись монолитом, а когда без микросервисов не обойтись.
✅ Распределённые системы, кэширование, базы данных, размещение в CDN – когда, зачем и почему.

🕒 Формат: один вечер, около 2 часов, где разберём ключевые принципы System Design и научимся применять их на практике.

📅 Дата – скоро анонсируем!

Будет полезно и аналитикам, и тем, кто хочет прокачать системное мышление. Так что приходите! 🚀

Software Architect vs Solution Architect: в чём разница?
Давно у меня в списке на просмотр висело видео Ильдара, где он чётко раскладывает разницу между Software Architect и Solution Architect. Наконец-то дошли руки – и хочу поделиться выводами.

📌 Кто такой Software Architect?
Это крутой разработчик со знанием архитектурных паттернов и глубокой практикой их применения. Он не просто знает теорию – он чувствует плюсы и минусы подходов, потому что сам через них проходил.

👨‍💻 Почему аналитику сложно стать Software Architect?

Нет практического опыта кодинга – а значит, нет интуитивного понимания, когда применять тот или иной паттерн.
Есть риск теоретического оверинжиниринга – когда аналитик знает о паттернах, но не умеет правильно оценить их сложность в разработке.
Отсутствие авторитета в команде – с этим я согласен частично, но разработчики чаще доверяют тому, кто сам через всё это прошёл.
🔗 А кто такой Solution Architect?
Вот тут ситуация другая:
✔ В первую очередь это аналитик, который связывает несколько систем для решения бизнес-задачи.
✔ Не обязательно иметь опыт кодинга, но нужно понимать паттерны взаимодействия сервисов и систем.
✔ Опыт в аналитике тут даёт огромное преимущество, потому что ключевой навык – понимание бизнес-процессов и интеграций, а не написание кода.

💡 Вывод
Если ты аналитик и хочешь в архитекторы – Solution Architect выглядит более естественным вектором роста. В Software Architect без бэкграунда в разработке путь будет очень сложным.

Рекомендую видео к просмотру! Очень годно и по делу. 🎯

Учусь отдыхать. Сложнее, чем кажется
Предыдущий пост про концерт был не случайным. Главный мотив – напомнить, что отдыхать можно и нужно. Для меня эта тема сейчас особенно острая.

Последние пару лет – бесконечный поток событий, задач, тревог, амбиций. Всё это подталкивало двигаться быстрее, выше, сильнее. Работать. Развиваться. Достигать. И, честно говоря, в таком режиме очень легко себя загнать.

💡 Что происходит, когда ты загоняешь себя?
Ты выгораешь.
Ты начинаешь делать меньше.
Ты начинаешь страдать от того, что делаешь меньше.
Ты загоняешь себя ещё сильнее.
🔄 Петля обратной связи, которая ведёт только вниз.

И вот теперь я учусь разрывать эту связь. Учусь отдыхать заново. Учусь разрешать себе отдыхать.

📌 Что значит отдыхать?

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

Но сейчас я вижу реальный эффект. 🔋
Батарейка, которая казалась полностью разряженной, начинает заряжаться.
Появляется энергия.
Появляется желание делать что-то новое, крутое, важное.

И знаете что? Это правильно. Это работает.

Так что если вам кажется, что вы не можете себе позволить отдых – возможно, вам он нужен больше всего. 😉

Только что пришел с концерта Diary of Dreams. Лет 10 хотел сходить на эту группу и наконец-то получилось.
Ради него специально прилетел из Лиссабона в Варшаву.✈️
И оно того стоило.

🔉Звук был настроен просто великолепно, Я не ожидал такого качества от клуба, респект.
🎸И сами музыканты, конечно, не подвели. У вокалиста просто башенная энергетика, чтобы я так отжигал в 52 года (надеюсь буду).

Из интересного отмечу ещё, что аудитория была в основном 40+, а ведь раньше на такие концерты ходила молодежь. Лет 20 назад 😁.

Официально в свободном плавании: что дальше?

Сегодня был мой последний урок в качестве руководителя курса «Системный аналитик.Advanced». Группа завершила обучение, мы подвели итоги, и теперь я окончательно ухожу в свободное плавание.

📌 Какие планы дальше?
Как уже говорил, Аналитическая мастерская – мой новый вектор, и цель на этот год – вывести её на оборот 1,5 млн рублей.

💡 Первый шаг – запуск предзаписанного курса
Будет полноценный курс на Stepik, где я соберу всю экспертизу, которую структурировал и углублял за 4 года преподавания в Otus. Формат:
🔹 Лекции + практические занятия.
🔹 Обратная связь (будут тарифы с проверкой от меня).

💼 Что будет в курсе?
Я выстрою пошаговый путь аналитика, начиная с самых основ и заканчивая архитектурой решений. В программе:
✅ Выявление бизнес-потребностей и целей.
✅ Формализация требований и их трассировка.
✅ Работа с бизнес-процессами и управление требованиями.
✅ Архитектура решений: когда действительно нужен микросервисный подход, а когда – нет.
✅ Работа с API, синхронные/асинхронные модели, базы данных.
✅ Как передавать всё это в разработку.

Буду честен: системный анализ – это уже не то, что меня прямо драйвит, но в этом курсе я соберу именно те аспекты, которые реально работают и дают результат.

🚀 Что дальше?
Это только первый шаг. В дальнейшем хочу углубиться в более продвинутые темы, но об этом расскажу позже.

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

Hard vs Soft: о чём мы забываем?

В последнее время я всё больше убеждаюсь, что хард и софт скиллы – это два элемента одной системы, которые нельзя рассматривать отдельно. Да, если у тебя слабые харды, можно частично выехать на софтах. Но если с софтами проблема – только хардов часто недостаточно.

❓ Почему это важно?
Когда я смотрю на российский рынок образования, вижу, что 80% внимания уделяется хардам. Курсы по разработке, по анализу, обучают работать с инструментами – SQL, UML, BPMN, Kafka – но мало кто учит подходу к работе, коммуникации, достижению результата. Всё сводится к технологиям, хотя они всего лишь инструменты. Без методологии и понимания, как работать с людьми, эти знания становятся в лучшем случае бесполезными, а в худшем – вредными.

📊 Курсы и резюме: в чём проблема?
Если вы посмотрите на вакансии или резюме в России, то заметите одну вещь: акцент почти всегда на харды. «Умею работать с X, умею работать с Y», но редко кто пишет: «Вот что я сделал, вот каких результатов добился».

Для сравнения, на Западе в резюме технологии занимают одну строку, максимум два предложения. Основной акцент – на результатах. Например:

Сократил время обработки данных на 30% за счёт оптимизации процессов.
Увеличил производительность команды на 20% благодаря внедрению Agile.
А у нас? Большинство пишут: «Умею работать с Confluence и Jira». Но это ведь базовые вещи, которые можно освоить за пару дней. Почему так мало говорят о том, чего реально добились?

🌟 Что делать?
Мне кажется, что здесь нужно менять подход, в том числе в образовании. В своих мастер-классах я хочу уделять больше внимания софтам:

Как добиться результата?
Как эффективно работать с командой?
Как убедить коллег или заказчика?
Вместо того, чтобы зацикливаться на инструментах, которые к тому же быстро устаревают, я вижу ценность в том, чтобы дать людям универсальные навыки, которые помогут в любых проектах.

🎯 Мой вывод
Hard и soft скиллы – это две стороны одной медали. Но если харды – это «что делать», то софты – это «как и зачем». И без этого «как» ни один инструмент не поможет довести дело до результата.

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

P.S. картинки хорошей не нашел, поэтому попросил помочь нейросеть)

Как то внезапно подкралась цифра в 2000 подписчиков!
Это значимый рубеж и для меня и для канала.
Спасибо всем, кто читает, комментирует, ставит лайки и даже дизлайки!
Буду двигаться дальше и публиковать для вас полезный и интересный контент!🎉