Технически дълг (technical debt)

Пример

Магазин пуска промоция за три дни. Отстъпката се прави набързо: цените се вписват направо в кода на две страници, вместо да минат през правилата за отстъпки. Промоцията свършва, кодът остава. Следващата промоция минава по същия път, защото така е по-бързо, и след година правилата за цени живеят на пет места.

Лихвата се вижда в часове. Промяна в цените, която е отнемала два часа, вече отнема пет, защото всяко от местата трябва да се провери. Четири такива промени месечно са дванадесет допълнителни часа, а веднъж годишно някой пропуска едно място и магазинът продава на грешна цена.

Изплащането обикновено е по-малко, отколкото звучи: два дни, в които правилата се събират на едно място и се покриват с проверки. След това промяната пак отнема два часа. Числата са примерни, но съотношението е познато на всеки, поддържал стар сайт.

Защо има значение за бизнеса

Техническият дълг не се вижда в сайта, а в офертите. Когато малка промяна се остойностява като голяма, обяснението почти винаги е тук. Той обяснява и защо някои сайтове не се обновяват: екипът знае, че обновлението ще счупи нещо, което държи сайта изправен.

Натрупва се и без нито една грешка — стара версия на PHP, изоставена добавка, дизайн, правен преди повечето трафик да идва от телефони. Затова при заварен проект първо оценяваме колко от него може да се променя спокойно и колко трябва да се пренапише, независимо дали работата продължава върху съществуващия сайт, или върху собствената ни платформа.

Какво да попитате

• Кои промени вече отнемат повече време, отколкото би трябвало?
• Има ли части, които екипът избягва да пипа, и защо?
• На какви версии работят PHP, системата и добавките и кои са към края на поддръжката?
• Има ли тестова среда и проверки, които хващат счупеното преди клиентите?
• Колко време месечно отива в изчистване, а не в нови функции?
• Колко би струвало пренаписването на частта, която се чупи най-често?