Zkratka UX patří do běžného slovníku celého IT světa. Uživatelská zkušenost, která se pod touto zkratkou skrývá, je vcelku dobře probádanou disciplínou, o jejíž nezbytnosti při vývoji aplikace nebo webu už nikdo nepochybuje. Na druhé straně softwarového řešení stojí ale vývojáři, o jejichž zkušenosti se už tak často nemluví. Developer experience, zkráceně DX, je konceptem, který na důležitosti začal nabírat především v poslední době, kdy se firmy o kvalitní vývojáře doslova přetahují a snaží se všemožně odlišit od konkurence. Osvětu v tomto směru poslední dva roky šíří především startup DX Heroes, první projekt z inkubátoru přímo v Appliftingu, skrze který si vývojáři navzájem zlepšují život.
Co je to developer experience?
Vývojářská zkušenost, dále jen DX, nemá zatím pevně danou definici a lze ji jen obtížně kvantifikovat. Pro lepší ilustraci ji můžeme rozdělit na dvě základní oblasti - externí DX je spokojenost vývojářů s používáním určitého nástroje, například API. Řeší se rozsáhlost technické dokumentace, příkladů použití, dostupnost podpory a snadnost implementace. Cílem je doručit vývojářům skvělou zákaznickou zkušenost a udělat vše pro to, aby pro ně použití nástroje bylo příjemnější a efektivnější, než volba konkurenčního řešení nebo vlastní vývoj.
Druhou je oblast interního DX, která má v hledáčku spokojenost vývojového týmu uvnitř firmy. Pozitivní vliv zlepšení této zkušenosti se týká celého týmu i produktu. Zkušenosti ukazují, že kromě nižší fluktuace vede lepší DX i k vyšší kvalitě odevzdaného kódu a zrychlení, tedy i zlevnění a vývoje. Jde tak o řešení toho, jak si dlouhodobě v týmu udržet odborníky, případně jak pomocí vyšší efektivity cenově konkurovat levným vývojovým společnostem z Asie a východní Evropy.
Oblast interního DX si představíme na třech příkladech obvyklých chyb, které mají negativní vliv na spokojenost vývojářů:
1. Nezvládnuté procesy
Velmi často bývají problémem špatně nastavené vývojové procesy. Typicky k nim dochází při přechodu z lineárního projektového řízení ve stylu “waterfall” na pružnější modely jako “agile” nebo “scrum”, kdy v řízení projektů přežijí určité pozůstatky staré metody a vývoj začne drhnout. Obvykle se to projevuje tak, že někteří vývojáři nejsou přizváni do fáze analýzy a nejsou tak seznámeni s tím, co se bude v dalším sprintu vyvíjet.
Drhne tvorba dokumentace, nejsou dostatečně popsány uživatelské příběhy (user stories), nedochází ke správnému předávání informací mezi vývojářem a testery.
Takové případy obvykle provází velmi nízká zastupitelnost, vývojáři si neumí sami nabrat úkoly ani odhadnout jejich velikost, takže buď nemají na čem pracovat, nebo, což je častější, dochází k přetížení celého týmu. To vše se negativně odráží na jejich spokojenosti, rostou obavy z plnění termínů a motivace do práce dál klesá.
2. Nedostatečná automatizace
Celou řadu vývojových úkolů lze automatizovat. Firmy s nízkou DX se vyznačují tím, že neautomatizují testování produktů ani nasazování nových verzí do produkčních prostředí. Tyto činnosti tak obvykle provádí jen jeden člověk nebo úzká skupina, která je de facto nezastupitelná, nemůže si vzít delší dovolenou, aniž by nebyl ohrožen chod celého produktu. Stačí drobnost jako chybně nastavená CICD pipeline (tedy způsob, kterým se kontinuálně dostává nová verze vývoje do produkčního prostředí) a snižuje se DX celého týmu.
3. Podcenění technologie
Častým důvodem nízké DX je vznik technologického dluhu. Jde o stav, kdy firma v rámci vývoje používá zastaralé technologie, ačkoliv ji k tomu nic nenutí, pouze řada špatných rozhodnutí. První chybou, která obvykle ke vzniku technologického dluhu vede, je rozhodnutí pro vývoj vlastního frameworku.
V první chvíli se to může zdát jako skvělé rozhodnutí, které umožní vyvíjet komplexnější funkce na míru produktu. V dlouhodobém horizontu ale zpravidla firma není schopna framework dostatečně rychle rozvíjet a dokumentovat. Čím složitější jejich řešení je, tím déle trvá zaškolování nových vývojářů. Navíc se komplikují i případné aktualizace a vzniká obvykle neprůhledný chaos, který vývojáři z praxe jistě dobře znají.
Vývojáři vývojářům
Nekoncepční řešení jakékoliv části vývoje, ať už jde o výběr nástrojů, frameworku, nastavením deployment procesů nebo projektovou organizaci týmu, se přímo promítá do nízké úrovně DX. Ale i v případě, že firma ve výše uvedených disciplínách exceluje, může DX srazit nezvládnuté DevOps, tedy spolupráce mezi vývojáři a operativou.
„Pokud je vývojový tým naprosto odtržený od běžného chodu produktu a postřehy z praxe mu nejsou nijak předávány, zákonitě se to promítne do kvality odevzdávaného kódu, případně to celý tým může naprosto rozložit. Především v korporacích bývalo zvykem, že se vyvinutý software předal operations, což často bylo úplné jiné oddělení nebo dokonce společnost. Ti si ho nasadili do produkce, aniž by se k vývojářům dostala zpětná vazba o tom, jak jejich produkt funguje a zda nejsou potřeba nějaké úpravy,” vysvětluje šíři aspektů ovlivňujících vývojářskou zkušenost Pavel Michalík, spoluzakladatel a současný CEO startupu DX Heroes. Ten usiluje o evangelizaci konceptu developer experience mezi vývojáři.
Pavel Michalík má zkušenosti s vývojem ve velkých bankách a fintechových startupech.
DX Heroes založili v roce 2019 Pavel Michalík s Prokopem Simkem a osvětě ohledně DX se zatím věnují převážně na českém trhu, ačkoliv startup má sídlo v Londýně a v dlouhodobém plánu počítá s expanzí za hranice, jelikož ani tam DX zatím nedostává dostatek pozornosti. Původně tento projekt vzešel z praxe vývojové agentury Applifting, která slovy Pavla Michalíka již před lety bojovala za spokojenost vývojových týmů, ačkoliv na to většina klientů hleděla se zdviženým obočím. Michalík se přitom značnou část své kariéry pohyboval ve fintechu a bankovním sektoru.
Za nejdůležitější věc, která pomohla zlepšení DX velkého množství vývojářů, vidí ze své praxe restrukturalizaci vývojových oddělení velkých bank. „Už jen tím, že někdo osvícený v bance sloučil vývoj a byznys do jedné budovy, udělal z pohledu DX krok správným směrem. Pokud šel ještě dál a jednotlivá oddělení rozdělil na tribes a squads, které začal řídit agilně, tak zlepšil život tisícům vývojářů. V takto rozsáhlých korporacích nebude DX nikdy stoprocentní, ale tuto změnu, která ve většině bank již proběhla, považuji za velký úspěch,” vysvětluje Michalík.
DX Heroes bojují za štěstí vývojářů
DX Heroes nabízí firmám odbornou pomoc při zlepšování developer experience jejich týmů. Michalík vysvětluje, že cílem není prosté poskytování konzultací, ale s klientem naskočí přímo do vývoje produktu a společně s vývojáři klienta vytvoří tzv. hybridní tým, kterému pomohou správně nastavit vše, co se může negativně podepisovat na spokojenosti vývojářů a kvalitě kódu.
„Mezi typické symptomy, se kterými za námi firmy chodí, patří nestíhání termínů, vysoká chybovost a vysoká fluktuace v týmu. Naším úkolem je rozpoznat, co je příčinou problémů a navrhnout změny, které povedou k vyšší DX. Klienta vše učíme a staráme se o to, aby naše řešení nezůstalo jen na papíře. Některým firmám zatím ego nedovoluje pracovat na interním DX, takže zhruba 60 procent našich zakázek je o zlepšování externí vývojářské zkušenosti,” doplňuje Michalík. V případě, že klient vyvíjí integrační či jiný nástroj používaný dalšími vývojáři, DX Heroes mu pomáhají nastavit strukturu, dokumentaci a zapojení komunity tak, aby použití jeho nástroje bylo v souladu s principy externí DX.
Firmou, kde neberou DX na lehkou váhu, je například fintechový startup Wultra zaměřený na kyberbezpečnost. S DX Heroes proto dlouhodobě spolupracují na zlepšování spokojenosti vývojářů.
Přímá asistence klientům tvoří první ze tří pilířů, kterými se DX Heroes za vyšší spokojenost vývojářů bojují. Druhý přístup by se dal popsat jako zlepšování DX zespoda, kdy DX Heroes vytvořilo znalostní bázi pro vývojáře a team leadery, kteří by rádi přispěli ke zlepšení DX ve svých týmech. Na tomto místě jsou popsána řešení nejpalčivějších technických i procesních problémů a postupně se tato veřejně dostupná sbírka zkušeností rozrůstá o nové články.
Posledním pilířem je nástroj DX Scanner, který DX Heroes vyvinuli s cílem kvantifikovat, jak se DX ve firmě mění s časem, zda vzniká technologický dluh, jak umí tým spolupracovat na vývoji pomocí pull requestů a code review či jak kvalitní a bezpečný kód vzniká. „Vývojářskou zkušenost není snadné popsat jedním číslem, ale firmám a především klíčovým manažerům se snažíme dát možnost sledovat změny a směr vývoje DX. Stačí nám připojení produktu přes repository kódu, nad kterým DX Scanner začne měřit virtuální skóre,” popisuje Michalík.
DX Scanner je nabízen v placené Enterprise verzi, pro startupy a menší vývojové týmy je k dispozici omezená verze zdarma. Skóre DX mohou firmy zveřejňovat formou odznaků, což se zdá být na přehřátém trhu práce, kde všechny firmy pociťují akutní nedostatek zkušených vývojářů, praktickým způsobem, jak se odlišit od konkurence.
Oblastí, kde před jasně čitelným hodnocením úrovně DX ve firmách leží potenciálně zajímavá budoucnost, je ale více. Dost možná ho firmy začnou zveřejňovat kvůli snazšímu náboru nebo ho začnou požadovat sami potenciální kandidáti, protože budou preferovat firmy s kvalitnějším prostředím a spokojenějším týmem. A v neposlední řadě by se DX skóre mohlo stát i běžnou součástí smluv o dodávkách vývoje software jako transparentní hodnocení kvality odevzdávaného produktu.
Foto: Unsplash, archiv DX Heroes
