Навчись кмітливому проектуванню ІТ-систем
Реєстрація на воркшоп
🗓️ 18 / 07 / 2026
💳 13500 грн
⏱️ 09:00 – 19:00
Один воркшоп – повна трансформація підходу до проектування
За одноденний воркшоп ви навчитесь проводити EventStorming сесії самостійно – збирати за одним столом гуманітарієв та технарів, і одразу моделювати систему, щоб вийти з готовим рішенням.
“Круто. Буду малювати системи тільки разом з замовником”
“Величезне дякую команді, було дуже круто працювати разом!”
“Мені прям дуже зайшов воркшоп і величезне дякую”
“Об’єднювати навколо історії,
замість читання доків”
“Івент Штормінг – це не страшно,
а дуже цікаво і корисно”
“Картинка комплексна, тому і будується легше”
“Не думав, що можна за день погодити MVP“
“Простий підхід до складних систем”
“Дякую, ми тільки що зекономили бюджет для 2го проекта“
“Раніше було трохи страшно з розробниками спілкуватись, а зараз буду сильно впевненішою“
Програма навчального воркшопу
- Чому замовники не розуміють виконавців і що з цим робити.
Подивимся, як традиційний збір вимог програє сторітелінгу, як навіть одна команда живе одночасно в багатьох контекстах і непорозуміння неминучі. Розкажемо один одному просту історію і перевіримо, чи зійдемося. - EventStorming – суть, мова, правила.
Як працює метод і чому він саме такий. Опановуємо спільну мову – події, команди, дані, правила, ролі, гарячі точки – і одразу спробуємо на простих прикладах, щоб синтаксис осів до кінця дня. - Рівні моделювання та формати воркшопів.
Big Picture, Process Modelling, Design Level – від загальної картини до технічного дизайну. Розбираємо реальні кейси і спробуємо кожен рівень окремо, щоб зрозуміти коли і який використовувати. - Моделювання великої системи.
Головна частина дня, змоделюємо реальну складну систему разом, від першого стікера до спільної картини. Спробуємо різні форми опису та пройдемо повний цикл. - Штучний інтелект та EventStorming.
Коли рутину забирає LLMʼка, залишається найважче – зрозуміти що будувати, тому спільне моделювання стає ще важливішим. Повправляємся у використанні ШІ-інструментів, як частини сесії моделювання.
Бізнес та розробка знову не порозумілися? EventStorming вирішує проблеми комунікацій, бізнес-логіки та архітектури за один день!
Що ви будете вміти після навчання
- Проводити сесії спільного моделювання самостійно
Знатимете як провести сесію, пояснити синтаксис, нотувати роздуми, утримати увагу групи і вийти з валідованою моделлю. Зможете провести першу сесію у своїй команді вже наступного дня, з шаблонами та чеклистами. - Виявляти конфлікти у вимогах до початку розробки
Знаходити, де стейкхолдери хочуть неможливого і де частина процесу зависає без відповідального. Навчитесь перетворювати конфлікт на спільне рішення прямо за столом. - Говорити з бізнесом і розробниками однією мовою
Зможете перекласти розмиту бізнес-ідею в чітку модель, а технічне обмеження пояснити бізнесу без жаргону і непорозумінь. - Tech Lead буде вміти зрозуміло пропонувати бізнесу архітектуру, яка природно випливає з бізнес-моделі.
- Product Manager буде вміти валідувати рішення до початку робіт, без човникового бігу між стейкхолдерами .
- Business Analyst буде вміти проводити воркшопи, де стейкхолдери самі формулюють свої вимоги та доповнити документи живою моделлю.
- Scrum Master отримує інструмент фасилітації для колег, які раніше боялись або не вміли спілкуватись напряму та скоротить тривалість рефайнментів
EventStorming – це найкмітливіший спосіб зібрати бізнес, розробників та користувачів за одним столом, щоб побудувати спільну картину. Замість передавати вимоги “зіпсованим телефоном” – будуйте разом, одночасно і простою мовою.
Готові навчитися
спільному моделюванню?
Реєстрація на воркшоп 18 / 07 / 2026
💳 13500 грн, група до 12 учасників
⏱️ 09:00 – 19:00 (Київ, GMT+3)
📺 Miro, Discord, Google Meet, онлайн
Оплата участі за реквізитами
ФОП Литвиненко Антон Сергійович
IBAN UA173220010000026005380011957
ІПН/ЄДРПОУ 3185217650
УНІВЕРСАЛ БАНК
МФО 322001, ЄДРПОУ Банку 21133352
Призначення платежу:
ПІБ, ІвентШтормінг Воркшоп 18.07.26
Чекатиму квитанцію про сплату
та ваші контакти 📩anton_ltvnk@icloud.com
Коли і для чого застосовувати EventStorming
- Моделювання нової ІТ-системи
Коли треба побудувати систему з нуля і одразу осягнути весь масштаб. EventStorming дозволяє до написання перших драфтів вимог зрозуміти, які події відбуваються в домені, де межі між модулями, що взагалі будуємо і в чому реальна складність. - Дизайн великої фічі
Коли фіча зачіпає кілька команд або систем і кожен розуміє її по-своєму. Спільний дизайн фіксує єдине розуміння вирішуємих проблем ще до старту розробки. - Проєктування мікросервісної архітектури
Майже ніколи не очевидно, де проходять межі між сервісами. EventStorming виявляє природні розрізи домену/під-доменів через набори подій, акторів, дати, правил, а не через організаційні схеми чи інтуїцію архітектора. - Розбиття моноліту на сервіси
Перед тим як розрізати моноліт, треба зрозуміти, що реально відбувається всередині. Воркшоп допоможе намапити живу і потрібну логіку системи, а не ту, що була в документації пʼять років тому. - Розробка нового бізнес-процесу
В корпорації кожен департамент цікавиться лише своєю частиною роботи, не розуміє специфіку інших відділів та й взагалі мало хто бачить цілісну картину. EventStorming збирає всіх в одній кімнаті і будує спільну картину – хто що робить, де передає естафету, де виникають конфлікти, де взагалі зайві рухи.
Впізнаєте себе?
Chief Tech Officer, робити треба двічі – вперше, а потім переробляти 👇
Хоча розробники пишуть непоганий код, але технічний борг все одно росте, бо вимоги приходять неповними, а дізнаєтесь ви про це запізно. Бо розробники кодять по ТЗ, але не розбираються в проблемі, яку вирішують.
Chief Product Officer, продукт виходить суцільним компромісом 👇
Роадмапа постійно тріщить по швах, бо бізнес дає “уточнення” вже під час розробки, коли вже починає розуміти, чого насправді хотів, а команда ніколи не встигає закінчити попереднє.
Product Manager, витрачаєте більше часу на комунікацію, ніж на продукт 👇
Ви працюєте перекладач між бізнесом і розробкою, забираєте інфу від одних, пояснюєте іншим, потім пояснюєте назад і щось губиться при кожній ітерації. Займатися саме продуктом у вас часу немає.
Business Analyst, ви детально все пояснили, а зрозуміли вас по-різному 👇
Ви ретельно описуєте вимоги, але їх або не читають, або читають і розуміють по-своєму, а коли щось іде не так, перший погляд саме на вас. Розробка потребує не додаткових документів, а діалогу між усіма сторонами.
Agile Coach, церемонії полікували симптоми, але не причину 👇
Ви вибудували R&D флоу, стендапи, ретро, рефайнменти та планування. Але команда все одно в розсинхроні з іншими відділами та бізнесом, бо немає спільної картини, яку однаково розуміють всі учасники.
Ви демите роботу за квартал, все працює очікувано і тут вмикається стейкхолдер – “Все прикольно, але ми чекали інший функціонал, ми ж пояснювали”. Ви навіть звикли до таких ситуацій, закладаєте ці ризики в бюджети та терміни, а замовникам пояснюєте про ітеративний Agile-підхід.
Промах стається до початку робіт, просто його помічають пізніше. Бо на старті кожен зрозумів продукт по-своєму. Бізнес намагався формулювати одразу рішення, архітектор малював схеми, але не радився з нішевими експертами, аналітик описував APІ, проте не валідував UX-флови з користувачами, ПМ різав таски по фігмє, без спільної декомпозиції з інженерами. Все робилось по совісті, але відокремлено. Всі думали, що решта з попереднього етапа все розуміє. Початковий сенс розробки, якщо він взагалі встиг з’явитися, пройшов усі фільтри й розвіявся.
Звідки зʼявився EventStorming?
EventStorming створив італійський розробник Альберто Брандоліні.
Він зробив Domain-Driven Design ( ІТ-система має відображати реальність бізнесу )
доступним і для нетехнічних спеціалістів, клієнтів та бізнесу.
Чим EventStorming корисний організаціям?
0. Спільна мова, як основа будь-якого моделювання. Це нейтральна та проста мова, яку однаково коректно використовують і програміст, і касир, і CEO. Всі певні, що їх зрозуміли саме так, як вони мали на увазі.
1. Завчасна валідація рішення. Бізнес сформулює, чого насправді хоче саме під час моделювання, а не коли отримує готовий продукт для ревʼю. Розробники, розуміючи нащщо це будують, одразу пропонують елегантніші рішення.
2. Спільна картина, яку всі однаково розуміють. Це буде не нове ТЗ/БВ, а модель, яку учасники будували разом. Те, що людина створила сама, вона розуміє та захищає.
3. Синергія, яка дає якісно інший продукт. Коли систему моделюють разом, то народжується рішення, до яких жодна з сторін не змогла б дійти самостійно.
4. Вирішення конфліктів до того як вони коштують грошей Місця, де вимоги суперечать або по-різному інтерпритуються стають видимим і коштують стікер, а не спринти переробок.
5. Тижні перемовин – за один день Типовий цикл погоджень великих фічей, особливо в корпораціях, займає місяці, і все одно щось губиться. Event Storming замінює цей ланцюжок одним воркшопом.
Cправжній сенс розробки часто навіть не існує до моменту спільного моделювання. Він народжується саме тоді, коли учасники разом змоделювали спільну картину під час воркшопа. Поразуміння під час живої розмови неможливо замінити ланцюгом поетапних узгоджень.
Вагаєтесь або залишились питання?
Feel free мені написати 👇