Всеки стартъп има технически дълг и по-голямата част от него е било правилното решение. Въпросът не е как да го премахнете, а кои части начисляват лихва, която вече не можете да си позволите.
Забавяния
Оперативен риск
Регистър на дълга
Техническият дълг има лоша слава, която не съвсем заслужава. Да минете по пряк път, за да валидирате идея по-бързо, обикновено е правилно — алтернативата е да строите грижливо към нещо, което никой не е искал. Провалът не е в поемането на дълга; провалът е никога да не проверите лихвения процент.
Четирите вида, а значение имат само два
| Вид | Пример | Присъда |
|---|---|---|
| Съзнателен и краткотраен | Твърдо зашита логика за тест на търсенето, после премахната | Правилно — инструментът работи както трябва |
| Съзнателен и постоянен | Пряк път, поет съзнателно и никога преразгледан | Опасно — лихвата се натрупва беззвучно |
| Случаен | Тогава никой не е знаел по-добър начин | Нормално — да се поправи, когато започне да струва |
| Козметичен | Именуване, форматиране, структурни предпочитания | Да се игнорира изцяло |
Как да разберете, че е станал твърде много
Няма абсолютен праг; дългът има смисъл само спрямо това, което се опитвате да направите. Но тези сигнали надеждно показват, че лихвата е станала непосилна:
- Оценките непрекъснато растат за функции с подобен размер — най-чистият количествен сигнал
- Екипът рутинно казва «това не става с текущата постановка» за обикновени заявки
- Бъговете се струпват отново и отново в едни и същи модули
- Въвеждането на нов инженер отнема месеци вместо седмици
- Хората избягват да пипат определени файлове и всички знаят кои
- Разгръщанията се трупат на пакети и се планират, защото са рискови
Какво да погасявате и кога
Дългът си струва да се погасява, когато блокира нещо конкретно, а не по принцип. Три правила, които работят:
- Погасявайте дълга, който лежи на пътя напред. Ако следващите две тримесечия минават през даден модул, изчистете го, преди да строите там. Дълг в код, който няма да пипнете, не струва нищо.
- Дълг, който докосва пари, данни или автентикация, погасявайте веднага, независимо от пътната карта — отказите там са невъзстановими, а не просто досадни.
- Рефакторирайте опортюнистично. Подобрявайте това, което и без това променяте, вместо да планирате отделни проекти за разчистване, които под натиск падат първи.
Бюджетът, който работи
Няма универсален процент поддръжка, който автоматично стабилизира дълга. Планирайте капацитета според рисковете и продуктовия план и го преразглеждайте. Пренаписването е възможност за оценка, не задължителен резултат от одита.
Целта не е нулев технически дълг. Целта е дълг, който сте избрали, за който знаете и който бихте могли да погасите, ако пътната карта го изискваше.
Какво да казвате на инвеститорите
Основателите често се опитват да скрият дълга по време на due diligence. Това се обръща срещу тях: проверката го намира, а откритието струва в преговорите повече, отколкото би струвало разкриването. По-силната позиция е писмен регистър — какъв дълг съществува, какво блокира, колко струва отстраняването. Екип, който може да формулира това, се чете като компетентен; екип, който твърди, че има чиста кодова база, се чете като наивен или уклончив.
Приоритизирайте техническия дълг с доказателства
Прегледът на код проверява реализацията, архитектурният — границите и работата. Започнете с бизнес решение: системата ще поддържа ли следващото издание или нови клиенти? Оценете последици, наблюдавана честота и труд. Активни проблеми със сигурността или целостта на данни са отделно спешни.
| Направете решението измеримо | Доказателства, които да договорите предварително |
|---|---|
| Забавяния | Свържете промяна с модули, чакане за преглед и пропуски в тестовете. Сравнете подобни промени преди и след поправката. |
| Оперативен риск | Проверете инциденти, трасета и възстановявания. Липсващ достъп означава непроверено, не успешно. |
| Регистър на дълга | Запишете доказателства, засегнат път, отговорник, диапазон на труда и тест за поправката. |
Няма универсален процент поддръжка, който автоматично стабилизира дълга. Планирайте капацитета според рисковете и продуктовия план и го преразглеждайте. Пренаписването е възможност за оценка, не задължителен резултат от одита.
Често задавани въпроси
Колко технически дълг е нормален за стартъп?
Значително количество, и това обикновено е правилно — скоростта на ранен етап струва повече от ранната изпипаност. Проблемът не е количеството, а дали дългът е известен, съзнателен и ограничен до области, които не блокират пътната карта и не докосват пари и данни.
Какъв процент от инженерното време трябва да отива за технически дълг?
Няма универсален процент поддръжка, който автоматично стабилизира дълга. Планирайте капацитета според рисковете и продуктовия план и го преразглеждайте. Пренаписването е възможност за оценка, не задължителен резултат от одита.
Да спрем ли функциите, за да поправим техническия дълг?
Почти никога. Отделните проекти за разчистване трудно се обосновават, трудно се завършват и първи отпадат. Изключение е дългът, който активно губи пари или данни — той спира всичко, докато не бъде поправен.
Не сте сигурни кой дълг наистина има значение?
Триажираме го спрямо вашата пътна карта — какво ви блокира, какво струва пари, какво да оставите на мира.
Още по темата
Как да поправите счупено MVP (без да започвате отначало)
Почти всеки основател със счупено MVP пита дали да го пренапише. Почти винаги отговорът е не — и причината е аритметика, а не сантимент.
Одит на системната архитектура: кога е нужен и какво открива
Одитът на архитектурата не е мнение за вашия стек. Той е карта на местата, където системата се чупи под плана, който наистина имате.