Запит, який розпочав тисячу суперечок
"Ви можете просто пересунути цю кнопку праворуч?"
"Ви можете просто змінити шрифт?"
"Ви можете просто додати ще одне поле до форми?"
Ці запити здаються простими. Часто вони такими не є. І розрив між очікуваннями клієнта та реальністю розробника є одним із найпоширеніших джерел розчарування в будь-якому веб-проекті.
Дозвольте пояснити, що насправді відбувається.
Проблема айсберга
Те, що ви бачите на веб-сайті, становить, можливо, 10% від того, що існує. Решта — це невидима інфраструктура: налаштування сервера, таблиці бази даних, код, який опрацьовує десятки крайових випадків, плагіни, які взаємодіють один з одним, мобільні макети, сумісність із браузерами, рівні безпеки.
Коли ви просите "просто змінити" щось видиме, розробнику часто доводиться пробиратися через всю цю невидиму інфраструктуру, щоб дістатися туди — не зламавши нічого.
Та кнопка, яку ви хочете перемістити? Вона може бути компонентом, який використовується в 12 різних місцях. Переміщення її в одному місці без впливу на інші вимагає знайти всі 12 випадків використання, протестувати кожен і переконатися, що мобільний макет досі працює.
Що насправді відбувається, коли розробник отримує "дрібне виправлення"
Налаштування середовища (30–90 хв)
Професійний розробник не вносить зміни безпосередньо на вашому живому сайті. Спочатку він працює з локальною копією або проміжним середовищем. Налаштування цього — отримання правильної бази даних, правильних плагінів, правильної конфігурації — займає час.
Розуміння існуючого коду (змінно)
Якщо сайт створював хтось інший, новому розробнику доведеться читати та розуміти код, якого він ніколи раніше не бачив. Це все одно, що отримати чиєсь есе з проханням "просто додати одне речення" — спочатку потрібно прочитати все, щоб зрозуміти, куди це речення вставити.
Внесення змін (іноді швидко, іноді ні)
Власне зміна може зайняти 10 хвилин. Або вона може виявити щось несподіване — конфлікт з іншим плагіном, макет, який ламається на планшеті, поле бази даних, яке також потрібно оновити.
Тестування (щонайменше 30–60 хв)
Після кожної зміни: тест на комп'ютері, тест на мобільному, тест у кількох браузерах, тест, що зміна нічого не зламала поруч. Це займає час, і його не можна пропустити без ризику зламати щось гірше.
Розгортання (15–30 хв)
Перенесення змін із тестового середовища на живий сайт, перевірка, що все перенесено правильно, перевірка роботи живого сайту.
Підсумовуючи: для "простої" зміни часто потрібно 3–5 годин фактичної роботи, перш ніж вона безпечно потрапить на живий сайт. "Триденний термін" зазвичай означає, що розробник впише це між іншими завданнями.
Коли це справді лише 5 хвилин
Деякі речі справді швидкі. Зміна текстового рядка. Оновлення кольору в CSS-змінній. Додавання електронної адреси до списку контактів.
Досвідчені розробники часто можуть це помітити і сказати: "Я можу зробити це сьогодні". Але їм потрібно достатньо інформації, щоб таке рішення прийняти — і їм справді потрібно спочатку подивитися на код.
Як прискорити виправлення
Будьте конкретними. "Виправте кнопку" → "Кнопка 'Додати до кошика' на сторінці товару не працює на iPhone 12, iOS 16, Safari. Кнопка натискається, але нічого не додається до кошика."
Групуйте запити. Замість того, щоб надсилати 8 окремих "дрібних виправлень" протягом 8 днів, надішліть їх усі разом. Налаштування та розгортання відбуватимуться один раз замість восьми.
Не поспішайте зі змінами на продакшені. "Ви можете просто зробити це безпосередньо на живому сайті?" — це те, через що сайти падають о 3 годині дня в п'ятницю. Хороший розробник наполягає на тестуванні. Це займає час.
Визначайте пріоритети. З ваших 8 запитів, який насправді коштує вам грошей, якщо не виправити його сьогодні? Виправте це спочатку. Решта може зачекати.
Чесно кажучи: "Чому це займає стільки часу?"
Тому що "зроблено" означає не "змінено". Це означає "змінено, протестовано, не зламано, розгорнуто і перевірено на живому сайті".
Остання миля — ось куди йде час.