Měříte AI ROI špatně: metriky, které opravdu ukážou dopad na tým

Koupili jste týmu Copilot nebo Claude a po třech měsících vám finanční ředitel pošle jednoduchou otázku: 'Stojí to za ty peníze?' A vy zjistíte, že nemáte odpověď. Otevřete dashboard, který vám vendor nabízí, a vidíte čísla jako 'akceptováno 8 200 návrhů' nebo '340 tisíc vygenerovaných řádků kódu.' Zní to působivě. Neznamená to nic.

Vendor mi ukázal, že tým akceptoval 71 % návrhů. Zeptal jsem se: a dodáváme rychleji? Ticho. — engineering manager na mém školení

Tenhle problém vidím pořád. Firma měří aktivitu, protože je snadno měřitelná, a doufá, že aktivita znamená hodnotu. Neznamená. Pojďme si to srovnat — které metriky vás matou a které skutečně ukazují, jestli AI vašemu týmu pomáhá.

Proč jsou LOC a acceptance rate zavádějící

Počet vygenerovaných řádků kódu je nejhorší metrika, jakou si můžete vybrat. Víc kódu není lepší kód — často je to naopak. AI umí vygenerovat 200 řádků boilerplate tam, kde by senior napsal 20 řádků elegantního řešení. Když odměňujete objem, odměňujete bobtnání codebase, víc plochy na bugy a víc kódu k údržbě. Řádky kódu jako metrika produktivity byly nesmysl už v 90. letech; s AI jsou nebezpečné.

Acceptance rate — kolik procent návrhů vývojář přijme — zní chytřeji, ale měří ochotu zmáčknout Tab, ne kvalitu výsledku. Vývojář může naklikat autocomplete a pak strávit hodinu opravováním toho, co přijal. Vysoký acceptance rate klidně koexistuje s klesající produktivitou. Měříte, jak často lidé říkají AI 'ano', ne jestli je to k něčemu.

Co měřit místo toho: outcomes, ne aktivita

Dobré metriky mají jednu společnou vlastnost: měří, co se stane s prací, ne kolik jí AI vyprodukovala. Tady jsou ty, které v praxi fungují.

• Cycle time — od prvního commitu po nasazení do produkce. Nejpřímější signál, jestli tým dodává rychleji.
• Doba code review — od otevření PR po merge. AI často pomůže nejvíc právě tady (pre-review, generování popisu PR, vysvětlení diffu).
• Time-to-first-PR u nováčků — jak dlouho novému člověku trvá, než pošle první smysluplný PR. Dobrý ukazatel, jestli AI zrychluje onboarding.
• Četnost incidentů a bug rate — hlídá, jestli rychlost nejde na úkor kvality. Klíčové: měřte to spolu s cycle time, ne odděleně.
• Developer-reported friction — krátká pravidelná otázka týmu: 'Kde vám AI tento sprint ušetřilo čas a kde vás zdržela?'

Všimněte si, že žádná z nich nepochází z dashboardu AI nástroje. Cycle time, review time a bug rate už pravděpodobně máte v Gitu, Jiře nebo Linearu. Nemusíte kupovat nový nástroj — stačí se dívat na data, která už sbíráte.

Nejsilnější dvojice je cycle time + bug rate. Když klesne cycle time a bug rate zůstane stejný nebo klesne taky, máte reálný důkaz, že AI pomáhá. Když cycle time klesne, ale bugy vyletí nahoru, tým jen tlačí rychleji nekvalitní kód — a to je horší než nic.

Baseline: bez čísla 'předtím' nemáte nic

Nejčastější chyba: firma zavede AI a teprve pak začne měřit. Pak nemá s čím srovnávat. 'Cycle time je 3,1 dne' není informace — je to číslo bez kontextu. 'Cycle time klesl z 4,8 na 3,1 dne za kvartál' je informace, kterou obhájíte před vedením.

Než rozjedete plošné zavádění, seberte 2–4 týdny baseline. Většina metrik jde vytáhnout zpětně z Gitu a issue trackeru, takže baseline často zvládnete i retrospektivně — spočítejte cycle time a review time za poslední měsíc před tím, než tým začal AI reálně používat.

# Lehky baseline z Gitu (pred zavedenim AI)

## Cycle time (commit -> deploy)
- Median za posledni 4 tydny: ___ dni

## Review time (PR open -> merge)
- Median za posledni 4 tydny: ___ hodin

## Bug rate
- Pocet bugu z produkce / mesic: ___

## Onboarding
- Time-to-first-PR posledniho novacka: ___ dni

=> Za kvartal zmer stejne metriky a porovnej.

Kvalitativní signály neignorujte

Ne všechno se dá dát do grafu. Některé z nejcennějších signálů jsou kvalitativní a přijdou z pravidelného ptaní se týmu. Na retrospektivě položte dvě otázky: 'Kde vám AI tento sprint pomohla nejvíc?' a 'Kde vás zdržela nebo zavedla do slepé uličky?'

Odpovědi vám řeknou věci, které v číslech nevidíte: že AI je skvělá na testy, ale mizerná na váš legacy modul; že juniorům šetří hodiny, zatímco seniory občas zdržuje; že po zavedení AI code review lidé míň vyhoří z nudných PR. Tohle jsou reálné dopady, které cycle time nezachytí. Sledujte i jednoduchý sentiment — 'nechtěl bych to vzdát' je silnější signál než jakékoli procento.

Lehký plán měření na jeden kvartál

Nepotřebujete data tým ani nový nástroj. Tohle zvládne jeden lead za kvartál vedle běžné práce.

• Týden 0: Vytáhněte baseline z Gitu a issue trackeru — cycle time, review time, bug rate, time-to-first-PR. Zapište čísla.
• Týden 1–2: Zaveďte AI cíleně (ne emailem 'od teď používáme AI'), dejte lidem čas a školení.
• Každý sprint: Na retrospektivě dvě otázky o AI. Zapisujte, co lidé říkají.
• Týden 12: Zmerte stejné metriky jako v baseline. Porovnejte. Přidejte kvalitativní shrnutí z retrospektiv.
• Rozhodněte: Které use cases jasně fungují (škálujte je), které ne (přestaňte je tlačit), kde je potřeba víc školení.

Na konci kvartálu máte jednu stránku: čísla předtím a potom, plus co říká tým. To je obhajoba investice, kterou finanční ředitel pochopí — a zároveň mapa, kde AI vašemu týmu reálně pomáhá a kde jen děláte hluk.