„Na čtyři měsíce si půjčíme deset lidí a pak je vrátíme.“ Přesně tahle věta v plánu kapacit pošle přínos z AI zpátky na nulu.
AI transformace není projekt s datem konce. Schválně jí říkám adopce AI: podíl skutečné produktové práce, kterou tvoje týmy dodají s AI nástroji, měřený vedle toho, jak dlouho trvá, než se mergnutá změna dostane do produkce.
Lepší nástroje neznamenají, že je lidi budou používat. Nová verze Javy nikomu nepomůže, dokud s ní někdo něco nedodá.
Jeden VP of Engineering, říkejme mu Tomáš, dostal na svou AI transformaci zelenou. Jak ji prodat, popisuju v článku jak prodat business case na AI produktovému vedení. Tenhle článek je o týdnu po souhlasu, kdy rozhoduješ, kdo tu práci udělá a podle čeho poznáš, že zabrala.
Žádný projekt AI transformace neexistuje
Tomášův první plán měl klasický tvar: vezmi deset lidí, postav s nimi AI nástroje, po pár měsících je všechny vrať do produktových týmů a přínos poroste dál sám. To je mylný předpoklad. AI se hýbe tak rychle, že potřebuješ tým, který se o ni stará pořád. Ne deset lidí, ale aspoň tři.
Běžné rady to rámují jako program. HBS Online uvádí čtyři AI páky transformace: strategii, řízení (governance), architekturu a kulturu. Všechny čtyři jsou skutečné. Žádná z nich ale neříká, kdo v pondělí přestane dělat produktovou práci, a právě tohle rozhodnutí rozhýbe ty ostatní čtyři.
Výzkum DORA od Googlu v roce 2025 zjistil, že AI v práci už používá 90 % respondentů a že AI je „zesilovač, který zvětšuje existující silné i slabé stránky organizace“. Nástroje jsou všude. Zesilují ale to, jak tvoje firma dodává.
Zpráva MIT NANDA z roku 2025 to řekla tvrději: 95 % organizací mělo ze svých pilotů generativní AI nulovou návratnost. Její metodika je sporná, stojí na 153 odpovědích z průzkumu, ale obrázek sedí s tím, co vidím v mentoringu: pilot skončí, lidi se vrátí, přínos vybledne.
Je to jako ptát se, proč držíš lidi na supportu, když je funkce hotová. Hotovou funkcí ta práce nikdy nekončila.
Sedm rozhodnutí na první týden
1. Odřízni tým od produktové práce
Když ty lidi nevytáhneš a nepostavíš kolem nich nový tým, stará práce je bude dál žrát. Když jsme to dělali ve firmě, se kterou teď pracuju, poslali jsme odříznutý AI tým osmi lidí na dvanáctitýdenní misi, schválně do tmy, jako raketu, kterou vystřelíš. S nikým na zemi nemluvil, takže lidi měli čas a nikdo je nerušil.
Opačná verze, „dál budou dělat produkt a na AI jim dáme 4 % kapacity“, nefunguje.
2. Nech si stálé jádro tří lidí
Jeden je lektor a sleduje trendy. Druhý dělá evaly a experimenty. Třetí pořád ladí nástroje pro agenty a nasazuje je. Tomášův tým už odhadl, že dlouhodobě bude potřebovat asi tři lidi. Jen ty role takhle nerozdělili a ti tři ještě nebyli v plánu kapacit.
3. Zbytek po pár měsících rozpusť
Moje pravidlo od oka: z deseti lidí, které vezmeš, si tři necháš a sedm pošleš zpátky do týmů. Tam šíří, jak s tím pracovat, přímo na skutečných funkcích. A to žádné školení nedokáže.
4. Rozpočtuj adopci, ne jen nástroje
Interní komunikace o tom, proč to děláš, workshopy, hackathony, někdy pomoc zvenku. Ne každý člověk ve tvé firmě je AI-native. To jsem za celý život neviděl.
Obvykle je tam hrstka lidí, kolem kterých to postavíš. Někdy si firma takového člověka půjčí jako kontraktora, který působí jako interní, aby se to rozjelo.
Když tenhle rozpočet vynecháš, lidi vidí partu chlapů, co něco kutí, pak jim někdo řekne, ať to používají, a jsou vytočení. Co dělat s lidmi, kteří odmítají, jsem psal v článku jak odpor k AI roztřídí tvůj tým.
5. K lidem, kteří staví, přidej komunikátora
Silní lidi, kteří nástroje staví, obvykle nejsou ti komunikativní a vysvětlování, které potřebuješ, dělat nebudou. Ať jsou tvoje nástroje sebelepší, když k nim lidi nedostaneš bez tření, jsi v háji. Oni to chtějí, jen budou říkat, že to bolí. Hledáš člověka, který je hands-on, hoří pro to a ukazuje týmům: „tahle funkce trvala tři dny místo dvou týdnů“.
6. Udělej z cesty od commitu do produkce druhé KPI
Tomáš chtěl transformaci měřit tím, jak rychle tým dodá první verzi řešení. Fér. Pak popsal, co se děje po napsání kódu, a já se ho hypoteticky zeptal: co když problém není AI, ale cesta od commitu do produkce?
| Krok po napsání kódu | Typické čekání v Tomášově firmě |
|---|---|
| Review od člověka z jiného týmu, v jehož kódu měníš | 2 až 3 dny |
| End-to-end testy | přes noc |
| Release train (vydání v pevném rytmu) | až 2 týdny |
| Postupné nasazení všem zákazníkům | asi 1 týden |
| Od merge po první reálný provoz v produkci | až ~3 týdny |
Jedna skutečná tech organizace, anonymizovaná. Agenti navíc neměli ani přístup ke čtení produkčních metrik, takže si nemohli zkontrolovat vlastní práci.
DORA tomu říká lead time změny, „čas, za který se commit nebo změna úspěšně nasadí do produkce“, a podle její zprávy z roku 2024 to elitní týmy zvládají za méně než jeden den. Tomášovy týmy byly až na třech týdnech a každý z těch dní je cost of delay, tedy cena zdržení.
Když zrychlíš jen psaní, optimalizoval jsi nejkratší krok.
Druhé KPI na cestu od merge do produkce ukáže release train, frontu na review a chybějící přístup ke čtení produkce jako problémy AI, kterými skutečně jsou. Pokud chceš pohled zvenku na to, kam ti mizí čas dodání, přesně to měří audit produktivity týmů.
7. Vezmi si to jako VP na sebe, nahlas
Jeden tah mám hodně rád, pokud si to VP může dovolit: vezmi si AI práci na půl roku osobně a rozpočty, plánování roadmapy a část incidentů předej kolegovi na stejné úrovni. Řekneš nahlas, před boardem i před kolegy, že za to odpovídáš a neseš riziko, protože tomu věříš.
Jedno varování: s kolegou to není úplné předání. Je to „díky, že to chvíli pohlídáš, se systémy a procesy ti dál pomůžu“, a kolega na oplátku dostane produktové týmy, které dodávají rychleji.
Říkej tomu adopce a měř to jako adopci
Používání není problém. Ale není ani důkaz. Ve studii METR z roku 2025 zkušení vývojáři s AI nástroji potřebovali o 19 % víc času a přitom věřili, že jsou o 20 % rychlejší. Report licencí by je všechny počítal mezi ty, kdo AI přijali.
Lepší nástroje neznamenají, že je lidi budou používat.
Dashboard, který bych chtěl v prvním měsíci, má proto dva řádky, ne deset: první dodaná verze a cesta od merge do produkce. K tomu jedna upřímná otázka na každý stream při měsíčním vyhodnocení: co AI nástroje tenhle měsíc změnily na tom, jak jste pracovali?
Odpověď, kterou chceš slyšet, zní jako ta Tomášova o jeho vlastní práci: jeho agent postaví tabulku postupu pro C-level za pět minut, on ji vloží do Slacku a hodina výroby slidů je pryč. Tohle je adopce. Změnila se práce, ne počet licencí.
Co se pokazí ve třetím měsíci
Produkt začne nadávat na platformu
Odříznutý tým skončí, lidi se vrátí, nástroje nikdo nedrží aktuální a o tři měsíce později produktové týmy říkají, že jim platforma slibovala věci, které nefungují. V jejich očích je to selhání platformy, ať je příčina jakákoli. Právě tomu brání stálé jádro tří lidí.
Championa roztrhají na tři kusy
Tvůj nejvíc hands-on AI člověk je obvykle zároveň ten, bez koho se neobejde produkce ani backlog. Když mu neuvolníš ruce, dělá všechny tři věci špatně. Uvolni ho a na ty dvě další najdi někoho jiného.
Zlý jsi nakonec ty
Když adopce selže, týmy neviní tým, který stavěl nástroje. Viní VP, který se nepostaral o komunikaci. Proto rozhodnutí 4 a rozhodnutí 7 patří tobě, ne týmu.
Tomáš si tým ještě nevybral. Až ho vybere, číslo od commitu do produkce je první, na co bych se díval.
Jak dlouho dnes trvá, než se mergnutá změna dostane do tvé produkce? Pokud chceš pomoct s nastavením týmu a obou KPI pro svou firmu, přesně takovou práci dělám jako fractional CTO.
[Čas psaní: 3 h]
