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