Чи можливо бізнесу разом з розробниками моделювали складну ІТ-систему, невимушено та просто?
Та звісно, що неможливо! Навіть не намагайтесь, мабуть...
Типова задача – Компанія починає розробку великої фічі або ІТ-системи, з десятками стейкхолдерів, зі сторонніми інтеграціями та з декількома типами користувачів.
Типове рішення – Продакти (проджекти або аналітики) місяцями збирають вимоги у стейкхолдерів, самі вибудовують UX-флови, підключають дизайнерів для прототипування, погоджують рішення зі стейкхолдерами і вже потім презентують команді розробників ці простирадла вимог та UI-екранів (kickoff meeting). Далі починається командні рефайнменти, декомпозиція на epics/user story, оцінка задач і сама розробка.
Типові проблеми – Витрачний час на збір та погодження вимог перед початком роботи. На kickoff meeting (презентація змодельованої фічі з UI-макетами ) у розробників зʼявляються пропозиції та недобачені обмеження, які треба узгоджувати зі стейкхолдерами, але ті переймаються, що розробники «намагаються схитрувати та ліняться», час піджимає, тому задачу погоджуть одразу з компромісами для бізнеса, для розробників та кінцевого споживача.
До кінця розробки половина колег не буде розуміти, який же кінечний результат має вийти, бо мало хто памʼятає той єдиний kickoff meeting, де презентували всю фічу та домовилялись про милиці.
Під кінець розробки всі бубонять, що інша сторона їх не чує, що «вони самі не розбираються в темі» (бізнеса чи розробки) та «треба було одразу робити по-іншому». Класіка і всі звикли.
АЛЬТЕРНАТИВА:
Одразу всією громадою моделюємо систему за день або швидше
Розпочати з одного воркшопа Event Storming / Івент Штормінг (ES / ІШ), замість витрачання тижнів на перемовини та планування. Замість документів та погоджень – спільне створення!
Воркшоп економить тижні часу, не потребує збору вимог, синхронізує очікування сторін, дає спільне розуміння бізнесових та технічних проблем. А ще – кардинально покращується комунікація стейкхолдерів з розробниками, бо вони проходять справжній тімбілдінг протягом воркшопу (до речі, саме тому я і почав проводити ІШ)
Після ІШ, коли у всіх буде єдине пропущене через свої руки-мізки розуміння загальної картинки та узгоджена модель, можна почати паралельно дозбирати вимоги, прототипувати UI, точково рефайніти та оцінювати user story.
Цей метод, Івент Штормінг / Event Storming, вигадав італійський программіст, DDD-євангіліст, Пан Альберто Брандоліні. Ось тут та тут можна ознайомитись з його ідеями, та й взагалі в мережі багато прикладів та похідних варіантів цього методу, шукайте у темах повʼязаних з domen driven design, event modeling, process storming, event sourcing, architecture design, etc.
Головне для воркшопу – зібрати наживо в кімнаті всіх «правильних» людей – тих, хто знає, що питати, та тих, хто знає, як відповісти, а сам ІШ / ES дає змогу спільною мовою моделювати систему.
Але зараз всі живуть в онлайні, тут є обмеження для командної співпраці. Тому я вирішив запакувати оригінальний ІШ / ES у спрощений (сплощений?) формат онлайн-воркшопа, але так, щоб зберігти і персональне включення, і групову роботу, і творчий хаос немодерованого спілкування (наживо – все одно краще!)
Гайд проведення в онлайні Івент Штормінга / Event Storming
Що робити – Писати багато кольорових стікерів, сувати їх по дошці, ставити питання та дивитись один на одного.
Час – від 3 до 6 годин креативного часу, підлаштовуйте під себе, перерви на ваш розсуд. Я намагаюсь вкластись у 3-3,5 години загального часу (специфіка задач та колективу) за раз. Впоратися швидше, ніж за 3 години, навряд чи вийде.
Кількість осіб – до 20 колег, наживо можно і більше, але фасилітація онлайн воркшопа на більшу кількість учасників є поганою ідеєю, навіть якщо ваша аудиторія кофеінозалежні екстраверти. Звісно, краще мати окремого фасилітатора-ведучого.
Інструменти – відео-чат з можливістю розбивки учасників на кімнати (Zoom, MS Teams) та дошка для колаборації (Miro, Mural, FigJam). З телефона приймати повноцінну участь не вийде. Камери обовʼязково вмикаємо, щоб не загубити крихти невербальних сигналів.
Очікувані результати – високорівнева картина фічі та її ризики, модель системи з технічної та ціннісної точки зору. Це буде грунтом для подальших предметних, вузьких рефайнментів, UI-прототипування та оцінки user story.
У вас відбуватиметься контрольований креативний хаос, з суперечками та невизначенністю,
будьте обережні, щоб не задушити це.
Сутності, якими будемо оперувати
Вісім сутностей ІШ / ES , якими зможуть оперувати і бізнеси, і технарі, і юристи, для цього не треба бути програмістами чи бізнес-аналітиками.
Подія – факт, завершена дія в минулому часі, дає розуміння що було зроблено, що сталося в системі, має технічний та бізнесовий сенс (file attached, call received, money withdrawn, послугу підключено, рахунок поповнено). Помаранчевий стікер.
Актор – користувач системи, той, хто запускає процеси, команди, користується фічею (end user, accountant, operator, менеджер).
Жовтий стікер.
Команда / дія – дія, яку ініцєює актор чи система – зроби оце, робиться те (put item to cart, send money, підключити послугу).
Блакитний стікер.
Правила / політики – умови, які визначають подальші події – як, чому, коли (deposit more than 100 cash, user is trustfull, all conditions are met, перевірка на сумісніть, настав обліковий період).
Бузковий стікер.
Зовнішні системи – системи, з якими відбувається взаємодія, які варто зазначити – куди, звідки (billing, accounting module, proxy api level, ДІЯ)
Темно-синій стікер.
Ризики / невідоме – все непрогнозоване, ризиковане, незрозуміле, всі питання, що потребують відповіді, в оригіналі це зветься hot spot.
Червоний стікер.
Моделі читання – інформація, необхідна для прийняття рішень, данні, якими обмінюються системи (інформація про продукт, склад кошика).
Зелений стікер.
Агрегати – обʼєднана сукупність подій-команд-правил, які логічно обʼєднувати у єдині юніти, щоб підтримувати узгодженність данних в бізнес-процесах (shopping cart, loan scoring, замовлення)
Світло-жовтий стікер.
Важливо витримувати кольоровий код стікерів, це сильно спрощує читання моделі та структурує мислення. А от кількість сутностей, якими ви будете оперувати – на ваш розсуд, можете спершу спробувати лише події та акторів, а коли розіграється апетит, тоді розберетесь з рештою.
Етапи онлайн ІШ воркшопа
Загальна послідовність воркшопа – Спочатку згенерувати події, які можуть мати місце в системі. Потім обрати умовно першу, останню та середню події (з точки зору їх настання в UX-послідовності). Далі вибудуємо всі події у єдиному часовому проміжку та додати акторів. Потім додати команди, зовнішні системи, правила/політики, моделі читання. Ризики можна додавати на всіх етапах для всіх сутностей. Агрегатами краще оперувати вже в кінці, коли в системі вибудуються межі бізнес-контекстів. Коли учасники вже опанують суть метода, можна додавати будь-які сутності на всіх етапх.
Перший етап
Вступне слово від власника фічі, щоб презентувати контекст та ідею, тількі найважливіший ціннісний вимір. До 5 хвилин.
Фасилітатор-ведучій пояснює правила воркшопа, якими сутностями оперувати та як будемо діяти. До 15 хвилин, з запитаннями та прикладами.
Всі генерують-пишуть події на стікерах. Один стікер – одна подія. Краще писати в incognito mode (miro), щоб домогтись більшої варіативності від учасників. Пишемо все, що приходить в голову, не переймаючись, що в голову лізе якась фігня з кінця системи або тільки події з початку флова. Якщо намагатись записувати події одразу в хронологічному порядку, то ви надовго застрягнете і будете постійно переставляти їх місцями. До 5-7 хвилин.
Прибираємо incognito mode (miro), щоб всі мали змогу ознайомитись з написаними стікерами. Далі ведучій починає розбирати з учасниками їхні стікери, задача – знайти саме події, правильно сформульовані, що мають технічний та бізнесовий контекст. Це важливий етап, бо не всі одразу зможуть переформотувати своє мислення, щоб розмірковувати категоріями подій. Не треба перевіряти всі стікери, головне, щоб учасники зрозуміли метод. До 20 хвилин.
Другий етап
Тепер спускаємо часову лінію та мапимо під нею приблизно першу, останню та середню події (далі їх реальний порядок скоріше за все зміниться). Розбиваємося на 2 команди (намагайтесь врівноважити їх по спеціалізаціям) та рушаймо в окремі кімнати (Zoom/MS Teams rooms). Задача першої команди – вибудувати послідовність подій від першої до середньої, задача другої – від середньої до останньої події.
Використовуємо завчасно згенеровані події або/та додаємо нові, дублі прибираємо. Обирайте найкоротші та чітки формулювання. Розсовуйте стікери та займайте стільки простору дошки, скільки потрібно! До 30 хвилин.
Повертаємо всіх в загальну кімнату зустрічі та намагаємся поєднати послідовності двох команд. Перша команда пояснює свою послідовність, потім передає слово другій, щоб вони пояснили свою послідовність і домовились, як їх поєднати. Обговорення, уточнення, запитання заохочуються! Все, що незрозуміло, записується на червоних стікерах ризиків. Добре, якщо присутні будуть працювати асинхронно, хтось читає в голос, хтось одразу вносить правки в модель чи пише ризики-питання. До 30 хвилин.
Всі разом на вибудовану послідовність мапимо стікери акторів, тобто тих користувачів, хто реально взаємодіє з системою, фічею, інтерфейсами. До 10 хвилин.
Третій етап
Знову розбиваємся на команди (як в минулий раз або випадковим чином) та йдемо працювати у окремі кімнати – збагачувати свої частини послідовностей сутностями команд, політик, моделей читання, зовнішніх систем та агрегатів. Червоні стікери з ризиками можна і треба мапити на будь-якому етапі обговорень. До 30 хвилин.
Повертаємо всіх в загальну кімнату, читаємо вголос та обговорюємо збагачену сутностями модель. Перша команда презентує свою частину, потім передає слово другій команді. Але можна і навпаки (так навіть краще буває), комади вголос читають не свої частини послідовностей – друга презентує першу, а перша – другу частини. Знову ж таки, не бійтись займати більше простору на дошці та посувати стікери для зурочності. До 30 хвилин.
Приклад, як може виглядати реальна частина змодельованої системи
Підбиваємо підсумки, наскількі вибудована модель фічі задовільняє всіх присутніх стекхолдерів, юристів, маркетологів, девелоперів та дизайнерів. Чи залишились кардинальні неспівпадіння в очікувннях? Чи готові присутні погодити цю модель та взят її на точкове опрацювання та UI-прототипування?
За потреби, ітерації третього етапу повторюються, долучають доменних експертів та інших «правильних» людей, щоб разом збагатити та відкорегувати модель. Взагалі гарна практика під час воркшопу долучати інших носіїв знань, хоча б на 10 хвилин, наживо їм щось показати чи спитати.
Застереження
Не намагайтесь будувати щось по типу BPMN чи UML, це зайве і сильно гальмуватиме вас. Також не намагайтесь оперувати категоріями інтерфейсів, кнопок, інпутів, на цьому етапі це звузить розуміння цінності. Але якщо не зможете уникнути дизайну інтерфесів, то введіть окреми стікер (білий?), що буде відповідальним за UI-нотатки. Намагайтесь використовувати меньше стрілочок між стікерами, а якщо в стрілочках вже складно розібратись, значить щось не так з логікою всієї послідовності, інкаше вам би не хотілося все стрілочками зʼєднувати.
Якщо хтось мовчить на воркшопі – женіть геть, він/вона розмиває групову відповідальність та зменшує креативне (і трохи стресове) напруження в колективі!
А що треба після гарної вечері ?
Еспреско та цигарка десертик !
Наполегливо рекомендую після Івент Штормінга (після перерви або на наступний день) провести тим самим складом воркшоп по декомпозуванню фічі на інкрементальні частини та погодити етапи розробки.
Модель у вас вийшла обʼємною, але звідки починати розробку? Чи всі під-послідовності однаково важливі для кінцевого користувача? Які флови мають критичний пріорітет, а якими можна нехтувати? Той самий склад учасників повинен домовитись про перші, другі та всі інші пріорітети в фічі перед стартом розробки. До UI-прототипів та предметних рефайнментів також краще приступати після декомпозиції та пріорітезації.
Родзинка в тому, що на етапі пріоритезації складових інкрементів вся система (фіча) починає «перевертатися», тобто деякі «прості» під час ІШ штуки стають значно важливішими, а холівари по якимось рішенням взагалі зникають самі собою.
Методів декомпозування фічей вистачає, у вас точно є улюблені. Але мені подобається проводити свій простенький воркшопчик по декомозуванню, він логічно завершує ІШ – ось тут розповідаю детальніше.
Наостанок ☕️
Івент Штормінг не вирішує всіх проблем ІТ-розробки, не налагоджує регулярні релізи чи оцінку задач. Але ІШ дає змогу перейти до розробки значно швидше, з більшою мотивацією та єдиним порозумінням всіх дотичних, чому система саме така, а не інакша.
Ще одне про швидкість та прозорість, яку дає ІШ. Коли вся громада руками змоделювала систему, то подальші предметні рефайнменти можуть проводитись паралельно, бо всі в курсі всього і вже встигли раззнайомитись на воркшопі! Вже не треба аналітику чи продакту лідерувати ці процеси та послідовно висмикувати бек/фронт розробників з команди на деталізацію задач зі стекходерами – можно розділитися, організувати пари-тройки і рефайніти задачі параллельно.
Як візьмеш участь у декількох штормінгах, то цей метод стає дуже простим та зрозумілим. Наразі ІШ став мені таким звичним і очевидним, ніби я все життя тільки так і дизайнів фічі, навіть не памʼятаю, що було до нього. В моїх командах спростились процеси моделювання та покращились (стали легшими!) стосунки зі стекхолдерами, бо у них зʼявилась спільна мова та зручний формат спілкування. Гарних штормінгів, грінчата!
GRINCHY COACH - перезбираю продуктову розробку 