Находим скрытую бизнес-логику через Event Storming
🔔 Зачем это нужно?
В любой компании есть формально описанные процессы, в которых на практике существуют неучтённые согласования, ручные действия и «обходные» решения. Именно эти скрытые нюансы повышают затраты, задерживают релизы и снижают удовлетворённость клиентов. Когда процесс не задокументирован, вопросы вроде «Почему это произошло?» или «Кто несёт ответственность?» всплывают уже в критический момент.
Что даёт Event Storming?
— Это командный подход к анализу процессов. Мы буквально «высыпаем» все события на стикеры — пусть каждый участник озвучит свою часть работы
— В итоге, все видят «живую» последовательность шагов и начинают согласовывать, что на самом деле происходит в компании
— Уже за пару часов можно найти провалы и лишние действия: если по цепочке непонятно, куда дальше идёт инициатива, значит тут узкое место
Какие зоны оптимизации обычно всплывают?
— Сценарии, про которые все забыли: «Что, если клиент хочет оплатить позже?», «А если доставка срывается?», «Кто возмещает ущерб?»
— Дублирующиеся действия (например, несколько сотрудников параллельно проверяют одинаковые документы)
— Ручные шаги, которые можно легко автоматизировать
— Неочевидные проверки, о которых не вспоминали на этапе формального описания (например, дополнительный контроль на складе)
🔍 Как понять, где мы теряем ценность?
— Посмотрите, какие события вносят наибольший вклад в достижение результата (взаимодействие с клиентом, выпуск нового продукта)
— Всё, что косвенно поддерживает процесс, но при этом отнимает много усилий, следует оптимизировать
— Если какое-то событие затягивает сроки (много согласующих лиц), именно оно чаще всего вызывает недовольство пользователей
За счёт чёткого визуального формата Event Storming быстро раскрывает «серые зоны» бизнес-процесса. Команда видит, где теряет время или несёт лишние расходы, и формирует план улучшений. А главное — все участники синхронизированы: больше нет «скрытых правил», которые внезапно всплывают при запуске проекта.
Если хотите освоить эту практику в режиме реального времени, приходите на воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов».
Регистрация
#воркшоп@systems_education #event_storming@systems_education
🔔 Зачем это нужно?
В любой компании есть формально описанные процессы, в которых на практике существуют неучтённые согласования, ручные действия и «обходные» решения. Именно эти скрытые нюансы повышают затраты, задерживают релизы и снижают удовлетворённость клиентов. Когда процесс не задокументирован, вопросы вроде «Почему это произошло?» или «Кто несёт ответственность?» всплывают уже в критический момент.
Что даёт Event Storming?
— Это командный подход к анализу процессов. Мы буквально «высыпаем» все события на стикеры — пусть каждый участник озвучит свою часть работы
— В итоге, все видят «живую» последовательность шагов и начинают согласовывать, что на самом деле происходит в компании
— Уже за пару часов можно найти провалы и лишние действия: если по цепочке непонятно, куда дальше идёт инициатива, значит тут узкое место
Какие зоны оптимизации обычно всплывают?
— Сценарии, про которые все забыли: «Что, если клиент хочет оплатить позже?», «А если доставка срывается?», «Кто возмещает ущерб?»
— Дублирующиеся действия (например, несколько сотрудников параллельно проверяют одинаковые документы)
— Ручные шаги, которые можно легко автоматизировать
— Неочевидные проверки, о которых не вспоминали на этапе формального описания (например, дополнительный контроль на складе)
🔍 Как понять, где мы теряем ценность?
— Посмотрите, какие события вносят наибольший вклад в достижение результата (взаимодействие с клиентом, выпуск нового продукта)
— Всё, что косвенно поддерживает процесс, но при этом отнимает много усилий, следует оптимизировать
— Если какое-то событие затягивает сроки (много согласующих лиц), именно оно чаще всего вызывает недовольство пользователей
За счёт чёткого визуального формата Event Storming быстро раскрывает «серые зоны» бизнес-процесса. Команда видит, где теряет время или несёт лишние расходы, и формирует план улучшений. А главное — все участники синхронизированы: больше нет «скрытых правил», которые внезапно всплывают при запуске проекта.
Если хотите освоить эту практику в режиме реального времени, приходите на воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов».
Регистрация
#воркшоп@systems_education #event_storming@systems_education
❤3
Воркшоп «Проектирование и реализация очередей в брокерах RabbitMQ и Apache Kafka»
На воркшопе вы развернёте в бесплатных облачных средах свои инстансы и решите на них задачу публикации и потребления сообщений разными сервисами, написанными собственноручно на Python в Google Colab.
🔹Цель обучения
— Познакомиться c теорией по RabbitMQ и Apache Kafka
— Научиться проектировать потоковый конвейер обработки данных (data pipeline)
🔹Когда старт?
17 мая (сб)
🔹Что получат участники:
— 2 занятия по 4 часа
— Вы узнаете теорию по RabbitMQ и Apache Kafka
— Спроектируете потоковый конвейер обработки данных (data pipeline)
Регистрация
#воркшоп@systems_education #RabbitMQ@systems_education #ApacheKafka@systems_education
На воркшопе вы развернёте в бесплатных облачных средах свои инстансы и решите на них задачу публикации и потребления сообщений разными сервисами, написанными собственноручно на Python в Google Colab.
🔹Цель обучения
— Познакомиться c теорией по RabbitMQ и Apache Kafka
— Научиться проектировать потоковый конвейер обработки данных (data pipeline)
🔹Когда старт?
17 мая (сб)
🔹Что получат участники:
— 2 занятия по 4 часа
— Вы узнаете теорию по RabbitMQ и Apache Kafka
— Спроектируете потоковый конвейер обработки данных (data pipeline)
Регистрация
#воркшоп@systems_education #RabbitMQ@systems_education #ApacheKafka@systems_education
Герои комикса фулстек-аналитик Иван и ИИ-бот Марика помогают исследовать словарь терминов системного аналитика.
СЕГОДНЯШНЯЯ ТЕМА — ТРЕБОВАНИЯ. Выдержки из словаря:
👇 Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. На основании ваших обсуждений мы дополним глоссарий, так наша подборка станет ещё полезнее.
СЕГОДНЯШНЯЯ ТЕМА — ТРЕБОВАНИЯ. Выдержки из словаря:
Спецификация требований (SRS – Software Requirements Specification)
Определение: Формализованный документ, описывающий функциональные и нефункциональные аспекты компьютерных программ, используемый для согласования между стейкхолдерами и командой разработки.
Официальные термины: «Software Requirements Specification (SRS)»
Разговорные: «спека», «требования в доке»
Функциональные требования (Functional Requirements)
Определение: Описывают, что именно должна делать система (функции, процессы, реакции на действия пользователя), формирующие основу предметной логики.
Официальные термины: «Functional Requirements», «FR»
Разговорные: «ФТ»
Нефункциональные требования (Non-functional Requirements – NFR)
Определение: Характеристики системы, не описывающие конкретный функционал (производительность, безопасность, масштабируемость), но влияющие на её качество и архитектуру.
Официальные термины: «Non-functional Requirements (NFR)», «Атрибуты качества»
Разговорные: «НФТ»
👇 Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. На основании ваших обсуждений мы дополним глоссарий, так наша подборка станет ещё полезнее.
👍9😁7🔥3❤2
Кто должен писать OpenAPI: аналитик или разработчик?
Разбираемся, где заканчиваются требования и начинаются спецификации
Если вы работаете с API, этот вопрос возникал не раз!
Аналитик, который формулирует требования? Разработчик, который реализует эндпоинт? Или архитектор, который проектирует взаимодействие компонентов?
Разберём роли каждого
🦸♂️Роль аналитика: зачем, что, кому и почему
Что именно делает аналитик:
— Определяет сценарии использования API (например: «получить список заказов клиента по ID»)
— Описывает структуру и логику данных, включая ограничения и валидации
— Согласует API с внешними/внутренними потребителями
— Пишет черновой draft OpenAPI, если уровень зрелости команды это позволяет
🥷 Роль разработчика: реализация и точка правды
Разработчик отвечает за то, чтобы API было реализуемо и работало как надо. Даже идеальная спецификация бесполезна, если код делает что-то другое.
Разработчик:
— Уточняет детали реализации, которые могли быть упущены в требованиях
— Сопоставляет спецификацию с реальным кодом
— Поддерживает актуальность OpenAPI, особенно если используется code-first подход (например, с Springdoc, Swagger Annotations и пр.)
Если спецификацию пишет аналитик — разработчик её валидирует. Если наоборот — аналитик проверяет соответствие требованиям.
Хотите научиться работать с OpenAPI и AsyncAPI на практике?
На воркшопе «Проектирование сложных API: OpenAPI + AsyncAPI» всего за 7 часов вы:
— Научитесь читать и писать спецификации OpenAPI и AsyncAPI
— Разберётесь, как описывать синхронные и асинхронные интеграции
Подробнее
#воркшоп@systems_education
Разбираемся, где заканчиваются требования и начинаются спецификации
Если вы работаете с API, этот вопрос возникал не раз!
Кто должен писать OpenAPI?
Аналитик, который формулирует требования? Разработчик, который реализует эндпоинт? Или архитектор, который проектирует взаимодействие компонентов?
Разберём роли каждого
🦸♂️Роль аналитика: зачем, что, кому и почему
Что именно делает аналитик:
— Определяет сценарии использования API (например: «получить список заказов клиента по ID»)
— Описывает структуру и логику данных, включая ограничения и валидации
— Согласует API с внешними/внутренними потребителями
— Пишет черновой draft OpenAPI, если уровень зрелости команды это позволяет
🥷 Роль разработчика: реализация и точка правды
Разработчик отвечает за то, чтобы API было реализуемо и работало как надо. Даже идеальная спецификация бесполезна, если код делает что-то другое.
Разработчик:
— Уточняет детали реализации, которые могли быть упущены в требованиях
— Сопоставляет спецификацию с реальным кодом
— Поддерживает актуальность OpenAPI, особенно если используется code-first подход (например, с Springdoc, Swagger Annotations и пр.)
Если спецификацию пишет аналитик — разработчик её валидирует. Если наоборот — аналитик проверяет соответствие требованиям.
Хотите научиться работать с OpenAPI и AsyncAPI на практике?
На воркшопе «Проектирование сложных API: OpenAPI + AsyncAPI» всего за 7 часов вы:
— Научитесь читать и писать спецификации OpenAPI и AsyncAPI
— Разберётесь, как описывать синхронные и асинхронные интеграции
Подробнее
#воркшоп@systems_education
❤3👍3
Типы защитных мер в информационной безопасности: как выстроить комплексную защиту, которая действительно работает
Информационная безопасность — это не только технические средства, но и стратегия. Эффективная защита строится на комплексном подходе, где разные типы мер работают согласованно: предупреждают, обнаруживают, минимизируют ущерб и помогают быстро восстановиться после инцидентов.
Ниже рассказали про пять ключевых типов защитных мер
🔐 Превентивные меры (Preventive): минимизируем риск до инцидента
Цель — не допустить реализацию угрозы. Это фундамент безопасности.
Ключевые вопросы:
— Какие угрозы наиболее вероятны в вашей системе?
— Как их можно устранить до возникновения?
— Что можно сделать, чтобы ошибка пользователя или случайное действие не привели к катастрофе?
🔍 Детективные меры (Detective): своевременно замечаем угрозу
Цель — обнаружить инцидент, зафиксировать его и собрать данные для анализа и реагирования.
Ключевые вопросы:
— Какие события нужно логировать и хранить?
— Какие данные критичны для расследования инцидентов?
— Как защитить логи от компрометации?
— Как обеспечить автоматическое оповещение и корректную визуализацию инцидентов?
🚨 Восстановительные меры (Recovery): быстро возвращаемся в строй
Цель — минимизировать последствия и оперативно вернуть систему в рабочее состояние.
Ключевые вопросы:
— Какие процессы критичны и должны быть восстановлены в первую очередь?
— Сколько времени система может быть недоступна без серьёзных последствий?
— Какие данные нельзя потерять ни при каких обстоятельствах?
— Какие процедуры восстановления нужно регулярно тестировать?
🖋 Корректирующие меры (Corrective): устраняем причины и учимся на ошибках
Цель — не просто «потушить пожар», а устранить источник проблемы и предотвратить повторение.
Ключевые вопросы:
— Как выявить и нейтрализовать первопричину инцидента?
— Как изменить процессы, чтобы ситуация не повторилась?
— Как не нарушить бизнес-функции при реализации мер?
— Какие изменения стоит зафиксировать документально и процедурно?
🔋 Компенсирующие меры (Compensating): когда основная защита недоступна
Цель — обеспечить защиту там, где по каким-то причинам невозможно реализовать основной механизм.
Ключевые вопросы:
— Какие альтернативные меры возможны в текущих условиях?
— Какие компромиссы допустимы без потери безопасности?
— Какие условия должны быть соблюдены, чтобы компенсирующая мера была признана достаточной?
Примеры всех типов мер показали на карточках ⬆️
— Не породят ли эти меры новые векторы атаки?
Каждый тип мер — часть этой архитектуры, и только в совокупности они дают реальный эффект: от профилактики до восстановления. На воркшопе «Основы разработки требований к информационной безопасности ИТ-систем» вы получите универсальный фундамент понимания принципов информационной безопасности, сформируете умения, применимые для разных категорий систем в разных юрисдикциях и улучшите качество проектной документации и ТЗ, в том числе на проектах интеграции.
Регистрация
#воркшоп@systems_education #безопасность@systems_education
Информационная безопасность — это не только технические средства, но и стратегия. Эффективная защита строится на комплексном подходе, где разные типы мер работают согласованно: предупреждают, обнаруживают, минимизируют ущерб и помогают быстро восстановиться после инцидентов.
Ниже рассказали про пять ключевых типов защитных мер
🔐 Превентивные меры (Preventive): минимизируем риск до инцидента
Цель — не допустить реализацию угрозы. Это фундамент безопасности.
Ключевые вопросы:
— Какие угрозы наиболее вероятны в вашей системе?
— Как их можно устранить до возникновения?
— Что можно сделать, чтобы ошибка пользователя или случайное действие не привели к катастрофе?
🔍 Детективные меры (Detective): своевременно замечаем угрозу
Цель — обнаружить инцидент, зафиксировать его и собрать данные для анализа и реагирования.
Ключевые вопросы:
— Какие события нужно логировать и хранить?
— Какие данные критичны для расследования инцидентов?
— Как защитить логи от компрометации?
— Как обеспечить автоматическое оповещение и корректную визуализацию инцидентов?
🚨 Восстановительные меры (Recovery): быстро возвращаемся в строй
Цель — минимизировать последствия и оперативно вернуть систему в рабочее состояние.
Ключевые вопросы:
— Какие процессы критичны и должны быть восстановлены в первую очередь?
— Сколько времени система может быть недоступна без серьёзных последствий?
— Какие данные нельзя потерять ни при каких обстоятельствах?
— Какие процедуры восстановления нужно регулярно тестировать?
🖋 Корректирующие меры (Corrective): устраняем причины и учимся на ошибках
Цель — не просто «потушить пожар», а устранить источник проблемы и предотвратить повторение.
Ключевые вопросы:
— Как выявить и нейтрализовать первопричину инцидента?
— Как изменить процессы, чтобы ситуация не повторилась?
— Как не нарушить бизнес-функции при реализации мер?
— Какие изменения стоит зафиксировать документально и процедурно?
🔋 Компенсирующие меры (Compensating): когда основная защита недоступна
Цель — обеспечить защиту там, где по каким-то причинам невозможно реализовать основной механизм.
Ключевые вопросы:
— Какие альтернативные меры возможны в текущих условиях?
— Какие компромиссы допустимы без потери безопасности?
— Какие условия должны быть соблюдены, чтобы компенсирующая мера была признана достаточной?
Примеры всех типов мер показали на карточках ⬆️
— Не породят ли эти меры новые векторы атаки?
Каждый тип мер — часть этой архитектуры, и только в совокупности они дают реальный эффект: от профилактики до восстановления. На воркшопе «Основы разработки требований к информационной безопасности ИТ-систем» вы получите универсальный фундамент понимания принципов информационной безопасности, сформируете умения, применимые для разных категорий систем в разных юрисдикциях и улучшите качество проектной документации и ТЗ, в том числе на проектах интеграции.
Регистрация
#воркшоп@systems_education #безопасность@systems_education
❤5🔥2👍1