Lov na duchy: jak odhalit skutečný přínos vývojářů

„Ghost engineers“ — každý desátý vývojář prakticky nedělá nic užitečného a jen přesvědčivě předstírá velkou pracovní aktivitu. Skutečné příčiny této nečinnosti — práce bokem, vyhoření nebo obyčejné flákání — přitom mohou vedení velmi dlouho unikat. (Stanfordská studie z roku 2024: původní vlákno)

Vývojáři nemají rádi, když se začne mluvit o jejich výkonnosti. Po dlouhých „zlatých letech“ této profese vzniklo v oboru tabu kolem jednoduché otázky: odpovídá výsledek vývoje času a penězům, které do něj firma vložila? Jenže vývojáře kolegové-duchové štvou také — a problém obvykle zaznamená tým dříve než vedení.

V Rusku se historicky nenosí „bonzovat“. O problému tak může vědět spousta lidí, ale nikdo o něm nechce mluvit: proč se plést do cizích sporů? Všechno vyplave na povrch, až když už týmu dojde trpělivost.

A možná bychom je prostě měli nechat být — tyhle duchy. Vždyť firma ty peníze ani nepocítí.

Jenže je tu jeden háček…

Nízkou výkonností nemyslím situaci, kdy Petr sedí, dře a udělá o 10 % méně než Jan. Mluvím o něčem jiném: na každém stand-upu celý tým poslouchá další dojemný příběh — jiný tým ho zklamal, zadání bylo nejasné, hvězdy nepřály. Ale zítra bude úkol určitě hotový. Čestné slovo.

Jenomže tohle „zítra“ už bylo včera i předevčírem — a mezitím se z něj stala tradice.

Tým si podobných věcí všimne rychle. Lidé, kteří práci skutečně táhnou, si logicky začnou klást otázku: proč dřít, když stačí vyprávět pohádky a nic se vám nestane?

Všimnout si problému ale nestačí. Dokud nejsou po ruce čísla a fakta, rozhovor rychle sklouzne do sporu: tým říká „pracuje špatně“, vývojář odpovídá „nenechají mě pracovat“. Situace se obvykle začne řešit teprve tehdy, když už došla trpělivost a tým požádá přímého nadřízeného, aby vývojáře nahradil.

Pak začíná dlouhá epopej: shromáždit fakta, vyslechnout obě strany, dát člověku zpětnou vazbu a čas situaci napravit. Podle mých zkušeností to nejčastěji končí odchodem ducha k novému — a velmi šťastnému — zaměstnavateli.

Problém není jen v tom, že jeden člověk udělá méně. Firma platí dvakrát: nejprve za práci, která nevznikla, a potom za čas kolegů a vedoucích, kteří všechno kontrolují, jistí a zjišťují příčiny. Nakonec už neklesá výkon jednoho vývojáře, ale celého týmu.

Může vedoucí odhalit problém dříve — všimnout si odchylky, vyžádat si kontext a situaci prošetřit dřív, než týmu dojde trpělivost a firma přijde o čas a peníze?

S dostatkem zkušeností lze podobné příběhy rozpoznat předem podle typických vzorců chování:

• Úspěchy jsou moje, neúspěchy tvoje.
• Výmluvy na selhání úkolu ještě předtím, než na něm práce vůbec začala.
• Nedostatek schopností nahrazený přehnanou upovídaností.
• Postupem času je za „viníka“ stále častěji označován právě vedoucí.
• Na rozdíl od člověka, který má objektivní potíže, se toto chování nezlepší ani po přímé zpětné vazbě.

K ověření podezření však potřebujeme digitální stopy.

Podívejme se na nejběžnější nástroje pro hodnocení výkonnosti vývoje a na to, zda dokážou duchy odhalit.

Než je porovnám, uvedu zjevný střet zájmů: čtete oficiální blog DevGhost a já jsem zakladatelem produktu. Jde tedy o autorský pohled, nikoli nezávislou studii.

Pro hodnocení výkonnosti samotného vývoje — ne celé firmy nebo produktu — používám jednoduchou trojici: rychlost, kvalitu a objem. Rychlost ukazují metriky DORA, kvalitu testy a defekty. S objemem je to složitější: právě tady je cesta nejméně prošlapaná a schovávají se tu duchové, které hledáme.

DORA: rychlost a spolehlivost releasů

DORA ukazuje, jak rychle a spolehlivě tým dostává změny do produkce. Model zahrnuje pět metrik: dobu od commitu do produkce, frekvenci nasazování, podíl nasazení se selháním, dobu zotavení a podíl neplánovaných oprav.

Je to dobré hodnocení procesu delivery, nikoli však osobního přínosu. Pokud jeden člověk pracuje za tři a druhý se schovává za celkový výsledek týmu, DORA vám to neřekne.

Tyto metriky jsou také báječně pohodlné jako KPI. V jedné firmě, kde jsem pracoval, se dojily už od roku 2018: všechny dashboardy se úspěšně barvily nazeleno a všichni byli spokojení. Aktuální model DORA.

Testy a defekty: jak dobře byla práce odvedena

Tyto postupy jsou dávno známé a v praxi fungují. Kvalita se kontroluje pomocí code review, testů a statické analýzy, následky se sledují podle defektů a incidentů.

O objemu ale tyto signály nic neříkají. Jedna malá bezchybná oprava rozsvítí všechny ukazatele zeleně — a duch zůstane neviditelný.

Jira a story points: kolik úkolů bylo uzavřeno

Jira ukazuje uzavřené úkoly a story points, ale odhady stanovuje samotný tým. Stejnou práci lze ohodnotit třemi nebo třinácti body, rozdělit ji do pěti úkolů nebo spojit do jednoho.

Pro plánování jsou story points užitečné, jako měřítko osobního přínosu však spolehlivé nejsou. Jakmile se body stanou cílem, lidé začnou optimalizovat práci podle nich.

Jako KPI se hodí také. Data se zadávají a úkoly posouvají výhradně proto, aby prošly quality gates. Spousta zbytečné ruční práce.

Commity a řádky kódu: fakta bez kontextu

Git není závislý na týmových odhadech, takže je lákavé počítat commity a řádky. Pět commitů ale může představovat jedinou drobnou opravu, zatímco jeden squash commit může skrývat týden práce.

Formátování, generování, kopírování a přesouvání kódu nafukuje počet řádků, přestože obtížná oprava může mít jen deset řádků.

Swarmia, LinearB a Waydev: celý vývojový systém na jednom místě

Swarmia, LinearB a Waydev spojují Git, systém pro správu úkolů a CI/CD. Vedoucí vidí metriky DORA, fronty na review, dobu průchodu změn i výsledky průzkumů.

Poskytují užitečný obraz vývojového systému — a často ukážou, že problém je v procesu, nikoli v člověku. Srovnatelný objem práce konkrétního vývojáře však není hlavní otázkou, na kterou se tyto platformy snaží odpovědět. Swarmia, LinearB, Waydev.

GitClear: co zůstane po odfiltrování kódového šumu

GitClear rozlišuje přidávání, přesouvání a kopírování kódu, vylučuje generované soubory a zohledňuje, zda byl nový kód později přepsán nebo odstraněn.

Tak vzniká Diff Delta — vlastní jednotka GitClear pro smysluplné změny, které v kódové základně zůstaly. Zkopírovaný nebo rychle vyhozený kód má menší váhu než kompaktní změna, která nadále funguje v produkci. Jak funguje Diff Delta.

Diff Delta neodpovídá na otázku, kolik práce bylo potřeba. Říká, kolik smysluplných změn zůstalo po šumu a předělávkách. Silnou stránkou GitClear je měření trvanlivosti a kvality kódu a analýza vlivu AI.

Už jsme blíž. Služba zveřejňuje benchmarky, ale Diff Delta zůstává její vlastní jednotkou: číslo 10 000 bez vhodného srovnání a znalosti metodiky mnoho neřekne. Jasný referenční bod typu „100 % je norma“ tu není. Benchmarky Diff Delta.

BlueOptima: stejná otázka v korporátním měřítku

BlueOptima znám z vlastní zkušenosti. S platformou jsem začal pracovat v roce 2019. Právě tato zkušenost mě inspirovala k vytvoření vlastního produktu.

Algoritmus Coding Effort analyzuje každou změnu zdrojového kódu pomocí sady statických metrik, zohledňuje její velikost, složitost a propojení se zbytkem kódu a výsledek vyjadřuje v hodinách.

Díky tomu lze srovnávat vývojáře z různých týmů a technologických stacků, a to i s globálním benchmarkem. Pro mě to byl první přesvědčivý pokus odpovědět nikoli na otázku „Kolik řádků tento vývojář napsal?“, ale na otázku „Kolik smysluplné práce se za těmito změnami skrývá?“. Metodika BlueOptima, globální benchmark.

V mém případě vyžadovalo získání těchto korporátních funkcí poměrně náročné nasazení: agent musel běžet v uzavřeném síťovém prostředí, cena byla vysoká a výsledky vyžadovaly odbornou interpretaci.

Pro firmu s tisíci vývojářů to může být oprávněné. Pro startup nebo malý tým spíš ne. Právě tato mezera se později stala jedním z důvodů vzniku DevGhost.

Stejné měřítko, bez tendru

Když jsem vytvářel DevGhost, nesnažil jsem se postavit další univerzální platformu se všemi představitelnými vývojovými metrikami.

Chtěl jsem stejnou odpověď, jakou nabízela BlueOptima — kolik smysluplné práce se skrývá za změnami — ale v podobě, kterou by majitel startupu nebo malý tým mohl použít bez tendru, zdlouhavého nasazení a týmu konzultantů.

Princip je jednoduchý: DevGhost analyzuje samotné změny — co bylo přidáno, odstraněno a přestavěno a jak obtížné bylo výsledek vytvořit a ověřit. Formátování, přesuny kódu, hromadné automatické náhrady a generovaný kód se oddělují od smysluplné práce.

Výsledkem je odhad úsilí vyjádřený v ekvivalentních hodinách: jak dlouho by stejný kód psal středně zkušený vývojář, který zná kódovou základnu a pracuje bez AI. Nejde o skutečný čas strávený u klávesnice ani o hodnocení kvality či obchodní hodnoty kódu. Je to společné měřítko pro porovnávání změn. Více o metodice DevGhost.

Ghost% tento odhad porovnává s očekávaným výstupem středně zkušeného vývojáře a bere v úvahu, kolik času daný člověk skutečně věnuje vývoji. Výsledek 100 % znamená soulad s normou. Nižší výsledek je důvodem hledat příčiny; vyšší stojí za prozkoumání a možná i za převedení do osvědčeného postupu.

Referenční hodnota záměrně předpokládá práci bez AI. DevGhost se nesnaží určit, kdo napsal konkrétní část — člověk, Copilot, nebo autonomní agent. Hodnotí výsledné změny: kolik úsilí by středně zkušený vývojář potřeboval k jejich vytvoření a ověření bez pomoci AI.

Vliv AI se tak uvnitř metriky neztratí, ale stane se viditelným. Pokud vývojář za určité období vytvoří a ověří výsledek, který by dříve vyžadoval dvakrát nebo třikrát více úsilí, Ghost% to zachytí. Formátování, hromadné generování ani jiný kódový šum by stejný efekt vytvářet neměly.

A kdo posoudí hodnotitele?

Nejzřejmější otázka zní: proč bychom vůbec měli věřit strojovému odhadu? Krátká odpověď: slepě bychom mu věřit neměli.

Posuzování obtížnosti práce je ze své podstaty subjektivní. Ověřili jsme si to: několik zkušených vývojářů dostalo stejné změny a jejich odhady se citelně lišily. Každý má jiné tempo, zkušenosti i představu o tom, co je obtížné.

Také DevGhost se může mýlit. Jeho výhoda nespočívá v přístupu k absolutní pravdě, ale v tom, že každou změnu hodnotí podle stejného měřítka — bez sympatií, únavy nebo předem utvořeného názoru na autora.

Ghost% je proto signál, nikoli rozsudek. Nízký výsledek může znamenat malý přínos, ale vysvětlit ho mohou také povinnosti tech leada, práce na architektuře, mentoring, incidenty nebo blokace.

Číslo ukazuje, kde je dobré položit otázku. Odpověď musí stále najít vedoucí — nyní se však může opřít o nezávislý druhý názor, ne jen o intuici.

„Stejně vím, jak kdo v mém týmu pracuje“

Jeden z klientů DevGhost je technickým vedoucím rychle rostoucí AI firmy. Zpočátku byl skeptický k samotné myšlence měřit výkonnost vývoje. Jeho postoj byl jednoduchý: dobrý technický vedoucí ví i bez dashboardu, jak kdo pracuje.

Analyzovali jsme historii repozitáře, který dobře znal. Už dříve panovaly obavy ohledně tří vývojářů: jejich úkoly postupovaly pomalu, ale pracovali na oddělené službě, takže bylo obtížné porovnat je se zbytkem týmu. DevGhost u všech tří ukázal přibližně půl roku trvale nízké výsledky.

Později, když vývojáři začali odcházet, vyšlo najevo, že po celou dobu souběžně vytvářeli vlastní produkty. DevGhost nemohl znát důvod. Pouze odhalil něco, co nebylo vidět z počtu commitů, pull requestů ani každodenních rozhovorů na Slacku: objem jejich práce byl znatelně nižší, než se očekávalo.

Analýza se ale nezměnila v seznam lidí k propuštění. U dalších dvou vývojářů pomohl nízký výsledek dát konkrétní zpětnou vazbu, zjistit příčiny a zlepšit výkon. Oba v týmu zůstali.

Vývojáři, které považoval za silné, se také objevili přesně tam, kde je očekával. Nově navíc viděl nejen to, kdo překonává očekávání, ale také jak stabilně se mu to daří.

Jeden případ samozřejmě nedokazuje přesnost metody. Klienta ale překvapilo, jak dobře celkový obraz odpovídal tomu, co se dříve vědělo jen na úrovni pocitu a co se v některých případech ukázalo až zpětně.

Co když jeden vývojář dodává výstup za tři?

Lov na duchy je nejvýraznější částí tohoto příběhu. Horní část grafu však může být užitečnější.

Pokud vývojář stabilně dodává několikanásobek průměrného výstupu, stojí za to zjistit, jak přesně toho dosahuje.

Dnes už nejde o to, zda vývojář používá AI — pro mnoho lidí se stala běžnou součástí práce. Otázkou je, jak efektivně člověk promění agenty v dodatečnou vývojovou kapacitu.

Jeden člověk skončí u automatického doplňování. Jiný umí agentům předat správný kontext, formulovat jasná pravidla, vést několik úkolů souběžně a pečlivě kontrolovat výsledek. Stejný přístup k AI proto může přinést zcela odlišný nárůst produktivity.

Vysoký Ghost% pomáhá najít vývojáře, kterým už spolupráce člověka s agenty přináší silné výsledky, a pochopit, které postupy by mohl převzít zbytek týmu.

Pokud vysoký výsledek potvrzuje kvalita práce i hodnocení vedoucího, takového vývojáře je dobré ocenit, udržet a zvážit jeho povýšení. Jeho postupy je pak vhodné zkoumat a šířit v týmu.

Nedělejte z měřítka klacek

Každou metriku čeká stejný osud: dříve nebo později se z ní někdo pokusí udělat KPI. Ghost% se k tomu nehodí.

Udělejte z Ghost% týmové KPI a lidé mu začnou přizpůsobovat práci. Zveřejněte žebříček a důvěra zmizí. Proměňte výsledek v tlačítko pro výpověď a chybám se nevyhnete.

Stanovil bych čtyři pravidla:

• Nedělat závěry z jediného měření nebo krátkého období.
• Zohlednit roli člověka, podíl času věnovaného vývoji a práci mimo kód.
• Ukázat výsledek vývojáři a dát mu možnost vysvětlit kontext.
• Nepoužívat Ghost% jako jediný podklad pro personální rozhodnutí.

Pokud nízký výsledek přetrvává, měl by vedoucí nejprve zjistit příčiny. Možná člověk práci opravdu nezvládá. Anebo se věnuje architektuře, zachraňuje incidenty jiných lidí či ho blokují týmové procesy.

Pokud se problém potvrdí, je třeba stanovit konkrétní plán zlepšení a po dohodnuté době hodnocení zopakovat.

Odmítnutím metrik hodnocení lidí nezmizí. Místo čísel zůstanou jen pocity, příběhy ze stand-upů a osobní sympatie vedoucího.

Rychlost, kvalita a objem vyžadují různé nástroje. DORA ukazuje, jak se změny dostávají do produkce. Testy a defekty ukazují kvalitu. DevGhost přidává odhad práce, která se skrývá za změnami v kódu.

Žádná z těchto metrik by neměla rozhodovat místo vedoucího.

Hodnota čísla nespočívá v tom, že vynese rozsudek. Spočívá v tom, že obtížný rozhovor začne dříve a opírá se o fakta.

Jak hodnotíte objem práce vývojářů vy — a kde pro vás vede hranice mezi užitečnou transparentností a sledováním?