arrow_backVšechny články
produktivita vývojářůdora metrikyřízení softwarové firmyctospace framework

Jak měřit produktivitu vývojářů – a nezničit přitom tým

· Josef Chmel

Počet commitů ani řádků kódu vám neřekne, jestli vývojový tým vydělává. Co měří DORA, SPACE a DevEx a jak to jako šéf softwarové firmy použít v praxi.

Každý majitel nebo ředitel softwarové firmy si dřív či později položí stejnou otázku: „Dostávám za mzdy vývojářů odpovídající výsledek?“ U obchodu je odpověď jednoduchá – uzavřené zakázky. U vývoje se nabízí počítat commity, pull requesty nebo odpracované hodiny. Přesně tady ale většina firem udělá chybu, která je stojí víc, než kolik ušetří.

Proč počítání aktivity nefunguje

V roce 2023 publikovala společnost McKinsey článek s tvrzením, že produktivitu vývojářů změřit lze, a navrhla sadu metrik zaměřených mimo jiné na individuální výkon. Odpověděli na něj Kent Beck (autor Extreme Programming) a Gergely Orosz (The Pragmatic Engineer) a jejich rozbor se stal jedním z nejčtenějších textů o řízení vývoje.

Jejich argument stojí na jednoduchém modelu: práce vývojáře prochází fázemi úsilí → výstup → výsledek → dopad. Úsilí (hodiny, plánování) a výstup (commity, řádky kódu, počet PR) se měří nejsnáz. Jenže jakmile lidé vědí, že je podle nich hodnotíte, začnou optimalizovat metriku, ne byznys. Víc menších PR, víc řádků, méně času na review cizího kódu. Měření samo změní chování, které měří.

Obchod a nábor měří úspěšně právě proto, že sledují výsledek a dopad – podepsané smlouvy, obsazené pozice. U vývoje je potřeba udělat totéž: měřit tým a to, co doručil zákazníkům, ne jednotlivce a jejich aktivitu.

DORA: čtyři (dnes pět) metrik doručování

Nejpoužívanější rámec pochází z výzkumného programu DORA (DevOps Research and Assessment, dnes pod Google Cloud). Metriky rozděluje do dvou skupin:

Propustnost

  1. Change lead time – jak dlouho trvá, než se změna dostane z repozitáře do produkce.
  2. Deployment frequency – jak často nasazujete.
  3. Failed deployment recovery time – jak rychle se zotavíte z nasazení, které se nepovedlo.

Stabilita

  1. Change fail rate – jaký podíl nasazení vyžaduje okamžitý zásah.
  2. Deployment rework rate – kolik nasazení je neplánovaných, vynucených incidentem v produkci.

DORA sama upozorňuje na dvě pasti. První je Goodhartův zákon: jakmile se metrika stane cílem, přestane být dobrou metrikou. Druhá je srovnávání týmů mezi sebou – metriky mají smysl pro konkrétní aplikaci nebo službu, ne jako žebříček. Tým, který udržuje legacy systém pro banku, nikdy nebude nasazovat tak často jako tým interního webu, a neznamená to, že pracuje hůř.

DORA metriky – 5 čísel, která řeknou, jak dobře tým doručuje

SPACE: produktivita má víc rozměrů

Nicole Forsgren (spoluautorka DORA) a výzkumníci z Microsoftu a University of Victoria v roce 2021 publikovali v ACM Queue rámec SPACE. Jeho hlavní teze: produktivitu vývojářů nelze vyjádřit jedním číslem. Rozkládá ji do pěti dimenzí:

  • Satisfaction and well-being – spokojenost a vyhoření,
  • Performance – výsledky (kvalita, dopad na zákazníka),
  • Activity – aktivita (commity, review, nasazení),
  • Communication and collaboration – spolupráce a předávání znalostí,
  • Efficiency and flow – plynulost práce bez zbytečného čekání.

Praktické doporučení: sledujte metriky aspoň ze tří dimenzí současně. Aktivita sama o sobě je tu jen jedna pětina obrazu – a ta nejsnáze zmanipulovatelná.

DevEx: co vývojáře skutečně brzdí

Na SPACE navázal v roce 2023 rámec DevEx (Noda, Storey, Forsgren, Greiler). Místo „kolik toho lidé udělají“ se ptá, co jim brání. Tři hlavní oblasti:

  1. Zpětná vazba – jak dlouho se čeká na build, testy a code review.
  2. Kognitivní zátěž – jak složité je zorientovat se v systému, dokumentaci a procesech.
  3. Flow – kolik souvislého času bez přerušení lidé mají.

Autoři kombinují dva typy dat: dotazníky (jak to vývojáři vnímají) a data z nástrojů (skutečné časy buildů, review a nasazení). Ani jedno samo nestačí.

A co AI?

Otázka produktivity je dnes o to naléhavější, že firmy nasazují AI nástroje a chtějí vědět, jestli se vyplácí. Zpráva DORA 2024 přinesla střízlivé číslo: při zvýšení adopce AI o 25 % se zlepšila kvalita dokumentace (+7,5 %), kvalita kódu (+3,4 %) a rychlost code review (+3,1 %), ale propustnost doručování klesla o 1,5 % a stabilita o 7,2 %. Závěr zprávy: AI automaticky nezlepší doručování – funguje jen tam, kde tým dodržuje základy, tedy malé dávky práce a spolehlivé testy.

Co udělá +25 % adopce AI s vývojovým týmem – DORA 2024

Pro šéfa firmy z toho plyne, že AI nelze vyhodnotit tím, kolik kódu vygenerovala. Dívejte se na stejné metriky jako u lidí: doručené úkoly, lead time, chybovost nasazení.

Jak začít v malé softwarové firmě

Nepotřebujete drahou analytickou platformu. Stačí pár kroků:

  1. Měřte týmy, ne jednotlivce. Individuální metriky nechte na rozhovorech s vedoucím týmu.
  2. Vyberte 3–4 čísla – například lead time, frekvenci nasazení, chybovost nasazení a jednou za čtvrtletí krátký dotazník spokojenosti.
  3. Sledujte trend, ne absolutní hodnotu. Zajímá vás, jestli se tým zlepšuje oproti sobě, ne oproti jinému týmu.
  4. Zmenšete úkoly. Malé, jasně zadané úkoly s akceptačními kritérii zkracují lead time i review a snižují riziko chyb – u lidí i u AI.
  5. Propojte úkoly s kódem a časem. Když víte, který commit a který PR patří ke kterému úkolu a kolik času na něm padlo, máte data pro výsledky, ne jen pro aktivitu.

Kde pomůže mcptask.online

mcptask.online vznikl jako nástroj pro řízení softwarové firmy – úkoly v hierarchii Epic → Story → Task, sprinty, scrum pointy s odhadem hodin a timesheety do JSON, CSV i PDF. Commit s odkazem na úkol (například „#Task-47 2h“) zaloguje čas a aktualizuje úkol, merge PR může úkol dokončit. Vidíte tak, co tým skutečně doručil, bez ručního vykazování. A pokud v týmu pracuje i autonomní AI vývojář, jeho úkoly, čas a akce vidíte ve stejném přehledu jako u lidí.

Chcete mít přehled o tom, co váš tým opravdu doručuje? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.

Zdroje