Tomáš Plecháč: DesignOps a frontend vývoj v Lundegaard jsou spojené nádoby

Kdo by to někdy nezažil…?! Představte si tu výzvu v podobě skvělého nápaditého a hravého designu, který je ale v reálu  náročné nebo velmi obtížné nakódovat. Prostor pro nedorozumění mezi designéry a frontend vývojem je totiž v praxi obrovský, proto se v Lundegaard snažíme tyto dvě oblasti udržovat úzce svázané a propojené tak, aby výsledkem byly kvalitní výstupy a motivované týmy. Nejen na správném nastavení procesů a komunikace v obou oblastech dlouhodobě pracuje Tomáš Plecháč, Head of Digital Experience.

Tome, v Lundegaard se dlouhodobě snažíš o propojení Designu a Frontend UI vývoje. Z jakého důvodu? Co bylo impulsem pro tento směr?

Prvně lehký prolog – zdánlivě odlišné světy kreativního a nápadům otevřeného designu a technicky přísného, pravidly a dokumentacemi svázaného frontendového vývoje, jsou u řešení, které doručujeme našim klientům, ve skutečnosti silně blízké disciplíny. Dalo by se i říct, dvě propojené nádoby, které když jsou propojené nevhodně, tak nefungují a neprospívají společnému záměru. Čehož jsem za svou kariéru nejen já, ale de facto každý designer, kodér a vývojář byl svědkem. Ruku na srdce, kdo někdy neřešil, že poskytnutý design byl nevhodně navržený pro cílovou platformu a buď nešel nakódovat v požadovaném čase a nebo velmi náročně za cenu určitých kompromisů? Nebo naopak - že kodér nebo vývojář chybně interpretoval a ve výsledku nepřenesl do cílových šablon nebo komponent požadovanou ideu nebo interakci, jak si ji designér představoval a jak ji koncipoval? Oba tyto ukázkové případy ukazují, že je potřeba tomu věnovat péči. 
 
A toho jsme si v našich týmem dobře vědomi,  proto mám radost, že se této symbióze mohu věnovat, vést ji a zodpovědně rozhodovat, kudy se bude ubírat. Není to převratný objev, kde bychom takzvaně a pomyslně “objevili kolo”, ale samotný proces a nastavování efektivní spolupráce je pro mě klíč, kterým se snažím odemykat efektivní cestu našich řešení a pracovat na intenzivnější spolupráci svého velkého týmu. 

Co je obecně největší výzvou či problémem v současné spolupráci mezi návrháři a vývojáři?

Upřímně si myslím, že největším “protihráčem” náš všech je čas a tlak na termíny, který bohužel v důsledku užírá prostor adekvátní soustředěnosti, kreativní tvůrčí složce, správnému dotažení vstupů/výstupů a potřebné improvizaci při dotahování. Ano, neříkám nic unikátního, s čím by “nebojovali” i jiné týmy a je to pochopitelné a zdravé. Proto je třeba se soustředit na věci, které jsou rutinnějšího a standardizovanějšího charakteru, které lze často a jednoduše poloautomatizovat, evidovat v check-listech a kontinuálně edukovat. Hned v závěsu za plynulou součinností na vstupech a výstupech je nezbytná definice společného jazyka, nemyslím teď mezinárodního, ale toho řemeslného, a intenzivní komunikace, na kterou je zejména v současné asynchronně-poloremotní době kladen velký důraz. 

Jaké jsou pro tebe hlavní cíle propojení DesignOps a frontend vývoje v Lundegaard?

To je až poeticky jednoduché. Efektivní spolupráce bez zbytečných reworků a slepých cest nad rámec životního cyklu sprintu nebo samotného inkrementu aplikace. Jinými slovy, propojená komunikace celého týmu připravující user-interface aplikace po čas celé tvorby a přípravy, kde všichni vědí, co od druhého očekávat a jaký je požadovaný výsledek společného konání. Propojení a aktivní zapojení celého týmu je nepostradatelnou ingrediencí.

Nejčastěji v jakých případech dochází ke konfliktům/nedorozumění nebo problémům mezi návrháři a vývojáři? A jak tyto problémy eliminovat?

Typicky k těmto třecím situacím dochází v závěrech sprintů nebo před samotným major releasem, kdy naše QA oddělení finalizuje poslední testy a nachází dobře známé hraniční situace, na které nemuselo být tolik myšleno nebo nebylo vidět během designu a vývoje. Z tohoto důvodu jsme zavedli například design review nebo validation checkpoint, kterého se účastní autor designér a zkušený FE kodér nebo vývojář, který přesně ví, jakým situacím se vyhnout, na co se zeptat a jakým směrem se zaměřit. Je to standardně okamžik předtím, než jde grafický návrh na schválení klientovi a do backlogu pro vývojový sprint. 

Jakým konkrétním způsobem může DesignOps manager podpořit a koordinovat spolupráci mezi návrháři a vývojáři?

Zde bychom mohli začít výčtem zavedených, ale i do budoucna zamýšlených postupů a procesů, které se snažíme zavádět do naší každodenní práce a delivery procesů, aplikovat na projektech a retrospektivně vyhodnocovat. Nicméně svou hlavní roli vidím hlavně ve facilitaci týmu, hledání odpovědí a odpovídaní na otázky “proč“ a společné podpoře tvorby takového prostředí, která tuto diskuzi umožní a motivuje kolegy. Rád bych zde podotknul, že tato práce je kontinuální, neboť myslet si, že máme vše nastaveno, z hlediska neustálých novinek, kupříkladu v posledním roce všudypřítomné AI, by bylo slepé.  

Jaké jsou klíčové ukazatele výkonu (KPIs), podle kterých by se dal hodnotit úspěch propojení DesignOps a frontend vývoje?

Opakoval bych se, kdybych zde uvedl, že klíčovým faktorem je spokojenost a angažovanost týmu potažmo jedinců, kteří díky tomu disponují vyšší motivací s tahem na branku při doručování kvalitnější práce. Postranními ukazateli je potom menší chybovost aplikace a vracení naší společné práce z QA oddělení z titulu nesouladu zadání a výsledku.