Більшість засновників ставляться до технічного боргу так само, як до юридичних ризиків: він існує, хтось має ним займатися, а найкращий час для цього настане на наступному етапі проєкту.
Стартапи рідко обирають технічний борг свідомо. Вони успадковують його від учорашнього дедлайну.
За даними дослідження McKinsey & Company, директори з ІТ стверджують, що технічний борг становить від 20% до 40% загальної вартості їхнього технологічного портфеля до амортизації. Це не є характерною рисою саме стартапів на ранніх стадіях. Це відбувається, коли рішення щодо прийнятних компромісів залишається непомітним. Рецензоване лонгітюдне дослідження зафіксувало, що розробники витрачають у середньому 23% робочого часу саме через це (Besker, Martini та Bosch). Вартість боргу непомітно накопичується протягом кожного спринту, доки не виявиться під час комплексної перевірки або невдалого масштабування.
Що таке технічний борг у стартапах?
Технічний борг – це майбутні витрати, які стартап приймає, коли технічне рішення робить подальшу розробку, підтримку або масштабування дорожчими. Іноді цей компроміс є навмисним: команда обирає швидкість зараз і погоджується на додаткову роботу пізніше. Іноді борг виникає випадково, коли змінюються продукт, архітектура або вимоги.
Уорд Каннінгем запропонував цей термін у 1992 році, вдавшись до навмисної фінансової аналогії. «Невеликий борг пришвидшує розробку», — писав він, «якщо його вчасно погасити переписуванням. Небезпека виникає тоді, коли борг не погашається». Мартін Фаулер пізніше відобразив цю ідею за двома осями: свідомий чи ненавмисний, необачний чи виважений. Найнебезпечнішим є необачний та ненавмисний борг. Це компроміси, довгострокових наслідків яких ніхто не усвідомлює.
Найприйнятнішим є виважений та свідомий борг: узятий навмисно, вже з прив’язаним планом погашення.
Технічний борг також приховує вартість, яку компанія вже оплатила. Дослідження Deloitte називає це «прихованим потенціалом»: часткою вартості технологій, яка залишається заблокованою і недоступною через те, що складність боргу приховує її. Ідеться про функції, наполовину побудовані на хиткому фундаменті, дані, які ніхто не може легко запитати, інтеграції, яким ніхто не довіряє достатньо, щоб на них будувати. Погашення технічного боргу – це не просто уникнення майбутніх витрат. Йдеться про повернення цінності, яку компанія вже профінансувала.
Чи завжди технічний борг є поганим?
Ні. Хороший технічний борг є свідомим, задокументованим і тимчасовим. Стартап, який витрачає зайві три місяці на побудову ідеально масштабованої архітектури для продукту, який ще ніхто не валідував, зазвичай приймає гірше рішення, ніж той, хто запускає недосконалу версію й дізнається, чи вона комусь потрібна. Борг робить небезпечним не його існування, а його невидимість.
Важливою є відмінність між тим, чи знає конкретна людина, який борг існує, і чи є в неї план щодо його погашення. Документований борг за своєю природою є керованим. Недокументований борг має бути виявлений, перш ніж ним взагалі можна буде керувати, оскільки виявлення зазвичай відбувається у найневідповідніший момент.
Два способи виникнення та п’ять місць накопичення технічного боргу
Технічний борг у стартапах можна розділити на дві категорії за походженням:
Свідомий борг
Компроміс, прийнятий навмисно: команда розуміє трейдоф і знає, що знадобиться для його погашення. Найприйнятніший тип, оскільки він видимий із самого початку.
Випадковий борг
Компроміс, якого ніхто свідомо не обирав: зазвичай результат рішення, прийнятого без усвідомлення його довгострокових наслідків. Такий борг спочатку потрібно виявити, перш ніж з ним розбиратися, тому він небезпечніший за свідомий борг аналогічного масштабу.
Технічний борг можна розділити на п'ять категорій за сферою:
Архітектурний борг
Структурне рішення, як-от монолітна архітектура або тісно пов’язані сервіси, стає дорогим для зміни, щойно інші рішення будуються поверх нього. Саме цей тип найчастіше перетворює перехід до масштабування на повне переписування замість оновлення.
Інфраструктурний борг
Тимчасові інфраструктурні рішення, зокрема один сервер або ручний процес розгортання, були розумними при низькому навантаженні, але стають неприйнятними при вищому. Рідко відчувається як щось термінове, поки раптом не стає саме таким.
Борг документації
Рішення та системи, які ніхто не зафіксував. Через це онбординг нового інженера або партнера-CTO стартапу відбувається набагато повільніше, ніж мав би. А логіка минулих рішень зникає разом із тими, хто їх ухвалював.
Борг тестування
Автоматизоване тестування, пропущене заради прискорення релізу: невелика швидкість у короткостроковій перспективі та зростаючий ризик щоразу, коли нетестований код зачіпають.
Борг безпеки
Практики безпеки, відкладені через тиск дедлайнів. Цей тип технічного боргу найчастіше стає не сповільненням, а загрозою для існування бізнесу. Його відкладені витрати найменш передбачувані.
Архітектурний борг і борг безпеки з часом не залишаються керованими так, як це може бути з боргом документації або тестування. Архітектурний борг, який працював при десяти користувачах, може перетворити раунд Series A на структурне переписування замість інвестиційної події. Борг безпеки, який здавався незначним на стадії seed, може стати проблемою відповідності або зламом на стадії зростання. Обидва потребують відповідальної особи та прив’язаного до них терміну погашення, а не командного припущення.
Хто керує технічним боргом у стартапі
Спільна відповідальність за технічний борг нічим не відрізняється від її відсутності. Технічне керівництво ним оперує: конкретна людина з реальними повноваженнями щодо архітектурних рішень.
Розробник може піти на компроміс під тиском дедлайну, і це часто правильний вибір. Ризик починає наростати тоді, коли рішення про важливі компроміси залишається на розсуд того, хто працює над відповідною частиною кодової бази. Це не відповідальність. Це розмитість, і саме через розмитість борг стає невидимим, поки не виявиться під час due diligence.
На практиці ця відповідальність лежить на CTO-партнері стартапу до того моменту, поки компанія не зможе найняти фахівця, або на технічному співзасновнику з найперших архітектурних рішень. Структура управління не має бути складною. Вона повинна мати назву.
Ланцюг управління технічним боргом
Top Netics працює як CTO-партнер стартапів та студія технічного співзасновництва венчурів у сфері ШІ, блокчейну, фінтеху та комп’ютерного зору у семи країнах. Наш ланцюг управління сформований на основі архітектурних рішень, прийнятих в умовах обмежень фінансування, найму та продуктових дедлайнів у венчурах.
Top Netics використовує його як діагностичний інструмент для оцінки боргової позиції стартапу та як систему координат для будь-якого майбутнього архітектурного або due diligence рішення:
Компроміс, який неможливо простежити далі першого кроку, не є свідомим рішенням щодо боргу. Це випадковість у процесі.
П’ять звичок, що тримають борг під контролем
Управління технічним боргом не потребує складного інструментарію чи окремої команди. Воно потребує п’яти звичок, послідовно застосовуваних від першого архітектурного рішення.
Ідентифікація: Назвіть місця, де існують компроміси, до того, як вони проявляться у вигляді збою, проваленого аудиту або питання під час due diligence. Борг, який не можна назвати, не можна пріоритизувати.
Пріоритизація: Не весь борг однаково небезпечний. Борг безпеки та архітектурний борг, що блокують масштабування, важливіші за безладний, але малонавантажений внутрішній інструмент. Це оцінне рішення належить технічному керівництву.
Документування: Записуйте, який компроміс був прийнятий і чому. Технічний співзасновник або новий інженер, який може прочитати логіку минулих рішень, починає повноцінно працювати за кілька тижнів. Без цього вони починають з нуля.
Відповідальність: Одна конкретна людина відповідає за відстеження та погашення боргу. Не загальне відчуття, що команда колись до цього дійде. Спільна відповідальність за технічний борг нічим не відрізняється від її відсутності.
Стратегія погашення: Реальний план, прив’язаний до роадмапу, з конкретними позиціями, запланованими до погашення. Борг, якого немає у роадмапі, не погашається. Він успадковується.
Коли технічний борг стає реальною проблемою
Інженери помічають технічний борг значно раніше, ніж дашборди.
Перший сигнал: вартість змін. Фічі, які мали б займати години, займають дні, бо інженери змушені обходити попередні рішення, перш ніж зробити нові. Здавалося б незначні зміни стають непропорційно дорогими. Це і є показник. Коли вартість зміни визначається тим, що вже існує, а не тим, що будується, борг вже керує розробкою.
Другий сигнал: уникнення систем. Той самий тип помилки з’являється знову після виправлення. Ще показовіше: інженери починають уникати певних частин кодової бази, бо кожна зміна там створює непередбачувані наслідки в іншому місці. Команда, яка позначила частини системи як «не чіпати без крайньої потреби», задокументувала свій борг точніше, ніж більшість трекінгових інструментів.
Третій сигнал: організаційний. Новий співробітник витрачає тижні на розуміння кодової бази, перш ніж щось зробити. Саме тут незадокументована архітектура перестає бути питанням якості коду і стає організаційним обмеженням.
Бізнесовий поріг настає пізніше і відрізняється за природою. Технічний борг стає реальною проблемою, коли ці інженерні обмеження починають обмежувати рішення компанії: фіча потребує переписування, перш ніж її можна запустити; інфраструктура не витримує наступного етапу зростання; прогалина в безпеці блокує корпоративного клієнта або вимогу відповідності; кількість інженерів зростає без відповідного зростання продуктивності; або due diligence виявляє ризики, про які керівництво не знало.
У цей момент компанія вже не несе технічного боргу. Борг визначає, що компанія може зробити далі.
Коли робити рефакторинг
Не «коли буде час». Цей момент рідко настає сам по собі.
Правильним тригером є чітко визначене рішення: вартість певної суми боргу тепер перевищує вартість його погашення. Цей розрахунок зазвичай зосереджений на етапах фінансування. Борг на стадії seed, як правило, переживається. Борг на стадії Series A починає обмежувати рішення щодо найму та масштабування. Неврегульований борг на етапі зростання зазвичай означає вимушену реструктуризацію, яка поглинає пропускну здатність, необхідну компанії для розробки продукту. Рішення про рефакторинг ухвалює та сама людина, яка відповідає за борг.
Два методи, що працюють
Жоден із них не потребує зупинки розробки. Обидва потребують конкретного технічного власника боргу, який послідовно їх застосовує.
Патерн Strangler Fig: Побудуйте нову систему поруч зі старою, поступово перенаправляйте трафік від старої до нової та демонтуйте стару лише тоді, коли нова обробляє все. Це дозволяє стартапу погашати архітектурний борг поетапно, зберігаючи робочий продукт у кожний момент часу, а не робити ставку на одне велике переписування, яке майже завжди займає більше часу, ніж заплановано, і породжує нову кодову базу з іншим набором проблем.
Netflix вдався до патерну Strangler Fig, коли Reloaded, його семирічна платформа медіаобробки, більше не встигала за компанією, яку вона переросла. Reloaded будувалася для невеликої команди, яка працювала над одним сценарієм використання, а саме конвеєром обробки відео та аудіо, на обмеженому обчислювальному кластері. Замість того, щоб ризикувати повним переписуванням, Netflix побудував нову платформу Cosmos і дозволив їй поступово охоплювати Reloaded по одному сервісу за раз, перенаправляючи трафік поступово, а не вмикаючи перехід одразу. Патерн дав Netflix те, чого монолітні міграції зазвичай не можуть обіцяти: безперервну роботу системи для студій та партнерів, на яких вони покладаються, без єдиної точки, де весь конвеєр мав би зупинитися для переходу.
Правило бойскаута: Щоразу, коли ви торкаєтеся коду, залишайте його трохи кращим, ніж ви його знайшли. Це не замінить продуманого плану погашення. Це запобігає швидшому накопиченню боргу, ніж можуть врахувати заплановані платежі. Невеликі, послідовні покращення накопичуються так само, як і борг, тільки в правильному напрямку.
Як технічний борг впливає на залучення фінансування та due diligence
Технічний борг може послабити позиції під час залучення фінансування, збільшуючи технічний ризик, який інвестори виявляють під час due diligence. Неякісна архітектура, прогалини в безпеці, незадокументовані системи, обмеження масштабованості або накопичені обхідні рішення можуть сигналізувати про майбутні витрати на переписування, повільніше зростання та додаткові інвестиції в інженерію, що може вплинути на впевненість інвесторів, умови угоди, оцінку або на те, чи взагалі відбудеться інвестиція.
Уявіть двох засновників на однаковій стадії, обоє залучають Series A для фінтех-продуктів із зіставними показниками виручки. Один приходить на due diligence здатним назвати архітектурні рішення, прийняті компроміси та план погашення для найважливіших позицій. Другий не може відповісти, який борг існує, бо ніхто його не відстежував. Однакова стадія. Однакова виручка. В одного є конкретний технічний власник з інвентаризацією боргу та термінами. У другого лише дифузне командне припущення, що хтось за цим стежив.
Технічний радник виявляє різницю впродовж перших тридцяти хвилин огляду кодової бази. Перша розмова може просунути due diligence вперед. Друга породжує уточнювальні запитання, поки інвестор намагається встановити розмір і вартість невідомого технічного ризику. У деяких угодах це може затримати процес або вплинути на умови, щойно витрати на усунення стануть зрозумілими.
Процес технічного due diligence побудований саме для того, щоб виявити це. Технічний радник шукає не ідеальну систему. Він шукає докази того, що борг, який існує, був прийнятий свідомо, що хтось знає, що це таке, і що є план погашення для позицій із найбільшими бізнесовими наслідками.
Коли інвестори запитують про технічний ризик, вони ставлять проксі-запитання. Вони хочуть знати, чи може команда виконувати технічні завдання без неочікуваних сюрпризів. Дайте відповідь прямо: назвіть, хто відповідає за рішення щодо боргу, який борг існує наразі та який термін погашення для позицій із найбільшими наслідками. Ось і вся розмова. Не якість коду в абстрактному сенсі.
Чи змінює ШІ-кодинг принципи роботи з технічним боргом?
Так, і в обох напрямках. ШІ-інструменти прискорюють створення технічного боргу, оскільки робочий, але недбалий код тепер можна згенерувати майже миттєво. Водночас вони прискорюють його погашення, оскільки ці ж інструменти справді здатні на рефакторинг у кодовій базі, яку хтось вже розуміє.
ШІ прискорює написання боргу. Він не спрощує відповідальності за нього.
Конкретний ризик полягає у прийнятті ШІ-згенерованого коду без архітектурного огляду, що іноді називають «vibe coding». Результатом є кодова база, повна боргу, якого ніхто насправді не розуміє, включно з інженерами, які його номінально написали. Інженери, які не можуть пояснити систему, в якій працюють, не можуть безпечно її змінювати, не привносячи нових збоїв. Нові співробітники, яких наймають для прискорення виходу, витрачають перші місяці на зворотну розробку того, що існує. Операційні витрати боргу наростають через процес найму.
Дослідження Deloitte формулює ширший висновок прямо: більшість організацій не можуть накласти ШІ-ініціативи поверх застарілого фундаменту й очікувати, що фундамент покращиться. ШІ змінює швидкість написання коду. Він не скасовує вимогу, щоб хтось відповідав за архітектурні рішення, включно з тими, що генеруються інструментом. Навпаки, вимога до управління зростає, коли ШІ прискорює виробництво, бо обсяг рішень, які потребують власника, зростає швидше, ніж будь-який окремий інженер може їх охопити.
Визначте відповідальність за технічний борг
Чи є у вашій структурі конкретна людина, яка відповідає за те, які компроміси є прийнятними, які фіксуються документально та які погашаються до того, як вони проявляться під час due diligence або відмови від масштабування? Якщо відповідальність за борг є дифузною, спільною для команди або просто незакріпленою, це і є прогалина. Для її усунення не потрібен штатний найм. Потрібні конкретна людина з реальними повноваженнями та ланцюг управління технічним боргом, застосований до кожного компромісу відтепер.
Технічний борг не знищує компанії. Некерований технічний борг, виявлений у невідповідний момент, знищує.
