Жертвы Шторма

Есть у технологий ранние последователи, есть и ранние жертвы. У меня такое случилось с Event Storming.

2017 год, зима, летим к заказчику делать интеграцию на микросервисах. Тогда со всех сторон кричали, что MSA - это новый ESB высшая ступень эволюции, DDD познавали по Вернону, а об Event Storming’е перешептывались в углах избранные. Вот и мы наслушались шепотов.

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

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

На выходе осталась некоторая недосказанность:

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

- Что нам теперь с этим делать?

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

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

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

• Екатерина Пантелей - системный аналитик

• Ольга Бугаева - руководитель продукта

• Евгений Асламов - архитектор

Приходите, сэкономите на ватманах.

📆 13 мая, 18:00 мск, рега тут

Профит Шторма

Справедливости ради, профита Event Storming принес больше, чем боли и страданий. Чем помогал лично мне:

• быстро вкатиться в новый проект или предметку

• познакомиться и наладить контакты со стейкхолдерами и командой

• выявить конфликты и разночтения между бизнес подразделениями - внезапно, представители бизнеса часто имеют разное представление о реальных процессах

• разобраться в работе системы, когда совсем нет документации

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

🛠 Если хотите пощупать технику ручками, чтобы использовать на бою, приходите в субботу 17 мая, рега тут.

😱 Если хочется просто поговорить о проблемах Event Storming, то приходите сегодня в 18:00 мск на вебинар.

Как же AI может заменить аналитика, если нужно работать с заказчиком, который не знает, чего хочет? Да вот так.

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

Как должно работать:

1. Даете доступ к своей базе знаний

2. Подрубаете сервис ко всем каналам связи с заказчиком

3. На основе встреч и переписки сервис генерит требования и проверяет их на полноту и противоречия. Если что-то не так - сигнализирует об этом

4. Формирует доки: BRD, C4, что-то еще

5. Создает таски и трекает корректность реализации - тут я не понял, как

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

Да, сомнительно с точки зрения безопасности. Да, больше заточено под типовую разработку и внедрение. Уверен, работает раз в 10 хуже, чем обещают. И все равно нужен будет живой эксперт.

Но все это неважно. Пройдет 3-5 лет, ребята дотюнят модели, выпустят on-premise версию, а корпораты начнут экспериментировать со своими ассистентами по требованиям. И вот зачем толпа аналитиков продакту, проджекту или техсейлзу с таким инструментом - большой вопрос.

Кстати, Александра подогнала расшифровку своего доклада. Очень советую почитать: https://bryzgalova.ru/effectiveness

А Катя собрала классную подборку шаблонов для Event Storming

Подборка шаблонов для EventStorming
Если вы планируете сессию или просто хотите разобраться в подходе — вот несколько полезных шаблонов и инструментов:

🔶 Unidraw — инструмент не плохой, но после внимательного изучения шаблона у меня остались вопросы. Интересно, кто пользовался — как вам?
🔶 Miro — классика. Именно с неё я начинала и до сих пор люблю за стабильность и адаптивность.
🔶 Excalidraw — скорее пример, чем шаблон. Но для старта может быть очень полезен — просто, быстро, понятно.
🔶 Figma — забавно, как чётко расписаны первые 4 шага. Но вот когда речь доходит до Process Modeling — тишина. Хотя в целом шаблон зачетный.
🔶 GitHub — настоящая сокровищница. Много полезностей в одном месте, и видно, что автор явно читал ту самую книгу по EventStorming. Советую заглянуть!

💾 Сохраняйте в закладки — даже если сейчас ES вам не нужен, уверена, тренды от международных коллег до нас точно дойдут. А шаблоны пригодятся 😉

Свой шаблон тоже сделала, ими поделюсь немного позже отдельным постом для 3 инструментов)

#eventstorming #шаблоны #аналитика #системныйаналитик #itинструменты

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

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

Начинаю марафон конференций

Analyst Days. Основы криптографии для аналитика - интерактивный доклад / воркшоп, чтобы познакомиться с основами, на которых строятся защищенные протоколы, подписи, сертификаты и прочие слова из лексикона безопасников.

Codefest. CAP-теорема в теории и на практике - доклад-размышление о том, почему ACID, CAP и прочие академизмы куда важнее изучения очередных паттернов и технологий. Навеяно постом.

ЛАФ. Как брокеры не гарантируют доставку сообщений - воркшоп, чтобы разобраться в природе гарантий доставки, и существуют ли они вообще. Развитие идей постов: раз и два.

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

#конференции

#конференции

В субботу провел воркшоп на Analyst Days. Познавали азы криптографии и переизобретали TLS. Участникам спасибо за работу, вроде тема зашла. Мб сделаем продолжение.

Немного ссылочек для закрепления и дальнейшего погружения, как обещал:

• Основные понятия криптографии

• Глубокая статья про шифрование, TLS, сертификаты и вообще все необходимое

• PKI - инфраструктура открытых ключей

При желании закидывайте отзывы, камни и вопросы в комменты.

🐰 Самый простой способ понять работу RabbitMQ 🐰

В сообществе аналитиков довольно известен этот визуализатор работы Kafka. Я узнала о нём из блога Системный сдвиг, а затем оценила классную рекомендацию по работе с ним от Yet Another Analyst.

Но поскольку я провожу уроки именно по RabbitMQ, стало интересно: А есть ли похожая визуализация RabbitMQ — для тех, хочет быстро просто “увидеть”, как оно работает?

Оказывается, есть! И даже несколько:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer

Я советую первый. Как с ним работать? Часть 1.


🚦 0. Добавьте producer и queue. Попробуйте соединить их напрямую. Добавьте exchange, соедините всё по схеме: producer → exchange → queue. Что то должно начинать получаться, потому что еxchange — обязательный этап маршрута в RabbitMQ. У связи exchange и queue появился binding — ключевой элемент понимания маршрутизации. Добавьте consumer. Попробуйте соединить consumer с exchange. Что-то снова будет не хватать. Но правильный порядок близок: producer → exchange → queue → consumer.

💥 1. Выберите для exchange тип fanout. Создайте еще 2 очереди и 2 потребителя и привяжите их к exchange. Отправьте сообщение без routing key. Куда оно ушло? Установите разные binding key и отправьте сообщения со случайными с routing key. Что происходит? Удалите один binding. Получает ли эта очередь сообщение? Здесь можно еще поэкспериментировать с ключами, Но основную особенность обменника типа fanout вы уже должны нащупать.

Это первые важные шаги для знакомства с базовой схемой кролика и типом обменника Fanout. Сохраняйте, пробуйте.

В следующем посте расскажу про упражнения для схем с Direct и Topic exchange — не пропустите!

#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst

#конференции

Други, поделитесь мнением. Думаем над форматом следующей NextConf:

Классический формат - стандартная онлайн конфа в выходной день с 2-3 потоками.

Режим подлодки - каждый будний день в течение недели проходит активность утром и вечером: в 10 мск доклад, в 18 мск воркшоп или что-то интерактивное.

Ткните в опросик ниже, плз.

#оффтоп

2025 год, консерваторы и постмодернисты продолжают холиварить на тему Системный Анализ vs Системная Аналитика

Тем временем во всех ТЗ страны: интересанты, подписанты, согласованты.

Открытие вечера: заинтересанты.

А какие производные от серванта и космодесанта знаете вы?

#конференции

Вернулся с ЛАФ, где разбирались, почему брокеры нам ничего не гарантируют. Держите ссылочки, кому было мало:

• О гарантиях доставки и порядка сообщений

• Детальный разбор реализации Transactional Outbox

• Хардкорно про устройство брокеров

• Задача двух генералов

#AI #анализ

Классная статья об использовании AI сисаналитиком. Показывает полный цикл работы над задачей от бизнес-хотелки до формирования конкретных спек.

Никаких чудес, осознанное применение AI для автоматизации рутины и в роли копилота. Очередной раз подтверждаются тезисы:

- стоит передавать AI то, что хорошо умеешь делать сам

- валидировать результат все равно нужно

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

Фактически, имеем IDE для аналитика, которая помогает сэкономить время на механической работе. Можно работать без нее, как и кодить без IDE - реально, но зачем?

А какую рутину уже автоматизировали вы?

#AI #мышление

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

Кажется, что для количественных исследований в b2c вариант отличный - быстрее и дешевле. Но есть нюанс.

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

Я когда-то писал, что многие техники и фреймворки нужны не столько для получения формального результата, сколько для активации мыслительных процессов. Фактически, это инструменты мышления, которые важно не растерять в процессе автоматизации. Ну или найти новые.

Репликация и партиционирование

Лайтовое введение в репликацию и партиционирование данных в БД для тех, кому лень читать кабанчика. Полезно вдумчиво изучить с точки зрения проектирования распределенных систем в целом, даже если вы ВНЕЗАПНО сами не разрабатываете хранилища.

Репликация
• Часть 1 - синк/асинк репликации, лидер-фоловер
• Часть 2 - проблемы чтения и консистентности, разрешение конфликтов, мультилидеры
• Часть 3 - схемы без лидеров

Партиционирование - проблемы, использование ключей, ребалансировка

#архитектура

Тревожитесь? Не тревожьтесь, Денис принес кусочек спокойствия на ночь. А я попробую завтра разогнать безмятежность.

в общем двачую, что на интервале 10 лет системные аналитики сметут нахер архитекторов (по крайней мере для условно безответственных программных систем автоматизации бизнеса, а точнее — сбыта — информационный учёт, элементарная обработка, приём заказов, маршрутизация, логистика, аналитика)

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

как это станет возможно? несмотря на неумение архитекторов объяснять, всё равно логика архитектурного проектирования становится всё более и более прозрачной и понятной для воспроизводства.

первый гвоздь в крышку гроба дало движение Systems Design, которое показало, что можно проектировать программные системы без Archimate, UML и прочих умных слов.

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

Три новости для любителей брокеров

• В воскресенье в 18:00 мск буду вещать, какие гарантии брокеры нам не дают. Как на ЛАФе, только в режиме говорящей головы.

• Нашел видос про гарантии в YDB Topics. Штука интересная, особенно транзакционность на уровне топики-таблицы. Но как я понял, это работает только в случае, когда используем YDB и как базу, и как брокер. Но тогда мне не совсем понятна общая архитектура системы. Может позовем их пообщаться?

• Мы пересобрали курс по брокерам с прицелом на задачи аналитиков, убрали совсем хардкор и добавили полноценный блок про кролика. Теперь он состоит из трех модулей: базовые понятия и паттерны брокеров, RabbitMQ, Apache Kafka. Отдельно поговорим о постановке задач для разработки.

#брокеры