Коли я розбираю чужу систему на аудиті, насамперед ставлю просте запитання: чому в цього замовлення такий статус? І дуже часто ніхто не може відповісти. Статус «відвантажено», але відвантаження в системі немає. Оплата пройшла, але рахунок позначений як неоплачений. Клієнт у базі позначений як «новий», хоча в нього двадцять замовлень. Дані є, а причин у них немає. Система показує наслідки, які ні з чого не випливають. Це найвірніша ознака того, що під час проєктування хтось забув про причинно-наслідковий звʼязок.
Бізнес-система це набір реакцій на події
Будь-яка облікова система, якщо зняти з неї інтерфейс, влаштована дуже просто. У світі щось відбувається: клієнт оформив замовлення, постачальник привіз товар, бухгалтер провів оплату, менеджер скасував угоду. Це причини. Система на них реагує: змінює залишки, створює документи, перераховує борги, надсилає сповіщення. Це наслідки. Усе. Уся складність бізнес-логіки зводиться до того, щоб правильно описати, яка подія що спричиняє і в якому порядку.
Я люблю порівнювати це з роботою детектива. Добрий детектив не просто фіксує, що в кімнаті розбита ваза. Він відновлює ланцюжок: хто увійшов, що зачепив, чому впало. Добра система має вміти те саме: для будь-якого стану даних відповісти, яка подія до нього призвела. Якщо не може, Ви керуєте не бізнесом, а набором випадкових цифр.
Де ламається причинність
За роки роботи я склав для себе перелік типових помилок моделювання. Вони трапляються в проєктах будь-якого розміру, від маленьких магазинів до великих облікових систем.
- Ігнорування проміжних станів. Замовлення в моделі буває «новим» і «виконаним», а між ними порожнеча. Насправді ж воно проходить через резервування, збирання, очікування оплати, передавання курʼєрові. Коли ці стани не описані, працівники починають кодувати їх коментарями, кольорами рядків і усними домовленостями.
- Порушення послідовності операцій. Гроші списалися, а товар не зарезервувався, бо між двома діями щось упало. Система лишилася в стані, який не міг виникнути з жодного розумного ланцюжка подій.
- Пряме редагування наслідків. Хтось вручну виправив залишок на складі, не провівши ні надходження, ні списання. Цифра стала «правильною», але причини в неї більше немає, і за місяць ніхто не зрозуміє, звідки вона взялася.
- Змішування бізнес-логіки та інтерфейсу. Правило «у разі скасування замовлення повернути товар на склад» живе в кнопці на екрані. Скасували замовлення через інший екран, через інтеграцію чи через мобільний застосунок, і правило не спрацювало.
У добрій моделі не можна змінити наслідок, не створивши причину. Це не бюрократія, це памʼять компанії про те, що з нею відбувалося.
Як будувати модель, у якій усе пояснюване
Перше правило: проєктуйте від подій, а не від екранів. Перш ніж малювати форми, випишіть усі події, які відбуваються у Вашому бізнесі, мовою самого бізнесу: «клієнт оформив замовлення», «склад зібрав відправлення», «бухгалтерія підтвердила оплату». Для кожної події опишіть, які дані вона змінює. Екрани зʼявляться потім, як спосіб ініціювати ці події.
Друге: описуйте всі стани обʼєкта й дозволені переходи між ними. Із «нового» можна перейти в «зарезервований» або «скасований», а з «відвантаженого» в «новий» не можна. Це називається машина станів, і вона одна з найкорисніших речей у проєктуванні. Вона одразу показує діри: а що буде, якщо клієнт скасує замовлення, яке вже зібране? А якщо оплата прийшла після скасування?
Третє: повʼязані зміни проводьте як єдине ціле. Списання грошей і резервування товару або відбуваються разом, або не відбуваються зовсім. У техніці це називають транзакцією, у житті здоровим глуздом. Половина операції гірша за відсутність операції.
Четверте: зберігайте історію подій. Не лише поточний статус, а й те, хто, коли і з якої причини його змінив. Тоді на запитання «чому в цього замовлення такий статус» завжди буде відповідь, а аудит перетвориться з археології на читання журналу.
Передбачуваність як головна якість
Правильна модель передбачувана. Дивлячись на подію, Ви точно знаєте, до яких наслідків вона призведе. Дивлячись на стан, Ви точно знаєте, які події до нього призвели. Це здається нудною властивістю, але саме вона дає системі змогу рости. До непередбачуваної системи страшно додавати нові функції, бо ніхто не знає, що ще зламається. До передбачуваної системи нові події додаються спокійно, як нові ходи в грі зі зрозумілими правилами.
Мені в цьому сенсі близька фізика: світ складний, але він підкоряється законам, і саме тому його можна вивчати й передбачати. Бізнес-система має бути маленьким всесвітом зі своїми законами, а не набором див, які іноді трапляються з даними.
Що робити завтра
Візьміть один ключовий обʼєкт Вашого бізнесу, наприклад замовлення, і разом із людьми, які з ним працюють, намалюйте на дошці всі його стани й стрілки переходів між ними. Підпишіть кожну стрілку подією, яка її спричиняє. Ви майже напевно знайдете стани, які є в житті, але немає в системі, і переходи, які система дозволяє, а життя ні.
Ми в Ingello робимо це на кожному проєкті: у Systems із цього починається проєктування, а у Fractal мапа екранів і сценаріїв описується окремою мовою, тож ланцюжки причин і наслідків видно ще до того, як написано перший рядок коду. Модель, у якій кожен наслідок має причину, не перфекціонізм архітектора. Це спосіб зробити так, щоб Ваша система завжди могла пояснити сама себе.
