Воркшоп «BPMN для людей: основы самой популярной нотации для описания бизнес-процессов»

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

🔹 Когда?
24 ноября (вс)

🔹 Что Вас ждет?
— Вы познакомитесь с принципами построения BPMN-диаграмм, а также на практике освоите применение основных элементов алфавита этой нотации
— Детально опишете логику выполнения бизнес-процесса по выбранному кейсу

Регистрация

#BPMN #воркшоп

Воркшоп «Проектирование сложных API: OpenAPI + AsyncAPI»

Воркшоп по проектированию и документированию API для системных аналитиков, которые хотят познакомиться со спецификациями OpenAPI и AsyncAPI, а также научиться проектировать и документировать синхронные и асинхронные API

🔹 Когда?
11 декабря (ср)

🔹Что ждать от воркшопа?
— Короткое онлайн-занятие в будни
— 2-7 часов теории, практики и обратной связи
— Работа в группах до 10 человек
— После окончания поделимся полезными материалами

Зарегистрироваться на воркшоп и узнать подробнее о программе можно тут!

#воркшоп

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

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

1️⃣ Построение Impact Map
Impact Map помогает определить ключевую цель выпуска продукта и его влияние на пользователей. Начинайте с вопроса: «Как новая версия улучшит жизнь пользователей?» Ответ на этот вопрос станет основой для принятия решений о том, какие функции и свойства продукта нужно разработать. Это позволяет сфокусироваться на ценности, а не на мелких деталях реализации.

2️⃣ Создание качественных пользовательских историй
Формат User Story позволяет описать требования через призму пользователя: «Как [роль], я хочу [действие], чтобы [результат]». Такой подход помогает заказчику и команде обсуждать ценность продукта и достигать взаимопонимания. Качественная история всегда конкретна и понятна, и её описание ориентировано на пользователя.

3️⃣ Приёмочные критерии и приёмочные тесты
Чтобы убедиться, что история реализована правильно, используйте технику Definition of Done и приёмочные тесты. Приёмочные критерии описывают, как именно должна работать функциональность, а тесты проверяют это на бизнес-ориентированном языке. Это снижает риск ошибок и недопонимания.

4️⃣ Декомпозиция крупных пользовательских историй
Большие идеи нужно разбивать на небольшие, конкретные и управляемые задачи. Это облегчает планирование и выполнение. Правильная декомпозиция позволяет сохранить целостность продукта и видеть конечную цель.

5️⃣ Создание карты пользовательских историй
User Story Map — это инструмент, который визуализирует дорожную карту разработки. Он показывает, какие возможности получат клиенты и когда. Это облегчает планирование релизов и демонстрирует, как улучшения продукта повлияют на пользователей.

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

Освоить эти инструменты на практике вы сможете на нашем воркшопе «Основы бизнес-анализа и разработки требований в Agile»

Регистрация

#воркшоп #Agile

Воркшоп «Use Case: основы»

🔹Когда старт?
7 декабря (сб)

🔹Воркшоп будет полезен начинающим системным аналитикам, которые хотят:
— научиться писать Use Cases
— строить диаграмму сценариев использования
— формировать пакеты и реестр Use Cases
— не допускать типичных ошибок

🔹Тебя будет ждать короткое онлайн-занятие
— Утром в выходной день
— 4,5 часа с перерывом

Регистрация

#воркшоп #системный_анализ #требования #Use_Case

Сколько компании стоит плохой API?

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

Но что происходит, если API разработан с ошибками или вовсе без учёта современных подходов?

🤷 Вот лишь несколько последствий:
1. Высокие затраты на исправления. Исправление ошибок на поздних этапах разработки или после релиза обходится сильно дороже, чем их предотвращение на старте.
2. Потеря времени. Неудобный и плохо документированный API замедляет работу интеграторов и разработчиков, удлиняя сроки запуска продуктов.
3. Отток клиентов. Если партнёры или клиенты сталкиваются с нестабильной работой или сложностями при интеграции, они просто выбирают конкурентов.
4. Риски безопасности. Плохо спроектированный API может стать точкой уязвимости, что чревато утечками данных и финансовыми потерями.
5. Потеря репутации. Один сбой в работе API — и негативный отзыв может мгновенно разлететься по сети.

💯 Как этого избежать?
1. Придерживаться лучших практик проектирования. Использовать стандарты, такие как REST или GraphQL, прорабатывать архитектуру, следить за качеством документации.
2. Учитывать потребности всех заинтересованных сторон. API должен быть удобным не только для внутренних разработчиков, но и для внешних пользователей.
3. Проводить ревью и тестирование. Автоматизированные и нагрузочные тесты, код-ревью и пилотные интеграции помогут выявить проблемы заранее.
4. Обучать команды. Недостаток знаний разработчиков часто становится причиной ошибок.

Если вы не хотите сталкиваться с такими проблемами, приглашаем на воркшоп «Проектирование сложных API: OpenAPI + AsyncAPI»

Регистрация

#воркшоп

Воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов»

🔹Когда старт?
16 декабря (пн)

🔹Воркшоп будет полезен системным аналитикам и начинающим архитекторам, которые хотят:
— научиться быстрому исследованию бизнес-процессов
— изучить технику моделирования предметной области
— выделять микросервисы

🔹2 занятия по 2 часа
— По будням вечером
— 2 часа без перерыва
— Чередование теории, практики и обратной связи

Регистрация

#воркшоп #event_storming

Что важнее — знать принципы моделирования или основы нотации и инструмент?

Знающий специалист скажет, что, конечно, принципы важнее, ведь нотации меняются, а понимание основ остается. Но что делать, если знание нотации и инструмента нужно здесь и сейчас?!

На воркшопе «BPMN для людей основы самой популярной нотации для описания бизнес-процессов» ты изучишь:
— Основные принципы и особенности построения моделей бизнес-процессов;
— Возможности и ограничения нотации BPMN для моделирования процессов различной сложности

🧑‍💻 Мы пройдем от ЖЕЛАНИЯ научиться до СОЗДАНИЯ своей диаграммы через
— Освоение принципов работы нотации
— Представление изучаемого процесса или деятельности в виде совокупности подпроцессов, типовых объектов и систем
— Построение диаграммы BPMN с учетом границ процессов; участников; смежных систем; потоков управления, сообщений, данных и объектов
— Оценивание полученных результатов, включая поиск альтернативных вариантов развития процесса и всех возможных результатов его реализации
— Утверждение законченной диаграммы как документа для согласования и принятия в работу

🧘‍♀️ Для повышения эффективности процесса разработки диаграмм на каждом из приведенных шагов ты поймешь, как добиваться баланса между:
— Сложностью диаграммы и ее понятностью любому стейкхолдеру
— Содержательностью диаграммы и лаконичностью формулировок ее основных элементов
— Детализацией модели процесса и наглядностью представления результатов
— Затрачиваемым временем на построение и качественной документацией

Регистрация на воркшоп

#BPMN #воркшоп

Как правильно спроектированный REST API снижает издержки на разработку?

REST API — это не просто интерфейс для взаимодействия между системами. Это стратегический инструмент, который при грамотном проектировании позволяет значительно сэкономить ресурсы компании. Как это работает?

🔄 Повторное использование
Когда API спроектирован по универсальным принципам (например, REST и стандартные ответы), его легко можно использовать в других проектах компании. Это снимает лишнюю нагрузку с команды и экономит время на создание новых интерфейсов.

⏳ Сокращение времени интеграции
Унифицированный API с продуманной логикой и чётким описанием снижает трудозатраты разработчиков. Вместо вопросов «Как это работает?» они сосредотачиваются на реализации, потому что всё понятно с первого взгляда.

💻 Упрощение поддержки
Когда API логично организован, ошибки легче выявить и исправить. Это уменьшает количество багов, с которыми сталкиваются разработчики.

🧑‍💻 Снижение зависимости от конкретных разработчиков
Хорошая документация — это не просто формальность, это инструмент, который избавляет команду от зависимости от одного специалиста. Уход ключевого разработчика не станет катастрофой: все знания о работе API уже описаны и понятны.

💰 Долгосрочная экономия
Ошибки на этапе создания API могут в будущем вылиться в большой перерасход средств: от переработки кода до сложностей с расширением. Вложив время в качественное проектирование, вы убережёте себя от этих рисков.

Научиться правильно проектировать REST API вы можете на воркшопе, который стартует 21 декабря

Регистрация

#воркшоп #интеграция #RESTAPI

Воркшоп «Проектирование интеграции с REST API»

🔹Когда старт?
21 декабря (сб)

🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки

🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона

Регистрация еще открыта!

#воркшоп #интеграция #RESTAPI

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

Но решение есть — использовать риск-ориентированный подход

Для эффективного определения требований к ИБ рекомендуется использовать риск-ориентированный подход, включающий следующие этапы:

1. Оценка защищаемой информации: Определите, какие данные нуждаются в защите, и оцените их ценность для организации.

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

3. Классификация и моделирование злоумышленников: Идентифицируйте потенциальных нарушителей, их цели и возможности.

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

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

6. Формирование контрмер: Разработайте меры по предотвращению или минимизации выявленных рисков.

На каждом этапе важно привлекать соответствующих специалистов: архитекторов, аналитиков, специалистов по безопасности и даже юристов. Это обеспечит всесторонний подход к выявлению и формулированию требований к ИБ.

Если вы хотите на практике познакомиться с выявлением требований к ИБ, приглашаем вас на январский воркшоп

Регистраций

#воркшоп #безопасность

Воркшоп «Проектирование и реализация очередей в брокерах RabbitMQ и Apache Kafka»

На воркшопе вы развернёте в бесплатных облачных средах свои инстансы и решите на них задачу публикации и потребления сообщений разными сервисами, написанными собственноручно на Python в Google Colab.

🔹Цель обучения
— Познакомиться c теорией по RabbitMQ и Apache Kafka
— Научиться проектировать потоковый конвейер обработки данных (data pipeline)

🔹Когда старт?
18 января (сб)

🔹Что получат участники:
— 2 занятия по 4 часа
— Вы узнаете теорию по RabbitMQ и Apache Kafka
— Спроектируете потоковый конвейер обработки данных (data pipeline)

Регистрация

#воркшоп #RabbitMQ  #ApacheKafka

Воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов»

🔹Когда старт?
27 января (пн)

🔹Воркшоп будет полезен системным аналитикам и начинающим архитекторам, которые хотят:
— научиться быстрому исследованию бизнес-процессов
— изучить технику моделирования предметной области
— выделять микросервисы

🔹2 занятия по 2 часа
— По будням вечером
— 2 часа без перерыва
— Чередование теории, практики и обратной связи

Регистрация

#воркшоп #event_storming

Воркшоп «BPMN для людей: основы самой популярной нотации для описания бизнес-процессов»

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

🔹 Когда?
с 21 января (вт)

🔹 Что Вас ждет?
— Вы познакомитесь с принципами построения BPMN-диаграмм, а также на практике освоите применение основных элементов алфавита этой нотации
— Детально опишете логику выполнения бизнес-процесса по выбранному кейсу

Регистрация

#BPMN #воркшоп

Воркшоп «Проектирование интеграции с REST API»

🔹Когда старт?
1 февраля (сб)

🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки

🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона

Регистрация еще открыта!

#воркшоп #интеграция #RESTAPI

Почему BPMN-модели «не работают»? Или чего не хватает в ваших диаграммах

BPMN — стандарт описания бизнес-процессов, который обещает ясность и прозрачность. Однако многие команды и компании сталкиваются с проблемой: «Мы рисуем красивые схемы, но на практике они не работают». Почему так происходит? Давайте разберемся

1. Нет связи с реальными бизнес-целями 🔗
Часто BPMN-модель остаётся формальной «картиночкой» ради самого факта её существования. Но если модель не увязана с ключевыми метриками и бизнес-показателями, она перестаёт быть полезной.

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

2. Отсутствуют роли и зоны ответственности 👥
Многие забывают про swimlanes (пулы, дорожки) или указывают их слишком обобщённо. В итоге команда не понимает, кто конкретно отвечает за тот или иной шаг.

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

3. Недостаток «живых» данных и реальных сценариев 📝
Если BPMN-модель не учитывает исключительные ситуации и вариативность реальной жизни, в итоге при запуске процесса возникают сбои и вопросы.

Что делать:
— Для каждого основного блока или ветви укажите, что происходит в случае ошибок или нестандартных ситуаций.
— Добавьте события типа «Error», «Escalation» и т.д. в BPMN, чтобы процесс стал ближе к реальным кейсам.

4. Слишком высокая детальность или чрезмерная абстракция 🤷
— Чрезмерная детализация превращает схему в «нагромождение» символов, в котором никто не может разобраться.
— Слишком общая модель наоборот, не даёт понимания того, что и когда происходит.

Что делать:
— Найдите «золотую середину»: описывайте ключевые шаги и принципы взаимодействия, не упуская важных разветвлений.

5. Отсутствие документации и описания «за кадром» 👀
BPMN-диаграмма показывает кто и что делает, но не всегда понятно зачем и какие данные используются. Без этого модель становится сухим набором блоков, которые трудно интерпретировать.

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

Итог: Чтобы BPMN-модель работала, её нужно связать с реальными целями, ролями, данными и бизнес-контекстом. Тогда диаграммы станут надёжным ориентиром для всех участников процесса — от операционного сотрудника до руководителя. Научиться всем этому на практике вы сможете на воркшопе «BPMN для людей: основы самой популярной нотации для описания бизнес-процессов»

Регистрация

#BPMN #воркшоп

Как диаграммы последовательностей облегчают работу с API и микросервисами

Как не потеряться в сложном взаимодействии десятков сервисов при работе с микросервисами и открытыми API? Один из самых наглядных инструментов для этого — диаграммы последовательностей. Ниже расскажем, как они помогают командам и приведём конкретные примеры.

1️⃣ Быстрый старт и визуализация логики
Представьте, что ваш новый разработчик спрашивает: «Почему сервис аутентификации выдает токен, а затем сервис каталога товаров вызывает сервис оплаты?» Вместо многостраничной документации вы показываете диаграмму последовательностей — и всё становится прозрачно в считанные минуты.

📍Пример: В ритейл-проекте диаграмма показывает, как пользователь авторизуется, получает данные товаров, оформляет заказ, а система оплаты связывается с банком. Без лишних слов всё на виду.

2️⃣От архитектурной идеи к конкретному коду
Sequence Diagram помогает детализировать цепочку вызовов: что именно «дергается» первым и какие параметры передаются на каждом шаге.

📍Пример: В финтех-проектах видно, что после получения запроса на перевод сервис обработки платежей вызывает службу верификации, а та — внешний сервис антифрода. Любая ошибка или несоответствие форматов сразу бросаются в глаза.

3️⃣ Коммуникация внутри команды
Аналитики, тестировщики, разработчики интерфейсов — у всех свой взгляд на систему. Диаграммы последовательностей работают как универсальный «переводчик».

📍Пример: В проекте по онлайн-образованию тестировщик видит, что после нажатия «Сдать тест» система должна не только записать результат, но и уведомить почтовый сервис о необходимости отправить сертификат. Все знают свой участок работы и не мешают друг другу.

4️⃣ Предупреждение интеграционных ошибок
В сложных интеграциях легко упустить мелочь — например, один сервис ждёт JSON, а другой отдаёт XML. На диаграмме такие расхождения сразу заметны.

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

5️⃣ «Живая» документация
Микросервисы эволюционируют, меняются форматы API, добавляются новые модули. Если держать диаграмму в актуальном состоянии, она станет первым местом, куда смотрят все новые участники проекта.

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

Диаграммы последовательностей — не просто красивые схемы, а мощный инструмент для упрощения интеграции и снижения рисков. Если вы хотите строить их эффективно и корректно, мы приглашаем вас на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования».

Регистрация

#воркшоп #UML

Как аналитику понять сложный процесс «под капотом» системы? 

UML-диаграмма последовательности (Sequence Diagram) — это мощный инструмент в арсенале аналитика, позволяющий визуализировать взаимодействие между объектами во времени внутри одной системы или между разными. Она отображает последовательность сообщений, передаваемых между объектами, и наглядно демонстрирует ход выполнения конкретного сценария.

Что дает аналитику Sequence Diagram?
Диаграмма позволяет быстро понять, как работает система внутри или со смежными, находить узкие места и улучшать бизнес-логику. С ней проще согласовать требования с разработчиками и заказчиками, а также документировать систему для будущего развития.

Что в ней отображается?
🔹 Акторы (Actors): Пользователи или внешние системы, инициирующие сценарий.
🔹 Объекты (Objects): Компоненты системы, участвующие во взаимодействии.
🔹 Линии жизни (Lifelines): Вертикальные линии, представляющие время существования объекта.
🔹 Сообщения (Messages): Стрелки, обозначающие взаимодействие между объектами (вызов методов, отправка данных).
🔹 Активация (Activation): Прямоугольники на линии жизни, показывающие время, когда объект выполняет операции.

Где это пригодится?
■ Например, при моделировании авторизации пользователя диаграмма отображает последовательность действий при вводе логина и пароля, проверке данных и предоставлении доступа.
■ Для оформления заказа в интернет-магазине она визуализирует взаимодействие между корзиной, системой оплаты, складом и службой доставки.
■ При обработке API-запроса диаграмма показывает, как запрос проходит через различные компоненты API и возвращает результат.

Хотите получить практический опыт в применении UML-диаграмм? 

Приглашаем вас на воркшоп: «UML-диаграммы последовательности для аналитика: ликбез и примеры использования»

Регистрация

#воркшоп #uml #sequence