Анна Вичугова, Главный исследователь и разработчик курсов SE, эксперт по бизнес-анализу и проектированию ИС, выступит на ЛАФ с воркшопом на тему «Производительная и отказоустойчивая маршрутизация потоков данных с RabbitMQ»

На практических кейсах посмотрим, как:
1. Спроектировать топологию конвейера приема и маршрутизации событий в RabbitMQ, используя различные обменники и задав параметры для очередей.
2. Отработать случаи с внезапным повышением производительности продюсеров и падением потребителей.
3. Из нескольких альтернативных вариантов обеспечения отказоустойчивости и масштабируемости потокового конвейера выбрать наиболее оптимальный с экономической точки зрения.

Задача участников — справиться с внештатными ситуациями со скачками нагрузки продюсеров и отказами потребителей, не потеряв данные

Подробнее о воркшопе

#выступления@systems_education #эксперты@systems_education

Очный курс «Интеграция систем. Разработка требований и основы проектирования»

🔹Когда?
24 — 26 Июля

🔹Цель курса — разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем

🔹Этот курс для:
— Системных аналитиков, которые хотят повысить свой уровень и зарплату с Junior + на Middle
— IT-специалистов, которые хотят разобраться в интеграциях
— Бизнес-аналитиков, которые хотят стать системными и для этого освоить интеграцию
— Руководителей отдела анализа и проектирования, которым нужно подтянуть подчинённых по интеграции
— HR, T&D, Тимлидов, которым нужно выбрать курс по запросу внутри компании и обучить на нём сотрудников

🔹На курсе вы:
— Изучите технологии интеграции
— Спроектируете рабочую интеграцию, которую можно будет использовать в качестве образца в работе или положить в Портфолио
— Научитесь документировать межсистемное взаимодействие

Регистрация

#интеграции@systems_education #REST@systems_education #брокеры@systems_education #Kafka@systems_education #SOAP@systems_education #XML@systems_education

Опубликовали запись доклада Дениса Бескова с конференции Flow на тему «Что не так с онтологией требований Вигерса и что с этим делать»

Онтология требований Вигерса, хотя и не опирается ни на какие стандарты, остается популярным среди ИТ-аналитиков способом думать о требованиях. Денис использует методики Вигерса более 20 лет, и за это время стали видны нестыковки и проблемы в его модели. Используя языковые методы и подходы системной инженерии, Денису удалось придумать, как можно сделать модель Вигерса более точной, сбалансированной и полезной для своей работы. В докладе он предложил эту обновленную онтологию и объяснил, как ее применять.

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

#выступления@systems_education

Курс «Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей»

🔹 Когда?
c 5 Июля по 2 Августа 2025 г.

🔹 Курс для опытных бизнес-аналитиков, системных аналитиков и проектировщиков информационных систем, которые хотят развить свои практики постановки задачи на выбор, разработку и внедрение ИТ-решений при автоматизации бизнеса

🔹 Курс будет полезен, если Вы хотите научиться:
— Проводить интервью с заказчиком, задавать правильные вопросы
— Исследовать контекст проекта: изучать и описывать процессное окружение в области рассмотрения проекта
— Выявлять и описывать организационные роли, их интересы, которые вызвали проект к жизни
— Выявлять проблемы и риски в реализации интересов
— Формулировать измеримые цели и ограничения ИТ-проекта
— Выявлять и описывать ключевые требования организационных ролей
— Использовать нейросети для выполнения перечисленных задач

🔹 Что вы получите?
— 6 занятий по 2 и 4 часа
5 модулей для освоения авторской технологии перехода от бизнес-требований к требованиям к ИТ-решению
— Опыт командной работы
Практика в командах до 5 человек, работа над сквозными кейсами

Регистрация

#бизнес_анализ@systems_education #ИИ@systems_education

Как провести Event Storming: от физической доски до удалёнки

Event Storming — это полезная техника для визуализации процессов и создания общего языка между бизнесом и техническими командами. Её можно проводить в двух основных форматах: офлайн или онлайн, рассмотрим их ниже.

🧑‍🏫 ОФФЛАЙН-ФОРМАТ

Классическая сессия Event Storming проводится очно: все участники собираются в одной комнате у физической доски, работают со стикерами, записывают события процесса и обсуждают их лицом к лицу.

Преимущества такого подхода:
— Участники мгновенно реагируют на реплики друг друга, жестикулируют и находят решения «на лету».
— Возможность приклеить стикеры, передвигать их, прямо на стене создаёт эффект полного погружения.
— Все чувствуют динамику процесса и поддерживают одну скорость.

👩‍💻ОНЛАЙН-ФОРМАТ

Если участники работают удалённо, Event Storming можно полностью перенести в виртуальное пространство. Для этого чаще всего используют инструменты для совместного рисования и работы со стикерами. Помимо Miro существуют платформы:
— Pruffme
— Sboard
— Unidraw
— holst
— Яндекс Доски

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

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

Чтобы получить практический опыт проведения Event Storming приглашаем вас на воркшоп: «Event Storming как техника моделирования предметной области и выявления микросервисов».
Регистрация

#воркшоп@systems_education
#event_storming@systems_education

В течение ближайших месяцев мы проведём несколько вебинаров по самым популярным UML-диаграммам. Ведущие расскажут необходимую теорию и закрепят её на примерах по одному сквозному кейсу «Каршеринг».

🎥 Опубликовали запись первого вебинара из этого марафона на тему «Диаграмма Use Case: Построение и применение»

Тайм-код вебинара:
00:00 Введение
02:16 План вебинара
03:30 Диаграмма Use Case. Теория
05:02 Процесс проектирования системы
06:50 Описание кейса. Каршеринг — аренда автомобиля
09:23 Элементы диаграммы Use Case
14:04 Название Use Case
23:46 Инструменты для создания диаграмм UML
25:10 Построение диаграммы на примере
35:38 Типовые ошибки
40:19 Пакеты Use Cases
44:18 Заключение
48:43 Вопросы зрителей
01:20:01 О домашнем задании

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

Курс и воркшоп, которые могут быть вам интересны:
— «Системное моделирование. Проектирование информационных систем с помощью UML»
— «Use Case: основы»

📚 Как и обещали на вебинаре, публикуем домашнее задание для отработки полученных знаний. Через несколько дней в группе по вебинарам @se_webinars опубликуем разбор дз от Татьяны Назаренко. Получить же полноценную обратную связь по вашим наработкам у вас будет возможность на курсе по UML-диаграммам или на коротком воркшопе по Use Case.

Задание — Проект мобильного приложения для пользования услугами такси. Необходимо разработать диаграмму Use Case для будущей системы. Категории пользователей и функционал, который должен быть реализован, приведены ниже

Приложение для пассажиров такси

1. Регистрация и запуск
После установки приложения пользователь регистрируется по номеру телефона. Приложение определяет текущее местоположение с помощью GPS, но адрес можно ввести вручную или выбрать на карте

2. Оформление заказа
— Задать маршрут (адрес отправления и назначения). Можно добавить промежуточные точки.
— Выбрать тариф (Эконом, Комфорт, Детский, для животных и т.д.), при необходимости добавить комментарии для водителя или выбрать дополнительные опции (например, перевозка багажа, детское кресло).
— Выбрать способ оплаты – банковская карта, наличные, Apple Pay, Google Pay и др. Для этого карта привязывается в разделе «Способы оплаты».
— При необходимости можно заказать такси для другого человека, приложение отправит ему SMS с деталями поездки.

3. Поиск и назначение водителя
После подтверждения заказа система автоматически подбирает ближайшего свободного водителя. На экране отображается информация о водителе (имя, рейтинг, стаж), марка и номер машины, время ожидания и маршрут.

4. Ожидание и поездка
— Приложение показывает время прибытия машины и оповещает о её приближении.
— Во время поездки отображается маршрут, время и стоимость, есть функция «поделиться маршрутом» с близкими.

5. Завершение поездки и оплата
По окончании поездки оплата списывается автоматически (если выбран безналичный способ), либо оплачивается наличными. Можно оценить поездку и оставить отзыв.

Дополнительные функции:
— Bстория поездок — быстрый доступ к часто используемым маршрутам.
— Рейтинг пассажира и водителя — влияет на качество обслуживания и доступные опции.

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

#вебинары@systems_education

🧑‍💻 Ищем авторов экспертно-информационных постов

Что надо делать:
— Писать лаконичные и полезные посты для канала @systems_education
— Форматы: «как это работает», мини-кейсы, инструкции (≈ 2 000–2 500 знаков), создание схем и диаграмм для иллюстрации
— Частота: 1-2 поста в неделю (гибко согласуем график)

Мы даём:
— Доступ к платному ChatGPT Plus от Open AI для написания постов
— Доступ к платному Miro со встроенным AI для создания диаграмм
— Доступ к «Книжной полке» Бюро Горбунова — прокачиваем информационный стиль
— Подборка профессиональных IT-изданий для вдохновения.
— Редакционный гайд и быстрый фидбек
— Дружелюбное комьюнити во внутреннем чате школы

Условия:
— Оплата 1000 ₽ за один готовый пост
— Раз в полгода — бесплатное прохождение курса или воркшопа школы
— Гонорар на карту РФ как самозанятому или ИП

Требуемый бэкграунд:
— Практикующий системный аналитик Middle+ со знаниями интеграций, нотаций моделирования
— Умеете писать понятно о сложном
— Следуете принципам информационного стиля — короткие абзацы, чёткая логика

📌 Как откликнуться

Пришлите @systemseducation:
— ссылку на 1–2 лучшую публикацию в канале @systems_education,
— пару строк о себе и любимую тему в IT-образовании,
— идею вашего первого поста для нашего канала.

Мы ответим в течение 3 дней, дадим тестовое задание (оплачиваемое).
Дедлайн приёма заявок — 23 июня 2025.

👥 До встречи в команде Systems.Education!

#вакансии@systems_education

14 июня (сб) в 18:00 мск проведём вебинар на тему «Что может пойти не так в микросервисах»

▫️На вебинаре разберём:
— что такое монолит, а что — микросервис
— почему не стоит сразу писать на микросервисах
— когда действительно нужно переходить на микросервисы
— как выглядит ад микросервисов на практике
— какие задачи придётся решать в микросервисной архитектуре: логгирование, трейсинг запросов, observability

▫️Кому будет полезен вебинар:
— разработчикам, которые хотят понимать последствия архитектурных решений
— архитекторам, выстраивающим масштабируемые и поддерживаемые решения
— системным аналитикам, которым важно учитывать архитектурные ограничения при проработке требований и взаимодействий между сервисами
— тем, кто только планирует миграцию на микросервисную архитектуру, так и тем, кто уже столкнулся с её сложностями.

▫️Ведущий вебинара — Аким Мамедов, Software Engineer с опытом проектирования и реализации корпоративных систем. Работал в банковском секторе, логистике, FMCG и на крупных технологических платформах. В проектах Акима — как классические монолиты, так и распределённые микросервисные архитектуры, включая переезды, масштабирование и устранение последствий неудачного проектирования.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

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

Регистрация обязательна
❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

Продолжаем серию постов с задачами по поиску оптимального способа интеграции
Все прошедшие задания и разборы эксперта можете найти по хештегу — #задача_от@systems_education

Ваша задача такая же — выбрать наиболее подходящий способ интеграции к описанной ситуации. Через несколько дней выложим пост с разбором от Елены Бенкен, эксперта школы SE и автора курса «Интеграция систем. Разработка требований и основы проектирования».

Ситуация — Передача файлов между бухгалтерией и банком

Задача: бухгалтерская система компании должна ежедневно передавать платежные данные (например, реестры платежей, зарплатные ведомости) в банк и получать ответные файлы с результатами обработки или выписками. Объем данных умеренный, обмен происходит раз в день, ключевые требования — надежность и безопасность передачи.

Варианты решений:
— Безопасная файловая передача (SFTP/FTP) по расписанию
— Прямое подключение по API банка (если доступен)
— Использование шины/посредника (ESB) для маршрутизации данных
— Отправка данных вручную по email 😅

Какой способ выберете для обмена файлами с банком? Совсем скоро сравним ваши ответы с разбором от эксперта!

Если этот вопрос пока вызывает у вас трудности, рекомендуем пройти курс «Интеграция систем. Разработка требований и основы проектирования», на котором вы под руководством эксперта сможете разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем.
Подробнее о курсе

🔔 Следите за обновлениями в канале, если не хотите пропустить разбор от эксперта и следующие задачки по поиску оптимального способа интеграции!

#интеграции@systems_education #курс@systems_education

💰Через 2 недели повышение цен на осенний поток буткемпа «Systems Analyst Bootcamp»

Буткемп нацелен на быстрый и уверенный старт в карьере СА. Формат обучения на программе переподготовки нацелен на то, чтобы познакомить вас со спецификой работы в данной сфере. За 12 недель вы полностью погрузитесь в реальные задачи системного аналитика, поработав с заказчиком над реальным проектом под присмотром экспертов.

В течение 3 месяцев каждую неделю вас будут ждать:
— Два четырехчасовых воркшопа для получения теоретических знаний и практических навыков
— Двухчасовая встреча-созвон с Заказчиком
— Встреча-созвон с командой для выполнения совместных заданий / распределения задач
— Отработка теоретического материала на обучающей платформе
— Выполнение индивидуальных домашних заданий и предоставление их на проверку
— Ведение документации в рабочем пространстве команды

4 июля будет второе повышение цен на осенний поток программы переподготовки. Если вы давно хотели сменить профессию или избавиться от «синдрома самозванца», не затягивайте с регистрацией на «Systems Analyst Bootcamp»!

Подробнее

#буткемп@systems_education

Критерии приемки: как четко задавать границы User Story

Критерии приёмки — это четкие условия, по которым можно определить, действительно ли завершена и работает User Story. Они приносят пользу как команде разработки, так и заказчику. С помощью критериев приёмки можно:
— Очертить границы задачи, чтобы никто не додумывал
— Достигнуть общего понимания как внутри команды, так и с бизнесом
— Сделать оценку и планирование более точными
— Подготовить тестирование заранее, ещё до разработки
— Учесть негативные сценарии, которые иначе могут всплыть только на проде

Подходы к описанию критериев приёмки
Существует несколько подходов к тому, как формулировать критерии приёмки. Чаще всего используются два формата, которые могут применяться как по отдельности, так и вместе:
1️⃣ Свод правил. Перечисление требований и условий списком, своего рода чек-лист того, что должно быть реализовано для выполнения истории.
2️⃣ Сценарный подход. Описание поведения системы через пользовательские сценарии, например, в формате Given/When/Then (Gherkin).

Оба подхода в итоге помогают достичь единого понимания требований, просто представляют информацию по-разному.

🔹 Критерии приёмки как свод правил

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

Как сформировать такой список? Обычно аналитик и команда прорабатывают пользовательскую историю, задавая уточняющие вопросы заказчику и друг другу. Например, возьмём историю: «Как пользователь, я хочу искать товары в пределах заданного диапазона цен, чтобы найти подходящие мне по стоимости товары.» Чтобы сформулировать критерии приёмки для этой функции поиска по цене, команда выясняет детали:
— Какие границы цен может указать пользователь?
— Как именно пользователь задаёт диапазон — движком-ползунком или вводом точных значений с клавиатуры?
— Нужно ли нажимать кнопку для начала поиска или результаты должны обновляться автоматически?
— Как обрабатывать неверно указанный диапазон (пустой ввод, перепутанные границы)? Какое сообщение об ошибке показать?
— Как отображать результаты поиска: сколько элементов на странице, как реализовать пагинацию, сортировку?
— Учитывать ли товары, которых нет в наличии, или те, что скоро поступят?

🔹 Сценарно-ориентированный подход (Given/When/Then)

Сценарный подход описывает критерии приёмки через конкретные ситуации использования системы. Чаще всего его реализуют с помощью языка Gherkin, используя конструкции Given/When/Then (в русской адаптации – «Допустим/Когда/То»). Такой формат представляет собой набор сценариев, написанных на понятном для бизнеса языке, и отлично подходит для методик BDD (Behavior Driven Development).

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

На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» у вас будет возможность на практике познакомиться с критериями приемки и многими другими техниками, которые помогают в описании постановки задачи на разработку ИТ-системы. Подробнее тут.

#воркшоп@systems_education #популярные_посты

Опубликовали запись доклада Влада Хононова на тему «Как найти оптимальную связанность компонентов при проектировании ПО» с третьей онлайн-конференции Systems Design Online

Тайм-код доклада:
00:00 О докладе
01:46 Что такое сложность?
04:48 Что вызывает сложность?
05:49 Влияние сложности
07:14 Сложность vs модульность
08:16 Что такое модульность?
09:59 Связанность
15:12 Сила интегрирования
16:05 Интеграция через вторжение
18:09 Функциональная связанность
20:20 Связанность через модель
23:00 Связанность через контракт
24:09 Модель интеграционной силы
25:14 Расстояние
27:34 Интеграционная сила vs расстояние
32:50 Что такое волатильность?
33:48 Модель поддоменов
35:30 Модель сбалансированной связанности
36:30 Заключение
37:42 Вопросы

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

✍️ Если вам интересна тема доклада, рекомендуем рассмотреть курс «Архитектура ИТ-решения: Проектирование и реализация MVP» (подробнее)

#конференция@systems_education

🌳 Дерево текущей реальности

Дерево текущей реальности Голдратта — инструмент, который превращает набор симптомов в строго проверяемую цепочку «причина → следствие» и выявляет одну–две корневые причины большинства нежелательных явлений.

Что даёт дерево:
— показывает, на какие факты реально стоит влиять
— создаёт общий язык для команды
— определяет, куда попадут показатели успеха после улучшений

Алгоритм построения дерева текущей реальности:
1. Соберите нежелательные явления. Записывайте только подтверждённые факты в утверждительной форме и с отрицательным контекстом, каждое явление — отдельная карточка.
2. Соедините карточки причинно-следственными стрелками «если … то …». При необходимости вставляйте промежуточные явления.
3. Проверьте каждую связь по восьми категориям правомерных оговорок:
— слова понятны и однозначны?
— существует ли это явление на самом деле?
— приводит ли причина к следствию?
— одной причины достаточно?
— есть ли ещё фактор, без которого следствие не возникает?
— не перепутаны ли направление стрелки?
— есть ли другие эффекты, которые должны проявиться, если связь верна?
— нет ли логического круга?
4. Найдите коренные причины — узлы, в которые не входят другие стрелки.
5. Поднимитесь к последствиям, задавая вопрос «и что тогда?». Эти верхние узлы фиксируют ущерб для денег, клиентов или сотрудников и позже станут ключевыми показателями эффективности.

🔔 В следующем посте мы расскажем, как использовать эту методику в качестве промта для ИИ

На курсе «Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей» мы обучаем строить дерево текущей реальности на реальном бизнес-кейсе логистики. Подробнее тут.

#бизнес_анализ@systems_education #ИИ@systems_education

Ошибки рисования потоков данных: почему стрелки иногда вредят

В визуализации процессов и архитектуры неаккуратное использование стрелок может ввести в заблуждение, замаскировать скрытые зависимости и создать иллюзию «мёртвых» связей. Рассмотрим самые распространенные случаи.

📌 Перегрузка стрелок: визуальный шум

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

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

Как исправить:
— Выделяйте только ключевые потоки. Отмечайте стрелками лишь те взаимодействия, которые критичны для бизнес-функции или архитектурного решения.
— Группируйте компоненты. Если несколько компонентов обмениваются похожими данными, покажите общий шлюз или шину сообщений вместо десятка стрелок.
— Используйте стили стрелок. Разные типы линий (пунктир, толстая линия) помогут разграничить синхронные запросы, асинхронные события и «человеческие» коммуникации.

📌 Фиксация стрелок вместо событий

Симптомы:
— Постоянное рисование «от А к Б» блок-схем, где забыты ключевые события домена
— Стрелки заполняют место, где должны висеть стикеры с бизнес-событиями

Так теряется смысл Event Storming, и фокус смещается с «что происходит» на «как соединить»

Как исправить:
— Начинайте с событий. Сначала фиксируйте все события на таймлайне, а только потом рисуйте самые важные связи.
— Используйте стрелки для интеграции, а не для каждого события. Эвенты остаются на месте, а стрелками отмечаете только вызов новых обработчиков или сервисов.
— Чётко разделяйте зоны Event Storming и Data Flow Design. Делайте два этапа: сначала «нарисовать события», затем «нарисовать только критичные потоки данных».

Чтобы предотвратить возможные ошибки:
— Фильтруйте только ключевые потоки, группируя остальное
— Разграничивайте типы взаимодействий (команда, запрос, событие, ответ)
— Не забывайте об ошибках и обратных путях
— Сначала фиксируйте события, затем — минимальные связи для интеграции
— Чётко указывайте инициатора и направление каждого потока

Приглашаем вас на воркшоп: «Event Storming как техника моделирования предметной области и выявления микросервисов». На нем вы освоите все этапы моделирования, от Big Picture до System Design, и научитесь применять Event Storming в команде.
Регистрация

#воркшоп@systems_education
#event_storming@systems_education