Konec nedotažených projektů aneb jak v Seznamu našli recept na lepší řízení vývoje a spokojenější vývojáře

Když jsou členové týmu nespokojení, nejsou efektivní a hrozí, že odejdou. To je průšvih u každého šikovného zaměstnance a u vývojářů obzvlášť. O ty se totiž firmy stále přetahují, a tak byť to může znít jen jako fráze, spokojenost zaměstnanců je klíčová, protože pokud jsou dobří, tak jakmile se ozvou, mají na stole hned několik nabídek od konkurence.

V Seznamu i z těchto důvodů nedávno dokončili velkou změnu, která spokojenost a s ní i výkon vývojářů a dalších expertů zvedla. O celém projektu a jeho výsledcích píše jeden z jeho hlavních aktérů, Jan Šebek, manažer projektové kanceláře v reklamní divizi české internetové jedničky.

***

Začalo to v roce 2018 v naší reklamní divizi. Ta je největší ze sedmi, zaměstnává přes 230 lidí a je s ní spojená více než polovina všech tržeb Seznamu. Zhruba 150 lidí v divizi se zabývá přímo vývojem, ostatní jsou na dalších pozicích, například produktoví manažeři nebo byznys analytici. Změna procesů, kterou jsme prošli, se týká všech.

Když jsme s transformací začali, fungovalo u nás asi 25 vývojových týmů a každý měl svého vedoucího vývoje. K tomu tu bylo asi 12 produktových manažerů, kteří měli na starost jeden nebo více týmů. K ruce jim byl také scrum master, ten se obvykle staral o dva až tři týmy. Struktura to byla složitá a důsledkem bylo i několik procesních failů.

Měli jsme s nastavením správné struktury a procesů problém, který ale řeší i další velké a známé firmy. Do mnohých jsme chodili, diskutovali s jejich zástupci, učili se od nich. Zpětně musím přiznat, že nám to pomohlo rozšířit si obzory a vystoupit z našich zajetých kolejí. I proto dnes sdílíme náš příběh.

Věříme, že může pomoci všem, kteří se najednou ocitnou ve slepé uličce. Změny u nás totiž měly nakonec pouze pozitivní dopady a přinesly dobré výsledky. V celém týmu jsme například zásadně snížili fluktuaci, výrazně se také zvýšil počet úspěšně dokončených projektů a zkrátila se doba jejich dodání.

Projekty trvaly roky a často se nakonec nerealizovaly

Jedním z častých problémů původního nastavení fungování vývojových týmů bylo, že neexistovala žádná úroveň, která by řídila priority a hlídala závislosti v celé divizi. Vznikla i situace, kdy dva týmy pracovaly na projektech s jiným názvem, ale stejným cílem.

Problém nastával také v situacích, kdy měl projekt dopad na dva a více vývojových týmů. Každý produktový manažer s daným týmem měl vlastní priority a stávalo se proto, že část hotového projektu skončila jen „v šuplíku“. Kvůli nedostatečné komunikaci a nejasným společným prioritám jsme plýtvali časem zkušených lidí.

S odstupem se naše někdejší problémy zdají být do očí bijící, v zajetých systémech o tolika týmech a lidech však není jednoduché určit záškodnický prvek. Na začátku jsme mysleli, že nám pomůže role projektového manažera, který bude řídit priority mezi týmy a pomůže projekty úspěšně dokončovat. Bohužel jsme brzy narazili, protože neexistovaly priority na úrovni portfolia, ale pouze na úrovni jednotlivých týmů.

Je hodně těžké, ale zároveň klíčové udělat si čas a vystoupit ze zajetého systému a podívat se, jestli to děláme dobře. Na začátku bylo nejdůležitější přenastavit týmy a role v nich, abychom si připravili půdu pro další procesní změny.

Stačí nám tři úrovně a jen pár manažerů

Jedním z problémů, které jsme dlouhodobě řešili, byla obtížnost naplánovat vývojářům smysluplný a spravedlivý kariérní rozvoj. Ideálně opřený o pravidelné milníky, při kterých dochází k navýšení mezd, a tím i ke srovnávání s aktuálními trendy na trhu práce. Došli jsem k tomu, že nejlepší je, když si řešení a svůj kariérní rozvoj navrhnou lidé sami.

Nakonec jsme se dobrali k následujícímu závěru: máme tři úrovně seniorních vývojářů, jasnou odbočku mezi manažerem a specialistou a rámcově definované dovednosti pro podporu spravedlivého rozřazení do skupin.

Mělo to skvělý efekt. Spousta manažerů přiznala, že chtějí být raději seniorními vývojáři a o vedení lidí zase tolik nestojí. Počet manažerů tak klesl o polovinu. Spravedlivě jsme rozdělili seniory podle jejich dovedností. Tím, že zmizeli manažeři, se vytvořily ploché struktury. V rámci nich lidé najednou chtěli sami experimentovat s různými přístupy k vývoji, jako jsou virtuální full stack týmy na projekt, virtuální specializované týmy a podobně.

Pomohl P3O model

Následnou práci nám hodně zefektivnila metodika P3O (3P office – project, program, portfolio office). Začali jsme definovat procesy, role a jejich odpovědnosti. Výsledkem byla první verze našeho vlastního projektového workflow, kde se snažíme o spojení toho nejlepšího ze světa agilního a waterfall přístupu. Je pro nás přitom důležité dělat si to po svém, prakticky, aby nešlo jen o buzzwordy, ale výsledek měl skutečný efekt.

Sbíráme nápady, přijít s nimi může kdokoliv, následně je na úrovni programů, tedy ucelených částí systému, prioritizujeme. Poté je společně s nejzkušenějšími vývojáři projdeme a přilepíme na ně za každou komponentu hrubý odhad náročnosti projektu, s čímž souvisí i odhad ceny.

Výsledný seznam priorit se zástupci vývoje rozplánujeme mezi jednotlivé týmy a tím vznikne roadmapa pro následující období. Tu pravidelně aktualizujeme a jakýkoliv posun termínu včetně důvodu je transparentní pro všechny.

Čtvrtletní plánování

Po různých pokusech jsme zjistili, že je pro nás nejefektivnější plánovat na tři měsíce. To je pořád dostatečně krátký čas na to, abychom dokázali reagovat na případné potřeby na trhu. Dřív jsme dělali hodně projektů, ale byly nepřehledné a trvaly příliš dlouho. Když máte projekt na rok nebo tři, je pravděpodobné, že se původní potřeba změní a projekt se nikdy nedořeší a skončí v šuplíku. To se nám běžně stávalo a lidi to demotivovalo.

Začali jsme proto rozpadat aktivity na menší části. Dosáhli jsme toho, že projekty jsou teď mnohem přehlednější. Menší kousky si člověk odškrtává a má z toho dobrý pocit. Celkově se kratší projekty také míň protahují, a naopak více dokončují.

Nakonec přišla na řadu ta nejtěžší část, a to přesvědčit více než dvě stovky lidí, kteří se nově nastavenými procesy měli začít řídit. Ale i to se povedlo. Pokud by se mě někdo zeptal, zda bych do toho šel znovu, moje odpověď by byla určitě ano. Výsledek si zatím chválí i ostatní.

Není to pouze o pocitech, konkrétní přínosy se snažíme podložit i čísly. Byť reálně pracujeme na více projektech, než tomu bylo dříve, úspěšněji je dokončujeme. Aktuálně nám průměrný projekt trvá zhruba tři měsíce, což pro nás ve scrumu představuje šest sprintů.

Zároveň víme, že průměrně se nám náročnost projektu oproti prvotním odhadům zvyšuje zhruba o 19 %. To v přepočtu znamená, že průměrná délka projektu se protahuje o půl měsíce, tedy jeden sprint. Díky tomu jsme schopni našim zákazníkům dodat přidanou hodnotu daleko dříve než před změnami.

Dalším přínosem je, že díky programové a portfolio vrstvě, kde pravidelně sledujeme stav jednotlivých projektů, nám splněné úkoly nepadají do šuplíku. Jednotlivé návaznosti jsou na kliknutí vidět v roadmapě a každý člen týmu se díky tomu může podívat, jaký projekt ho v příštím týdnu/dvou čeká. Zároveň je to místo, které jednoznačně určuje priority a už se nám nemůže stát, že některý projekt skončí nedotažený proto, že tým, který byl k jeho dokončení nutný, měl jiné priority.

Změny nám přinesly hlavně transparentnost v tom, co děláme. A to nejen na úrovni týmu, ale v celé divizi. To přispívá k tomu, že každý zaměstnance se cítí více vtažený do toho, co se ve firmě děje, a přispívá to k jeho spokojenosti. Důkazem může být extrémní snížení fluktuace lidí, která se v reklamní divizi dostala na nejnižší úroveň z celého Seznamu.

Samotný první proces trval zhruba rok, ale měníme se dál. Úplně hotovo nebudeme mít nikdy. Neustále si dáváme zpětnou vazbu a co tři měsíce dochází ke zefektivňování, což drží systém stále v pohybu.