arrow_backVšechny články

Vyhoření vývojářů: jak ho poznat včas a jak mu jako šéf předejít

· Josef Chmel

Vyhoření vývojářů: jak ho poznat včas a jak mu jako šéf předejít

Nejlepší vývojář najednou mlčí na standupu, chyby přibývají a za dva měsíce podá výpověď. Co o vyhoření říkají WHO, Gallup a DORA, podle čeho ho poznáte včas a co s ním může udělat šéf softwarové firmy.

Vyhoření v softwarové firmě málokdy začne velkým výbuchem. Začne tím, že váš nejspolehlivější vývojář přestane mluvit na standupu. Pull requesty od něj chodí pomaleji a s víc chybami. Na retrospektivě řekne „je to jedno“. A za dva měsíce vám na stole leží výpověď – zrovna v době, kdy je rozjetý projekt s pevným termínem. Pojďme se podívat, co vyhoření je, jak časté je mezi vývojáři a co s ním může udělat ten, kdo firmu nebo tým řídí.

Co vyhoření je (a co není)

Světová zdravotnická organizace zařadila vyhoření (burn-out) do 11. revize Mezinárodní klasifikace nemocí (MKN-11) – ne jako nemoc, ale jako pracovní jev. Definuje ho jako syndrom, který vzniká z chronického pracovního stresu, jenž se nepodařilo zvládnout, a má tři projevy:

  • vyčerpání – pocit, že člověku došla energie,
  • odstup od práce – cynismus a negativní postoj k vlastní práci,
  • nižší pracovní výkonnost – člověk má pocit, že nic pořádně nezvládá.

Pro šéfa je na té definici důležité slovo pracovní. WHO výslovně říká, že pojem vyhoření se vztahuje k práci, ne k jiným oblastem života. Nejde tedy o osobní slabost jednotlivce, ale o důsledek toho, jak je práce nastavená. A to je dobrá zpráva – nastavení práce můžete ovlivnit.

Jak časté je vyhoření mezi vývojáři

Firma Haystack Analytics nechala v červnu 2021 udělat průzkum mezi softwarovými vývojáři (sběr dat zajistila výzkumná společnost Survation). 83 % vývojářů v něm uvedlo, že zažívá vyhoření v práci. 81 % řeklo, že se jejich vyhoření během pandemie zhoršilo.

Gallup se podíval na zaměstnance obecně. Z téměř 7 500 zaměstnanců na plný úvazek je 23 % vyhořelých často nebo stále a dalších 44 % občas. Pro firmu jsou podstatné hlavně důsledky: lidé, kteří vyhoření zažívají často, mají o 63 % vyšší šanci, že si vezmou den nemocenské, a 2,6× častěji si aktivně hledají jinou práci.

Vyhoření v číslech: 83 % vývojářů uvedlo vyhoření v práci (Haystack, 2021), 23 % zaměstnanců je vyhořelých často nebo stále, ti 2,6× častěji hledají jinou práci a mají o 63 % vyšší šanci, že si vezmou den nemocenské (Gallup)

V softwarové firmě, kde odchod seniorního vývojáře znamená měsíce náboru a zapracování nástupce, je to jeden z nejdražších problémů, které můžete mít. Jen se v účetnictví neukáže na jednom řádku.

Odkud se vyhoření bere

Na otázku, co je příčinou, odpověděli vývojáři v průzkumu Haystacku takto: vysoká pracovní zátěž (47 %), neefektivní procesy (31 %) a nejasné cíle a zadání (29 %). Žádná z těch tří věcí není „osobní problém“. Všechny tři jsou rozhodnutí managementu.

Gallup došel k velmi podobnému seznamu pěti hlavních příčin:

  1. nespravedlivé zacházení – lidé, kteří s tím silně souhlasí, mají 2,3× vyšší šanci vysokého vyhoření,
  2. nezvládnutelná pracovní zátěž,
  3. nejasná role – jen 60 % pracovníků rozhodně ví, co se od nich čeká,
  4. chybějící komunikace a podpora od vedoucího,
  5. nerealistický časový tlak.

Výzkum DORA od Googlu (zpráva Accelerate State of DevOps 2024) k tomu přidává jednu příčinu typickou pro softwarové firmy: nestabilní priority. Když se to, na čem se má pracovat, pořád mění, produktivita podle DORA výrazně klesá a vyhoření výrazně roste. Zpráva upozorňuje, že tento efekt je velmi odolný – nevyváží ho ani dobrý leader, ani kvalitní dokumentace.

Nejčastější příčiny vyhoření podle vývojářů: vysoká pracovní zátěž 47 %, neefektivní procesy 31 %, nejasné cíle a zadání 29 %; podle DORA 2024 nestabilní priority firmy výrazně zvyšují vyhoření

Proč přesčasy nepomáhají

Nejčastější reakce na zpožděný projekt je „tento měsíc zabereme“. Ekonom John Pencavel ze Stanfordu ale v práci pro IZA ukázal na historických datech britských dělníků z roku 1916, že výkon roste s počtem hodin jen do určité hranice (kolem 48–49 hodin týdně) a nad ní se zisk rychle zmenšuje. Výkon při 70 hodinách týdně se téměř nelišil od výkonu při 56 hodinách. A týdny bez volné neděle měly při stejném počtu hodin zhruba o 10 % nižší výkon.

Jsou to data z továrny, ne z vývojářského týmu, takže čísla nepřenášejte doslova. Princip ale platí i pro práci hlavou: dlouhodobé přesčasy kupují málo výkonu navíc a platí se únavou – tedy přesně tím, z čeho vyhoření vzniká.

Signály, kterých si všimnout včas

Vyhoření se obvykle neohlásí samo. Podle tří projevů z definice WHO si v týmu všímejte hlavně:

  • Vyčerpání: člověk pracuje víc hodin a stíhá méně, přestává si brát dovolenou, odpovídá na zprávy pozdě večer.
  • Odstup a cynismus: dřív se zapojoval do diskusí o architektuře, teď mlčí. Na retrospektivě zaznívá „stejně se nic nezmění“.
  • Nižší výkonnost: úkoly se táhnou, přibývá chyb a vracení z code review, odhady přestávají sedět.

Žádný z těch signálů sám o sobě nic nedokazuje. Proto je důležité mluvit s lidmi – pravidelné rozhovory 1:1 jsou místo, kde se o přetížení dozvíte dřív, než z výpovědi.

Co může udělat šéf softwarové firmy

Gallup u ochranných faktorů uvádí čísla, která stojí za zapamatování. Lidé, kteří cítí podporu svého vedoucího, mají asi o 70 % menší šanci, že budou pravidelně vyhořelí. A ti, kdo mají na svou práci dost času, mají o 70 % menší šanci vysokého vyhoření.

Co chrání tým před vyhořením: podpora vedoucího snižuje šanci vyhoření asi o 70 %, dostatek času na práci snižuje šanci vysokého vyhoření o 70 %, nespravedlivé zacházení ji zvyšuje 2,3×

Z toho plyne praktický kontrolní seznam:

  1. Plánujte podle kapacity, ne podle přání. Sprint naplňte jen tolik, kolik tým reálně zvládne, a vyhoďte z něj práci, když přibude nová.
  2. Držte priority stabilní. Nové požadavky jdou do backlogu a o pořadí se rozhoduje při plánování, ne v úterý odpoledne po telefonu se zákazníkem.
  3. Zadávejte jasně. Každý úkol s cílem a akceptačními kritérii – nejasné zadání je podle Haystacku třetí nejčastější příčina vyhoření.
  4. Sledujte odpracované hodiny – kvůli lidem, ne kvůli kontrole. Když někdo dlouhodobě loguje 55 hodin týdně, je to signál k rozhovoru, ne důvod k pochvale.
  5. Odstraňte zbytečnou práci. Neefektivní procesy, ruční reporty a opakovaná rutina vyčerpávají a nikoho nebaví.
  6. Mluvte s lidmi pravidelně a ptejte se na zátěž, ne jen na stav úkolů.
  7. Buďte spravedliví v tom, kdo dostává zajímavou práci a kdo „hasí požáry“.

Jak s tím pomůže mcptask.online

mcptask.online vyhoření za vás nevyřeší – to dokáže jen dobré vedení. Dá vám ale data, podle kterých se dá vést. Projekt rozložíte na Epic → Story → Task, úkoly ohodnotíte scrum pointy, ze kterých se automaticky počítá odhad hodin, a ve sprintu tak vidíte, jestli plán odpovídá kapacitě týmu. Čas se loguje u konkrétních úkolů – ručně nebo z commitů s odkazem na úkol – a timesheety vyexportujete do JSON, CSV nebo PDF. Přetížení je tak vidět dřív, než se projeví na náladě týmu.

Závislosti mezi úkoly evidujete jako skutečné blokující vazby, takže nikdo neztrácí čas na práci, která stejně čeká na někoho jiného, a priority úkolů jsou pro všechny čitelné na jednom místě.

A rutinu, která lidi vyčerpává a nebaví, může převzít autonomní AI vývojář (runner) na vaší infrastruktuře. Ze stejné fronty si vezme malý, dobře popsaný úkol, napíše kód i testy a otevře pull request – o merge a releasu rozhoduje člověk. Vaši vývojáři se tak dostanou ke složitější a zajímavější práci.

Chcete mít zátěž týmu pod kontrolou? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.

Zdroje

Související články