Kdo je GINA Software
GINA Software je technologická společnost zaměřená na vývoj moderní mapovací platformy a aplikací používaných v oblasti záchranného systému a v organizacích s cílem zajišťovat bezpečnost a ochranu lidí či majetku.
Produkty firmy jsou instalovány ve více než 50 zemích světa a pomáhají více než 250 tisícům uživatelů se zorientovat v neznámém terénu, koordinovat týmy a sdílet spolu informace, ať už se jedná o mimořádné události, jako požáry či zemětřesení, nebo každodenní úkoly.
Startovací pozice a cíle spolupráce
GINA Software sídlí v Technologickém parku v Brně, konkrétně v prostorech Jihomoravského inovačního centra JIC. V době zahájení spolupráce (červenec 2023) měla přibližně 35 zaměstnanců, z toho zhruba 15 se přímo podílí na vývoji produktu a další více než 10 zaměstnanců se stará o stávající či budoucí zákazníky.
Společnost se potýkala s typickými problémy škálování. Firma hledala řešení, jak dosáhnout:
- zpřehlednění prioritizace – tak aby každému zaměstnanci bylo jasné, co je pro firmu důležité a co méně
- zrychlení smyčky mezi vývojem a testy – tak aby vývojáři nemuseli čekat na výsledky testů několik dní či týdnů dle kapacity jiného oddělení
- posílení pocitu zodpovědnosti za výsledek – tak aby vývojáři nekončili práci naprogramováním svého úkolu a předání jinému oddělení, ale tím, že dodají smysluplnou novou funkci pro zákazníka
Jak to probíhalo?
Několikrát jsme se sešli a společně vytvořili audit aktuálního stavu firmy. Zmapovali jsme stav produktu, organizační strukturu, zavedené procesy a plány do budoucna. Na základě auditu jsme ve spolupráci s CEO, CTO a projektovým manažerem určili další kroky.
Pro první fázi jsme našli dva hlavní prvky organizačního designu, které jsme mohli změnit tak, aby se firma přiblížila k požadovaným cílům.
- Roztříštěné požadavky v rámci produktového řízení. GINA své portfolio aplikací řídila jako separátní produkty – jinými slovy, existovalo mnoho (více než 10) “produktových” backlogů a v mnoha z nich byly položky s nejvyšší prioritou. S tím se pojilo komplikovanější plánování, větší množství týdenních i denních schůzek, ale i složitější orientace při exekuci úkolů kvůli jejich evidenci na různých místech a prakticky nulová orientace v tom, co se právě vyvíjí v aplikacích mimo doménu jednotlivce. Toto vše zároveň vedlo ke zmatení napříč celou firmou, co je vlastně nejdůležitější, a často ke zklamání, že se na položkách s vysokou prioritou ani nepracuje, protože se řeší věci evidované v jiném backlogu.
- Nevhodná struktura týmů. Firma měla v organizační struktuře oddělení vývoje a oddělení deployment, které provádělo i testování nových vlastností produktu (features). Každá nová vlastnost musela projít oběma odděleními, aby se dala prohlásit za dokončenou. Často to bylo na mnoho iterací, které trvaly týdny. Situaci nepomáhaly ani neshody v tom, které oddělení je vlastně zodpovědné za kvalitu či termíny plnění.
Další kroky
Tato zjištění nám pomohla určit další kroky:
- Sloučit všechny backlogy do jednoho a nastavit globální priority pro celou firmu.
- Vytvořit multi-disciplinární (cross-functional) týmy tak, aby jeden tým byl schopen doručit celou novou funkci od A do Z.
- Díky těmto změnám se ze současného projektového manažera stal plnohodnotný Product Owner, který se může věnovat rozvoji produktu místo administrativní práce v podobě neustálého vysvětlování priorit položek z různých backlogů či každodenní snahy urychlovat předávky mezi vývojem a testy.
Všechny tyto kroky odpovídají principům škálování (nebo spíš zjednodušování) pomocí LeSSu.
Sloučení backlogů provedl projektový manažer v řádu dnů a informoval o tom zbytek firmy. Od té chvíle už existuje pouze jeden seznam priorit a všichni se podle něho řídí.
Vytvoření týmů byla citlivější záležitost, proto mu předcházely rozhovory manažera oddělení (CTO) se všemi členy týmů. Všichni zaměstnanci prošli také školením Certified LeSS Basics, kde pochopili, co je to Feature Team a co se od nich očekává. Poté se vytvořily dva multi-disciplinární týmy, ve kterých byli namícháni zaměstnanci z různých rolí a různých úrovní zkušenosti. Vytvoření těchto týmů si mimo jiné vyžádalo změny v organizační struktuře – z původních vedoucích týmu se stali plnohodnotní členové týmu a mentoři menšího množství juniorních kolegů. Díky předchozí přípravě ale změna proběhla hladce.
V polovině září 2023 se nový přístup rozjel v pilotním režimu. Rozhodli jsme se použít týdenní sprinty, abychom snížili množství vyrušování v průběhu sprintu, kterého bylo tradičně velké množství.
Výsledky
Implementace LeSSu brzy přinesla řadu přímých i nepřímých dopadů. Už v prvních týdnech provozu zaznamenal projektový manažer (nyní Product Owner) výrazné snížení administrativní práce v rámci koordinace plnění úkolů. Většina komunikace probíhala uvnitř nových týmů a Product Owner u ní nebyl vůbec potřeba.
Jeden backlog znamenal jasnou zprávu do zbytku GINA software o tom, jaké jsou priority na daný týden, potažmo další období. To významně zpřehlednilo očekávání zejména obchodníků a členů technické podpory, kteří věděli, na čem se v daný týden pracuje a na čem nikoli.
Výrazně ubylo nedodělků, tedy nových funkcí, které dodělalo jedno oddělení (programátoři), ale ještě nebyly otestovány a nasazeny (oddělení Deploy). Naprostou většinu funkcí a změn přiřazených k řešení v rámci sprintu se nyní daří dokončit do stavu, že jsou připraveny k nasazení u zákazníka. Zodpovědnost za dokončení věci má nyní vždy jeden přiřazený tým, zatímco v minulosti se občas ztratila v meziprostoru mezi jednotlivými odděleními, do čehož musel na denní bázi vstupovat projektový manažer.
Členům multi-disciplinárních týmů se nově dostala příležitost si vyzkoušet práci kolegů, kteří v předchozí struktuře spadali pod jiné oddělení, případně asistovat či přímo spolupracovat u dotahování věcí do konce. Lepší znalost souvislostí při vlastní práci a větší povědomí o tom, na čem pracují kolegové, přinesly výrazné zlepšení v oblasti vzájemného respektu a staly se pilířem pro každodenní spolupráci nejen členů uvnitř týmů, ale i mezi týmy navzájem.
Díky LeSS má každý člen týmu lepší představu o tom, čím se firma zabývá, co je pro firmu důležité, a jak tomu může přispět. Motivace jednotlivců i týmů dotahovat věci do konce vede k vyšší kvalitě na výstupu, k rychlejším dodávkám a menšímu tlaku na jednotlivce. Jednotlivci mají pocit, že je jim přiřazeno méně práce, a přitom jako firma vyrobí více, což přineslo velmi dobrou a zdravou atmosféru.
Zlepšené metriky
Zvýšení kvality na výstupu je prokázáno snížením počtu všech nalezených defektů o 30 % a snížením počtu stížností zákazníků o 60 %, což dává jednotlivcům i týmům neměřitelně lepší pocit z dobře odvedené práce a firmě kapacitu nejen pro inovace, ale i na lepší zvládání neplánovaných změn. Před zavedením LeSS podíl řešení problémů (bugfixing, troubleshooting) vůči všem úkolům dlouhodobě kolísal okolo 50 %, nyní je již stabilně pod 30 %. Zlepšení připisujeme zejména tomu, že na implementaci změn spolupracuje v rámci týmu více lidí, což vede k rychlejšímu odhalení případných problémů, a tedy lepší výsledné kvalitě.
Nejenom, že teď dělají to, co je důležité, ale ještě je to i víc baví.
Martin Ingr, Product Owner
Pro koho je podobný přístup vhodný
Pro každou firmu, která chce efektivně vyvíjet software s více než 10 lidmi na palubě. Typicky nastává bod zlomu podobně jako u GINA Software někde mezi 40 a 100 zaměstnanci. Tehdy už je firma moc velká na to, aby se všichni osobně znali a dokázali si všechno vyjednat na místě.
Podobný přístup je ale vhodný i pro skupiny v rámci větší firmy. Podívejte se třeba, jak se povedlo zorganizovat vývoj v jednom oddělení (40 lidí) firmy SolarWinds (3000 zaměstnanců).
