1. Розбиття ІТ-розробки на етапи
Більшість компаній, які прагнуть покращити процес розробки програмного забезпечення, спираються на логіку структурованого підходу. Вони розбивають процес на окремі контрольовані етапи, сподіваючись, що це гарантуватиме якість і передбачуваність. Типова схема виглядає так:
загальне узгодження концепції;
погодження верхньорівневого технічного рішення;
діскавері-фаза для виявлення основних бізнес-вимог;
рефайнменти для уточнення деталей;
декомпозиція та оцінювання інкрементів;
розробка та тестування.
На перший погляд, це виглядає як раціональний підхід, але на практиці він створює проблеми. Оскільки кожним етапом займаються різні люди, що працюють у різних контекстах і часі, сенси втрачаються, ключові рішення приймаються без глибокого розуміння продукту, а креативність "команди виконавців" зводиться до мінімуму. У підсумку компанія отримує затягнуті терміни, втрату важливих деталей та низьку мотивацію скрам команди, яким треба виконувати кимось прийняті не самі оптимальні продуктово-технічні рішення.
2. Низьку ефективність компанії компенсують ретельним плануванням
Розбита на етапи розробка виявляється настільки неефективною, що компанії намагаються компенсувати це ще більш детальним плануванням. Складаються ретельні дорожні карти, вводяться додаткові контрольні точки, дедлайни по етапах, додаються рівні погоджень. Це призводить до ще більшого уповільнення процесу та втрати сенсів майбутнього ІТ-продукта.
Наприклад, замість однієї перевірки архітектури вводиться спочатку Solution Architect Review, потім Technical Architect Approval. Бюджет погоджують не тільки на рівні проєктної команди, а й у фінансовому комітеті. Щоб проєкт просувався далі, потрібно отримати схвалення PMO-офісу та повідомити доменних експертів про потенційні складнощі. Це створює гігантську бюрократичну машину, яка працює не на користь швидкості, а на підтримку жорсткої структурованості.
Але чи дає це гарантію якості? Ні. Чим більше людей у ланцюгу прийняття рішень, тим більше розмивається відповідальність і тим складніше враховувати всі нюанси продукту. Тому навіть найретельніші плани не можуть гарантувати якісний і своєчасний випуск продукту.Знову ж таки, треба регулярно перевіряти, щоб всі дійові особи плану розуміли, що і коли від них треба, і виконували свої обовʼязки строго по плану, щоб не порушити його хід надалі. що знову переводить фокус уваги з сенсів розробки, на бюрократичні процедури.
3. Вам не потрібні кращі плани — вам потрібна спільна мова!
Ключова проблема полягає в тому, що всі учасники процесу мають різні контексти. Архітектори мислять мікросервісами, бізнес-аналітики – інтеграціями, тестувальники – помилками, продакти - інкрементами, а фінансисти – бюджетами. Кожен спеціаліст бачить майбутній ІТ-продукт через свою призму, використовує свій професійний жаргон та сутності, які поза цим контекстом нікому не будуть зрозумілими. Іноді ці колеги навіть не знайомі, хоча роками розробляють один продукт.
Через це спроба звести всіх до одного плану виглядає як комунікаційний хаос. Усі розмовляють, але розуміють різне, рішення приймаються ізольовано під етап, а не для продутку, інформація спотворюється, а продукт виходить фрагментованим і далеким від початкової ідеї.
Яка альтернатива?
По перше, навчити всіх розмовляти спільною мовою!
По друге, перед початком проєкта (продукта) разом змоделювати стратегічний дизайн майбутньої ІТ-системи! Тобто замість того, щоб місяцями визбирувати вимоги - одразу зберіть всіх разом в одній кімнаті і починайте спільною мовою розмовляти та дизайнити ІТ-систему.
Event Storming якраз і є цією мовою. Він дозволяє зібрати разом технарів і фінансистів, бізнес-аналітиків та спонсорів, дизайнерів і проджектів, спеціалістів з безпеки і тестувальників, щоб у реальному часі разом моделювати ІТ-систему. Це дає змогу всім одночасно зрозуміти ключові події, команди, дійових осіб, команди, правила та політики, які визначають поведінку продукту та синхронізувати бачення.
Головна ідея Івент Штормінгу - дати всім дотичним до ІТ-розробки таку спільну мову, щоб кожен міг її легко опанувати, розмовляти, бачити помилки та виправлятися. Сильною перевагою такого підходу є його швидкість! Замість місяців узгоджень бізнес-вимог достатньо одного дня інтенсивного воркшопу, щоб сформувати єдине розуміння продукту і приступити до розробки. Немає потреби окремо готуватись до цих воркшопів, головне - зібрати разом всіх потрібних людей.
Наприкінці воркшопа команда буде мати:
- виявлені основні проблеми ще до початку діскавері та розробки;
- узгоджений стратегічний дизайн всієї ІТ-системи, з його UX-флоу, креативними рішеннями та білими плямами ризиків;
- збере основні критичні вимоги до ІТ-системи;
- знайде та одразу вирішить безліч продуктових та процесних питань, які б могли загубитись у проектній документації та вилізти вже на етапі імплементації;
- досвід справжнього тімбілдінга, коли задача плавить розрізнених спеціалістів у єдину продуктову команду, коли інженери починають мислити категоріями бізнесу, а бізнес моделює процеси та UX.
В Івент Штормінгу цей артефакт називається Big Picture (Загальна Картина).
Маючи Загальну Картину, можна розпочинати процеси діскавері, планувань, рефайментів, обговорень технічних рішень, UX/UI-досліджень і т.д. І всі ці процеси йтимуть значно швидше, бо команда (вже саме команда, а не просто розрізнені спеціалісти різних відділів) вже синхронізована.
Ба більше, мотивація команди, яка була дотична до спільного моделювання майбутньої ІТ-системи, значно вища при такому підході! Неможливо добитися подібної вмотивованості учасників, якщо їм просто спускати на виконання відірвані від контексту бізнес вимоги чи залучати в окремі етапи погоджувальних робіт.
Event Storming бере свій початок із інженерного підходу Domain-Driven Design (DDD), який зосереджується на створенні програмних систем через глибоке розуміння предметної (доменної) області. Використовуючи основний принципи DDD, ES/ІШ залучає до моделювання як технічних спеціалістів, так і користувачів, доменних експертів та замовників, що сприяє створенню спільної мови (та розуміння) між усіма учасниками процесу. Використовуючи доменних підхід до моделювання можна швидко виявляти проблеми, усувати невизначеність і формувати цілісну картину системи ще до початку робіт та планувань.
4. Воркшоп навчання Event Storming
Вже 1 березня 2025 року, ви можете прийняти участь у публічному тренінгу Event Storming Workshop (ESW). ESW - одноденний, 7-годинний тренінг-інтенсив про застосування методу візуального моделювання складних систем, який дозволяє командам синхронізувати розуміння, спільно моделювати, усувати вузькі місця в комунікації та прискорювати прийняття рішень.
Під час цього практичного курсу учасники:
дізнаються, як працює Event Storming;
опанують його основні принципи;
навчаться застосовувати його для Discovery-фази, Refinement-сесій та інших ключових етапів розробки;
розвинуть навички фасилітації, що допоможуть їм проводити ефективні Event Storming-воркшопи.
Цей підхід допомагає побудувати спільну мову між технічними та бізнес-командами, дозволяючи їм разом створювати бачення складних доменів та ІТ-систем. Метод заснований на принципі моделювання системи через ключові події, що дозволяє швидко виявляти прогалини, покращувати дизайн та уникати критичних помилок.
Вам не потрібні кращі плани. Вам потрібне спільне бачення. Вам потрібен Event Storming.
Comments