Агрегаты - бойцовский клуб в мире ИТ

Когда в Event Storming доходят до шага определения агрегатов, у людей, не знакомых с DDD, начинается ступор. Приходится разбираться что это такое.

Нам, системным аналитикам, это часто даётся нелегко. Целый ад терминологии.

😂Если обратиться к создателю Event Storming и его книге по методу, то там можно найти забавную рекомендацию: «Не говорите, что такое агрегаты".😂

Ха-ха, Брандолини, очень смешно. Когда я продвигала Event Storming и началась сессия с очень занятыми архитекторами (скептически настроенными), провернуть такое у меня не получилось. 😉😉 Коллеги воспринимали эту подачу как «Зачем ты тратишь наше время?».

На следующих встречах я подготовила описания агрегатов. Но и они не зашли моим программистам и архитекторам. Тогда я предложила вместе разобраться, из чего агрегат состоит: мы коснулись Value Object и Entity, корня агрегата и обсудили, почему это важно с примерами агрегатов.

В книге Влада Хононова «Изучаем DDD» определение всё же есть. Но какое! См. фото. А потом ещё 8 страниц поясняющего текста.

😬😬Господа Хононов и Брандолини знают толк в извращениях.😬😬

Для тренингов я пыталась найти объяснения попроще. Пока что мне более-менее нравятся материалы:

Статья где про агрегаты рассказывается через их антипаттерн

Короткое определение от Мартина Фаулера.

Подробная статья (по стилю похожа на Хононова, но, на мой вкус, удачнее).

Но в целом поиск продолжается. Поэтому интересно, вы уже проходили этап понимания агрегатов в контексте DDD и Event Storming? Поделитесь, как у вас прошло. Может, у вас есть более удачные материалы?

Для завтрашнего же воркшопа, я пересмотрела свою подачу этой информации. Стало определенно проще и доступнее. Поэтому если хотите разобраться жду вас на тренинге Event Storming и System Design.

#EventStorming #СистемныйАнализ #DDD #агрегат

🎉EventStorming — это вечеринка! 🎉

Скажу очевидное: сегодня суббота и нужно отдыхать. Но я только что закончила вести тренинг по EventStorming и всё ещё на этой учебно-рабочей волне. Поэтому хочу поделиться с вами забавным ресурсом по методике.

Это презентация Альберто Брандолини. Того самого, кто продвигает EventStorming. Посмотрите, как она сделана: часть слайдов он рисовал от руки (ну или его дизайнер). Красиво, просто, доступно и смешно.

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

«EventStorming — это вечеринка!»

Так что проводить EventStorming в субботу оказалось очень символично. Всем вечеринок, коллеги! 🎊

😱Шок просто😱 Результатом прошедшего тренинга стало, пусть и с болью и переживаниями, понимание: почему на Event Storming действительно не стоит говорить об агрегатах!

Господин Брандолини прости мои шутки над тобой!

Одновременно очевидно почему нам, системным аналитикам, так хочется их обсуждать и свести к ER-диаграммам. Здесь всё просто: сущности, из которых потенциально может состоять агрегат, для нас понятная и знакомая часть работы А вот бизнес-контексты в понимании Event Storming - нет.

Здесь собаку и зарыли:

1) Часть людей на сессии будет чувствовать себя лишними.
2) Снова уйдём от бизнеса в сторону техники. А это нарушает главную задачу синхронизацию бизнес-экспертов и разработчиков.

И да, потенциальные агрегаты вполне можно выделить без того, чтобы обсуждать, что это такое!

Это отлично вяжется и с моей практикой: мы агрегаты вообще не выявляем.

Только что закончился мой доклад на Стачке, где я предложила рассматривать инициативы и идеи изменений в команде как маленький стартап. 😉😉

А раз это стартап, то можно подглядеть у них фреймворки и идеи. Но с фокусом на ИТ)

🔍 Поиск проблем

Jobs To Be Done — знакомая многим аналитикам техника.
Event Storming — разбор процессов и рутины, но с вовлечением всей команды. Подходит для лидов и менеджеров.
5 Whys — простой инструмент для индивидуальной работы.
* Техника MEAT для прожарки проблем (подсмотрела прямо сегодня у Насти

Работа со страхами

1 Почему изменения часто терпят неудачу — Kotter
2 Роль эмоций в сопротивлении изменениям

📊 Критерии успеха

1) если хотите познакомится с международной практикой оценки ИТ отрасли то есть сложная книга Accelerate: The Science of Lean Software and DevOps
2) то о чем рассказывала, метрики ИТ команд от Atlassian все что можно использовать + ваша фантазия

💡 Продажа идеи

1) Любимое: Лифтовые презентации.
2) Книга Сделано, чтобы прилипать (Chip и Dan Heath). Ближайшее время сделаю обзор.
3) Как правильно выбрать время и язык продажи - кратко об этом говорила, здесь больше

🚀 Внедрение

1) Книга *Accelerate* (там тоже много про практики внедрения).
2) И снова сборник гайдов от Atlassian.


Не бойтесь быть авторами среды вокруг себя, приносить изменения и искать способы их внедрять
А если вы уже:
Успехами можете поделиться под этим постом)

Стачка 2025: ИИ, джуны, воркшопы и отличное комьюнити DevAnalyticsConf

Добралась до дома и начинаю серию постов про Стачку 2025:

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

На Стачке 2025 докладов при ИИ было больше чем кофе (как и на большинстве конференций этого года). Еще прошлым летом на другой конференции был всего 1 доклад, а в этом через один и даже секция аналитиков заканчивалась круглым столом «ИИ vs Аналитик — кто выживет в будущем?»

😬 Что это значит для нас?😬 Если в прошлом году ещё можно было игнорировать ИИ, то теперь это уже профессиональное отставание. Даже если у вас NDA, решения есть и на Стачке об этом тоже говорили.

При этом, честно, ничего по-настоящему нового в докладах об ИИ лично я не услышала. Всё примерно вокруг: «как облегчить рутину с помощью ИИ».

Стачка гостеприимно открыта для разных уровней. 🔥Как участников, так и спикеров. 🔥Это о больном. Помню, когда-то пришла на профконференцию и ушла в ужасе! Я не поняла ничего. Здесь не так.
Стачка открывает двери для начинающих спикеров. Доклад от джуна о болях отсутствия QA, хоть и не принес новых знаний, но погрел атмосферой и напомнил что кто-то сейчас проходит свой особенный путь в анализе.

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

Стачка определённо запомнится большим количеством воркшопов. Это тот редкий случай, когда я разрывалась не между докладами, а между практическими сессиями. Отличился программный комитет родной секции DevAnalyticsConf и аналитики - именно от них было больше всего воркшопов. Представляете, Конкуренция была такой, что не всем желающим спикерам удалось провести свои воркшопы.

🍷 конечно, комьюнити. около 300 спикеров, куча общения, посиделки в барах, афтерпати, 🍷афтерпати после афтерпати🍷
Отдельное спасибо Ольге и Владу если бы я знала, что они приготовили нам столько активностей, не планировала бы вечера заранее💜

🤪Еще Стачка это крутой тайминг🤪 Всё начиналось и заканчивалось строго по расписанию. У меня даже закралась мысль: не из РЖД ли организаторы?

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

Спасибо Стачке за атмосферу и повод выбраться в Питер.

#stopworking #стачка2025

Как я чуть не подралась с участником за 2 балла или Ресурсный баттл

Самым запоминающимся на Стачке для меня стал «Ресурсный баттл» от Владимира Бурмистрова и Станислава Доброхотова

В формате увлекательной настолки нужно было разработать ПО. Задача - побороться за ресурсы в виде человеческих единиц.

Перчинка: в игре были и победители, и проигравшие.

Я достаточно быстро вспомнила, что у меня в близких друзьях бывший коллектор, и это стало основой для стратегии. А ещё азарт и оптимизм. И да, за 2 балла я торговалась как могла (а я вообще-то не умею). В итоге это привело нас с последнего места на второе, что считаю успехом😐

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

Теперь про мысли:

1️⃣ Некоторые люди с самого начала готовы пойти у вас по головам, других для этого нужно прижать. Неприятно, надеюсь, что в реальной работе такое всё же проявляется меньше.

2️⃣ Некоторые ресурсы ценны не сами по себе, а тем, что могут являться предметом торга. Но периодически они просто отправляются в утиль.
И да, иногда мы занимаем именно такие должности, потому что на нас был ресурс. А ещё это неэкологично, но продумано.

3️⃣ Очевидно, что задачи, за которые нам платят, нужно выполнять в первую очередь. Но иногда ресурсов на них может просто не хватить. Есть несколько вариантов, как это разрулить, но ты становишься более зависим от удачи.

4️⃣ В целом, каким бы крутым специалистом ты ни был, действовать приходится вслепую, на основании предположений. Чем больше ты можешь учесть нюансов, тем меньше у тебя неопределённость.

5️⃣ И да, если брать ровно столько сколько тебе нужно, то шансы выполнить задачу быстрее и прогнозируемо как будто выше, но победить нет.

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

Low-code + ИИ лишит работы разработчиков?

Представим, что 🙂‍↕️. Что поменяется в работе аналитика? Где будут заканчиваться границы нашей работы?

Опрос и вопросы, конечно не просто так. Очень хочу услышать ваше мнение на этот счет.

На Стачке случайно попала на рекламный доклад А. Сахарова «Архитектуры будущего: как ускорить разработку и снизить сложность». Он рассказывал об их low-code экосистемы ПО для разработки ПО. Давно пора!
Я зацепилась за следующий тезис: по заверению спикера, теперь не нужна команда программистов достаточно одного аналитика под присмотром архитектора и одного программиста. Когда все плохо, можно взять двух аналитиков!

То есть фокус смещается: не один аналитик на нескольких разработчиков, а один разработчик на аналитика + low-code.

Господа аналитики, этой ли революции мы все ждали ❌! Но готовы ли мы?

Тем кто работает с подобными системами предлагаю поделиться впечатлениями. А остальным поразмышлять на вопросы в начале поста.

Своими мыслями поделюсь завтра утром.

🤡 Программисты не нужны, да здравствуют аналитики! 🤡

Во вчерашнем посте я предложила пофантазировать: Low-code + ИИ используется повсеместно, а аналитиков нужно больше, чем разработчиков.

Мой взгляд:
Вот теперь аналитики заживут! Но если где-то густо, придут оттуда, где стало пусто. Часть разработчиков придёт в аналитику. Придётся постараться, чтобы конкурировать с ними.

Кроме того, Нам, аналитикам, придётся ещё больше думать 🛑 в терминах моделей, ограничений и оркестрации процессов. И учиться этому будет сложнее: low-code не убирает трудности разработки, он их маскирует.

С другой стороны, путь «требования → архитектура → код» станет нагляднее и понятнее аналитикам. Мы перестанем быть посредниками и сможем стать полноценными исполнителями. Вот он ответ на мой старый дискуссионный пост!

Разработка в целом станет доступнее. Помните, сколько негатива от специалистов было, когда появлялись инструменты типа Tilda?! А потом домохозяйки и студенты отняли работу у них работу.

Впрочем, 💃сложно прогнозировать будущее💃. Здесь вспоминается 2014 год: конференция по искусственному интеллекту, ученые мужья обсуждают, что deep learning не имеет будущего, потому что человечество не готово терпеть решения «чёрного ящика». Ха-ха-ха.

А вот что мне по-прежнему ясно:

🤬Грустное🤬 мир не даст нам отдохнуть, развиваться нужно всегда.

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

#lowcode #айтиюмор #жизньаналитика

💸Сколько стоит выступить на конференции?💸

Дано:
мой доклад взяли на Стачку в Питере.

Организаторы предоставили:
💵1 VIP-билет на конференцию (обед включён)
💵1 стандартный билет
💵 скидку на проживание в отеле

Что оплачиваю сама:
Самолет Самара —> Питер —> Самара: 8 500

Трансфер в и из аэропорта: 6800

Отель на 5 ночей: 22 000 с завтраками на двоих (кэшбэк 2000 вернётся)

☕️ Бары для нетворкинга: 4200

Шляпка для выступления: 8400 (только мужу не говорите 🙈)

Итого: 47 900 рублей

Ага, быть спикером не только почётно, но ещё и дорого.

Не скажу, что не скучаю по временам, когда МНЕ за выступления ещё и платили.

Зато радуют отличная обратная связь
и то, что был повод купить новую шляпку.

Ваши мысли: дорого или норм? Стоит оно того?

16 часов жизни ради 40 минутного доклада.

Стоило ли? Разбираю плюсы минусы и находки доклада "Как внедрять изменения, если тебе никто ничего не должен"

Было хорошо:

1️⃣ Людей было больше, чем в среднем по секции. Заслуга названия, оно было выбрано супер удачно.

2️⃣ При подготовке хотела дать всего и побольше: практик, фреймворков, технологий. Помог программный комитет в лице Ольги. Решила оставить только личный опыт. Это сработало!

3️⃣ Каждое выступление я очень переживаю. Наговоренная основа давала возможность не затупить от волнения.

4️⃣ Не успевала красиво оформить презентацию. Поэтому просто разрешила себе выйти с суперпростой PDF. Это дало достаточно времени на базовую подготовку.

5️⃣ Ставка на страхи. Изначально основной фишкой, о которой хотела рассказать, было использование таск-трекеров. Но в процессе подготовки стало понятно, что есть цензура. Это дало повод переосмыслить, зачем нужна вся работа с трекерами. А нужна она для отработки страхов и возражений. И это очень откликнулось!

7️⃣ Красивая одежда придавала уверенности, а новая шляпка радости что появился повод ее купить. И только муж знает сколько сил стоило уместить все мои образы в ручную кладь.

Было плохо:

1️⃣ Я так переволновалась, что не могла половину фишек выступлений я успешно забыла. Получилось много «бормотать» и меньше живого общения.

2️⃣ Когда начала прогонять презентацию, еле укладывалась в 55 минут. В итоге уложилась, но очень рисковала.

3️⃣ Доклад 40 минут! Представляете, сколько нужно времени, чтобы его хоть раз прогнать? У меня заняло 8 часов только прогонов!

А вся подготовка: 16 часов. Поэтому спасибо всем кто был и слушал.

Для тех кто не был - презентация во вложении, полезные материалы здесь.

И предлагаю поделиться, что вы никогда не простите спикеру?

👀 - воду
💩- саморекламу
🙈 - перегруженные слайды
😐 - бубнёж
😱 - неактуальную тему
Свое в комментарии.

Новый титул для аналитиков "Архитектор смыслов". Когда архитектором быть хочется, но кодить не умеем.

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

Вообще по описанию очень похоже на продакта. А по красивому названию (звучит лирично!) на попытку переосмысления своей актуальности и поиска места. И в этом я их очень понимаю.

Сказала я с ролью загадочного фича-овнера 😂.

Но согласитесь: архитектор смыслов звучит лучше!

Примерили бы на себя такую роль?

😐 Уже, по сути, архитектор смыслов
😱 Хватает своих обязанностей
👀 Если платят как архитектору, то да

Когда индексы БД вредят: мой практический опыт и исследование основ

Рассказываю:

Мы столкнулись с проблемой падения производительности БД при работе с группами, содержащими большое количество объектов. Исследовать проблему поручили отделу RnI (как же замечательно, когда такой отдел есть в команде). Как результат, целый час они напоминали мне основы и рассказывали про бинарные деревья, B-tree и хэш-индексацию. Честно, до такого уровня работы БД я ранее не погружалась

Стали очевидными все недостатки индексации:
👀 самый оптимальный способ записи данных при больших объёмах делает БД бесполезной для их выдачи. То есть лишает нас одной из двух основных функций БД: доступа к данным.
👀 На помощь приходит индексация, позволяющая оптимально искать данные, но тогда страдает производительность при создании, модификации и особенно удалении данных.

Рулят в итоге компромиссы

Здесь мне уже захотелось копнуть глубже вне работы.

И какое же было моё удивление, когда я обнаружила, что вся глава 3.1 знаменитого «Кабанчика» Клеппмана посвящена именно этой теме. В целом там хорошо объясняются структуры SS и B-tree. А вот хэш-индексацию и LSM-tree из Клеппмана мне уложить в голове не удалось.

Более подробное и наглядное объяснение, особенно с точки зрения влияния структур на работу БД, я нашла у Алекса Петрова в «Распределённые данные». Она стоит безумных денег в бумаге, что смешно, учитывая, что первая ссылка в поиске ведёт на бесплатное скачивание. Пока прочитала только одну главу по диагонали, но уже вижу, что материала много и глубоко. Но для уровня аналитика это, пожалуй, излишне.

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

Ещё один отличный инструмент, уже визуализатор хэш-таблиц Здесь можно посмотреть поведение при вставке, поиске и удалении - самое ценное для пониманией БД с таким способом индексирования.

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

Индексация в большинстве реляционных и NoSQL БД строится на одних и тех же структурах.

Господа аналитики, а вам знания о структурах БД на таком уровне помогают в работе?

👍 - да, постоянно (поделитесь в комментариях как), 👎🏼 - нет,
😐 - банальщина, как можно было это не знать?
😱 - только сейчас от тебя услышал(а).

#структурыданныхБД #СистемныйАнализ #btree

Мой чек-лист, как перевести «желания» в решение и аргументированно сказать «нет»

Периодически в моей работе аналитика от меня ждут, что я «защищу команду от пожеланий» заказчиков.

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

Мой коллега говорит, что у меня очень здорово получается с таким работать, и он подглядывает у меня, как это делать. Это потому что давно отработала следующий шаблон:

1️⃣ Начинаю всегда с детального перефразирования того, что хочет от нас заказчик.
2️⃣ Затем результаты анализа его пожелания с технической точки зрения, анализа конкурентов и в соответствии со стандартами. Да я не просто так часто пишу про RFC и иногда о сертификации;
3️⃣ Запрашиваю непонятный деталей. Они еще пожалеют что со мной связались)
4️⃣ Краткого, но понятного и бизнесу, и разработчикам плана по реализации.
5️⃣ Обязательно привожу риски реализации.
6️⃣ Оценки сроков всей реализации: от обработки пожелания до выпуска релиза.
7️⃣ Рекомендации а стоит ли вообще брать в работу.
8️⃣ Текущие альтернативы решения.
9️⃣ Максимально понятные итоги.

Не rocket science, но крайне эффективно.

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

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

А как у вас?
Для реакций:
😐 - слишком бюрократично 🔥 - Аналитики сила 🙈 -лучше бы код писали