Технічний борг є в кожного стартапу, і здебільшого це було правильне рішення. Питання не в тому, як його позбутися, а в тому, які його частини нараховують відсотки, яких ви вже не тягнете.
Затримки
Операційний ризик
Реєстр боргу
У технічного боргу погана репутація, якої він не цілком заслуговує. Піти навпростець, щоб швидше перевірити ідею, зазвичай правильно — альтернатива це ретельно будувати те, чого ніхто не хотів. Провал не в тому, щоб узяти борг; провал у тому, щоб ніколи не перевіряти відсоткову ставку.
Чотири види, а значення мають лише два
| Вид | Приклад | Вердикт |
|---|---|---|
| Свідомий і короткочасний | Захардкоджена логіка для перевірки попиту, згодом прибрана | Правильно — інструмент працює як треба |
| Свідомий і постійний | Скорочення зроблено свідомо і ніколи не переглянуто | Небезпечно — відсотки зростають беззвучно |
| Випадковий | Тоді ніхто не знав кращого способу | Нормально — виправляти, коли почне коштувати |
| Косметичний | Найменування, форматування, структурні вподобання | Ігнорувати повністю |
Як зрозуміти, що його стало забагато
Абсолютного порога немає; борг має сенс лише відносно того, що ви намагаєтеся зробити. Але ці сигнали надійно показують, що відсотки стали непідйомними:
- Оцінки для фіч однакового розміру постійно зростають — найчистіший кількісний сигнал
- Команда регулярно каже «цього не зробити на нинішній конструкції» про звичайні запити
- Баги раз за разом купчаться в тих самих модулях
- Онбординг нового інженера триває місяці, а не тижні
- Люди уникають чіпати певні файли, і всі знають які
- Розгортання збираються в пачки і плануються, бо вони ризиковані
Що погашати і коли
Борг варто гасити, коли він блокує щось конкретне, а не з принципу. Три правила, які працюють:
- Гасіть борг, що лежить на дорозі попереду. Якщо наступні два квартали проходять через модуль, приберіть у ньому, перш ніж там будувати. Борг у коді, якого ви не торкнетеся, не коштує нічого.
- Борг, що торкається грошей, даних чи авторизації, гасіть негайно, незалежно від роадмапу — відмови там невідновні, а не просто дратівливі.
- Рефакторте опортуністично. Покращуйте те, що й так змінюєте, замість планувати окремі проєкти прибирання, які під тиском ріжуть найпершими.
Бюджет, який працює
Універсальний відсоток підтримки не стабілізує борг автоматично. Плануйте ресурси за ризиками й дорожньою картою та переглядайте розподіл. Переписування — варіант для оцінки, а не обов'язковий результат аудиту.
Мета — не нульовий технічний борг. Мета — борг, який ви обрали, про який знаєте і який могли б погасити, якби роадмап цього вимагав.
Що казати інвесторам
Засновники часто намагаються приховати борг під час due diligence. Це б'є у відповідь: перевірка його знаходить, і відкриття коштує в переговорах більше, ніж коштувало б розкриття. Сильніша позиція — письмовий реєстр: який борг існує, що він блокує, скільки коштує усунення. Команда, здатна це сформулювати, читається як компетентна; команда, що заявляє про чисту кодову базу, читається або як наївна, або як ухильна.
Пріоритезуйте технічний борг на основі доказів
Огляд коду перевіряє реалізацію, архітектури — межі й роботу системи. Почніть із бізнес-рішення: чи витримає система наступний реліз або нових клієнтів? Оцініть наслідки, спостережувану частоту й зусилля. Активні проблеми безпеки чи цілісності даних розглядайте окремо як термінові.
| Зробіть рішення вимірюваним | Які докази погодити до початку |
|---|---|
| Затримки | Пов'яжіть зміну з модулями, очікуванням рев'ю та прогалинами тестів. Порівняйте схожі зміни до й після виправлення. |
| Операційний ризик | Перевірте інциденти, трасування й результати відновлення. Немає доступу — не перевірено, а не пройдено. |
| Реєстр боргу | Запишіть докази, уражений сценарій, відповідального, діапазон зусиль і тест підтвердження виправлення. |
Універсальний відсоток підтримки не стабілізує борг автоматично. Плануйте ресурси за ризиками й дорожньою картою та переглядайте розподіл. Переписування — варіант для оцінки, а не обов'язковий результат аудиту.
Часті запитання
Скільки технічного боргу нормально для стартапу?
Чимало, і зазвичай це правильно: швидкість на ранній стадії коштує більше за ранню відшліфованість. Проблема не в кількості, а в тому, чи борг відомий, свідомий і обмежений зонами, які не блокують роадмап і не торкаються грошей та даних.
Який відсоток інженерного часу має йти на технічний борг?
Універсальний відсоток підтримки не стабілізує борг автоматично. Плануйте ресурси за ризиками й дорожньою картою та переглядайте розподіл. Переписування — варіант для оцінки, а не обов'язковий результат аудиту.
Чи варто зупиняти фічі, щоб виправити технічний борг?
Майже ніколи. Окремі проєкти прибирання важко обґрунтувати, важко завершити і їх скасовують першими. Виняток — борг, що активно втрачає гроші або дані: він зупиняє все, доки не буде виправлений.
Не впевнені, який борг справді важливий?
Ми проводимо його тріаж відносно вашого роадмапу — що блокує, що коштує грошей, що краще не чіпати.
Читати далі за темою
Як полагодити зламане MVP (не починаючи з нуля)
Майже кожен засновник зі зламаним MVP питає, чи не переписати його. Майже щоразу відповідь — ні, і причина в арифметиці, а не в сентиментах.
Аудит архітектури системи: коли він потрібен і що знаходить
Аудит архітектури — це не думка про ваш стек. Це карта того, де система ламається під планом, який ви справді маєте.