Привет! Если вы меня потеряли — я ушел в творческий отпуск :) Но совсем отключиться не получилось — буквально в чистом поле меня поймали организаторы подкаста FlowLive и записали со мной выпуск про создание образовательных продуктов для аналитиков: https://www.youtube.com/watch?v=wGGwncJSMcM (выходит завтра, поставьте колокольчик, чтобы не пропустить!). Поговорили про то, какие темы востребованы, и что главное в учебном курсе. Enjoy! Ну и жду вопросов и обсуждений 🙏🏻

Если бы я попал на необитаемый остров, и мог бы взять с собой только одну книгу по системному анализу и разработке требований, я бы взял Руководство по написанию требований от INCOSE (Международный совет по системной инженерии). Что удивительно, это руководство есть в переводе на русский язык, я даже немного участвовал в его создании (настолько немного, что я не упомянут среди команды переводчиков и рецензентов).

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

Разделение на потребности и требования мне представляется очень важным. Потребности (и ожидания) — это те самые desiderata, о которых говорит Пол Ральф. Это ещё не требования. Требование — это обязательство, принятое каким-то субъектом (организацией, командой или человеком) по реализации системы, выполняющей определенную функцию или обладающей определенным качеством. Потребность может транслироваться в несколько требований, и одно требование может закрывать несколько потребностей. Требования не могут быть противоречивыми, а потребности и ожидания — постоянно. Когда мы говорим про согласование требований разных стейкхолдеров — на самом деле мы говорим про согласование ожиданий и потребностей. Руководство говорит, что требования происходят из потребностей путем формальных преобразований, в этом и есть инженерный подход. При этом сами потребности не берутся из ниоткуда и не выдумываются, а тоже, в свою очередь, являются результатом формального преобразования некоторых концепций. Концепции в данном случае -- не просто идеи, а совершенно конкретные документы: концепция деятельности и концепция эксплуатации. Концепция деятельности (ConOps) — это стратегический документ, содержащий цели и миссию, а также стратегию их достижения (альтернатива ConOps - Стратегический бизнес-план). Это изложение деятельности с точки зрения стейкхолдеров.

Концепция эксплуатации (Operational Concept, OpsCon), в свою очередь, описывает систему, которая реализует стратегию или её часть. То есть, это когда мы уже приняли решение, что у нас вот тут будет какая-то система, и описываем, как мы собираемся с ней работать. Уже из этой концепции мы, путем формальных преобразований, можем прийти к анализу потребностей и, наконец, к требованиям. Всё это звучит довольно заумно, но в Руководстве есть отличная история, живо показывающая всю цепочку (я прямо узнал все свои проекты, и вздрогнул, а также вспомнил анекдот про японскую бензопилу):

Представим, что на дворе 1930-е годы. На выставке инструментов для лесного хозяйства фирма Андреаса Штиля только что представила бензопилу, способную сделать революцию в отрасли. Герои нашей истории работают в небольшой компании, занимаются валкой леса. Её менеджеры только что вернулись с выставки. Просто взять и начать валить деревья с большей скоростью — это прекрасно. Но ведь нельзя просто так взять и посадить первого попавшегося представителя какой-нибудь из заинтересованных сторон за стол и попросить его написать требования для закупки бензопилы. Системное мышление заставляет задуматься: как же эта новая технология будет применяться с точки зрения бизнес-операций?

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

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

Перед тем, как на уровне бизнес-операций кто-то сможет ответить на все эти вопросы (то есть, выполнить требования), на уровне бизнес-менеджмента необходимо решить, как и зачем внедрять технологию на предприятии. Предприятию нужны эти бензопилы, чтобы быстрее валить деревья? Или скорость работы должна остаться такой же, просто выполнять ее хочется эффективнее (например, уволив несколько сотрудников)? В любом из этих случаев придется решить, что делать с людьми: переучивать ли их или нанять новых? Обслуживание топоров устоялось: торговцы не просто продают инструмент, но и отвечают за его состояние. Сломалось топорище? Просто отправляем его торговцу, он заменит. Затупилось лезвие? Снова к торговцу: он заточит. А с кем и как вести дела, если закупить бензопилы? Как поддержать снабжение? Как перевозить материалы — топливо, масла — с которыми сегодня в компании никто не работает? Как их хранить, с учетом пожароопасности? Как утилизировать просроченные остатки? Как и кто эту новую способность предприятия (все эти двигатели, цепи) будет поддерживать? Как поменять структуру организации? Как внедрять эту новую способность: выдать всем операторам бензопилы сразу, командам по очереди или начать с каких-то определенных регионов? Если начать валить деревья быстрее, нужно ли будет найти дополнительный транспорт для перевозки материала? Не придется ли расширять лесопилку? В конце концов, бизнес-менеджменту придется решить, стоит ли поставлять больше продукции и наводнить ею рынок, обрушив таким образом цены.

Летом в отпуске положено читать книги. Книг по системному анализу вообще мало. А художественных почти и нет. Но я неожиданно нашел! "Парк Юрского периода" - уже не помню, что там в фильме, а книга-то вся про системный анализ, с небольшими вкраплениями динозавров, просто для антуража.

Там же весь набор:
- эксперты не выдают ключевую информацию, потому что считают её несущественной/ошибочной/редким частным случаем (эксперты вообще склонны рассказывать про типовой опыт, а не про отклонения -- хотя именно отклонения и частные случаи "убьют" вашу систему. В книге про это тоже есть - "вы исследуете не систему, как она есть на самом деле, а систему, как вы её ожидали увидеть", говорит персонаж-математик);
- заказчики не выдают полной картины назначения и использования системы, а только частные ТЗ на отдельные модули - и пытаются из этого собрать работающую целостную систему, с предсказуемым результатом;
- потом те же заказчики требуют от программиста всё бесплатно доделать, и думают, что им за это ничего не будет;
- нанимают системного аналитика, а потом игнорируют его рекомендации - классика!
Отличный план для реализации сложной системы!

Какие ещё являения описаны очень жизненно:

во-первых, сочетания множества безобидных факторов, приводящих к катастрофе. Ну там: работы на центральном пульте управления, баг в управляющем контуре, одновременно с этим начинается гроза, одновременно с этим по каналам связи передается большой объем данных, одновременно с этим один сотрудник случайно пропустил нужный поворот, одновременно от ветра падает дерево... ну, понятно, заканчивается это тем, что кого-то съели. Я смотрел анализ крупных катастроф - они почти все были результатом сочетания многих факторов. Очень часто вмешивается природный или какой-то внешний фактор: ночь, дождь, туман, гроза, снегопад, или наоборот жара; повышение потребления, высокий трафик или наоборот - резкое падение... Мой однокурсник делал знаменитую пятерку новостей (ещё до закручивания гаек, когда всё было по-честному) - и рассказывал, что они очень быстро вычистили все часто встречающиеся ошибки - ну, вероятность которых больше 0,00001% - то есть, происходят на главной Яндекса по нескольку раз в день. Уже на вероятностях 0,001% это были сочетания трех-четырех маловероятных факторов. Дальше пошли сочетания 6-7 крайне маловероятных факторов - то есть, человек вообще про такие штуки редко думает, а уж представить, что будет при их сочетании заранее очень сложно. Между тем, в современных высоконагруженных системах такие события происходят гораздо чаще, чем мы ожидаем. В книге это очень достоверно показано.

во-вторых, создатели парка явно не изучали методические документы ФСТЭК по безопасности, поэтому у них там куча дыр и с точки зрения защищенности (чтобы защитить свои данные и ноу-хау), и собственно в безопасности (чтобы снизить вред для пользователей, операторов и окружающей среды). Например, в книге очень ярко показано, что может натворить внутренний нарушитель с высоким потенциалом и со следующими возможными целями (мотивами): "Причинение имущественного ущерба путем мошенничества или иным преступным путем. Любопытство или желание самореализации (подтверждение статуса). Месть за ранее совершенные действия. Выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды. Непреднамеренные, неосторожные или неквалифицированные действия".

в-третьих, создатель парка впадает в типичную ловушку всех визионеров: пытаться одновременно внедрить сразу несколько инноваций. Чувак, у тебя и так уже динозавры, чего ещё?! Но нет - ещё мы сделаем уникальную систему автоматического управления, чтобы людей поменьше нанимать, и впихнем в неё системы распознавания образов, автономные автомобили и сложный BI, завязанный на безопасность. Кто реально занимался сложными системами, знает железное правило: одно инновационное изменение за раз! Иначе будет невозможно локализовать проблему.

Ещё одна конференция в сентябре, на этот раз именно для аналитиков — Flow 2023. Она тоже 4-5 сентября, буду разрываться :) Но к Flow внимания больше — там я и член программного комитета, и выступаю с докладом Скрытая работа аналитика по проектированию систем и ещё буду экспертом на других докладах, работы много.

Как член программного комитета, скажу: мы отобрали самые лучшие доклады по анализу и проектированию систем, программа получилась просто огонь!

Так что приходите 4-5 сентября в онлайне и 11-12 сентября в офлайне — обсудим горячие темы системного анализа, а на моем выступлении — насколько профессия системного аналитика всё ещё про анализ, а не про проектирование (я считаю, что давно уже про проектирование, и анализ в чистом виде мало где встречается, вот только не все это окончательно осознали).

Встретимся на Flow!

Без юскейсов не построить физическую модель данных.

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

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

А вот когда мы переходим на физический уровень моделирования, нам нужно не просто разложить эти отношения по таблицам выбранной СУБД, а ещё и подумать про типовые кейсы их изменения и извлечения. Например, в реальной жизни почти всегда лучше использовать суррогатные ключи, а не надеяться на уникальность и неизменность каких-то естественных признаков. Например, данные извлекаются не произвольно, а исходя из потребностей пользователя (трейдер обычно смотрит на список сегодняших сделок, причем только своих, а не всех сделок вообще), причем пользователи могут иметь разные потребности (а отличие от трейдера, сотрудник миддл-офиса смотрит на сегодняшние сделки всех трейдеров, а риск-аналитик -- на все сделки за большой период). Не понимая потребности пользователей и их типовые запросы, мы, как минимум, не сможем построить индексы на таблицах, сформировать представления (view и materialized view), а где-то может, и денормализовать таблицы для большей скорости. Получается парадокс -- системные аналитики обычно проектированием физической модели данных не занимаются, а проектировщики БД, если они есть, не читают юскейсов. И отладка производительности БД начинается уже хорошо если на стейдже, а то и вообще в бою.

В Event Storming этой связке уделено специальное понятие: модель чтения. Помните -- результатом ES является "Картинка, которая объясняет всё". Это тот самый ответ на вопрос "какие данные нужны для того, чтобы пользователь принял решение и отдал команду, в результате исполнения которой произойдет событие". И, подумав о модели чтения, можно выбрать и подходящую форму хранения (может, вам вообще не реляционная база нужна, а графовая), и физическую модель определить.

Если вы хотите изучить новые слова и выражения на английском, попросите ChatGPT написать вам рекомендации для LinkedIn.

Мне пришлось через фразу лезть в оксфордский словарь! Хотел бы я знать, на каком курсе все эти фразы можно изучить (чтобы звучать, как нейтив). Я выделил курсивом слова и обороты, которые до этого, кажется, вообще нигде не встречал, ну или не придумал бы использовать в таком контексте:

"[Your Name] has consistently demonstrated a remarkable ability to seamlessly blend profound architectural insights with a visionary product perspective. Their unique aptitude for comprehending product strategies, UX design, and user satisfaction truly set them apart. With a keen eye for detail and a deep understanding of both technical and product domains, [bla-bla...] From understanding product strategy to UX design and user satisfaction, [Your Name] excels across the board. I want to highlight his unique ability to blend a deep understanding of software architecture with a product-centric vision, coupled with a knack for understanding user needs and designing intuitive user interfaces. I wholeheartedly recommend them for roles like Head of Product, where his expertise would undoubtedly shine."

Ну и если вам вдруг стало грустно, или вы почувствовали "синдром самозванца" -- почитайте хвалебную оду себе, насколько вы прекрасны! Всех с пятницей! 😜

Сегодня на Flow будем обсуждать ассессмент системных аналитиков, то есть оценку компетенций: самооценку, оценку коллег, оценку независимым центром и назначение оценки: внутренняя оценка в компании, независимая оценка "для себя", оценка перед подготовкой к интервью / новой работе...

А вы проходили оценку навыков? Как впечатления? Что думаете по этому поводу? Была ли польза? Видели какие-нибудь классные инструменты для оценивания?

Upd: что-то тема не вызывает отклика, вас что, на работе и при приеме не оценивают?!

Уфф, закончилась онлайн-часть Flow. Кстати, сегодня был community day, записи доступны бесплатно (после регистрации).

Я сам почти ничего не смог послушать — сначала вел интервью с Максимом Цепковым про DDD, и как обходиться на проекте без требований, а потом был экспертом на докладе Кати Гончаровой про применение AI инструментов в повседневной работе бизнес-аналитика (там ещё потом интересная дискуссия была).

Сейчас выдохну, и напишу своё резюме по всем докладам, есть интересные мысли.

Stay tuned!

Во-первых, хочу написать про доклад-иинтервью с Максимом Цепковым про DDD и работу без требований. Сам формат интересный, можно задать вопросы и направлять этим рассказ, а не идти в логике докладчика. Хотя 45 минут — это очень мало, понимаю теперь, почему у Дудя интервью по 2-3 часа длятся.

Что я вынес из разговора с Максом:

1️⃣ Словом требования называют разные по назначению сущности. Первая - это требования внешних стейкхолдеров, которые вообще-то не говорят о том, как система должна быть устроена внутри, а выражают некоторые пожелания или ограничения по её свойствам и возможностям. Вторая — требования как постановка задачи архитекторам и разработчикам, промежуточный артефакт внутри процесса производства ПО. То есть, бизнес-аналитики строят модель предметной области (бизнес-модель, модель использования системы, концепцию операций...) а системные аналитики и архитекторы строят модель самой системы. И заголовок интервью — про вторые требования, без них можно жить, если использовать единую модель. Забегая вперед, идея пересекается с моим докладом про скрытое проектирование, и с работами Пола Ральфа, который первый вид требований предлагает называть "desiderata", чтобы не путаться. Ну или попросту "хотелки" 😆

2️⃣ И вот если мы меняем способ общения между людьми внутри проекта, нам не нужен "переводчик" с языка заказчика на язык разработки, как часто называют аналитика. У нас общий язык! Ubiquitous language, одна из ключевых идей DDD. Не нужно фиксировать отдельно бизнес-требования, а отдельно их превращать в функциональные требования (спецификации), тексты в тексты. Нужно построить модель, которую поймут все - и заказчики, и разработчики, причем это должна быть одновременно модель бизнеса, и она же - модель системы.

3️⃣ Таким образом, DDD - это, в первую очередь, про способ общения, про коммуникацию между людьми. (Да что там, всё наше производство софта - это на 2/3 про коммуникацию - от сбора требований до проектирования архитектуры, развертывания и мониторинга.)

4️⃣ Соответственно, модель должна быть понятной и разработчикам, и стейкхолдерам. И тут нужно разделять модель и диаграмму - как некоторое представление модели (или одного из аспектов модели). Модель - формализованное упрощенное представление системы. Диаграмма или описание -- представление одного из аспектов модели (Максим показывал расположенные рядом диаграмму активности и диаграмму состояний - довольно наглядно, что на каком шаге происходит). Тут, конечно, бооольшой вопрос - как такую модель построить, и что это за средства и формализмы для её построения. В практике у нас тут в ИТ используются в подавляющем большинстве эвристические модели, то есть умозрительные - кто что придумал, как смог представить, так и ладно. Математических моделей у нас, как правило, нет. Пожалуй, единственная математически строго обоснованная модель -- это реляционная, да и то там есть проблема с 5НФ, которая на практике не решается чисто математически, без понимания бизнес-правил.

Тут подключился Денис Бесков, и мы немного поговорили про нотацию моделирования: у Макса в примерах UML, а Денис говорил про Event Storming. Я, со своей стороны, тоже склоняюсь к ES - и именно в контексте понимания - кажется, она гораздо лучше понимается и стейкхолдерами, и разработчиками, и содержит почти всё необходимое.

5️⃣ Имея единую модель системы, мы можем оценивать "хотелки" стейкхолдеров в отношении этой модели, не заглядывая в саму систему (если гарантировано, что система имплементирует именно эту модель). Так можно, а так нельзя, а вот это будет сложно сделать. Тут мы поговорили про нефункциональные требования (которые всё-таки внешние, зависят от сценариев использования, или, в широком смысле, от операционной концепции - см. ConOps и OpsCon). Про сценарии использования Максим таки проговорился, что они всё же есть, но "это просто текстовые описания" :) Вот тут, кстати, Event Storming дает фору, так как включает сценарии (через реакции актора на события).

6️⃣ Ограниченные контексты. Создать такую единую модель для всего предприятия, да и просто для большой системы - дело неподъемное. И на практике не нужное. DDD освобождает нас от необходимости объять необъятное, и разрешает строить изолированные модели для отдельных областей и думать больше о том, как их связать (и тут есть разные паттерны).

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

Что осталось за кадром, но о чем хочется ещё поговорить:
➡️ как, всё-таки, строить именно модель, а не отдельные диаграммы?
➡️ как научить стейкхолдеров читать модели и согласовывать именно их, а не многостраничные тексты (TAGRI, They Ain't Gonna Read It)
➡️ как работать с изменениями модели
➡️ как воплощать модель в код

Попробовал распознать запись дискуссии через гугл документы (запустил на телефоне и положил рядом с микрофоном). Получился бредок, но! ChatGPT это понимает и выдает нормальное summary.

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

"Во второй части текста обсуждаются дополнительные аспекты ассессмента системных аналитиков. Автор отмечает различия между аналитиками внутри больших компаний, где могут существовать разные подходы и системы оценки. Затем разговор переходит к рассмотрению того, как такой ассессмент может помочь аналитикам в общении с руководителями. Автор подчеркивает, что этот инструмент не только помогает аналитикам определить свое текущее место и цели развития, но также способствует более прозрачному общению между аналитиками и их руководителями. Он отмечает, что большие компании разрабатывают процессы оценки и карты компетенций, чтобы помочь аналитикам расти и развиваться на текущей позиции. Наконец, текст упоминает, как такой ассессмент может быть полезен при поиске работы и продвижении по карьерному пути."

1. Главная идея заключается в важности технического ассессмента системных аналитиков для самооценки и определения их места на рынке труда.

2. Участники подчеркивают необходимость построения системы оценки и карты компетенций, которые помогли бы аналитикам определить свои навыки, цели развития и потенциал карьерного роста.

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

4. Один из главных аспектов внутреннего ассессмента аналитика заключается в его нынешнем уровне компетенции и его развитии на текущей позиции внутри компании. Это позволяет руководителям и аналитикам прозрачно оценить его профессиональное развитие.

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

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

В целом-то всё по делу распознал :)

Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?

В общем, ловите презентацию, там есть немного ссылок по темам.

Отличный конспект Максима Цепкова выступления про EventStorming

#flowconf Денис Бесков. Радикальное ускорение аналитических работ методикой Event Storming. Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы.
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить.
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.

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

Вместо процессного представления применяется гораздо более простой формализм: события и реакция на них людей с помощью существующих систем или в ручном режиме. При этом фиксируются проблемные точки и потребности автоматизации. При этом, за счет одновременного присутствия всех представителей бизнеса противоречия быстро вскрываются и обсуждаются на месте. Фиксируется необходимая информация и команды, которые дают люди, а при детальной проработке - агрегаты (бизнес-объекты), с помощью которых организуется процесс.

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

Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS).

Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке.

Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).

Максим Цепков написал отчет о конференции Flow, очень хороший, с конспектами докладов (и моим тоже): https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-09-17:_Flow_-_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2_%D0%BE%D1%82_JUGru_-_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82

Кажется, нам (я был в этом году членом ПК Flow) удалось затащить в программу довольно много архитектурных докладов, что, с моей точки зрения, крайне полезно для системных аналитиков. Вслед за Максимом хочу отметить доклады Дениса Цветцих про C4 (это уже, кажется, вместе с DDD и ES становится азбукой в ИТ, которую нужно знать всем) и Святослава Котусева про Enterprise Architecture — что архитектура — это не диаграммы рисовать, а поддерживать постоянную коммуникацию с бизнесом, строить дорожные карты развития, инициировать проекты и вообще обеспечивать развитие ИТ в соответствии с потребностями развития бизнеса.