Прихований технічний борг, через який редизайн сайту коштує дорожче за план

Peretz Group

Chapters

The Hidden Technical Debt That Makes Website Redesigns More Expensive Than Planned

Кожен редизайн починається з числа.

Кошторис, терміни, документ з обсягом робіт, який усі підписують.

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

Запитай більшість агенцій чому, і почуєш про розповзання обсягу. Клієнт додавав сторінки. Замовник двічі передумав. Ніхто не міг домовитись щодо головної.

Іноді це правда.

Але частіша причина тихіша, і вона зазвичай уже там до старту проєкту: технічний борг, який ніхто не врахував, бо ніхто його не шукав.

Кошторис був на видимий сайт. Ціна, за те, що під ним.

Редизайн не створює технічний борг. Він його розкриває.

Технічний борг часто невидимий саме тому, що сайт все ще працює.

Клієнти можуть оформлювати замовлення. Команда може публікувати контент. Форми надсилаються. CMS відкривається.

Ніщо не виглядає терміновим.

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

Не обов'язково.

Редизайн, це момент, коли це припущення перевіряється.

Ти більше не просиш існуючу систему продовжувати робити те, що вона вже робить. Ти просиш її змінитись.

І саме тоді старі рішення раптово починають мати значення.

Плагін, встановлений роками тому, щоб встигнути до запуску, може стати блокером.

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

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

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

Редизайн не створює ці проблеми. Він просто робить їх неможливими ігнорувати.

Що таке технічний борг

Технічний борг, це не баг.

Це рішення, зазвичай розумне на той момент, яке міняє довгострокову вартість на короткострокову швидкість.

Плагін, встановлений, щоб встигнути до запуску.

Сторінка, зроблена копіюванням іншої сторінки із заміною тексту.

Інтеграція, вшита напряму в тему, а не через API.

Поле бази даних, перепрофільоване під те, для чого воно ніколи не проєктувалось.

Нічого з цього не обов'язково помилка в момент ухвалення рішення.

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

Тому технічний борг часто розуміють неправильно.

Це не просто старий код.

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

І редизайн, це саме момент, коли цей борг настає до сплати.

Ти міняєш не просто те, як виглядає сайт. Ти торкаєшся фундаменту, на якому він тихо був побудований.

Коли він все ще працює

Деякі з найбільш технічно заборгованих сайтів, не зламані сайти.

Це сайти, які працюють роками.

Бізнес вчиться обходити їхні обмеження.

Фіча стає «занадто складною».

Нову інтеграцію відкладають.

Маркетингова команда перестає просити про певні зміни, бо вже знає, що розробка буде болісною.

З часом організація починає ставитись до технічних обмежень як до бізнес-правил.

Сайт більше не підлаштовується під бізнес. Бізнес підлаштовується під сайт.

Саме тут технічний борг стає більшим, ніж інженерна проблема.

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

Чому він лишається невидимим

Видима частина сайту, розмітка, кольори, тексти і взаємодії, це, можливо, 20% того, що реально зачіпає редизайн.

Решта 80% живуть під поверхнею:

структура CMS
база даних
інтеграції
редиректи
хостинг
кешування
плагіни
API
зв'язки контенту
автентифікація
бізнес-логіка
деплой
бекапи

Скоуп-дзвінок може пройтись видимими 20% за один вечір.

Ніхто не може побачити решту 80% без того, щоб відкрити кодову базу і CMS і реально подивитись.

Більшість кошторисів будується на видимій частині, бо саме її може показати ознайомчий дзвінок і пара референсних сайтів.

Невидима частина проявляється тільки після того, як хтось починає будувати.

І до цього моменту ціна вже узгоджена.

П'ять видів боргу

Контентний борг

Роки сторінок можуть бути побудовані непослідовно.

Одні написані вручну.

Інші зроблені за шаблоном.

Деякі створені різними агенціями за різними конвенціями.

Деякі містять інформацію, в актуальності якої ніхто не впевнений.

Інші можуть виглядати неважливими, але все ще приносити органічний трафік.

Перенести їх, не означає скопіювати-вставити.

Це розплутування того, яка версія правди насправді вірна.

Інтеграційний борг

CRM-підключення могло бути побудоване розробником, який уже пішов з компанії.

Платіжний шлюз може бути вшитий напряму в шаблон замість документованого API.

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

Про це не потрібно думати, поки сайт продовжує працювати.

Потім редизайн змінює ту частину системи, від якої залежать ці інтеграції.

І раптово «редизайн сайту» перетворюється на інтеграційний проєкт.

Інфраструктурний борг

Конфігурації сервера.

Налаштування DNS.

Правила кешування.

Конфігурація CDN.

SSL.

Ланцюжки редиректів.

Cron-задачі.

Бекапи.

Правила безпеки.

Роки дрібних інфраструктурних правок можуть тихо стати несучими для SEO, продуктивності і аптайму.

Нічого з цього не видно на скріншоті головної сторінки.

І частина з цього може ніде не бути задокументована.

Борг дизайн-системи

Сайт може виглядати послідовно, не маючи реальної дизайн-системи.

Одну кнопку зробили для однієї сторінки.

Іншу скопіювали через півроку.

Третю створили під конкретну кампанію.

З часом накопичуються десятки трохи різних компонентів, що вирішують по суті те саме завдання.

Редизайн передбачає, що перевикористовувані патерни існують.

Потім команда виявляє, що їх немає.

Системи ніколи не було.

Була лише колекція окремих рішень.

Борг даних

Поля бази даних перепрофільовуються.

Значення набувають різного сенсу в різних частинах застосунку.

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

Зв'язки, які колись мали сенс, більше не відображають те, як працює бізнес.

Новому інтерфейсу може знадобитись чистіша модель даних.

Але зміна цієї моделі може зачепити весь застосунок.

Проблема не в новому дизайні. Проблема в тому, що стара структура даних ніколи не проєктувалась під бізнес, який існує сьогодні.

Борг міграції

Є ще одна категорія, яка стає особливо важливою під час редизайну: борг міграції.

Редизайн, це не просто перенесення одного візуального інтерфейсу в інший.

Можливо, ти також переносиш:

URL
контент
метадані
зображення
категорії
товари
внутрішні посилання
структуровані дані
редиректи
мовні версії
проіндексовані сторінки

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

URL, що виглядає застарілим, може мати цінні зворотні посилання.

Категорія, що здається зайвою, може містити сотні проіндексованих сторінок.

Саме тому SEO-міграція не повинна починатись після того, як новий сайт уже побудований.

Ти переносиш не просто сайт. Ти переносиш його накопичену історію.

І в цієї історії є цінність.

Чому кошториси вибухають

Ось як з вигляду простий проєкт може змінити форму:

«Нам потрібен лише новий фронтенд».

Потім хтось виявляє, що CMS не може підтримати нову структуру.

CMS потрібно модифікувати.

Це розкриває стару структуру бази даних.

Базу даних потрібно міняти.

Це зачіпає API.

API зачіпає CRM-інтеграцію.

Структура URL змінюється.

SEO-міграція стає необхідною.

Старі плагіни більше не підходять.

Контент потрібно реструктурувати.

Раптово проєкт вже не редизайн сайту.

Це:

часткова міграція системи + реструктуризація даних + інтеграційна робота + SEO-міграція + новий фронтенд.

Нічого обов'язково не пішло не так.

Проєкт просто став краще зрозумілим.

Саме тому редизайн за $20 000 може перетворитись на проєкт за $40 000 без того, щоб хтось навмисно намагався розширити обсяг.

Початкова оцінка була заснована на тому, що було видно.

Пізня оцінка заснована на тому, що було виявлено.

Чому агенції не знаходять вчасно

Зазвичай справа не в нечесності.

Справа в послідовності кроків.

Більшість агентських процесів ідуть так: ознайомчий дзвінок → пропозиція → контракт → технічний аудит → розробка.

Проблема очевидна.

Ціна фіксується до того, як борг виявлено.

Коли це трапляється, в агенції є два погані варіанти.

Поглинути зайві витрати самим, що підриває економіку проєкту і заохочує зрізати кути в іншому місці.

Або повернутись до клієнта посеред проєкту з проханням про додатковий бюджет.

Це рівно та розмова, яку ніхто не хоче вести через три тижні після старту редизайну.

Обидва варіанти існують, бо аудит стався після ціни, а не до неї.

Що має відбуватись натомість

Рішення нескладне.

Воно просто непопулярне, бо додає крок до того, як можна поговорити про приємну частину.

Аудіювати технічний борг до кошторису редизайну, а не після.

Це означає реально відкрити CMS, а не просто переглянути живий сайт.

Реально скласти карту інтеграцій, а не просити клієнта перерахувати їх з пам'яті.

Реально перевірити, як виглядає історія редиректів і SEO, а не припускати, що вона чиста.

Реально прочитати схему бази даних, а не тільки дивитись на фронтенд-шаблони.

Реально перевірити плагіни, залежності, конфігурацію хостингу і процес деплою. І, що важливо, визначити, кому належить кожна частина системи і чи розуміє її взагалі хоч хтось.

Це займає дні, не місяці.

І перетворює більшість великих невідомих на рядки початкового кошторису.

Аудит дешевий. Виявити борг посеред будівництва, ніколи.

Редизайн, перебудова чи аудит

Не кожен старий сайт потрібно викидати.

Іноді існуюча архітектура здорова, і проблема реально у фронтенді.

Іноді CMS все ще підходить бізнесу.

Іноді інтеграції чисті.

Іноді структура бази даних цілком адекватна.

У цих випадках перебудовувати все було б марнотратно.

Але якщо нові вимоги постійно конфліктують з існуючою архітектурою, питання змінюється.

Можливо, тобі не потрібен новий дизайн. Можливо, тобі потрібна нова структура.

Це інша проблема, і ми розбираємо її у статті Більшості компаній не потрібен новий сайт, їм потрібна нова структура.

Важливо визначити, в якій ситуації ти реально перебуваєш, до того, як почнеться розробка.

Кошторис на редизайн, побудований після реального технічного аудиту, може бути трохи вищим на старті.

Це не обов'язково проблема.

Це часто ознака того, що кошторис заснований на реальності.

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

Це припущення часто помилкове.

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

Графік стає реалістичнішим.

Бюджет стає передбачуванішим.

І клієнт розуміє, за що він реально платить.

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

Справжня ціна

Технічний борг зазвичай не надсилає один великий рахунок.

Спочатку він надсилає рахунки поменше.

Фіча займає більше часу.

Розробнику потрібно більше часу.

Міграція ускладнюється.

Реліз вимагає додаткового тестування.

Нова інтеграція стає «занадто ризикованою».

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

З часом ці маленькі витрати складаються у велику.

І найбільша витрата, можливо, зовсім не розробка.

Це може бути можливість, яку бізнес вирішує не переслідувати, бо система робить це занадто складним.

Технічний борг, тому, не просто інженерна проблема. Це обмежувач швидкості бізнесу.

Редизайн, це просто момент, коли це обмеження стає неможливим ігнорувати.

Якщо ти розглядаєш редизайн сайту, перше питання не повинно бути: «Скільки коштуватиме новий сайт?»

Воно повинно бути: «Що саме ми перебудовуємо?»

Перш ніж затверджувати бюджет, зрозумій, що вже є, що можна зберегти, що потрібно перенести, що потрібно перебудувати і що варто прибрати повністю.

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

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

Мультимовна перебудова несе свою версію цієї проблеми, ми розбираємо її у статті Чому мультимовні сайти потребують іншого підходу до дизайну.

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

Забронювати Стратегічну сесію