Розпад ІТ-розробки на етапи

Компанії прагнуть розробляти класні Продукти (проекти, ПЗ) і часто спираються на логіку розділяй-та-контролюй. Весь процес розбивається на етапи та зони відповідальності, сподіваючись, що це гарантуватиме якість і передбачуваність.

Типовий план розробки продукта виглядає так:
1. погодити візію (з кимось важливим)
2. схвалити архітектуру (з кимось технічним)
3. пройти діскавері (з кимось з бізнесу)
4. розробити дизайн (з кимось креативним)
5. уточнити деталі (з кимось досвідченим)
6. розкласти все на окремі задачі (з кимось продуктивним)
7. оцінити ресурси та естімейти (з кимось економним) 
8. передати все в розробку (тим, які завжди незадоволені)

Плани виглядають раціональним підходом,
але по суті – це конвеєр втрати сенсів. 

Оскільки кожним етапом займаються різні люди, які працюють у різних контекстах та з різними проблемами – сенси губляться. Рішення приймалися ізольовано, під процесний етап, а не через розуміння продутку.

Придумували одні, погоджували другі, уточнювали треті, а виконувати дали четвертим.  Результат – нудний, як квартальний звіт – продукт збирається з компромісів, а інженери-розробники, які відповідають за кінцевий результат, виявляються винуватими, хоча вони найменше впливали на рішення.

Планування по етапах створює ілюзію контролю, бо все виглядає організовано – таблиці, діаграми, чіткі відповідальні особи. Але це лише ширма. Реальність складніша, бо люди на цих етапах живуть з різними сенсами, говорять різними мовами і думають у різних системах координат.  

Чим гірше працюють плани, тим детальнішими їх роблять

Коли розробка стає дорогою та неефективною, компанії не ставлять собі питання, а чи правильно ми все організували? Ні. Вони вирішують, що треба ретельніше деталізувати плани! Глибше, більше, контрольованіше та з посиленою персональної відповідальністю.

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

Чому так? Бо компанії бояться

Ця логіка народжується зі страху. Великий проект – це перш за все великі ризики (читай великі втрати). Раптом щось піде не так? Недогледіли, як в минулий раз, і вжух – 10 млн. в трубу. Тому краще все задокументувати, перезатвердити на всіх рівнях, винести на всі комітети, додати ще один етап, ще одну ковбаску Ганта, що все було під контролем.

Ретельні плани є спробою підминити розуміння на контроль.

Замість розмовляти одне з одним і спробувати поразумітись – пишуться завдання, а замість перевірки сенсів – перевіряються формати зустрічей (цих – додати, тих – запрошувати окремо, адженду строго витримати).

І от уже починається: замість “обговорити архітектуру” додаються етапи Solution Review та Technical Approval; створюється перевірка PMO на відповідність процедур ведення ініціатив; бюджєтне погодження між продактом та фінансистом розрастається у фінансовий комітет; нові плани затверджується на VIP Commettee, де ніхто не переймається CI/CD, але є побажання по UI.

Але чи дають ці заходи гарантію якості або вчасності випуска Продукта? Навряд чи.

Ця ієрархічна машина пожирає саме те, що могло б врятувати проект – живу взаємодію, пошук реальних сенсів та запал співтворення.

Бо люди, які мають ідеї втомлюються їх пояснювати на комітетах. А люди, які можуть діяти заморилися чекати погоджень. А ті, хто руками роблять продукти втрачають сенс того, що роблять.

Продукт виходить не тому, що його спланували,
а попри цей план.

Весь цей парадоксальний ритуал не гарантує нічого, окрім розмитої відповідальності, затягнутих дедлайнів і командної апатії (оце як раз гарантовано)

Так народжуються дуже середненькі продукти, якими хтось і буде користуватись, але вимушено, бо діватися нікуди.

Вам не потрібні кращі плани – вам потрібна спільна мова

Яка головна проблема неефективної розробки? Ні, це не погані плани, не бюрократія з джирой…

Люди з різних світів, з різним уявленням про проблеми та з різними цілями розробляють начебто один і той самий продукт. Архітектори мислять мікросервісами, аналітики – інтеграціями, тестувальники – корнер-кейсами, проджекти – процесами, продакти – інкрементами, дизайнери – фловами, інженери – кодом, фінансисти – бюджетами, а клієнти – вони ще навіть не в курсі!

Всі сторони бачать продукт лише зі своїх точок зору
і не можуть поразумітися між собою

Кожна сторона користується своїм професійним жаргоном зі своїми сутностями, які поза цим контекстом нікому не будуть зрозумілими. Усі говорять, але розуміють по-різному.
В такому випадку “домовились” – це радше втомилися сперечатися і зупинилися, ніж справді порозумілися.

Поразумітися можна лише через спільну мову

Класні продукти починаються з поразуміння – зі спільної мови між розробниками, експертами та бізнесом.

По-перше – навчіть людей розмовляти разом.
Дайте їм просту, але точну мову, так щоб кожен міг пояснити себе, зрозуміти інших, бачити помилки та спільно “писати”.

По-друге – дизайніть продукти в колоборації.
Досить перекладати сенси та відповідальність між відділами, моделюйте системи в колоборації з усіма дотичними – технарями, гуманітаріями, маркетологами та доменними експертами – щоб одразу бачити всю комплексність.

По-третє – одразу збирайте усіх на старті та моделюйте систему.
Не треба чекати квартал, щоб зібрати бізнес вимоги, чи щоб архітектор “намалював драфт”, чи щоб продакт провів серію кік-офів – збирайте одразу усіх, кому з цим продуктом/процесом/проектом жити і спільно, наживо моделюйте систему.

Івент Штормінг – змога говорити однією мову
та домовитись про спільну реальність

Перше, друге та третє можна реалізувати за допомогою Івент Штормніга (EventStorming). Ця практика дозволяє людям із різних світів створити спільну реальність. Не через чергову BPMN схему та товсту Confluence, а через розмову, суперечку, подив, сміх, “а що, якщо..” і “о, а я такого не знав!“.

В результаті виникає спільна узгоджена модель продукту (процеса, проекта, системи), не як фантазія окремих людей, а як результат колективного та узгодженого моделювання.

І от тоді стається магія… Те, що тривало місяцями у вигляді погоджень на комітетах відбувається за один день. За день воркшопу команда створює таке розуміння, яке не втиснеш у жоден Confluence-шаблон і не отримаєш на жодному Approval Committee.

І не треба три тижні готуватись до воркшопу. Треба просто зібрати потрібних людей, без “спочатку зробимо окрему підготовчу фазу”, без “давайте напишемо драфт документації”. Просто зібрати людей, які реально щось знають або будуть руками робити –  і дати їм простір взаємодії.

Якщо розробники з самого початку дотичні до моделювання, вони стають не “виконавцями тасочек”, а авторами продукту з відповідною мотивацією. А коли замовники долучаються до спільного моделювання, вони перестають бути джерелом тиску і стають партнерами у створенні цінності.

Цей воркшоп – не просто технічна подія, а культурний акт – пошук спільної мови у всіх її значеннях. Продукт починає мати сенс не тому, що все погоджено, а тому, що все зрозуміло.

Як виглядає Івент Штормінг ?
Як справжня розмова

Уявить велику дошку (фізичну чи в Miro), стікери, фломастери і всі учасники проекту в одній кімнаті. Без ролей, без зон відповідальностей та без очікувань чергового етапу погоджень – просте живе моделювання того, як працюватиме система.

Починається з простого – з “подій” (жовті стікери). Що відбувається в бізнесі? Користувач прийшов у кошик і “замовлення створено”, “платіж не пройшов”, “система надіслала лист” і т.д. Люди клеять стікери, пояснюють, запитують, плутаються, сміються. І поступово хаос перетворюється на логічну систему, а кольорові папірці на послідовну модель системних подій.

Потім додаються ролі, “команди”, “правила”, “зовнішні системи” та “ризики”. Всі в процесі і ніхто не чекає свого ТЗ, щоб почати діяти. Усі бачать картину цілком, спільно доповнюють її, одразу бачать помилки і виправляються. І головне – кожен має шанс поставити питання (або тихенько стікер написати, але щоб всі бачили) і змінити щось, поки це ще не стало документом – комітментом – дедлайном – кодом.

Важливо, що ІШ не є складною BPMN/UML системою, яку треба вміти і писати, і розуміти. ІШ – це стікери людською мовою, які всі розуміють, які легко формулювати, якими просто писати(читай розмовляти), які дають змогу одразу бачати помилки і тут же виправлятись.  

Це складно уявити, але за один день з Івент Штормінгом ви отримаєте:
– узгоджену цілісну картину системи;
– виявлені ризики та зрозумілі залежності;
– купу зекономленого часу, нервів і грошей.
А ще — команду, яка знає, що і для чого вона робить.

…приступати до деталізованого аналізу, пропрацювань архітектури, UX/UI та бюрократичних процедур значно простіше, коли на руках є спільно змодельована загальна картина.

Як саме проводити штормінги?

Якщо ви зібрали разом потрібних людей та організували розмову всіх з усіма єдиною мовою – у вас вже правильний штормінг! Техніка письма, нотація, особливості фасилітації залежать від контексту та смакових вподобань. Якщо ви працюєте в Miro або Figma, то по запиту EventStorming може знайти безліч шаблонів, з сутностями та їх розʼясненням, або просто погугліть.

Для початку достатньо опанувати два типа сутностей – “події”(завершена дія, яка сталася в системі) та “ризики”(відкриті питання, ризики, все, що незрозуміло) – і ними вже можна моделювати комплексні системи.

Ось тут в пості я розгорнуто розповів, як проводжу свої Івент Штормінги – детально описав нотацію, одну з фасилітаційних технік та покрокове ведення воркшопу на 3-5 години, користуйесь 👇

Івент Штормінг, спільно моделюємо ІТ систему

Просте моделювання складних ІТ-систем. Event Storming дає єдину мову для бізнеса та розробників,…

Автор EventStorming методу, Domain-Driven Design євангеліст, Пан Альберто Брандоліні, каже, що не буває правильних та неправильних штормінгів, все залежить від контексту. Не переймайтесь формою воркшопа та нотацією, плекайте суть – спільну мову.

Може здатися, що хаос від спільного моделювання – це вже ризик. Але більший ризик – це будувати план на базі удаваної згоди, розрізнених рішень далеких кабінетів та без відсутності живого діалогу. Спільне моделювання не вирішує всіх проблеми, але воно створює простір, де кожен може стати частиною рішення, а не тільки виконавцем чужого, часто відірваного від контексту бачення. Ясність народжується в розмові, достатньо написати купку стікерів і команда перестає вгадувати, хто що має на увазі, а починає разом думати та створювати сенси…