Технічний борг — це майбутня вартість компромісів і коротких шляхів, обраних сьогодні під час розробки програмного забезпечення: написаний поспіхом код, відсутні тести, застарілі залежності, архітектура, розрахована на меншу компанію, ніж вона є зараз. Як і фінансовий борг, він виграє час одразу й генерує відсотки пізніше: кожна зміна коштує більше зусиль і несе більше ризику, поки хтось не вирішить його погасити. Якщо вам потрібно знати, скільки боргу несе ваша система і де саме, це завдання для технічного due diligence програмного забезпечення.
Цей гайд пояснює, звідки береться технічний борг, які сигнали дозволяють CTO або підприємцю виміряти його, не читаючи код, скільки коштує його ігнорування за даними наявних публічних досліджень і коли доцільно залучити фахівців ззовні.
Стисло
- Термін виник у 1992 році завдяки Уорду Каннінгему: код, який «ще не зовсім правильний», — це борг, а кожна хвилина, витрачена на обхідні шляхи, — це сплачені відсотки.
- Не весь технічний борг є помилкою: борг, узятий свідомо, щоб раніше вийти на ринок, — це вибір. Проблема — у боргу, який ніхто не фіксує і ніхто не повертає.
- Він вимірюється сигналами поставки (швидкість і стабільність релізів), коду (тести, залежності, крихкі ділянки) та організації (незапланована робота, залежність від кількох людей).
- В опитуванні McKinsey 2020 року CIO оцінювали, що 10–20% технологічного бюджету на нові продукти йшло на вирішення проблем технічного боргу.
- Інкрементний рефакторинг і повний перепис — це два різні шляхи його погашення: вибір робиться на основі фактів, а не віку коду.
Що таке технічний борг?
Технічний борг — це розрив між тим, як програмне забезпечення побудоване сьогодні, і тим, як воно має бути побудоване, щоб змінюватися швидко та безпечно. Щоразу, коли обирається найшвидше рішення замість найнадійнішого, час позичається в майбутнього. Позика повертається з відсотками: частіші баги, повільніші релізи, розробники, які витрачають дні на розшифровку коду замість його покращення.
Метафора належить Уорду Каннінгему, який у 1992 році, презентуючи систему WyCash на конференції OOPSLA, написав, що випуск коду з першої чернетки подібний до взяття боргу: трохи боргу прискорює розробку, за умови, що його швидко погасять переписом; небезпека виникає тоді, коли борг не повертається, бо кожна хвилина, витрачена на «не зовсім правильний» код, зараховується як відсоток.
Метафора працює, тому що говорить мовою бізнесу. CFO не потрібно знати, що таке тісно зв'язаний модуль, щоб зрозуміти: незафіксований борг зі зростаючою відсотковою ставкою — це ризик, який має бути в балансі компанії.
Які типи технічного боргу існують?
Найкориснішим способом його класифікації залишається квадрант, запропонований Мартіном Фаулером у 2009 році, який перетинає два питання: борг було взято свідомо чи ні? І обачно чи легковажно?
| Легковажний | Обачний | |
|---|---|---|
| Свідомий | «У нас немає часу на проєктування.» | «Ми повинні випустити реліз зараз і розберемося з наслідками.» |
| Несвідомий | «Що таке багаторівнева архітектура?» | «Тепер ми знаємо, як це треба було зробити.» |
Квадрант роз'яснює думку, яку часто розуміють неправильно: обачний і свідомий борг — нормальне явище для будь-якого продукту, який має вийти на ринок. Несвідомий і обачний борг неминучий, бо команда по-справжньому розуміє проблему лише після того, як розв'яже її вперше. Борг, якого слід уникати, — це легковажний борг, і особливо той, який ніхто ніколи не фіксував.
На практиці борг накопичується в чотирьох зонах:
- Код: дублювання, величезні функції, бізнес-логіка, розкидана всюди, відсутність автоматичних тестів.
- Архітектура: компоненти настільки тісно зв'язані, що зміна в одному місці ламає щось в іншому.
- Інфраструктура та залежності: бібліотеки, фреймворки, бази даних та операційні системи, підтримка яких завершилася.
- Знання: відсутня документація та частини системи, які вміє змінювати лише одна людина.
Звідки береться технічний борг?
Технічний борг рідко виникає через некомпетентних розробників. Він виникає з розумних рішень, ухвалених під тиском і ніколи не переглянутих:
- Комерційні дедлайни, які змушують випускати першу робочу версію без часу на те, щоб потім дати їй лад.
- Вимоги, які змінюються швидше за архітектуру: софт залишається спроєктованим під бізнес, якого більше не існує.
- Плинність кадрів у команді та серед підрядників, коли знання йдуть разом із людьми.
- Відсутність автоматичних тестів, яка перетворює кожну зміну на лотерею і відбиває бажання в тих, хто хотів би покращити код.
- Відкладені оновлення бібліотек і платформ, поки стрибок через версії не стане окремим проєктом.
- Код, згенерований поспіхом, зокрема за допомогою ШІ-асистентів, і прийнятий без senior-рев'ю тестів, залежностей та безпеки.
Коли ці причини накопичуються роками, борг перетворює програмне забезпечення на legacy-систему: досі критичну для бізнесу, але дедалі складнішу для змін.
Як виміряти технічний борг?
Не існує єдиного числа, яке вимірювало б технічний борг, і не довіряйте тим, хто його обіцяє. Проте існують конкретні сигнали, які CTO або підприємець без технічної підготовки може перевірити за кілька тижнів. Разом вони показують, скільки боргу є і де саме.
Сигнали поставки. Метрики поставки дослідницької програми DORA — найнадійніша відправна точка, бо вони вимірюють наслідки боргу, а не сам борг:
- час від зміни в коді до її появи в продакшені;
- частота релізів;
- відсоток релізів, які потребують негайного втручання, як-от rollback або термінове виправлення;
- час, потрібний для відновлення сервісу після невдалого релізу;
- частка незапланованих релізів, зроблених лише для усунення інциденту в продакшені.
Якщо релізи сповільнюються й ламаються частіше, а команда залишається тією самою, борг зростає.
Сигнали коду.
- Покриття автоматичними тестами потоків, які приносять дохід або обробляють чутливі дані, а не середній відсоток по всьому коду.
- Залежності, фреймворки та версії баз даних без підтримки або з відомими вразливостями.
- «Гарячі точки»: файли, які змінюються найчастіше і водночас є найскладнішими. Саме там борг коштує найдорожче, бо відсотки сплачуються при кожній зміні.
- Час збірки та запуску середовища розробки.
Інструменти статичного аналізу, як-от SonarQube, оцінюють борг у робочих днях за методами, похідними від SQALE. Вони корисні для відстеження динаміки в часі, менше — для ухвалення рішень: вони не знають, які частини коду важливі для бізнесу.
Організаційні сигнали.
- Частка роботи кожного спринту, витрачена на баги та незаплановані завдання.
- Частини системи, які вміє змінювати лише одна людина.
- Кількість тижнів, потрібних новому розробникові, щоб випустити свою першу зміну в продакшен.
- Оцінки, які систематично помиляються в один і той самий бік на одних і тих самих ділянках системи.
Скільки коштує ігнорування технічного боргу?
Вартість технічного боргу конкретної системи можна оцінити, лише проаналізувавши її. Публічні дослідження, однак, дають порядок величин, і їх варто цитувати разом із їхнім обсягом:
| Дослідження | Що вимірювалося | Результат |
|---|---|---|
| McKinsey, «Tech debt: Reclaiming tech equity» (жовтень 2020) | Опитування 50 CIO компаній фінансового та технологічного секторів із доходом понад 1 млрд доларів | 10–20% технологічного бюджету на нові продукти перенаправляється на проблеми технічного боргу; борг становить 20–40% вартості технологічних активів до амортизації; у 60% CIO він зріс за останні три роки |
| Stripe, «The Developer Coefficient» (вересень 2018) | Опитування Harris Poll понад 1000 розробників і понад 1000 керівників у США, Великій Британії, Франції, Німеччині та Сінгапурі | При середньому робочому тижні 41,1 години розробники оцінюють 17,3 години на підтримку (налагодження, рефакторинг) і 13,5 години на технічний борг |
| CISQ, «The Cost of Poor Software Quality in the US: A 2022 Report» (грудень 2022) | Макроекономічна оцінка для США | Накопичений технічний борг близько 1,52 трлн доларів; загальна вартість низької якості ПЗ не менше 2,41 трлн доларів у 2022 році |
| Уряд Великої Британії, State of Digital Government Review (січень 2025) | Технологічний парк центрального уряду | Близько 28% систем класифіковано як legacy; деякі організації витрачають до 70–85% технологічного бюджету на підтримку |
Ці цифри — не вартість вашого ПЗ. Проте вони говорять одне й те саме: технічний борг не стоїть на місці. Відсотки сплачуються часом розробників, бюджетом, відібраним у нових функцій, та операційним ризиком — і вони зростають, якщо ними ніхто не керує. Британський кейс показує, чим це закінчується: коли майже весь бюджет іде на підтримку життя наявних систем, на їх зміну не залишається нічого.
Є також вартість, якої таблиці не фіксують: безпека. Компоненти без підтримки більше не отримують патчів, а система, до якої ніхто не наважується доторкнутися, — це система, яку ніхто не оновлює.
Технічний борг в Agile і Scrum: як керувати ним у беклозі
У командах Agile технічний борг зростає, коли залишається невидимим: у користувацьких історій є product owner, який їх захищає, в елементів боргу — ні. Три практики повертають його під контроль:
- Фіксувати його в беклозі, як будь-яку іншу роботу, з описом впливу на бізнес, оцінкою та відповідальним.
- Виділяти фіксовану частку кожного спринту на погашення замість сподівань на «технічний спринт», який ніколи не настає.
- Включити його до Definition of Done: функція не завершена, якщо залишає по собі відсутні тести або застарілі залежності.
Пріоритет варто надавати боргу в ділянках, які змінюються найчастіше та спричиняють найбільше інцидентів, а не коду, який просто виглядає найгірше. Старий, але стабільний модуль, якого ніхто не торкається, може зачекати.
Рефакторинг чи перепис: як погашається технічний борг?
Є два шляхи погашення технічного боргу: рефакторинг, який покращує структуру наявного коду без зміни його поведінки, і перепис, який замінює компонент або всю систему.
- Інкрементний рефакторинг: правильний шлях у більшості випадків. Додаються тести на критичні потоки, потім покращується одна частина за раз, починаючи з гарячих точок. Бізнес не зупиняється, і кожен крок зворотний.
- Поступова заміна (strangler fig): нові функції будуються навколо старої системи за стабільними інтерфейсами, і відповідальність переноситься частина за частиною, поки старий компонент не можна буде вимкнути.
- Повний перепис: виправданий, коли фундамент більше не витримує навантаження, технологія більше не підтримується або бізнес-модель змінилася. Це також варіант із найбільшим ризиком, бо протягом місяців доводиться підтримувати дві системи.
Питання, які визначають вибір між цими варіантами, зібрані в нашому фреймворку rewrite чи refactor, написаному для CTO компаній середнього бізнесу.
Коли варто замовляти аудит технічного боргу?
Зовнішній аудит потрібен тоді, коли борг перестав бути темою інженерної команди і став темою бізнесу. Типові ознаки:
- кожен реліз приносить інциденти, а команда боїться торкатися певних частин системи;
- оцінки нових функцій зростають, хоча обсяг не змінюється;
- критична частина системи залежить від однієї людини — штатної або в підрядника;
- потрібно вирішити, чи робити перепис, а думки всередині компанії розділилися;
- ви збираєтеся придбати компанію або програмний продукт, або інвестор запитує про реальний стан технології;
- регуляції, як-от NIS2, або вимоги клієнтів зобов'язують показати, як ви керуєте безпекою та оновленнями.
У цих випадках технічний due diligence працюючого програмного забезпечення показує, що під загрозою, скільки коштує виправлення та в якій послідовності, з письмовим звітом за два–чотири тижні. Це спосіб перетворити технічний борг із відчуття на рядок бюджету: перелік проблем, упорядкованих за впливом на бізнес, з оцінкою зусиль для кожної. У кейсі Neotecnica, наприклад, аудит коду та безпеки завершився аналізом понад 13 000 проблем і усуненням понад 19 вразливостей.
Якщо ж борг уже перевищив межу безпеки, і система ламається в продакшені, поки бізнес має продовжувати нею користуватися, наступний крок — стабілізація legacy-програмного забезпечення: систематичне усунення того, що ламається, тести на критичних потоках і релізи, які знову стають передбачуваними, без зупинки операційної діяльності.
Хочете зрозуміти, скільки технічного боргу несе ваше ПЗ і з чого варто почати його погашення? Напишіть нам: ви поговорите з нашою інженерною командою, і ми скажемо, чи потрібен вам аудит, стабілізація, чи ваша команда може впоратися самостійно.
Зв'язатися з нашою інженерною командою →
Джерела
- Ward Cunningham, «The WyCash Portfolio Management System», experience report OOPSLA '92 (1992): c2.com
- Martin Fowler, «Technical Debt Quadrant», 14 жовтня 2009: martinfowler.com
- McKinsey & Company, «Tech debt: Reclaiming tech equity», 6 жовтня 2020 (переглянуто 7 жовтня 2026): mckinsey.com
- Stripe, «The Developer Coefficient», вересень 2018 (переглянуто 7 жовтня 2026): stripe.com
- CISQ, «The Cost of Poor Software Quality in the US: A 2022 Report», із пресрелізом Synopsys від 6 грудня 2022 (переглянуто 7 жовтня 2026): it-cisq.org
- Департамент науки, інновацій та технологій Великої Британії, «State of digital government review», 21 січня 2025: gov.uk
- DORA, «DORA's software delivery performance metrics», оновлено 5 січня 2026 (переглянуто 7 жовтня 2026): dora.dev
