Proč zlepšovat Developer Experience?

Věnovat veškerou pozornost jen produktu dlouhodobě nefunguje. Udržitelný byznys se stará i o tým, který produkt staví.

Zní to samozřejmě, a přesto spousta firem své vývojové týmy přehlíží a nechá je vyhořet. Vidíme to ve firmách kolem nás a nechceme jen přihlížet, jak lidé i jejich produkt trpí. Proto jsme vymysleli nový přístup, kterým jim chceme pomoct.

Ten přístup stojí na zlepšování Developer Experience. Právě proto jsme založili DX Heroes.

Developer Experience (DX) si můžete představit jako User Experience (UX), ale z druhé strany produktu. Uživateli jsou tady vývojáři. Jejich zkušenost utváří dobrá spolupráce, vhodné nástroje, příjemné prostředí a produkt, který rádi vyvíjejí.

Každý, kdo v IT chvíli pracoval nebo staví produkt, ví, že dřív nebo později narazí na řadu věcí, které musí se svým týmem vyřešit.

Vývoj produktu nebývá vždycky nastavený dobře a to ohrožuje celou snahu. Často vidíme demotivované lidi v týmu, vysokou fluktuaci, víc chyb a dodací časy, které rostou, jak produkt přechází do pozdějších fází života.

Víme, že nastavit všechno správně hned od začátku není snadné. Často to ani výchozí podmínky neumožňují. Tým třeba pracoval s příliš napjatým rozpočtem nebo s přísným termínem. Na začátku to může být nutné, ale jak produkt roste, takhle ho nechat nemůžete. Častou chybou je přetěžovat tým nereálnými termíny a vysokými očekáváními vedení. Tým ale může mít slabé výsledky i z opačného důvodu: kvůli nevhodným nástrojům, špatným architektonickým rozhodnutím, chybějícímu DevOps nebo žádným základním pravidlům, jak spolu lidé komunikují.

Je to těžký problém a zaslouží si respekt a pokoru. Proto vývojovým týmům pomáháme v několika fázích.

Než můžeme cokoli opravit, musíme pochopit, s čím máme co do činění. V téhle fázi se naši DX Guru zapojí do vývojového týmu a pomáhají stavět produkt přímo s ním. Je to nejlepší způsob, jak sledovat, jak tým doopravdy funguje.

DX Guru se soustředí na problémy, které tým trápí. Ty obvykle spadají do dvou skupin.

První skupinou jsou tvrdé problémy, často spojené se špatně zvolenými nástroji nebo chybějícími postupy, které sráží kvalitu produktu. Tým třeba nemá Continuous Integration, žádný proces Pull Requestů nebo špatně nastavené testovací prostředí, které stojí víc, než kolik ušetří.

Druhou skupinou jsou „měkké“ problémy, které pramení z prosté skutečnosti, že členové týmu jsou lidé. Mají pocity, emoce a očekávání. Když tuhle stranu opomenete, přijde demotivace, špatná komunikace nebo ztráta smyslu.

Pozorování obvykle trvá tři týdny až měsíc. Zjistili jsme, že v agilním týmu musíte prožít aspoň dva sprinty, abyste odhalili hlavní problémy.

Pak DX Guru sepíšou všechno, co našli. Navrhnou, jak každý problém v týmu řešit a jak zavést dobré DX praktiky.

Při návrhu řešení vycházejí z kritérií, která vedení týmu nastavilo ještě před pozorováním. Kritériem může být snížit chybovost produktu nebo zrychlit dodávky. Záleží na produktu a na tom, co tým potřebuje. Musí být reálná, jinak se změna neudrží.

Tady DX Guru proberou každé navržené řešení s vedením týmu, a kde to pomáhá, i se samotným týmem. Ověření hlídá dohodnutá kritéria, ale skutečným cílem je tým, který dobře funguje a sám se v tom cítí dobře.

Vysvětlení navržených řešení si zaslouží zvláštní péči. Často jde o změny, které nikdo nepřivítá s nadšením, takže každá z nich potřebuje jasné zdůvodnění opřené o reálnou práci a potřeby týmu.

Řešení vždycky ušijeme na míru konkrétnímu produktovému týmu a firmě kolem něj. Převzít obecné principy bez toho, abyste je nejdřív přizpůsobili, se málokdy vyplatí.

Uvedeme příklad, který často vidíme dopadnout špatně: nasadit agilní vývoj na existující tým bez ohledu na jeho potřeby. Představa, že agilní rituály a nástroje pojaté jako checklist najednou samy začnou fungovat, je prostě mylná. Většinou tým jen otráví a v podstatě nic mu nepřinese.

Ve čtvrté fázi začnou DX Guru praktiky v týmu zavádět. Klíčové je, že to dělají při práci s týmem na reálném produktu. Můžou tak každé pravidlo vysvětlit přímo na místě a ukázat jeho správné použití a smysl, čímž kolem změny budují shodu. To nevede jen k zavedení, ale ke skutečnému přijetí.

Důležité pravidlo, jak DX Heroes pracují: jakmile je úkol hotový, tým nás už nemá potřebovat.

Když DX Guru odejdou, tým zná všechny nové i vylepšené praktiky a zvládne pokračovat sám.

Chceme dát každému místo, kde může sdílet svou zkušenost i problémy, na které v týmech naráží. Proto zakládáme komunitu lidí, kteří chtějí ve svých firmách zlepšovat Developer Experience.

První věc, kterou spouštíme, je DX Knowledge Base, místo zaměřené na praktiky, které týmům pomáhají líp pracovat a zlepšovat jejich Developer Experience.

Každý článek v Knowledge Base vychází jako open source a je zdarma, takže každý, kdo chce přispět nebo upřesnit nějakou novou stránku DX, se může připojit tady.

Teprve začínáme. Pokud chcete víc informací nebo zůstat v kontaktu, podívejte se na náš web:

A co od nás můžete čekat dál? Víme, jak moc správné nástroje zlepšují život vývojářům i celému týmu. Proto jsme začali stavět nástroj DX Scanner. Umožní vám „změřit“ Developer Experience přímo ze zdrojového kódu a doporučí praktiky, které stojí za to zavést, abyste vylepšili to, jak stavíte svůj produkt.