Velký průzkum technik používaných v českých softwarových firmách zvaný „CZ Dev Radar“ má za cíl zmapovat, jaké nástroje, metody a technické a manažerské postupy se používají při vývoji software v Česku v roce 2024.

Použité pojmy

V průzkumu se používají pojmenování pro nástroje, techniky, frameworky, zejména z oblasti agilního vývoje, které nemusí být běžně známé. Stručný přehled nejdůležitějších z nich obsahuje slovníček pojmů.

Výsledky průzkumu CZ Dev Radar 2024

Obsah

Sběr dat probíhal v březnu 2024. Průzkumu se zúčastnilo 116 účastníků z nejméně 42 různých firem v různých městech Česka. Pokud vás zajímají podrobné demografické statistiky a diskuse o validitě odpovědí, můžete přeskočit na sekci, která se tomu věnuje. Výsledky se zveřejňují postupně na této stránce. O aktualizaci informuji vždy na sociálních sítích, zejména na svém profilu na LinkedIn.

Nástroje

V této sekci se zaměříme na nástroje, které vývojáři používají při své každodenní práci. V dalším textu budu používat pojem vývojář pro všechny pozice, které dělají individuální práci (tzn. programátor, tester, architekt, UX designer, atd.)

Odpovídali pouze respondenti bez podřízených a více odpovědí z jedné firmy se počítalo zpravidla vícekrát (pokud není uvedeno jinak), jelikož každý vývojář může používat jiné nástroje.

Nástroje pro programování

Mezi verzovacími systémy podle očekávání výrazně vede git, ostatní v podstatě nestojí za řeč.

Zajímavější je použití programovacích jazyků. Nějakou variantu jazyka pro vývoj frontendu používají zhruba 2/3 vývojářů. Backendové jazyky jsou rozložené poměrně rovnoměrně, mezi nejpopulárnější patří C#, Java Python. Do grafu se nevešly jazyky s méně než 3 odpověďmi (např. bash, PowerShell, Perl, AWK, Groovy).

U databázových technologií je ve výrazném vedení PosgreSQL, nicméně používané spektrum je poměrně široké a mnoho firem používá více technologií najednou.

V oblasti vývoje webu výrazně vede react, nicméně tady je pole pronásledovatelů opravdu široké a je poznat, že v oblastí probíhá překotný vývoj. V žádné jiné otázce nepřišlo tolik nápadů navíc v odpovědi „jiné“. Do grafu jsme dali jenom odpovědi, které se objevily aspoň třikrát, ale v odpovědích se objevily také Express, fastify, BitSwan, Dojo, Wicket, Handlebars, fastapi, Svelte i WordPress(?!).

I přesto, že technologie od Microsoftu jednoznačně nedominují v předchozích oblastech, na používaných IDE jednoznačně vidíme dominanci Visual Studia Code.

Když se na předchozí graf podíváme pořádně, všimneme si také, že se často objevují různá IDE od Jetbrains. Tyto odpovědi jsme tedy sloučili a podívali se kolik vývojářů používá aspoň jeden nástroj od Microsoftu a aspoň jeden od Jetbrains. Výsledky jsou vidět na dalším grafu.

Nástroje pro testování a nasazení

U cloudových technologií se při vyplňování dlouho o prvenství přetahovaly Microsoft Azure a AWS. Azure nakonec ukazuje větší použití, ale vzhledem k počtu odpovědí to může být v rámci statistické chyby.

U nástrojů pro automatické testy máme vzácně vyrovnaný stav. Na prvních 4 místech se v rámci statistické chyby umístily Azure DevOps, Jenkins, Github Actions a Gitlab.

U knihoven pro psaní automatických testů stále vede Selenium, i když celosvětově jeho popularita asi klesá. Na vzestupu jsou další frameworky – zejména Cypress a Playwright.

Nástroje pro spolupráci

U nástrojů pro správu požadavků jsme sloučili odpovědi lidí ze stejné firmy. Vidíme, že vládne Jira. (Pozn. autora: můj názor na Jiru je všeobecně znám a soudím, že stav, kdy mnoho firem používá Jiru, může být zároveň symptomem a zdrojem mnoha dysfunkcí v těchto organizacích. O tom ale nejspíš napíšu zvláštní příspěvek.)

Mezi online nástěnkami je jednoznačně nejpopulárnější Miro. Za mě trochu překvapivě skoro nikdo (1 odpověď) nepoužívá Mural, který má téměř stejné funkce jako Miro. Jednu odpověď posbíralo i Excalidraw, které umožňuje malovat nedokonalé obrázky, které vypadají jako ručně malované. A samozřejmě mám radost z toho, že několik lidí používá mé oblíbené draft.io. Bylo by možná zajímavé zjistit, k čemu všemu lidé ve firmách tyto nástěnky používají.

Skoro všichni používají pro psaní interní dokumentace Wiki stránky. Naopak dřívější praxe psaní dokumentů není už dnes příliš rozšířená. Není se čemu divit, v těch verzích se pak nedá vyznat. Zajímavé je, že zhruba polovina firem dokumentuje svůj software přímo v kódu nebo velmi blízko kódu (markdown). K tomuto tématu bych se někdy rád vrátil a prozkoumal, jaké to má důsledky.

Technické praktiky

V této části se zaměříme na to, jaké technické praktiky se používají při vývoji.

Analýza a design

Na tuto oblast směřovaly otázky na dvě techniky. Specification By Example se soustřeďuje na komunikaci vývojářů se zákazníky a pomáhá snížit množství nedorozumění, které vznikají špatným pochopením zadání. Podle odpovědí je poměrně málo rozšířená, což je trochu škoda.

Architecture Decision Records se naproti tomu zaměřují na spoluprácí uvnitř týmu. Umožňují týmu levným způsobem dokumentovat architektonická rozhodnutí.

Do této oblasti patří i udržování interní dokumentace, kterou jsme už uváděli v jiné sekci.

Kódování

Další část otázek se týkala kódování. Jelikož použité technologie a jazyky jsme si odbyli v první části, zde se zaměříme na praktiky, které jsou nezávislé na technologii. Jejich společnými rysy je to, že mají vliv na kvalitu výsledného produktu a také že tvarují spolupráci v týmu.

Zdá se, že drtivá většina vývojářů dnes používá unit testy, což je dobře, protože zvýšené pokrytí automatickými testy jednoznačně zvyšuje kvalitu produktu. Zajímalo by mě, jak funguje těch 14% firem, které unit testy nepíší. Jak zaručí, že jejich kód funguje po každé změně? Nějaké zkušenosti?

Ostatní techniky jsou už rozšířené méně. Pojďme je vzít postupně: pair/mob programming sám o sobě kvalitu nezajistí, ale výrazným způsobem přispívá ke zrychlení učení v týmu, což je důležité zejména, pokud pokud máte v týmu nováčka nebo pracujete s velkou codebase (a jste vlastně nováčci všichni). Bohužel tyto techniky využívá jen velmi málo lidí. Napadá vás, proč to tak může být?

Téměř čtvrtina lidí používá Test-Driven Development, což je pro mě osobně dobrá zpráva – očekával jsem daleko menší číslo. Potenciál ke zlepšení je ale značný – TDD prokazatelně zvyšuje pokrytí kódu testy a tím i kvalitu.

Dále se podívejme na konvence v kódu. Je to jedna ze základních technik, jak vylepšit spolupráci zejména na velkých produktech. Každý programátor má svůj styl psaní kódu a pokud se nesjednotí, vypadá každý kousek jinek (určitě jste to už zažili).

Většina týmů v nějaké formě konvence používá, ovšem vynucovány jsou pouze zhruba v polovině případů.

Revize kódu (code reviews) jsou další technikou, která zvyšuje jak kvalitu kódu, tak spolupráci v týmu. Je potěšující, že velká většina týmu nějaké revize dělá. Už méně potěšující je, že to dělají tou nejméně interaktivní formou – pomocí komentářů v Pull Requestu. Takové revize mají často tendenci sklouzávat k formalismu místo plodné diskuse o zadání designu a kvalitě kódu. Navíc jejich kvalita je nepřímo úměrná velikosti Pull Requestu. Jak říká známá průpovídka – 10 řádku – 10 komentářů, 1000 řádků – vypadá to dobře.

Poslední a nejzajímavější kódovací statistika se týká vlastnictví kódu. Vzhledem ke zkušenostem ze svých zaměstnáních, kde probíhaly velmi vzrušené debaty o tom, jak vůbec nepřichází v úvahu pustit každého blbce do všech částí kódu, jsem očekával, že soukromé vlastnictví kódu bude převažovat. Opak se ukázal být pravdou. Možnosti byly:

Každou část kódu někdo vlastní (jednotlivec nebo tým) a pouze tito lidé ji mohou upravovat.
Existují citlivé komponenty, které mohou měnit jen pověření lidé. Zbytek kódu má volnější pravidla.
Vývojář může upravit i jiné části kódu, než za které je zodpovědný, ale pokud upravuje něco, co není „jeho“, musí požádat o povolení.
Každý vývojář může upravit kteroukoliv část kódu, ale pro některé komponenty potřebuje schválení od určených jiných vývojářů.
Každý vývojář může upravit kteroukoliv část kódu bez omezení (plně sdílené vlastnictví)

Jak vidíme z obrázku – plně nebo skoro plně sdílené vlastnictví kódu významně převažuje. Háček ovšem může být ve formulaci otázky, která byla formlovaná takto: „Který výrok ohledně vlastnictví kódu se nejvíce hodí pro váš produkt?“ Nevíme, co přesně respondenti považují za produkt. Jestli respondenti odpovídali na sdílené vlastnicví kódu v celém produktu nebo jenom v části, za kterou je zodpovědný jejich tým. To by samozřejmě odpovědi zkreslilo.

Testování a nasazení

Nejen kódováním živ je vývojář. Produkty je potřeba taky otestovat a nasadit do produkce. Podívejme se, jaké techniky se k tomu používají.

Automatické testy (myšleno jiné než unit testy) používá většina týmů, pravděpodobně jako tzv. regresní sadu.

Několik dalších otázek se týkalo průběžné integrace. Schváně jsem ovšem nepoužil pojem Continuous Integration (CI), protože je přetížený jiným významem, ale ptal jsem se na konkrétní praktiky, které k tomu patří.

Zhruba dvě třetiny týmů používají feature branches, které se s CI prakticky vylučují. Jedna šestina používá Trunk-Based Development, která je jedním z předpokladů CI. Zajímalo by mě, co dělá ta zbývající šestina.

Dalším předpokladem CI je automatický build ihned po commitu. Opět jsme zhruba na dvou třetinách. Předpokládám, že ostatní pouštějí build méně často. Nebo snad dnes existují firmy, které dělají build manuálně? Pokud máte nějaké takové historky, sem s nimi.

Poslední část otázek se týkala vydávání.

Zdá se, že časté vydávání převažuje. Zřejmě to souvisí s přechodem na model Software-as-a-Service. Tomu by odpovídal i významný podíl použití feature flagů. Zhruba 15% respondentů vydává několikrát denně, což je model, který se blíží continuous delivery.

Je třeba zdůraznit, že časté vydávání není na úkor kvality. Více než dvě třetiny firem vydávají software s malým nebo žádným počtem známých chyb.

Na základě těchto dat bych si dovolit rozdělit české firmy na tři skupiny. Moderní firmy jsou schopny vydávat aspoň jednou týdně a používají několik moderních technických praktik. Firmy typu „aspoň“ něco mají nastavený pravidelný automatický build a používají aspoň nějaké moderní technické praktiky. No a pokud patřite mezi firmy, které nic z toho nědělají, měli byste se nad sebou zamyslet nebo požádat o odbornou pomoc.

Práce v týmech

V další části se zaměříme na to, jak ve firmách fungují týmy. Na všechny otázka odpovídali lidé bez podřízených (individual contributors), jedná se tedy o zhruba 60-70 odpovědí z nejméně 40 firem.

Na úvod mě napadá, že jsem při zadávání otázek automaticky předpokládal, že nějaké týmy existují. Žádný velký odpor proti formulaci otázek se ale nezvedl, takže můj předpoklad byl zřejmě správný. Pokud znáte nějakou firmu, která neorganizuje vývoj software v týmech, svěřte se v komentářích.

První otázka se týkala velikosti týmu.

Kromě několika respondentů, kteří pracují samostatně, všichni pracují v nějakém týmu, přičemž velká většina dodržuje doporučení velikosti sedm plus mínus dva, které pochází už z roku 1956 a kterým se inspiroval i Scrum. (I když já ve své praxi doporučuji spíš ještě menší týmy, něco jako pět až sedm.) Některé týmy jsou ale větší, možná i o hodně větší. Zajímaly by mě vaše zkušenosti s takto velkým týmy. Jak probíhá koordinace uvnitř týmu? Vzniká v takovém týmu nějaká přirozená hierarchie? Dá se tomu pořád říkat tým nebo je to spíš skupina?

Další otázka se týkala toho, jak moc jsou týmy end-to-end. Bylo poměrně obtížné se na to přesně zeptat, takže otázka zněla takto: Které fáze vývojového cyklu pokrývá váš tým? Možnosti byly: Analýza, Design, Kódování, Testování, Nasazení (Deployment), Údržba a bylo samozřejmě možné zatrhnout více fází. Upřímně, tady jsem měl očekávání, že většina týmů bude zodpovědná pouze za kódování a testování, ale dopadlo to jinak:

Polovina týmů (podle jejich vlastního vyjádření) jsou plně end-to-end týmy (pokrývají všech šest fází) a další čtvrtina vynechává pouze jednu fázi (přičemž vynechané fáze byly v odpovědích poměrně rovnoměrně rozloženy). Pokud by to tak opravdu bylo, znamenalo by to, že ve většině českých firem se to hemží týmy, které jsou schopny téměř jakékoliv činnosti od přímé komunikace se zákazníkem až po nasazení na produkci a řešení problémů v produkci. Já mám zkušenosti trochu jiné, týmy jsou většinou nějak omezené, ale možná jsem zatím viděl malý vzorek. Jaké jsou vaše zkušenosti? Dala by se tato otázka položit nějak líp? Kde může být háček? Nebo je to opravdu tak?

Ale pojďme dál. Další otázky se týkaly počtu programovacích jazyků používaných v týmech. Tady nám i při tomto počtuodpovědí vycházejí plynulé grafy, které připomínají nějaké pravděpobnostní rozložení (odborníci doplní které). Dodám, že toto rozložení se ustálilo při mnohem menším počtu odpovědí, než bylo nakonec průzkumu a potom už se moc neměnilo.

Pro vývoj velké většiny aplikací je potřeba více než jeden programovací jazyk, ale zase to není nějak závratně velké číslo. Dobrá, kolik programovacích jazyků tedy aktivně používá každý člen týmu?

Když si odmyslíme 0, kterou vyplnili neprogramátoři (poměrně vysoké procento), ostatní odpovědi opět tvoří plynulé pravděpodobnostní rozložení, které má maximum ve dvojce. Jinými slovy: pro většinu aplikací nám stačí tři jazyky a mně jako členu týmu stačí umět dva, abych mohl dobře fungovat. Je to zajmavý argument do diskusí o nutnosti učení do šířky v agilních týmech. Většina lidí si v první chvíli představí tu nejhorší možnou situaci (všichni musí umět všechno), ale vidíme, že v praxi to tak není.

Jak tedy členové týmu na vývoji spolupracují? Otázka zněla takto: Kolik lidí v týmu typicky ZÁROVEŇ pracuje na jedné nové funkci? (Funkce = requirement, feature, user story). Jelikož jsem v této fázi nemohl předpokládat žádný proces, musel jsem položit otázku hodně obecně i s tím rizikem, že odpovědi budou špatně porovnatelné.

Vidíme, že obvykle na jedné funkci pracují méně než 4 lidé, neméně objevily se i větší čísla. (Jeden respondent dokonce odpověděl 10. Tuto odpověď jsem z grafu vyřadil, aby byl čitelnější. Respondent měl asi na myslí větší celek než ostatní.) Když se tedy soustředíme na většinu, ta nám říká, že spolupráce při vývoji buď vůbec neprobíhá (1 = 34%) nebo probíhá v malé části týmu (2+3 = 54%). To nemusí být nutně špatně, pokud jsou vyvíjené funkce relativně jednoduché a nevyžadují žádnou spolupráci (např. oprava chyb). Může to být ale také symptom toho, že tým nepracuje jako tým, ale spíš jako skupina, například vývojář vyvine, předá testerovi k otestování a mezitím dělá něco jiného. Z jedné otázky se nedá tolik poznat a chtělo by to zeptat se podrobněji. Pokud vás nějaké vhodné otázky do příště napadají, dejte je, prosím, do komentářů.

Další otázka směřovala na stáří týmu neboli na dobu, kterou spolu lidé v týmu tráví. Opět je poměrně obtížné se zeptat tak, aby z toho byla jednoznačná odpověď. Např. když je vymění jeden člen týmu, je to už nový tým nebo ne? Proto otázka nakonec zněla takto: Jak dlouho je váš tým spolu? (Počítejte jako průměrný čas v letech, který spolu v jednom týmu strávila většina členů týmu.)

Z odpovědí je vidět, že většina firem se snaží držet relativně stabilní týmy, které jsou spolu roky. To je souladu s výzkumem týmové práce, který říká, že týmy jsou efektivnější, pokud jsou spolu dlouhou dobu.

Poslední otázka se týkala složení týmu a odpovídali na ni jak llidé bez podřízených, tak manažeři. Výsledky v obou skupinách byly prakticky totožné, takže je ukážu dohromady.

Zhruba o dvou třetinách týmů rozhoduje výhradně manažer. Zhruba čtvrtinu týmů si členové skládají sami. Zbytek jsou nějaké kombinace, při kterých jsou zapojeny obě strany, případně další lidé z firmy (koučové, produkťáci, apod.)

Management

V této části se zaměříme na to, jak funguje ve firmách management a organizace práce. Na všechny otázky odpovídali manažeři (lidé s podřízenými), odpovědi jsem seskupoval podle firem tak, aby nedošlo ke zkreslení více odpověďmi z jedné firmy.

Organizace práce

Nejprve otázky týkající se zadávání a vykazování práce zaměstnancům (typicky týmům vývojářů). Odhadování pracnosti bývá horké téma na různých meetupech a diskusích. Jak k tomu tedy české firmy přistupují?

Vidíme, že převažují body (story points) nebo jejich symbolická varianta – velikosti triček, hodiny jsou ve výrazné menšině. Což je dobře. (Otázka ovšem je, jestli Story pointy nejsou občas jenom převlečené hodiny. Ale to se z průzkumu spolehlivě zjistit nedá.) Za pozornost stojí 20% firem, které neodhadují vůbec. Jak je vidět, taky to jde. Hodně respondentů také v odpovědích zmiňovalo různé kombinace, např. volba metody podle velikosti úkolu.

Dalším horkým tématem bývá vykazování práce.

Jak je vidět, více než třetina českých firem (36%) se stále ještě nezbavila zlozvyku kontrolovat čas svých zaměstnanců. Věděli jste, že to jde i jinak? Skoro 60% firem čas nesleduje buď vůbec nebo jenom na týmové úrovni. Zřejmě pro ně jsou důležitější výsledky než čas strávený v práci. U sledovačů hodin by mě zajímalo, k čemu se ta data používají. Může to prosím někdo napsat do komentáře?

Jednou ze zásad vývoje dobrého produktu je pravidelná komunikace se zákazníkem. S koncovým zákazníkem a bez prostředníků. Týdenní status report na korporátním meetingu pro stakeholdery z vaší firmy se nepočítá. Proto tímto směrem směřovalo několik otázek. Všechny dopadly prakticky stejně: zhruba polovina lidí se s koncovým zákazníkem svého produktu téměř nevidí. A je jedno jestli se ptáme na zaměstnance nebo celé tým nebo dokonce jejich manažery.

Organizační struktura

Cílem několika otázek byl zjistit, jak moc plochá organizační struktura ve firmách bývá. To se podařilo jenom částečně – v odpovědích jsou totiž zdánlivé rozpory, které se mi nepodařilo vysvětlit.

Nejdříve si shrňme, co už víme. Většina firem dodržuje velikost týmů 5-9 a zároveň jsou jejich týmy aspoň částečně multi-disciplinární (cross-functional). První zajímavá otázka tedy je, jestli všichni lidé v týmu mají stejného nadřízeného (i když mají jiné specializace). Ukazuje se, že ano. Situace s jedním manažerem je mnohem častější než situace se dvěma a více manažery (např. dev lead a test lead).

Další otázky směřovaly na hloubku organizační struktury. Tady ale nastává rozpor. Většina manažerů tvrdí, že má méně než 10 podřízených.

Přitom ale většina z nich tvrdí, že se stará o více než jeden tým.

Což spolu s průměrnou velikostí týmu nějak nejde dohromady. Takže typický tvar organizační struktury se z průzkumu nedá odvodit. Dokáže někdo tento rozpor vysvětlit?

V každém případě platí, že velká většina týmů zůstavá stabilních, dokud nenastane nějaká významná potřeba tým měnit (odchod zaměstnance, změna strategie firmy, potřeba rozvoje zaměstnance).

Zajímavá je možnost „Složení týmů měníme, když se změní strategie firmy (např. nový produkt, akvizice)“. Jakkoliv je to pochopitelné, není to ideální. Kromě nového produktu se zaměstnanci musí učit také fungovat v novém týmu, což je zbytečně zpomaluje. Ideálně by týmy měly být schopny přejít ve stejném složení na jinou práci, což je přesně ten typ výzvy, se kterým vám může pomoci LeSS.

Problémy a výzvy

Na závěr sekce se podívejme, co manažeři vnímají jako největší výzvy při vývoji.

Scrum

Scrum je převažující metodikou pro vývoj software v českých firmách – používá jej přes 80% firem. Proto se v této části zaměříme na otázky týkající se aplikace Scrumu. Odpovědi jsem seskupoval podle firem tak, aby nedošlo ke zkreslení více odpověďmi z jedné firmy.

Více než 80% respondentů tvrdí, že používá Scrum. Co to ale přesně znamená? Ve Scrumu existují tři důležité koncepty – artefakty (produktový backlog, sprintový backlog, přírůstek produktu), role (tým, Scrum Master, Product Owner), události (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Daily Scrum).

Artefakty

Produktový backlog by měl být živý dokument, který slouží k zaznamenávání zpětné vazby od zákazníka a k vizualizaci plánované práce. Dobře udržovaný produktový backlog by neměl být moc dlouhý – ideálně tak na 1-2 sprinty dopředu, v praxi tak max 50-100 položek i u větších skupin. Jak je to v praxi?

Velká většina backlogů je mnohem delších – což může být indikátor špatně spravovaného backlogu, vnitřních závislostí ve firmě nebo toho, že obsahuje technické úkoly spíš než zákaznicky-orientované funkce. Na poslední možnost ukazuje i další odpověď. 15 úkolů ve sprintovém backlogu typicky znamená, že tým na nich moc nespolupracuje, každý si jede to svoje a tím pádem nejde o společnou práci, která by doručovala nějakou zákaznickou hodnotu.

Dobrá zpráva je, že mnoho týmů je schopno změny doručovat do produkce poměrně často. Tady zřejmě pomáhá technologický posun s Software-as-a-Service.

Události

Doručení do produkce nicméně automaticky neznamená, že se sbírá zpětná vazba od zákazníka. Na Sprint Review to dělá pravidelně jenom výrazná menšina.

Scrum Master

Scrum Guide poměrně podrobně popisuje roli Scrum Mastera. V českých firmách se ovšem nesetkává s pochopením.

Nejvíce firem Scrum Mastera vůbec nemá (což může být OK, pokud je tým dostatečně zkušený), hodně firem ji ovšem kombinuje s jinými rolemi. Bez kontextu těžko soudit, měl bych ale podezření na to, že Scrum Master je v tomto případě jenom nálepka na team leadera a Scrum je implementován ve firmě pouze formálně.

Některé týmy se taky snaží zavést hierarchii Scrum Masterů s tím, že existuje „agilní kouč“, který je něco víc než „obyčejný“ Scrum Master. Naštěstí tato praxe není moc rozšířená.

Product Owner

Z grafu je jasně vidět častá dysfunkce velkých firem – týmoví product owneři, neboli více product ownerů na jednom produktu. Bez znalosti dalšího kontextu se to nedá stoprocentně říct, ale velký počet odpovědí 1 a 2 ukazuje na to, že tzv. product owneři jsou ve skutečnosti jen vlastníci nějaké malé části produktu a dělají práci business analytiků a projektových manažerů.

Na to ukazuje i další graf, který ukazuje výsledky otázky na pozici produktového manažera. Možnosti byly (ne exluzivní):

A: Produktový manažer jedná spíše se zákazníky, Product Owner spíše s týmy
B: Produktový manažer je postaven výše než Product Owner
C: Jeden produktový manažer řídí několik Product Ownerů
D: Je to ta samá osoba
E: Nemáme produktového manažera

V agilní firmě vykonává roli Product Ownera typicky produktový manažer (nebo přímo CEO). Zkrátka člověk, který je schopen dělat byznysová rozhodnutí. Jak je ale z odpovědí vidět, v hodně firmách je „product owner“ spíš takový projektový asistent produktového manažera.

Provedení průzkumu

Výzkumu se zúčastnilo 116 účastníků. Z toho 68 vyplnilo jméno své firmy. Po ručním sloučení duplicit (např. Avast / GenDigital) se ukázalo že máme vyplněné výsledky z nejméně 42 různých firem, spíše mnohem více, protože dalších 48 účastníků firmu nevyplnilo. Zároveň z žádné firmy nemáme více než 7 odpovědí, typická je naopak 1 odpověď z každé firmy, takže odpovědi nejsou výrazně zkreslené ve prospěch jedné firmy.

Města

Většina respondentů působí v Brně a Praze. Mezi dalšími městy se objevily Olomouc, Ostrava, Hradec Králové nebo Plzeň. Někteří respondenti vyplnili více měst.

Zkušenosti

Výzkumu se zúčastnili respondenti s širokým spektrem zkušeností od několika měsíců po téměř 30 let.

Pozice

Téměř 40% respondentů pracuje na manažerských pozicích se zodpovědností za podřízené.

Názvy pozic se výrazně liší firma od firmy a kreativita personalistů je opravdu velká, jak se můžete přesvědčit na přiloženém Word cloudu.

Nicméně, pokud se pokusíme pozice vměstnat do nějakých předpřipravených odpovědí, dostaneme toto rozložení (vybírali jsme pozice, které se objevily více než jednou).

Firmy

Většina respondentů jsou zaměstnanci firem, a to velkých firem. Pokud započítáme i „živnostníky“, kteří pracují pouze pro jednoho zákazníka, jedná se o více než 90%, kteří jsou v zaměstnaneckém nebo podobném poměru.

Zároveň většina odpovědí přišla z velkých firem, ale i malé firmy jsou přiměřeně zastoupeny.

Skoro 80% respondentů vcelku podle očekávání uvedlo, že oborem podnikání jejich firmy je vývoj software. Zajímavé byly ale další odpovědi. Deset nejčastějších je ukázaných na následujícím grafu.

Více než 90% respondentů dělá produktový vývoj, z toho velká většina pro externí platící zákazníky. Jiné formy vývoje (body leasing, projektový vývoj, open source) jsou ve výrazné menšině.

Harmonogram

Aktivita	Období
Sběr dat	březen 2024 – do 29.3.
Zpracování dat	březen – duben 2024
Publikace výsledků	duben – květen 2024

Publikace výsledků CZ Dev Radar probíhá postupně na této stránce a v komentované podobě na mém LinkedIn profilu. Pokud vás výsledky zajímají, přihlaste se ke sledování profilu.

Sběr dat

Sběr dat byl ukončen. Nyní probíhá vyhodnocení. Pokud máte stále zájem připět, napište autorovi průzkumu.