[Зміст]Показати зміст
Tech debt — як іпотека: у малих дозах підйомний, смертельний, коли ігноруєш відсотки. Більшість компаній не знає навіть місячного платежу. Не мають технічного балансу, не рахують відсотки, не планують погашення. Дізнаються про масштаб у п’ятницю о 17:00, коли система падає і ніхто не вміє її підняти.
У Do More Soft ведемо rescue missions уже п’ять років — рятуємо проєкти, які інші покинули. Бачили кожен рівень боргу, від косметичного до термінального. Нижче фреймворк, що говорить прямо: рятувати чи переписати з нуля за 8 тижнів.
5 рівнів технічного боргу
Кожен рівень має операційний наслідок — не теоретичний, вимірюваний у спринтах.
- Косметичний — непослідовне іменування, відсутність коментарів. На 10-20% повільніше, але без prod fires.
- Структурний — відсутність розділення шарів, відсутність тестів. Feature триває втричі довше, регресія щоспринту.
- Архітектурний — моноліт без API, база як integration point. Кожна інтеграція — проєкт на квартал.
- Інфраструктурний — нуль CI/CD, ручний деплой через FTP. П’ятничний деплой = російська рулетка.
- Термінальний — мертва технологія, нуль тестів, оригінальна команда пішла. 80% ІТ-бюджету на підтримку, розвиток практично заморожений.
Рівень 1: Косметичний
Неоптимальні SQL-запити, дублювання, відсутність коментарів. Система працює коректно, неприємна в підтримці. Лікування: рефакторинг у межах звичайних спринтів, без виділеного бюджету. Кожен проєкт має цей рівень — і це нормально.
Рівень 2: Структурний
UI перемішаний з бізнес-логікою, відсутність тестів, hardcoded config. Система працює, але кожна зміна вимагає модифікації в 5 місцях і генерує регресію. Лікування: виділений рефакторинговий спринт раз на 4-6 тижнів.
Рівень 3: Архітектурний
Моноліт, що не масштабується. База як integration point — системи комунікують через shared database. Нуль API, нуль інтеграцій. Нові функціональності тривають у 3-5 разів довше. Лікування: виділення критичних модулів в окремі сервіси, шар API. 2-4 місяці роботи.
Рівень 4: Інфраструктурний
Без CI/CD, деплой через FTP, продакшн на одному сервері без бекапу, нуль моніторингу. Система працює за принципом «хай ніхто цього не торкає». Ризик catastrophic failure плюс повна залежність від однієї людини, яка «знає, як це працює». Лікування: побудова інфраструктури з нуля при живій системі — заміна двигуна в автомобілі на ходу. 1-3 місяці.
Рівень 5: Термінальний
Classic ASP, AngularJS, PHP 5. Нуль тестів, нуль документації, оригінальна команда пішла. Кожна зміна генерує непередбачувані побічні ефекти. Ніхто не розуміє системи цілком. Підтримка поглинає 80%+ ІТ-бюджету. Рішення бінарне: рятувати чи переписати.
Rescue Assessment Matrix — коли рятувати vs переписувати
Пройшли через це 30+ разів. Три з п’яти вимірів на 3+? Піддається порятунку. Три на 1-2? Переписування виграє. Коли приходить клієнт із проєктом «на порятунок», робимо 3-5 денний технологічний аудит і оцінюємо 5 вимірів за шкалою 1-5 (1 = на викид, 5 = міцно): якість бази даних, покриття тестами, дизайн API, інфраструктура, документація.
Правило рішення
Три з п’яти вимірів на 3+ — rescue mission. Рятуємо те, що добре, переписуємо те, що погане. Типова вартість: 40-60% бюджету повного переписування, термін: 2-4 місяці. Три виміри на 1-2 — переписування з нуля. Порятунок коштував би більше за нову систему і дав би гірший результат. База даних — точка важелю: якщо дані добре спроєктовані, решта відновлювана.
У проєкті automotive: база міцна (5/5), API legacy (1/5), тести нульові (1/5). Врятовано, бо 2 з 5 піддавалися порятунку — база і фронтенд. API і тести написали з нуля за 14 тижнів, клієнт зберіг дані та процеси.
Реальний TCO ігнорування боргу
Компанії, що ігнорують борг, платять відсотки в кожному вимірі TCO: повільніший time-to-market (конкуренція обганяє), 90% ІТ-бюджету на підтримку замість розвитку, залежність від ключових людей (відхід одного програміста паралізує проєкт), ризик catastrophic failure.
Найдорожча позиція в TCO боргу — вартість втрачених можливостей. Компанія, що могла б вивести продукт за 3 місяці, виводить його за 12 — бо 75% capacity команди поглинає битва з боргом. За цей час конкуренція займає ринок. Ця вартість невидима в балансі і болюча в квартальних результатах.
Рятувальний playbook: rescue mission крок за кроком
Тиждень 1: Аудит і стабілізація. Критичні вразливості безпеки, моніторинг, бекап, документація архітектури as-is.
Тижні 2-4: Рефакторинг пріоритетів. Відокремлюємо core logic від UI, тести для критичних шляхів, CI/CD pipeline.
Місяці 2-3: Модернізація. Нове API, міграція інфраструктури, усунення мертвого коду.
Місяць 4+: Розвиток. Нові функціональності на міцному фундаменті.
Правило 20%
П’ятничний спринт у DailyHair: 2 год рефактору, 1 год документації, 30 хв test coverage. Не опціонально. Це шаблон, який ми примушуємо виконувати в кожного клієнта з інженерною культурою.
Чому працює — кумулятивний ефект
20% capacity кожного спринту на погашення боргу. 20% сьогодні економить 200% за рік, бо кожен невикорінений компроміс блокує наступні архітектурні рішення. Команда, що регулярно погашає борг, швидша і пише кращий код. Клієнт платить за це двічі: раз нижчою вартістю підтримки, вдруге — вищим темпом фіч.
Як примусити — spike card, non-negotiable backlog
Spike card «Tech Debt 20%» у backlog кожного спринту, пріоритезована разом із фічами, а не після них. Definition of Done ідентичне до бізнес-сторі. Немає spike — спринт не стартує. Для компаній без технічної культури: одна п’ятниця на місяць виключно на cleanup («Tech Debt Fridays»). Це інвестиція в майбутню продуктивність, не втрата.
Робимо це самі
Q2 2026, velocity 45 SP. 9 пунктів на п’ятничний tech debt, 36 на фічі. При кожному новому проєкті показуємо клієнту лічильник боргу з попередньої системи — це зазвичай закінчує дискусію, чи 20% «справді потрібні».
FAQ
Що таке технічний борг і як його вимірювати? Відсоток ІТ-бюджету на підтримку замість розвитку. Понад 70% → червоний прапор.
Коли рефакторити, а коли переписувати? Rescue Matrix, 5 вимірів × шкала 1-5. Три на 3+ → rescue (40-60% вартості переписування). Три на 1-2 → переписування.
Що таке правило 20%? 20% capacity спринту на погашення боргу, spike card у backlog, не «якщо вистачить часу».
Скільки коштує компанії технічний борг? 60-90% ІТ-бюджету на підтримку. Найдорожча позиція — вартість втрачених можливостей.