Що таке технічний борг і як він впливає на бізнес

Уявіть будівлю яку зводили швидко і дешево. Фундамент закладали з економією на матеріалах, стіни вирівнювали "на око", комунікації прокладали як зручніше а не як правильно. Поки будівля нова — все виглядає нормально. Але з часом тріщини збільшуються, труби течуть, електрика барахлить. Кожен ремонт стає складнішим бо доводиться враховувати всі попередні компроміси. Це і є технічний борг тільки в програмному забезпеченні.

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

Термін "технічний борг" ввів розробник Ворд Каннінгем у 1992 році. Він описав ситуацію коли команда свідомо обирає швидке але недосконале рішення замість правильного — і "позичає" час у майбутнього розвитку продукту. Як і фінансовий борг, технічний борг потрібно повертати — і з відсотками у вигляді зростаючої складності підтримки.

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

Як виникає технічний борг

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

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

Застарілі технології. Бібліотеки і фреймворки які не оновлюються, deprecated API, підходи які вважалися стандартом п'ять років тому але вже не відповідають сучасним вимогам — все це форма технічного боргу.

Відсутність документації і тестів. Код без тестів важко змінювати безпечно. Код без документації важко розуміти. Кожна зміна в такому коді несе ризик непередбачених наслідків.

Ротація команди. Коли розробники йдуть вони забирають з собою розуміння архітектурних рішень. Нові розробники не знають контексту і приймають рішення які конфліктують з існуючою архітектурою.

Як технічний борг впливає на бізнес

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

Сповільнення розробки. Найбільш відчутний ефект. Команда яка могла випускати нові функції за тиждень починає витрачати місяць. Кожна нова функція вимагає розуміння і обходу існуючих обмежень. Прості зміни стають складними через заплутану кодову базу.

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

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

Складність найму. Досвідчені розробники уникають проєктів з репутацією поганої кодової бази. А ті хто приходить витрачають більше часу на онбординг.

Як управляти технічним боргом

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

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

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

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

Технічний борг — неминуча частина розробки програмного забезпечення. Мета не в тому щоб його повністю уникнути а в тому щоб свідомо ним управляти і не дозволяти йому накопичуватися до рівня коли він починає загрожувати продукту.