Dvě stě položek v backlogu, nejstarší rok a půl stará. Nikdo už si nepamatuje, kdo ji zadal, ani jestli problém, kterého se týká, vůbec ještě existuje. Každý týden přibývá víc požadavků, než tým uzavře, a každá debata o prioritách končí stejně: důležité je všechno, takže nic. Pokud vedete firmu nebo odpovídáte za produkt, takový seznam není technický problém. Je to problém rozhodovací. A dá se vyřešit bez najímání tří dalších programátorů.
Než začnete cokoli zrychlovat, delegovat nebo škrtat, backlog je potřeba roztřídit. Ne podle data zadání a ne podle toho, kdo se hlasitěji dožaduje svého.
Krok 1: rozdělte požadavky do čtyř košů
První třídění se dělá podle byznysových dopadů, ne podle technické obtížnosti:
- Kritické pro tržby: požadavky, které blokují prodej, péči o zákazníky nebo fakturaci. Každý den zpoždění má vyčíslitelné náklady.
- Compliance s pevným termínem: KSeF, GDPR, akt o umělé inteligenci (EU AI Act). Hraniční datum nevyjednává a pokuta bývá vyšší než náklady na celou změnu.
- Quality-of-life: nic přímo neblokují, ale denně stojí lidi čas. Ruční přepisování dat, report slepovaný v tabulce, obezličky, na které si všichni zvykli.
- Nice-to-have: nápady, které před rokem vypadaly dobře a od té doby se po nich nikdo neptal.
Z našich projektů plyne jednoduché pozorování: poslední koš tvoří často 30–50% celého seznamu. Klidně ho smažte. Pokud je některý nápad opravdu potřeba, vrátí se sám, a to s lepším zdůvodněním než napoprvé.
Krok 2: přidejte druhou osu, tedy kdo by to měl dělat
U požadavků, které přežily první škrt, si položte druhou otázku: vyžaduje realizace hlubokou znalost vaší domény, nebo jde o standardní inženýrskou práci? Přidání pole do formuláře, integrace přes API, nový report, migrace dat, regresní testy: to všechno vypadá stejně v dopravní firmě i ve farmaceutickém velkoobchodě. Cenová logika, algoritmus plánování tras, pravidla skóringu zákazníka: to dobře neudělá nikdo, kdo nezná váš byznys.
Z těchto dvou os vzniká matice, která rozhodování zpřehlední:
- Naléhavé a standardní: nejlepší kandidát na delegování externímu partnerovi. Dobře definovaný vstup a výstup, málo kmenového kontextu.
- Naléhavé a doménové: vlastní tým, hned. Tady zkratka neexistuje.
- Nenaléhavé a standardní: delegovat po dávkách, až se nasbírá smysluplný balík.
- Nenaléhavé a doménové: vědomě odložené, s konkrétním datem revize místo věčného „někdy“.
Častá chyba: delegování naopak
A tady jeden názor, vybroušený na modernizačních projektech: řada firem dělí práci přesně obráceně. Těžké doménové úkoly dává ven, protože „na to nemáme lidi“, a jednoduché změny si nechává, protože vypadají levně. Výsledek je špatný hned dvakrát. Externí partner se roky učí doménu, kterou by firma měla kontrolovat sama, protože je to její konkurenční výhoda. A vlastní senior propálí týdny přidáváním polí do formulářů, tedy prací, kterou by zvládl každý solidní dodavatel. Doménové jádro si držte in-house, i když to jde pomaleji. Standardní práci předávejte bez sentimentu.
Podle čeho poznáte, že se backlog uzdravuje
Počet položek na seznamu říká málo. Dvě metriky říkají skoro všechno:
- Stáří nejstaršího aktivního požadavku. Pokud klesá z 18 měsíců na 3, fronta se reálně točí. Pokud roste, třídění bylo jen kosmetické.
- Lead time, tedy medián času od zadání po funkční změnu na produkci. To je jediná míra, kterou byznys cítí.
K tomu jeden kontrolní test: bilance přílivu a uzavírání za měsíc. Dokud přibývá víc, než ubývá, žádná prioritizace nestačí — je potřeba zvýšit propustnost, nebo škrtat odvážněji. Jedna výhrada: tyto metriky se dají snadno ošidit. Mazání starých požadavků jen kvůli hezčímu grafu uklidí report, ne firmu.
Kde v tomhle rozdělení stojí ESKOM AI
V takovém rozdělení práce obsazujeme pravý sloupec matice: přebíráme standardní změny, integrace mezi systémy a automatizaci regresních testů, zatímco váš tým zůstává vlastníkem doménového jádra. Proces postavený na týmu specializovaných AI agentů, s plným rozsahem automatických testů (jednotkové, integrační, E2E, testy rozhraní, bezpečnostní a výkonnostní), umožňuje uzavírat typický požadavek z koše „standardní práce“ ve dnech nebo týdnech; o tom, odkud se ta rychlost bere, jsme psali v textu jak AI zkracuje dobu realizace změn. Poctivě: první týdny spolupráce jsou pomalejší, protože musíme poznat váš systém a prostředí. Tento vstupní náklad se vrací od dalších požadavků, takže pro jedinou drobnou opravu takový model nedává smysl. Pro souvislý proud změn dává smysl velký.
Čím začít už tento pátek
Zablokujte si hodinu v kalendáři a projděte seznam s tabulkou po ruce: čtyři koše, potom druhá osa. Po té hodině budete vědět tři věci: co smazat, co udělat vlastními silami a co jde předat externě hned. A pokud chcete tímhle tříděním projít s někým, kdo to dělal mnohokrát, domluvte si bezplatnou konzultaci přes formulář na eskom.ai/pl/kontakt. Přijďte s exportem backlogu. Odejdete s roztříděným seznamem a reálným rozpětím času pro požadavky, které se dají delegovat okamžitě.