Efektivita je teď velké téma ve většině firem. Ne že by ji předtím neřešily, ale velké přesuny na home office a nutnost řídit týmy na dálku po nastavení maximálně efektivních procesů vyloženě volají. Některé firmy se s tím popasovaly lépe, jiné hůře, ale všechny obecně hledají optimální nastavení. Výjimkou nejsou ani IT týmy, kde je často problém, že se jejich výkony neměří vůbec.

Na to se proto podíval Miroslav Fuksa, zakladatel vývojářské firmy Coding Bear, kde s kolegy vytvořili nástroj, který změří, jak pracují IT týmy. S nápadem přišli dávno předtím, než svět ochromila koronavirová pandemie, ale monitorovací nástroj Bear Inspector má využití jak v běžném provozu, tak i na home office. A teď v komentáři pro CzechCrunch Fuksa píše, jak práci vývojářů měřit, aby se z toho nestal Velký bratr.

***

Co neměříš, to neřídíš. Mantra, která se od doby jejího autora Petera Druckera stále opakuje a prosazuje na všech úrovních řízení a všech oblastech. Platí to však i pro tak specifický obor, jako je IT? Nemůže měření výkonu spíše již tak drahé a mnohdy velmi opečovávané ajťáky odradit? Jak a co vlastně měřit?

Na úvod je třeba říct, že pod zkratkou IT se samozřejmě skrývá řada různorodých rolí od analytiků přes programátory, testery, architekty až k adminům. Každá role má svá specifika a do jisté míry se již teď jejich výkon měří. Pokud se podíváme třeba na programátora, má řada firem nastaveno měření počtu odbavených ticketů, počet „spálených“ storypointů (zjednodušeně čas strávený nad určitým úkolem) či počet chyb (bugů).

Některé metodiky, například Scrum, si také zakládají na tom, že tým je v podstatě seberegulační jednotka a měří a řídí se vlastně sama. Jak moc toto v praxi doopravdy funguje, je však na zcela jinou diskuzi. U administrátorů sítě je pak často měřeno, zda běží vše, co má, jak rychle odpověděli na reportovaný incident a jak rychle ho vyřešili a případně počet odbavených požadavků v čase.

Nejtradičnější, univerzální a vlastně i nejefektivnější „metodou“ měření výkonu IT týmu je samotný tým lídr. Pokud je opravdu dobrý, dokáže svůj tým spolehlivě vést a motivovat. Má přehled o tom, kdo jak v týmu pracuje a nepracuje, zná způsoby práce jednotlivých členů týmu a dokáže rozpoznat pokles výkonnosti a rychle na něj zareagovat. Takový člověk je pak k nezaplacení.

Ucelený obrázek práce IT týmu

Metoda „tým lídr“ také nejlépe funguje u menších týmů, kde se informace předávají snadno a transparentně. Co ale mají dělat firmy, které už mají několik desítek lidí v IT a tolik dobrých tým lídrů nemají?

V takovém případě je určitě dobré začít výkony a výkonnost týmu měřit nějakým automatizovaným způsobem prostřednictvím dedikovaného nástroje. Takový nástroj aktuálně v Coding Bearu vyvíjíme. Jmenuje se Bear Inspector a jeho cílem je posbírat dostupná data o práci vývojářů a poskládat je tak, aby tvořily ucelený obrázek práce IT týmu a také jednotlivých programátorů.

Jak ale zajistit, aby se z měření výkonnosti nestal Big Brother? IT obor je ještě ke všemu poměrně specifický, kdy lidé, kteří v něm pracují, jsou často velmi zkoumaví, chtějí znát věci do detailů a rozumět, proč a jak se dějí, a zároveň očekávají spíše rovnostářský přístup.

Nejdůležitější pro vyhodnocení jakýchkoliv dat je samozřejmě hlavně jejich kontext. Žádný nástroj nedokáže ve 100 procentech případů nahradit kvalitní management, ale dokáže poskytnout zajímavá data a vhledy, které by bylo jinak velmi obtížné zjišťovat či komunikovat managementu výše. Takový nástroj navíc neměří pouze výkonnost jednotlivců, ale dokáže změřit a vyhodnotit celý vývojový proces.

Poskytuje tak managementu zajímavé informace o vývoji projektu, kam tým směřuje jako celek, kdo pracuje nad rámec svých povinností a nadstandardně dobře, což pak pomáhá managementu ocenit a hlavně udržet klíčové lidi v týmu. Rozhodně by tedy takový nástroj neměl být používaný jen na „vyhazovy“, ale dokáže naopak pomoci i s identifikací slabých míst v procesu (nepřesná analýza, neustále se měnící zadání ze strany byznysu atd.), jejichž odhalení a následné vyřešení může ulevit celému IT oddělení.

 

Důležitým pohledem, na který by se nikdy nemělo zapomínat při měření jakékoliv výkonnosti, je to, proč vlastně chceme a potřebujeme měřit, tj. udržet pozornost na nějakém společném cíli, proč se celá věc, projekt, dodávka dělá, kdo je zákazníkem a jaký je smysl celého projektu. Toto by mělo být jednotícím prvkem a hlavním motorem týmu. Od toho by se pak měly odvíjet úvahy co je potřeba měřit, proč a kdy.

Mnoha firmám jde především o měření trendů – ať už pozitivních nebo negativních, tedy jak se tým či projekt odchyluje od „normálu“, většinou dlouhodobého průměru. Měření výkonnosti a kvality také vůbec nemusí být vázáno na finanční odměnu účastníků, záleží na kultuře a prostředí dané firmy.

Pokud se ale firma rozhodne nastavovat nějaké KPIs s finanční vazbou, je nutné je velmi citlivě nastavovat a velmi dobře promyslet důsledky, aby se vyhnula tunelovému vidění a chování týmu. Tedy případu, kdy se celý tým „upne“ na jednu metriku a za každou cenu se ji snaží splnit bez ohledu na to, že to někdy naopak může být kontraproduktivní či nesmyslné.

Příkladem může být metrika „počet nových řádků kódu“. Pokud by byla nastavena osamoceně bez vazby na další metriky, dá se krásně obejít neustálým mazáním a přepisováním stejného kódu. Hlavní kategorií metrik v IT a projektovém managementu obecně by mělo být úplně prosté dodržování slibů – nějaký objem práce se odhadne na daný čas a měl by se dodat do určité doby. Toto často firmám úplně stačí a funguje to u menších projektů a týmů. Pokud se ale sliby přestanou dodržovat, musí jít management do většího detailu a musí se zjistit, proč se chyby v dodávkách dějí.

K tomu už je užitečné spoléhat se na exaktně naměřená data a ne jen na pocity, dojmy nebo se spoléhat na dobrou paměť. Kromě toho černobílého pohledu dodáno na čas/nedodáno na čas je určitě užitečné měřit na projektu i jeho průběh a dle něj predikovat, kolik a kdy bude hotového. Je to číselný podklad pro to, zda se projekt zvládne dodat v čase, nebo ne.

Dobrý softwarový inženýr by sice měl být schopen odhadnout, jak dlouho který task bude trvat, a v čase by se ve svých odhadech měl zlepšovat, ale vývoj softwaru je stále ještě hodně kreativní práce, kde je na začátku řada neznámých, a je možné, že se při práci řada věcí změní. I proto je tak dobré mít o projektu přehled v nějakém externím nástroji.

Velký přínos pro měření výkonnosti a kvality vývojových týmů má nástroj jako Bear Inspector i při měření projektů od externích dodavatelů, kdy má objednatel daleko menší možnost přímé kontroly nad tím, co kdo v dodavatelském týmu dělá a v jaké kvalitě. Je známo mnoho případů, kdy se firma z byznysových důvodů rozhodne, že v určitý okamžik musí mít naimplementovaný nový systém (např. před vánoční sezonou) a dojde k názoru, že bez pomoci externích dodavatelů softwarových služeb to není možné zvládnout.

V takovém případě je velmi těžké si udržet kontrolu nejen nad včasným dodáním projektu, ale i nad jeho kvalitou. Nástroj na měření výkonnosti IT týmu tak může poskytnout velmi užitečný podklad pro jednání s dodavatelem o kvalitě a včasnosti dodávky.

Pokud bychom to tedy měli shrnout. I ve vývojovém oddělení je možné měřit výkonnost a kvalitu dodávek, což může obzvlášť u velkých a komplexních projektů odhalit nejen slabá místa ve výkonu týmu a jejich členů, ale pomůže odhalit i nedokonalosti v samotném procesu vývoje softwaru od zadání práce pro IT tým až po její odevzdání.

Takové měření a vyhodnocování pak může, ale nemusí být vázáno na motivační složku týmu. Pokud se firma ale rozhodne odměnu týmu svázat s jejich výkony, bez dobrých a spolehlivých dat pro vyhodnocování se to téměř nikdy neobejde.