Každý šéf softwarové firmy to zná: tým hlásí, že „tohle se musí nejdřív přepsat“, odhady nových funkcí rostou a jednoduché změny trvají týdny. Za tím obvykle stojí technický dluh – zkratky, zastaralé závislosti, chybějící testy a dokumentace, které se nahromadily, zatímco firma dodávala. Dluh sám o sobě není chyba. Chybou je, když o něm vedení neví, neumí ho vyčíslit a nechá ho bobtnat. Podívejme se, co o něm říkají data a jak ho řídit prakticky.
Kolik technický dluh stojí
Stripe se v roce 2018 spolu se společností Harris Poll zeptal přes tisíc vývojářů a přes tisíc ředitelů v pěti zemích, kam jim mizí čas. Průměrný vývojář podle průzkumu z pracovního týdne o délce 41,1 hodiny stráví 13,5 hodiny technickým dluhem a dalších 3,8 hodiny opravami špatného kódu. Jako hlavní brzdu produktivity respondenti uvedli právě údržbu starých systémů a technický dluh.
Z pohledu rozpočtu to potvrzuje McKinsey. V průzkumu mezi 50 CIO finančních a technologických firem s tržbami nad miliardu dolarů odhadli, že technický dluh tvoří 20–40 % hodnoty jejich technologického majetku a že 10–20 % rozpočtu určeného na nové produkty ve skutečnosti padne na řešení problémů způsobených dluhem. 60 % z nich mělo pocit, že dluh za poslední tři roky znatelně narostl.
Pro menší softwarovou firmu jsou absolutní čísla jiná, princip ale stejný: každá hodina strávená obcházením starého řešení je hodina, kterou zákazníkovi nevyfakturujete jako novou hodnotu – nebo ji vyfakturujete a zákazník se diví, proč malá změna stála tolik.
Ne každý dluh je špatný
Martin Fowler navrhl jednoduchý kvadrant, který pomáhá o dluhu mluvit bez obviňování. Dluh může být úmyslný nebo neúmyslný a lehkomyslný nebo rozvážný:
- úmyslný a lehkomyslný – „na návrh nemáme čas“, tým vědomě dělá věci nahrubo, často proto, že podceňuje, jak moc by ho čistý návrh zrychlil,
- úmyslný a rozvážný – tým ví, že si půjčuje (třeba kvůli termínu vydání), a počítá s cenou splátky,
- neúmyslný a lehkomyslný – tým nezná dobré postupy a dluh vzniká, aniž o něm ví,
- neúmyslný a rozvážný – i výborný tým až během vývoje zjistí, jak to mělo být navržené. Podle Fowlera je to nevyhnutelné.
Pro šéfa z toho plyne důležitá věc: rozvážný dluh je legitimní obchodní rozhodnutí, stejně jako úvěr. Fowler navíc připomíná, že u kódu, na který se skoro nesahá, se splácení často nevyplatí – „úroky“ jsou malé. Splácet má smysl tam, kde se kód často mění a dluh tým opakovaně zdržuje.
Jak technický dluh měřit
Google se řízení technického dluhu věnuje několik let a výsledky shrnuli Ciera Jaspan a Collin Green v časopise IEEE Software. Jejich čtvrtletní průzkum mezi inženýry sleduje, jak často na jednotlivé druhy dluhu narážejí a jak moc je brzdí. Mezi nejčastěji uváděné druhy patří:
- potřebná nebo rozběhnutá migrace,
- dokumentace projektů a API,
- testování,
- kvalita kódu,
- mrtvý nebo opuštěný kód.
Zajímavější je, co nefungovalo. Výzkumníci zkusili 117 metrik z inženýrských dat, aby zjistili, zda dokážou dluh předpovědět bez ptaní. Výsledek označili za zklamání: žádná metrika sama nepředpověděla, kde inženýři dluh hlásí.
Co z toho plyne pro menší firmu:
- Ptejte se lidí. Krátká pravidelná anketa v týmu („co vás tento měsíc nejvíc zdrželo?“) řekne víc než jedno skóre z nástroje pro analýzu kódu.
- Rozdělte si dluh do kategorií. Seznam Googlu je dobrý start. Jinak vypadá dluh v dokumentaci, jinak nedokončená migrace.
- Nástroje berte jako signál, ne jako verdikt. Google používá nástroje, které upozorňují třeba na nízké pokrytí testy, zastaralou dokumentaci nebo zastaralé závislosti – ale o prioritách rozhodují lidé.
- Sledujte čas. Pokud se práce na dluhu loguje do samostatných úkolů, po pár sprintech přesně víte, kolik vás stojí.
Jak dluh splácet: pět pravidel
McKinsey doporučuje brát technický dluh jako obchodní téma, ne jen jako starost IT. Z jeho doporučení a zkušeností Googlu se dá poskládat jednoduchý postup:
- Žádný velký přepis. McKinsey výslovně varuje před projekty typu „všechno přepíšeme“ a doporučuje vyčlenit část kapacity na průběžné splácení. Úplně nový systém má smysl jen tam, kde je dluh tak velký, že se oprava nevyplatí.
- Dejte dluhu vlastníka. Každý systém by měl mít jasného vlastníka, který rozhoduje, co se splatí, co se nechá být a co se nahradí.
- Vyčleňte kapacitu. McKinsey uvádí příklad agilních týmů, kde v desetičlenném týmu pracuje na dluhu „náhradní pár“ lidí. Podle McKinsey může aktivní řízení dluhu uvolnit inženýrům až o 50 % víc času na práci pro byznys.
- Dluh patří do backlogu. Každý známý dluh má být samostatný úkol s popisem, dopadem a odhadem – ne poznámka v hlavě seniora nebo TODO v kódu.
- Řiďte, nemažte. Cílem není nulový dluh, ale dluh, o kterém víte, kolik stojí, a splácíte ho tam, kde se to vyplatí.
Jak s tím pomůže mcptask.online
V mcptask.online si technický dluh zapíšete jako běžnou práci: vlastní Epic se Story a Tasky, s prioritou a scrum pointy, ze kterých se automaticky počítá odhad hodin. Závislosti jsou skutečné blocker linky – když nová funkce čeká na dokončení migrace, zablokovaný úkol z fronty vypadne a po dokončení blokeru se do ní sám vrátí. Čas se loguje přímo do úkolů, i z commitů, a timesheet v JSON, CSV nebo PDF vám ukáže, kolik hodin dluh skutečně stojí. Úkoly z Jiry, Trella nebo Redmine převezmete importem.
Malé, dobře popsané úkoly z technického dluhu – doplnit testy, aktualizovat dokumentaci, odstranit mrtvý kód – jsou zároveň ideální práce pro autonomního AI vývojáře (runner). Bere úkoly ze stejné fronty jako lidé, píše kód i testy a pull request se mergne až po zelených testech. Vaši vývojáři se mezitím mohou věnovat složitějším věcem.
Chcete mít technický dluh v backlogu, ne v hlavách seniorů? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.
Zdroje
- The Developer Coefficient, Stripe a Harris Poll, září 2018; rozbor čísel od Lightspeed Venture Partners
- Tech debt: Reclaiming tech equity, Dalal, Krishnakanthan, Münstermann, Patenge, McKinsey, 2020
- Technical Debt Quadrant, Martin Fowler
- Defining, Measuring, and Managing Technical Debt, Ciera Jaspan, Collin Green, Google, IEEE Software 2023; shrnutí výsledků v newsletteru DX