Článek přináší detailní pohled na rozvoj engineering týmů během transformace Directu.

Tenhle modul rozebírá konkrétní nástroje, kterými jsme to udělali:

1. Maticové podporovatelství — nový kontext bez nové struktury
2. Sloučení analytiků do vývoje — z dokumentu rovnou do funkčního řešení
3. Pravidlo 50:30:20 — ochrana kvality a rozvoje
4. Shift-left QA — kvalita jako kompetence, ne fáze
5. Koncept „hrabiček" — od specialistů k lidem s přesahem

‍

Výchozí stav: technologická sila

Direct měl klasickou strukturu, kterou poznáte skoro všude: technologické týmy podle disciplín — frontend, backend, analýza, QA, databáze — a každý se svým team leaderem, který se zodpovídal výš do firmy. Vývojář byl „frontendista" nebo „backendďák" a jeho svět končil na hranici jeho technologie.

Tahle struktura je skvělá pro hloubku specializace. Ale má jednu vadu, která se s růstem firmy prohlubuje: nikdo nevlastní hodnotu dodanou klientovi. Každý odvede svůj kousek a předá dál; výsledek je ničí a zároveň všech.

‍

Krok 1: Maticové podporovatelství — nový kontext, ne nová struktura

Neměli jsme mandát rušit technologické týmy. Tak jsme je nezrušili. Místo toho jsme přidali druhý rozměr: každý vývojář kromě své technologie získal příslušnost k value streamu (byznysovému segmentu).

„Jsi frontenďák — a zároveň jsi v Rychlé rotě, která se stará o klienta." „Jsi backendista — a zároveň ve Strážcích galaxie, kteří dělají likvidaci."

Každý vývojář tak měl dva lidi, kteří mu pomáhají, každého s jinou rolí:

• Team Leader technologie, aka. „Sekerka" — rozvíjí ho v jeho technologii. Technický mentor.
• TechLead businessového segmentu, aka. „Kladívko" (pravá ruka Product Ownera) — spolu s ním zodpovídá za delivery byznysového segmentu.

A ve value streamu byl vývojář „doma": tam měl tým i eventy jako standupy, planning, retro.

‍

Jak jsme vyřešili klasický problém maticové organizace

Maticové uspořádání má pověstný háček: vývojář dostává protichůdné úkoly od dvou šéfů. Tomu jsme se vyhnuli jednoduchým pravidlem:

Práci řídí jednoznačně backlog, který prioritizuje Product Owner. Technology lead jen pomáhá s tím, jak věci technicky odbavit, a pomáhá s technickými položkami, které vývojář řeší ve svém čase. Nikdy nedává konkurenční „co".

Vznikli nám tím vlastně „fejkoví manažeři" — lidé s vlivem a zodpovědností, ale bez klasické mocenské linky. Největší skrytá práce nebyla v nastavení, ale v udržení: aby spolu sekerky a kladívka mluvili a řešili rozvoj lidí společně. Najít platformu, jak je dát pravidelně dohromady, trvalo dlouho — a je to věc, kterou bych příště řešil dřív.

‍

Krok 2: Sloučení analytiků do vývoje

V původním světě business analytici stáli mezi byznysem a vývojem: navnímali potřebu, vymysleli řešení a detailně ho zadali vývojářům. Tým tak dostával přežvýkané zadání — a ztrácel kontakt s tím, proč věc dělá.

Zrušili jsme samostatný tým analýzy a místo něj vytvořili kompetenci Low Code Development. LCD vývojáři normálně zapadli do týmů a jejich práce spočívala v tom, že byznysovou potřebu přetavili rovnou do funkčního řešení — ne do dokumentu k předání:

• přišli jsme s BPMN enginem, kde místo popisu procesu v diagramu vznikaly rovnou funkční procesy běžící v produkci;
• podobně jsme si vyrobili nástroje pro pricing.

K tomu se celý tým musel účastnit refinementů — nebylo jich málo, ale byly nutné, aby tým věděl co a proč dělá, popsal si vlastní story a vzal za zadání odpovědnost.

Někteří bývalí analytici zapadli do leaderských rolí: analytik má díky silné znalosti byznysové domény ideální výbavu na to být pravou rukou Product Ownera. Transformace pro ně nebyla degradace, ale nová role.

‍

‍

Krok 3: Pravidlo 50:30:20 — jak ochránit kvalitu a rozvoj

Klasický problém: technický dluh a refaktoring se nikdy nevejdou do produktového backlogu, protože tlak na nové funkce je vždycky větší. Přišli jsme proto s mentálním rámcem 50:30:20:

• 50 % času na nový vývoj — položky backlogu, dodávání hodnoty;
• 30 % na rozvoj sebe, týmu a aplikací — vzdělávání, konference, refaktoring, technický dluh, chyby;
• 20 % na přípravu — refinementy, planning, retro, standupy.

Klíčové: nebyl to bič ani striktní pravidlo. Cílem nebylo dodržet poměr každý sprint, ale sledovat dlouhodobý průměr. Když něco hořelo, klidně šel vývojář na pár sprintů na 70–80 % nového vývoje — a pak se to s Product Ownery zase srovnalo.

Krok 4: Shift-left QA — kvalita jako kompetence, ne fáze

Představte si vývojový cyklus jako čáru zleva doprava: plánování, analýza, kódování, testování, nasazení. V klasickém modelu se testuje až na konci, úplně vpravo — a chyba, která vznikla na začátku, se najde nejdráž a opraví nejdráž. Shift-left znamená posunout testování a péči o kvalitu co nejvíc doleva, tedy k začátku cyklu, a dělat ji průběžně. Čím dřív se chyba najde, tím levněji a rychleji se opravuje — dokud je změna ještě malá.

V praxi to znamená, že kvalita nesmí být poslední článek řetězce. QA jsme proto udělali plnohodnotnou součástí týmu od začátku — garanta a nositele know-how o kvalitě, ne člověka, který až na konci všechno ručně otestuje. Kvalita se tím stává sdílenou zodpovědností celého týmu, ne oddělenou fází na konci. Konkrétně:

• QA byl u definice user stories — pomáhal nastavit, co vůbec znamená „hotovo a kvalitní", ještě než se začalo kódovat;
• testování a kontrola kvality běžely průběžně uvnitř týmu, ne až při předání „hotového" kódu jinému oddělení;
• využívali jsme i pravidlo čtyř očí — vývojáři si kód kontrolovali navzájem a porovnávali ho s vizuálním zadáním.

Výsledek: práce šla do produkce prakticky bezchybná a počet chyb klesl o polovinu (viz hlavní příběh).

‍

Krok 5: „Hrabičky" — od specialistů k lidem s přesahem

Aby tým mohl dodávat end-to-end, nemohl být složený z čistých specialistů. Začalo vznikat něco, čemu jsme říkali hrabičky (hrábě).

Znáte T-shape pattern vývojáře: svislá čára je hluboká specializace, vodorovná je obecný přehled v dalších oblastech. My jsme chtěli, aby ten generalistický přesah nebyl jen povrchní — aby člověk uměl několik dalších kompetencí o stupeň výš, na juniorní až mediorní úrovni. Z „téčka" tak vyrostlo víc čar mírně dolů — hrábě.

Pravidlo bylo jednoduché a pragmatické: když tým nějakou dovednost potřeboval dlouhodobě, naučil se ji — a když ji potřeboval jen krátkodobě, půjčil si člověka, který ji uměl. A úkolem vypůjčeného člověka bylo tým to naučit, ne to za něj udělat a zase zmizet.

Tohle souvisí s tím, proč týmy v roce 2023 rostly — z pětičlenných na dvanácti- až třináctičlenné. Nebyl to růst pro růst. Potřebovali jsme, aby každý tým uměl dodávat do více aplikací svého value streamu — a učit takhle široký záběr pětičlenný tým by trvalo věčnost. Proto jsme týmy stavěli tak, aby v nich byly kompetence, které dlouhodobě potřebují, a lidé se v nich učili mezi sebou. Růst měl jasný strop: nerostlo to donekonečna, jen do velikosti, kdy měl tým pohromadě všechno, co pro svůj záběr potřeboval. Učení bere čas, ale byla to vědomá investice.

Výsledek v číslech: podíl „hrabičkářů" vzrostl z ~10 % (2023) na ~70 % (2025). Detailně v modulu Plochá struktura, self-design scaling a kompetenční matice.

Co si z tohoto modulu vzít

1. Nepotřebujete reorganizaci, abyste dali lidem nový kontext. Maticový rozměr nad existující strukturou je stravitelný první krok.
2. Vyřešte konflikt dvou šéfů předem — jednoznačným pravidlem, kdo dává „co" (backlog/PO) a kdo „jak" (technology lead).
3. Analytik není překážka, je to budoucí leader. Sloučení do vývoje uvolní jeho doménovou znalost tam, kde je nejcennější.
4. Kvalitu a technický dluh ochráníte jen tím, že na ně vyhradíte prostor — ale jako dlouhodobý průměr, ne jako policejní pravidlo.
5. Šířku je potřeba vědomě pěstovat i odměňovat, jinak zůstanete u specialistů, kteří na sebe čekají.

‍