Podcast

Dobrý den, jmenuji se Jirka Vicherek.
Ahoj, tady Karo Šmánek, vítáme vás u dalšího dílu podcastu Datatolku. Dnes tu máme Tondu Kučerovu z LiveSportu. Ahoj, Tondo.
Čau.
Ahoj, Tondo, vítáme tě v Datatolku. Ty jsi Head of BI v LiveSportu. LiveSport je asi jedna z nejznámějších českých technologických firem. Pro těch pár, co se nezajímají o sport ani o českou technologickou scénu, co je LiveSport zač a jaká je tvá role?

Díky za pozvání. LiveSport, ano, asi bych řekl, že patří mezi větší a známější technologické firmy v Čechách. Doufám, že tomu tak je, ale to musí posoudit někdo jiný, protože já to tak vnímám. Každopádně LiveSport je technologická firma. Hodně lidí ji vnímá jako sportovní výsledkovou firmu, což je částečně pravda, ale já ji vnímám hlavně jako technologickou společnost, která se snaží prostředí sportu a sportovních výsledků zlepšovat pomocí technologií. Používáme spoustu zajímavých technologií, jak dostat data k uživatelům, do aplikace i na web.

Často se nám stává, že nás lidé vnímají jako sázkovou kancelář – opravdu se to někdy stává. A to je důležité vysvětlit, že nejsme sázková kancelář. My poskytujeme sportovní výsledky. V poslední době, co děláme, jsou sportovní zprávy – začali jsme dělat sportovní novinky. Hlavní důvod je, že jsme se chtěli trochu rozkročit, aby naše služba nebyla závislá jen na sportovních výsledcích, a nabídnout uživatelům komplexní sportovní zpravodajství. Naší vizí je dobýt sportovní svět nejen sportovními výsledky, ale i komfortním servisem. Aby uživatel měl důvod k nám chodit každý den od pondělí do neděle, aby s námi vstával a usínal. Víme, že někteří uživatelé tak skutečně žijí sportem.

Co tedy dnes v aplikaci LiveSport najdu?
V aplikaci LiveSport najdeš zhruba 30 a více sportů, záleží, jak to počítáme – motorsport a další. Mnoho zajímavých sportů, které u nás lidé třeba vůbec neznají, například indický kabaddi. Možná někdo na táboře hrál hru, která se jmenuje Hutu Tutu, kdy se lidé honí a musí křičet „Hutu Tutu“, aby mohli někoho chytit. V té hře vykřikují něco a běhají po malém hřišti, je to trochu jako zápas. Pokud přestanou křičet, nemohou nikoho chytit. Je to docela zajímavé. Kabaddi je druhý nejpopulárnější sport v Indii po kriketu. Indie má přes jednu miliardu lidí, takže si umíš představit, kolik tam fanoušků tento sport sleduje. Takže i takový sport u nás najdeš.

Nabízíme také finský pesäpallo, což je obdoba baseballu, a spoustu dalších zajímavých sportů. Samozřejmě ty hlavní sporty jsou fotbal, basketbal, tenis. V několika zemích je to pak třeba hokej, například ve skandinávských zemích, v Česku nebo v Kanadě. A zmiňuješ kriket, který je velmi zajímavý – hodně populární je v bývalých britských zemích, jako je Jihoafrická republika, Austrálie, Indie, Pákistán. Tyto země dohromady představují asi přes 2 miliardy lidí, kteří kriket rádi sledují.

Ty jsi zmínil spoustu zemí. V kolika zemích je vlastně LiveSport dostupný?
Tuto otázku dostávám docela často. Jednou jsem tam našel uživatele ze Severní Koreje. Google nám aktuálně reportuje zhruba 241 zemí, a ze všech těch zemí máme nějaký traffic. Je to zvláštní, objevil jsem i země, které jsem nikdy neznal, i spoustu ostrovních států. Je to dáno i tím, že Google reportuje geolokalizace na základě cestování uživatelů. Dá se říct, že není místo na Zemi, kde by naši aplikaci lidé nepoužívali. I když je to třeba jen v jednotkách či desítkách uživatelů, v podstatě nás dnes používají po celém světě.

Nejsilnější uživatelskou základnu máme asi v Evropě, hodně rosteme v Latinské Americe a máme také dost uživatelů z Afriky.

Jak je to velké celkově?
Pokud mluvíme o loňském roce, máme přes 100 milionů uživatelů. Je to sice specifické, protože je to sezónní; hodně nás ovlivňuje sportovní realita. Pamatuji si, když byl covid – to si asi pamatujeme všichni – někdy v dubnu 2020 nám to úplně spadlo. Když jsme se podívali na graf, zhruba nám to zničilo statistiky meziročně.

Padli jsme někde na 10 až 15 milionů, možná i méně, a to byli takoví „hardcore“ uživatelé, kteří u nás třeba nesázeli, nebo byli víc než jen sázkovou kanceláří. Ti uživatelé jsou zvyklí sázet pořád, takže sázkové kanceláře v té době vypsaly třeba speciální sázky na pingpong v Rusku a podobně – tyhle uměle vytvořené soutěže běžely furt – my na ně sázení drželi, ale jinak většina lidí odpadla, protože neměli jsme kontent, nebylo o čem psát, nebylo o čem poskytovat zpravodajství ani výsledky.

Tak jsme zjistili, že nás hodně ovlivňuje sportovní realita, která se pak odráží i v datech. Ale přes 100 milionů uživatelů v nějakých vrcholových obdobích – co se týče dopadu – nám ukazuje tu komplexitu a velikost firmy. Když říkáme, že jsme největší český startup a že působíme ve 240 zemích, může se to zdát abstraktní. Ale že naše aplikace má desítky, stovky milionů uživatelů, to vypovídá o složitosti a rozměrech firmy.

Zajímalo by mě, když máš tolik zemí – říkáš přes 200 – a zmiňuješ sporty, které nedokážu ani vyslovit, jako ten Hutu Tutu a podobně, tak předpokládám, že musíte trávit hodně času přípravou verzí stránek pro jednotlivé země. Jak se množství těch zemí liší od množství domén, které máte na světě?

Ano, liší se to. Je důležité říct, že máme různou kvalitu dat, odkud skutečný traffic přichází. Využíváme přitom jazykové pokrytí. Dnes máme asi 33 jazyků. Pokud uděláme španělský web, pokryje i regiony, kde se španělsky mluví, ale nemáme tam lokalizovanou doménu. To samé je s angličtinou, ta osloví skoro všude.

Máme také specifické země jako Indonésie, Malajsie nebo Gruzie. Naši britští uživatelé řeší třeba rozdíl mezi názvy „soccer“ a „football“. Řešili jsme to, když jsme měli projekt zaměřený hlavně na Ameriku, kde jsme používali „soccer“. Například projekt Soccer24 má největší traffic z Afriky, což je trochu vtipné.

Máme asi 50 až 60 webových projektů, číslo se mění, protože některé končí, nové vznikají. Nedávno jsme otevřeli filipínský projekt v zemi s velkým potenciálem. Nově tam máme i jazyk Tagalog (filipínštinu), protože i když Filipínci mluví hodně anglicky, věříme, že přidávání jazyků nám pomůže oslovit určité regiony.

Přesto ale necustomizujeme příliš pro jednotlivé regiony. Využíváme škálování jednoho řešení po celém světě a customizace je jen minimální. Na frontendu jsou to hlavně top soutěže a nastavení preferovaných sportů. Například v Austrálii nebo Indii nemusí být fotbal na prvním místě, ale je tam mix sportů. Jinde je většinou fotbal první. Občas řešíme i sezónnost, třeba v zimě se objevují zimní sporty, které někdy nahrazují baseball.

Na stránce tak často najdete top 7 nebo top 8 sportů. Takže určitá customizace tam je. Máme i země, na kterých se více fokusujeme, vedeme tam kampaně a podobně.

Pokud se mi tedy ukáže například lyžování místo baseballu, je to tedy výsledek práce vašeho týmu a toho, co pro LiveSport děláte?

Ano. Jak vypadá datové oddělení, tvoje BI oddělení, a jak zkoumají data a jejich funkci?

Máme tam dva menší týmy po pěti lidech. Jeden tým se specializuje na data engineering a data development – staví celý datový produkt. Jsme kompletně v Google Cloudu a na konci máme dashboard v aplikaci Tableau, takže mnoho posluchačů si představí vizualizace jako konečný produkt. Tenhle tým se stará o datový produkt.

Druhý tým řeší market intelligence, competitive intelligence, market research a business analýzy. Hodně spolupracujeme také s UX research týmem, který provádí výzkumy uživatelů. My děláme výzkumy mimo náš produkt a spojujeme je s clickstream daty, která spravuje vývojový tým.

Je to celkem komplexní a není jednoduché procesně zajistit, aby to celé fungovalo, ale věřím, že se nám to daří.

Ty jsi říkal, že jsi v LiveSportu už osm let. Můžeš nám říct, jak se tvoje role a oddělení během té doby změnily? Komu jsi reportoval a jak vidíš výhody a nevýhody těch změn?

Ano, jsem zde docela dlouho. V jedné firmě říkám, že firemní kultura je pořád stejná a skvělá, což podle mě definuje LiveSport a důvod, proč tam spousta lidí je.

Kolikrát mám pocit, že jsem byl už v čtyřech či pěti firmách, protože firma se strašně změnila. Původně jsem reportoval přímo CEO v rámci marketingového oddělení. Později marketingové oddělení získalo svého CMO a já jsem vedl tým zaměřený na performance marketing, pomáhal jsem s trafikou a webovou analytikou.

V roce 2019 vznikl research and development tým, který řešil budoucnost produktu. Já jsem přešel do tohoto týmu. Přišli tam další lidé, například Vzdeněk Hejnák, který je dnes leader data development týmu. Takže jsme byli ve dvou. Ten R&D tým se později transformoval v produktový tým.

Nabrali jsme další dva lidi, byli jsme čtyři, dělali produktové a marketingové analýzy, protože jsme byli přímo v produktu a hodně jsme spolupracovali s UX týmem.

V roce 2020 vzniklo oddělení commercial a přišel Lukáš Raška ze Singapuru, který měl zkušenosti s vedením business intelligence týmů. Vzal nás pod sebe, což bylo skvělé, protože zkušenosti jsou vždy jinak cenné. Myslím, že nás to posunulo mnohem dál a posílilo naši pozici ve firmě.

Často se stávalo, že lidé označovali celé obchodní oddělení za BI, i když my jsme z business developmentu. To svědčí o tom, že naše role je ve firmě klíčová.

Začali jsme dělat spoustu dalších věcí – data i pro HR, spolupracujeme s controllingem. Na druhou stranu zůstává produktová a digitální analytika naším jádrem.

Pokud bychom se podívali na vaši agendu či produktovou mapu na tento rok, co tam najdeme za problematiky a témata?

Je toho skutečně hodně. Hodně se zaměřujeme na vyhodnocování clickstream dat, což znamená nejen odkud uživatelé přijdou, ale co tam dělají, jak dlouho na stránkách zůstanou. Zajímá nás, proč odcházejí – tzv. churn.

Snažíme se dlouhodobě měřit customer lifetime value. Každý se na to dívá jinak. Nemáme pro tento model tak komplexní data, jak je mají e-shopy, které mají transakční data, takže se heuristicky snažíme odhadnout hodnotu uživatele.

Zajímá nás, jestli má větší hodnotu, když navštěvuje určité typy soutěží, nebo když kliká na různé funkce. Děláme analýzy „label actions“, což jsou akce s vyšší hodnotou než třeba kliknutí do kalendáře nebo vyhledávání, protože tyto akce mají přímou vazbu na příjmy z reklamy, která nás více méně živí.

Nad uživateli počítáme model, který jim přiřazuje hodnotu na základě četnosti návštěv a akcí, které dělají.

Pokud chceš, mohu přepsat pokračování nebo jakoukoli část znovu!

Třeba byl uživatel získán přes nějaký kanál, ať už je to placená kampaň, nebo organický provoz. Můžeme si říct, že toto je směr, který máme posunovat, který máme zlepšovat. Protože pokud nejsme schopni uživateli přiřadit hodnotu, je pro nás velmi obtížné jej následně incentivovat. Vzhledem k tomu, že jsme globální společnost, v různých zemích stojí získání uživatele jinak. Někdy stojí uživatel 10 centů, jindy záleží na tom, na co incentivujeme, jestli na nějaký konkrétní sport nebo konkrétní výrazy, takže ceny se různí.

Musíme vědět, jestli si můžeme dovolit za uživatele dát třeba 4 eura, protože pokud nám vydělá 5 eur, můžeme do něj investovat bez omezení. Samozřejmě to má nějakou hranici. Je potřeba na to koukat, aspoň si to modelovat a odhadovat, protože jinak se může stát, že v marketingu utopíme obrovské peníze, které se nám nemusí vrátit.

Další věc, kterou musíme řešit, je churn, tedy odchod uživatelů. Musíme zjistit, proč se uživatelé vracejí. U této problematiky se zastavím podrobněji. Jsme tzv. non-contractual business, což znamená, že uživatel u nás neuzavírá smlouvu. U klasických SaaS služeb je výhodou, že víte, kdy uživatel odešel. U nás je velmi obtížné odchod uživatele definovat. Proto jsme si stanovili určitou hranici – například pokud je uživatel neaktivní 4 nebo 8 týdnů, označujeme ho za spícího, později může být reaktivovaný.

Problém je, že například fanoušci kriketu nechodí denně, ale jen na velké zápasy jednou za delší časový úsek. Proto do celé definice musíme zapracovat typ sportu a chování uživatele. Kdybychom například brali, že každý uživatel fandí fotbalu, očekávali bychom, že se na web alespoň jednou týdně objeví, třeba od pondělí do neděle, a případně během sezony si může dát pauzu. Nevíme ale, jestli je uživatel fandou tenisu, který sleduje Grand Slamy, jež se hrají jednou za čtyři měsíce. Takový uživatel může být pravidelným návštěvníkem webu, jen jinak rozloženým v čase.

Musíme tedy poznat, jaký sport uživatel preferuje, a pokoušet se mu ukázat další obsah, který by ho mohl zajímat. To je největší výzva: často nevíme, zda uživatel s námi skončil, jen to odhadujeme. Mnoho věcí si musíme pouze domýšlet, a to je zajímavé, jak velmi často pracujeme s odhady a modely.

To nás přivádí k tématu segmentace, o které jsme mluvili dříve. Můžeš specifikovat, jak k ní přistupujete? Určitě. Tlak na segmentaci byl od začátku, protože jsme nechtěli vidět všechny uživatele jako jednu skupinu.

Nejjednodušší metodou bylo podívat se statisticky na chování na webu – jestli jsou uživatelé, kteří přicházejí denně nebo dokonce stokrát za den a provádějí mnoho akcí, nebo jestli jsou uživatelé, kteří přijdou dvakrát za den, třeba jen zkontrolovat výsledek oblíbeného týmu o víkendu, a jen sporadicky na web chodí dlouhodobě.

Z těchto dat jsme vytvořili několik tzv. weekly segmentů založených na počtu akcí, které uživatel udělá za týden. Například pokud udělá méně než 500 akcí za týden, řadíme ho mezi casual uživatele, nebo naopak mezi core či power uživatele, pokud počet akcí překročí tuto hranici.

Sledovali jsme, jak se toto chování mění mezi týdny. Samozřejmě jsme sledovali i sportovní kalendář, protože aktivita klesá během okurkové sezony nebo svátků, například o Vánocích. Z objemu akcí se to dá poznat.

Ale tento přístup nám neříká, co uživatel skutečně potřebuje. Proto jsme zjistili potřebu hlubší práce s daty společně s UX týmem a kolegy z produktového oddělení. Seděli jsme kolem Dína Brabce a dali dohromady, že chceme řešit tzv. persony.

Začali jsme se na uživatele dívat z hlediska jejich potřeb – proč na web chodí. Jedna věc jsou jejich aktivity, které však nemusí zcela vystihovat motivaci uživatele. Někteří mohou kliknout zběsile a něco hledat, ale my potřebujeme vědět, proč jim obsah či určité soutěže významně pomáhají - třeba, že najdou informace o sázkách, sportech, nebo jiných oblastech.

Původně jsme plánovali vytvořit persony klasickou cestou – tedy analyzovat data a udělat clustering. Uživatele jsme takto našli, ale problémy nastaly při ověřování v dalších časových obdobích, protože modely se moc neopakovaly.

Proto jsme zvolili opačný přístup: já a kolegové jsme »vstoupili do dat«, protože jsme měli pocit, že uživatelé přicházejí z určitých důvodů. Proběhlo několik workshopů a diskuzí, kde jsme nadefinovali persony. Nakonec jsme skutečně identifikovali velmi podobné skupiny uživatelů, které jsou stabilní i za delší časové úseky.

Persony nám ukázaly, jak se různé typy uživatelů liší třeba ve využívání funkcí – například někdo používá funkci „oblíbené týmy“, jiný tuto funkci téměř nevyužívá, ale zajímá ho jiný obsah. Kvantitativní výzkum nám pak poskytl další podrobnosti.

Nakonec jsme prováděli i kvalitativní výzkum formou uživatelských interview, během kterých jsme si povídali s uživateli a často se nám rozšířily oči, protože jsme zjistili, že původní představy byly někdy zcela jiné od reality.

Měl bych jednu otázku. Vzhledem k širokému spektru zemí a domén, ve kterých působíte, a také obrovskému množství akcí a typů uživatelů – kolik person vlastně máte? Abych měl nějakou představu, řekl bych si, že jich bude asi osm. Přesně, person máme osm. Museli jsme to zjednodušit, protože víc by s nimi nebylo možné pracovat.

Jak jsem již zmínil, škálujeme náš produkt globálně a snažíme se o mírné přizpůsobení regionům, ale kdybychom měli více person, nebyli bychom schopni produkt pro všechny krajiny detailně customizovat. To by znamenalo mít mnohem větší tým vývojářů. Náš současný tým má zhruba 150 lidí, ale k tomu bychom potřebovali tým násobně větší.

Vyvíjíme pro platformy Android, iOS, KaiOS – která je známá například v Indii, kde KaiOS používá asi 400 milionů uživatelů – a někdy i GeoStore, kam však zatím nejdeme. Dále máme klasické webové prohlížeče.

Musíte mít backendisty, mobilní vývojáře a dalších odborníků, kteří jsou specificky zaměření. Vzhledem k tomu, že by pak bylo potřeba customizovat produkty i podle regionálních person, například indických, nepůjdeme zřejmě tímto směrem. Pokud bychom se na něco detailně zaměřili, asi bychom si vybrali jeden trh, na který by byla snaha koncentrace.

Zatím však žádný trh nepovažujeme za natolik hodnotný, abychom mu obětovali plný fokus. Věříme, že jsme schopni globálně produkt rámcově dělat s menšími úpravami podle regionů a zatím to funguje.

Mám dvě otázky. První je, zda jste během workshopů a ověřování person narazili na některá překvapení – momenty, které vám přišly neintuitivní, nebo naopak potvrzení vašich dosavadních znalostí, které se ukázaly být mylné? Občas se to stává. Nemohu být ve všech věcech úplně konkrétní, ale stalo se nám například, že jsme si mysleli, že určitá funkce musí být pro určitou skupinu uživatelů klíčová.

Například existuje záložka pro kurzové sázení, kde se srovnávají kurzy – očekávali jsme, že uživatelé, kteří se zajímají o sázení, ji používají. Ukázalo se, že daná persona tuto funkci téměř nepoužívá a zajímá ji spíše obsah, který jim pomáhá připravit se na sázení nebo získat jiné informace.

Doplňuji to jiným příkladem – často máte o personě představu, jak má fungovat, ale spojení clickstream dat a výzkumů ukazuje, že to nemusí být pravda. Ne všechno, co si původně myslíte, odpovídá realitě. Na druhou stranu se někdy potvrdí, že vaše předpoklady byly správné.

Druhá otázka se týkala týdenního segmentování – proč týden a ne den nebo například osm dní? Dobrá otázka. Tento přístup vznikl v našich BI oddělení. Hlavním důvodem je sportovní kalendář, zejména fotbal, který se hraje většinou o víkendu.

Zvažovali jsme denní, týdenní nebo měsíční intervaly a dospěli jsme k závěru, že týden je nejlepší. I další sporty jako hokej nebo americký fotbal mají většinu zápasů v týdnu – extraliga hokeje má 2-3 zápasy týdně, fotbal hraje pravidelně týdenní kola.

Tenis také má během týdne své události. Musíme tedy sledovat uživatele v týdnu, protože po nich nemůžeme chtít denní návštěvy, to není možné vzhledem k tomu, že nejsou zápasy každý den. Ale jednou týdně jsme si řekli, že uživatel by měl najít zajímavý obsah, který ho přiláká.

Cílem je, abychom měli co nejvíce obsahu pro daný týden, a aby uživatel nepřišel pouze na vrchol víkendu kvůli zápasům, ale i v průběhu týdne, v pondělí, úterý, nebo ve středu. Proto vznikly týdenní segmenty.

Mám jednu otázku – máte persony a týdenní segmenty, co s nimi vlastně děláte? Zajímavá otázka, na kterou se nás každý ptá. První věc je, že pokud nemáte segmenty ani persony, často se prosazují silné názory a hypotézy bez dat.

Segmentace a persony toto bourají. Končí „domněnkologie“, což je často oblíbený přístup lidí, kteří s předchozí zkušeností tvrdí „to jsme už zkoušeli a nefunguje to, naše uživatele chtějí něco jiného“.

Neříkám, že data vždycky musejí mít pravdu, obsahují určitý stupeň nespolehlivosti a většinou jsou historická, nemusí predikovat budoucnost.

Nicméně jsou klíčová jako podklad pro diskuzi, a to je to nejdůležitější. Nejde o okamžité změny, ale o otevření diskuse – například na úrovni managementu, vrcholného vedení, či produktových manažerů s odpovědností za danou oblast.

Diskuse může vést k tomu, že je potřeba něco změnit v produktu, například přidat jiný obsah, změnit soutěže, případně některé neefektivní aktivity ukončit z důvodu přílišných nákladů a nízkého přínosu.

Někdy už byly věci považovány za nutné, ale data ukázala, že to nemá význam. A to je dobré – díky tomu můžete některé věci odmítnout nebo naopak posílit.

Jako jednoduchý příklad lze uvést analýzu používaných zařízení a rozlišení v různých regionech. Tato data jsou důležitá pro testovací týmy, které musí rozhodnout, na kterých zařízeních produkt testovat.

Zejména v Africe má mnoho zařízení nevšední rozlišení a je potřeba rozhodnout, na jakých 80 % zařízení se bude zaměřovat testování. To je velmi užitečné.

Nebo sběr zpětné vazby z aplikací můžeme zmínit jako další příklad. Máme nástroj, který sleduje hodnocení v App Store. Když někdo dá aplikaci 3 hvězdičky nebo méně, zpráva putuje automaticky do Slackového kanálu.

Pokud je v nějaké aplikaci v dané zemi problém po releasu, vývojáři jsou o tom ihned informováni a mohou reagovat.

Tento proces může být rychlejší než zjištění, že uživatelé odpadávají až o týden později.

Typicky je k tomu využíván Crashlytics, nástroj, který monitoruje pády aplikace. Vývojáři pak mohou situaci vyhodnotit a často během hodiny udělat hotfix a chybu opravit.

To by byl jeden z příkladů aplikace dat k rychlé reakci.

Dlouhodobé produktové změny děláme společně s produktovým týmem a vývojáři, aby se některé věci zlepšily či změnily.

Přidali jsme nové funkce, ale to je většinou běh na dlouhou trať a musí to také odpovídat nějaké vizi. Mám si tedy představit, že vy to spíš používáte jenom k odhalování nějakých kategorií uživatelů a pak se na tu stránku díváte spíše globálně, anebo vlastně pro každého připravujete třeba nějaký personalizovaný obsah?

Ta první možnost. My vlastně v současné chvíli neumíme tak personalizovat ten obsah, že bychom ho cítili na jednotlivé persony, i když bychom si to možná přáli, nebo mě by se to třeba osobně líbilo. Na druhou stranu tam jsou nějaká technologická omezení, proč to není možné. Třeba i výkonová omezení, není jednoduché úplně personalizovat produkt například v reálném čase. To by bylo asi velmi složité, protože máme v některých chvílích opravdu obrovský provoz. Jsou to třeba miliony požadavků za sekundu, které přicházejí, a my kvůli tomu musíme škálovat i datacentrum, což není vůbec jednoduché, protože se pak může stát, že už tam fyzicky nezbývá místo.

Takže i toto je důležité, ale spíš je to o tom, abychom viděli, jaké typy uživatelů tam jsou, jaké konkrétní problémy řeší, a podle toho dávali stakeholderům možnost, co s tím lze udělat.

Ty jsi říkal, že jste vlastníci toho technologického řešení, jak vlastně probíhá zadávání práce u vás nebo její prioritizace? Mám dojem, že to řešíte hodně komplexně napříč odděleními, spojíte různé části uživatelského kontextu, jak tohle řešíte? Jsou to peníze a příjmy, co to odděluje, anebo je to vize, máte OKR či nějaký jiný framework? Jak v tom děláte pořádek?

Dobrý dotaz. My jsme centrem sběru požadavků, kam nám přicházejí požadavky úplně ze všech oblastí, co se týká dat. Prioritizace vychází z toho, že firma má nějaký roční plán. Na špici je nějaký příjem, dále uživatelé – to jsou hlavní metriky. Můžete se bavit o dalších výstupech a podobně, ale tyto jsou hlavní metriky, které nakonec chceme zvyšovat. To je asi to nejdůležitější.

Dlouhodobě jsme měli filozofii, že peníze jsou pro nás důležité, ale ještě důležitější je uživatel v uvozovkách. A pokud poroste produkt, to znamená, když porosteme v počtu uživatelů, věřili jsme, že příjem přijde nějakým způsobem automaticky. Pokud budeme mít dostatečně velkou bázi uživatelů a dostatečně velký produkt pro nějaké podniky, tak se monetizační potenciál vždycky najde.

Na druhou stranu roste konkurence, svět je propojený. Dnes už si můžete například jednoduše vyhledat spoustu sportovních výsledků přímo v Google. Takže musíme hledat nové způsoby, jak ten produkt lépe monetizovat. Příjem je pro nás důležitý, ne že ne.

Prioritizace tedy vychází z firemních cílů. Ta firma má nějaké cíle a my to děláme tak, že náš department, většina oddělení, se snaží napojit na tyto cíle. To znamená, co může dané oddělení udělat, aby se cíle naplnily. Ideálně se to rozpadá až na jednotlivce, aby každý, kdo pracuje celý rok, věděl, že to, co dělá, přispívá k dosažení těchto cílů.

Nemělo by se stát, že vám přijde požadavek na něco, co do této struktury nezapadá. Snažíme se také vést obrovský backlog firemních úkolů vedle sebe, což je velmi zajímavé cvičení.

Samozřejmě zatím jsme v ideálním světě, takže se nám stává, že nám přicházejí požadavky, které nejsou dlouhodobé, ale krátkodobé. Může přijít například velmi důležitý úkol, který začne mít velký význam, protože například obchodníci potřebují rychle data kvůli aktuální situaci. Takové požadavky nezahazujeme, naopak říkáme: „Hele, to dává smysl, protože nám to teď opravdu přinese nebo má potenciál nás výrazně posunout.“

Samozřejmě pak dočasně pozastavíme jinou práci a tomu se věnujeme. V roadmapě nejsme tvrdohlaví. Dodáváme interně dovnitř, ale necháváme si chvíli prostor, abychom tyto věci mohli odbavit.

Máme u nás tzv. domain leaders – to jsou lidé v týmu, v oddělení, kteří jsou specializovaní a komunikují s lidmi na druhé straně. Doménu si můžete představit třeba jako digitální marketing, obsah nebo UX.

Máme dedikovaného analytika, který přímo komunikuje s někým z dané oblasti. Je to o tom, aby spolu komunikovali, nastavili komunikační kanál a doménu rozvíjeli, tedy aby se bavili o metrikách a o tom, kam to celé posunout. Nepřipustíme, aby nějaká část firmy nebyla obsluhována daty nebo aby se požadavky nikomu nevěnovaly a pak nás někdo překvapil novým požadavkem, případně by byla škoda, že nemohou svou oblast posunout.

Snažíme se proto udržovat tyto domény. Zároveň edukujeme uživatele v tom, jak s daty pracovat a poskytujeme jim nástroje. Máme uživatele, kteří jsou Tableau Creators a tvoří obsah. Někteří jiní například dělají AB testování a používají pouze přístup do BigQuery.

Samozřejmě musíte uživatele nejdříve naučit, jak s daty pracovat; závisí, na jaké jsou úrovni – třeba znalost SQL. Edukace uživatelů je tedy zásadní.

BigQuery totiž účtuje za dotazy. Když někdo otevře tabulku o velikosti řádově desítek terabajtů s několika joiny, může to stát značné peníze. Proto je možné nastavit tzv. capping – omezit, kolik může uživatel udělat dotazů za den či za týden.

Vše vyžaduje nastavení a governance je časově náročná a není vůbec jednoduchá. Navíc když firma roste, governance se zpravidla nechce řešit. Máte jiné důležitější věci a governance působí jako dokumentace, kterou člověk chce dělat až po práci nebo později. To nám trochu nahrává.

My bychom se teď rádi každého zeptali na technologický stack. Už jste částečně naznačil, že jste na GCP, používáte BigQuery a frontend máte v Tableau. Jste tam jenom vy, nebo celý produkt?

Jsme tam, myslím, jedni z prvních ve firmě, částečně i tech oddělení a vývoj tam něco má. Píšeme si cloud popy a máme zajištěné doručování věcí, protože jeden z našich problémů byl výkon po světě. My dnes vlastně zrcadlíme web například s cloudpopem někde v Miami na Google serverech.

Dříve jsme se snažili vše doručovat z Prahy, což byl problém, protože třeba v Brazílii se to načítalo déle, a to není dobré. To jsme také objevili v datech.

K Google. Jsme kompletně na Google a důvod je jednoduchý – máme Google Analytics, které měříme a exportujeme do BigQuery.

Často slyším otázky: „Proč nemáte Snowflake, super technologii?“ Odpovídám, že musí být super, ale měsíčně nám do BigQuery přiteče 60 terabajtů dat a nemáme důvod migrovat do Snowflake, protože by to stálo víc než náklady, které tam máme, a ještě by to trvalo dost dlouho.

Takže používáme BigQuery a jsem s ním celkem spokojený. Je ale potřeba lidi s touto technologií dobře seznámit, vysvětlit výhody i omezení.

Výhodou BigQuery je, že platíte za query, například jeden terabajt stojí asi pět dolarů. Když máte pět až deset terabajtů tabulku a děláte složitější dotazy, může to být rychle finančně náročné, pokud pak máte například stovku uživatelů s otevřeným live connection.

Proto na konci máme Tableau server, na kterém provozujeme extrakty. Málo kdy používáme live connection do BigQuery, nabízí se spíš čistý extrakt, který se na serveru inkrementálně aktualizuje.

Dotazy mezi extraktem a Tableau jsou pak náročné pouze na výkon serveru, což je velká výhoda.

Nevýhodou je omezení velikosti extraktu, protože je limitovaný diskem. Proto musíme dělat kompromisy v tom, jak stavíme datamarty, abychom uspokojili uživatelské požadavky a zároveň byli schopni provoz technologicky zajistit.

Zkoušeli jsme několik přístupů, kombinaci extraktu a live connection; Tableau to umí nějak zvládnout, ale je to komplikované a postupně se v tom posouváme.

Zjistili jsme, že je málo firem v Česku, možná i střední Evropy, které mají zkušenosti s kombinací Tableau, Google a datového objemu v takovém rozsahu. Na světě je situace podobná, Google technologie jsou relativně nové a těžko seženete konzultanta, který by vám s tím poradil. Takže je to trochu složité.

Proč tedy nepoužíváte Looker? Nebylo by to lepší z hlediska synergie s Google stackem?

Samozřejmě to je první otázka, kterou lidé mají. Do určité míry by Looker byl zajímavý, má dobrou synergii s Google technologiemi.

Na druhou stranu tam vidím potenciální problém. Například starší Google Data Studio se nyní migruje na Looker Studio a v bezplatné verzi není možné řídit náklady na dotazy.

Napojíte to na BigQuery a můžete zapnout BI engine, který ale stojí desítky dolarů denně. Problém je také, že výsledky se cacheují, tedy když se někdo zeptá na stejný dotaz opakovaně, je výsledek načtený z cache.

Při více pohledech, filtrech nebo reportech ztrácíte kontrolu nad tím, kolik v BigQuery utratíte za měsíc, když máte velká data.

Když máte data v řádu megabajtů nebo gigabajtů, není to velký problém, náklady jsou řádově stovky dolarů.

Looker má samozřejmě perverzní možnosti cache a další věci, které bych dokázal ocenit. Měli jsme s nimi konzultaci, ale přechod z Tableau na Looker čistě technologicky by trval měsíce a výsledek nemusí být jednoznačný.

Navíc Looker není levný. Proto jsme stále u Tableau, které nám dává větší svobodu v vizualizaci. I oproti Power BI je Tableau asi nejlepší nástroj.

I když někteří nadávají, že je třeba něco složitější, v Tableau můžete vytvořit téměř cokoliv a přizpůsobit dashboard přesně podle svých představ.

Postupy v Power BI nebo Lookeru jsou spíše standardní, enterprise a korporátní – jednoduché šablony pro dashboardy, například výnosy, kde je to super, ale Tableau poskytuje větší volnost.

Chtěl jsem se vás zeptat na typ dat, která tam máte. Představuji si, že do toho vstupují clickstream nebo velké logy. Do jaké míry je můžete agregovat a jaké typy dashboardů vytváříte? Pokud mluvíme na řádkové úrovni, musí to být peklo.

Ano, to je to, co je typické v digitální analytice. Někdy můžeme udělat agregaci. Každý řádek totiž obsahuje user ID. Aby analýza digitálního produktu měla smysl, nelze prostě agregovat každý den.

Nemůžeme například zahodit user ID, protože pokud to uděláme, dostaneme nesprávný výsledek: „V pondělí jsem měl tisíc uživatelů a v neděli sedm tisíc“ – což je lež, protože bysme sčítali uživatele víckrát.

Proto si musíme udržovat user ID velmi dlouho, což u nás znamená tabulky o miliardách řádků, protože máme zhruba 100 milionů uživatelů měsíčně.

Musíme řešit business požadavky tak, aby odpovídal datový model, který nezatěžuje zbytečně uchováváním user ID, když to není potřeba.

Lidé často chtějí odhadnout, zda je potřeba takto detailní data, protože velké tabulky nejsou snadno zpracovatelné.

Často bojujeme s tím, jaká úroveň agregace nebo detailu má kde být.

Je to hlavní výzva, protože když máte třeba dvě až tři terabajty dat pro live connection, Tableau to občas pomalu zpracovává, i když dotazy jsou poměrně rychlé.

Je lepší mít denormalizovanou tabulku, ale když příliš agregujete, uživatelé nedostanou data, která potřebují, a často se nás ptají nebo chtějí doplňkovou ad hoc analýzu.

A je to, mám to. Podívej, pořád hledám nějaký kompromis toho, že používáme na tom světě jednu technologii, například Firebolt. Ti se tvářili, že to tady mají, ale podle mě spíš mají dobře připravené příklady, jak to opravdu běží rychle nad desítkami terabajtů dat. Oni to mají nějak nastavené i na ABSku. To jsme ještě nevyzkoušeli.

Ale říkáme si, že s tím skutečně bojujeme. Co chcete dát? Ten typ, který vlastně odmazává, schraňuje do budoucna, nebo to plně využívá? Když vám tam přiteče třeba 60 TB měsíčně, tak kolik toho přežije do konce roku? To je právě klasický problém, když to člověk provozuje dlouhodobě, začne to napočítávat a řekne si: "Hele, nejdřív archivujeme."

Co děláme? Archivujeme – to znamená, že ta klasická tabulka v BigQuery, první z Gáček, je vlastně v uvozovkách tabulkou, do které každá plná partition vstupuje. Důležité je říct, že v BigQuery jsou tabulky partitionované po dnech. To znamená, že se můžete dotazovat pouze do toho dne a tím se oddělují náklady, což je docela dobré. Navíc jsou tam tabulky klastrované po nějakých dimenzích. Tuhle tabulku však klastrovat nemůžete, protože je připravena přímo od Googlu. Pak jdou další klastrovatí třeba právě po těch dimenzích, což odděluje náklady na dotazy.

To představuje požadavek, že uživatel musí používat nějaké partition plánování, aby využíval jen ty správné partitiony. Jak to máte zajištěné? Jestli myslíš uživatele, který tam píše query, tak když tam někdo napíše query s hvězdičkou, partitiony jsou mu stejně na nic. Ano, tak nějak.

Zajištění máme, máme samozřejmě nějaký monitoring, který hlídá, co se tam odehrává. Když je něco špatně, zaznamená to. Ale když se dělá 0x, nebyli jsme si kamarádi. Takže technologicky toto zajištění nemáme natolik, aby nikdo nemohl napsat špatnou query. Zajímavé je, jestli by to vlastně vůbec v tom rozhraní šlo omezit, nejsem si úplně jistý.

Každopádně se nám to snad nestává. Myslím, že lidi si na to dneska už dávají pozor a tyto věci nedělají. Například tabulka má 30 KB, tak je mi to celkem jedno, protože potřebuji jen nějaký preview. Ale u větších tabulek to ne. Tam se opravdu snažíme, aby lidi používali dimenze a věci, které mají. To, co tam je, například exportujeme z Google po 30 nebo 50 dnech. Pokud jsou data starší než 50 dní, zabalíme je do formátu Avro a uložíme do Cloud Storage. Tam to stojí mnohem méně než v BigQuery.

V BigQuery jsou totiž dva typy storagových nákladů – jeden je za aktivní data (méně než 90 dní), které platíme, myslím, pět dolarů za terabyte, a druhý je za data starší 90 dní, kdy se platí možná dvojnásobek, tedy třeba deset či dvacet dolarů. Zajímavé je, že pokud na starší data spustíte dotaz, znovu se aktivují a zvyšují náklady.

Snažíme se tedy v celé pipeline řezat tak, abychom si nechávali historická data už pouze za účelem počítání v poslední fázi, a pak obvykle data archivujeme.

Měli jsme jednu tabulku, které jsme interně říkali L1 Events. Protože máme 60 projektů, což znamená 60 prototypů (datasets), měli jsme v Composeru (Airflow sám) obrovské sklady dat. Tato tabulka měla asi 500 TB, což bylo zajímavé, protože byla nebezpečná na dotazování.

Stále je velká, ale začali jsme ji archivovat. Data starší než dva roky jsme zahazovali, protože byla zbytečně veliká. Největší obavy jsem měl, že analýzy budou stát hodně peněz, ale nejvíc stojí storage. Jasné.

Co Big Data a BigQuery? Je Big skutečně dostatečně velké na dotazování? Zmiňoval jsi třeba algoritmy strojového učení na segmentaci, klasteringu a podobně. Vše děláte v BigQuery, nebo používáte i jiné nástroje?

BigQuery je skvělé v tom, že i terabitové dotazy vrací za pár sekund. Dělají to dobře. Víc než 90 % věcí, které dneska děláme v pipeline, je v SQL. Nyní například počítáme kombinací SQL, Pythonu a R. Záleží, kdo co dělá a jaký má nástrojový stack.

Ale snažíme se, aby lidi v týmu postupovali a učili se. Většinou pracujeme SQL, ale občas potřebujeme něco odehrát v Pythonu, protože ten je vhodný.

Někdy je R-kový background užitečný, znám spíše R než Python. BigQuery má i možnost BigQuery ML, kterou zatím nepoužíváme v produkci.

Mluvil jsi také o Dataformu, že balíte SQL, aby to nebyl jenom custom kód?

Ano. Dataform jsme začali používat v roce 2019-2020. Je to nástroj podobný DBT, který je teď populárnější. Není to úplně totéž, ale je to orchestrace, kde píšete SQL s nějakým templatingem v JavaScriptu. Má to assertions, tedy testy, a poskytuje datovou lineage – vidíte, jak data prochází pipeline. Dataform koupil Google a je nyní součástí jejich služeb, i když v betaverzi. Už se dá začít používat a doufáme ve větší rozvoj.

V BigQuery je teď také relativně nová možnost vidět detailní datovou lineage. Takže Dataform nám hodně pomáhá v orchestraci datových pipeline.

Přemýšleli jsme o těch velkých datech, která taháte od stovek milionů uživatelů z různých zemí, a o tom, jak udržujete komplexitu. Co externí data?

Máme projekt, který jsme interně před rokem a půl nazvali "Bible". Je to zatím dočasný název, později vymyslíme lepší. Je těžké najít lepší název, protože už se nás lidé ptají, kdy Bible bude venku.

Chybí nám dokončit frontend, což se nám snad podaří v nejbližších měsících. Projekt spočívá v tom, že kromě dat z různých typů výzkumů (market a user research) sledujeme i chování uživatelů.

Chybělo nám poznání samotných trhů. Chtěli jsme v trzích vidět potenciál – uživatelský i z pohledu možného příjmu. Také technologickou vyspělost trhu, oblíbenost sportů, velikost fanouškovské základny.

Tyto informace si stahujeme automatizovaně i ručně – používáme například nástroje jako SimilarWeb. Data kategorizujeme podle aktualizace – některá updatujeme měsíčně, jiná jednou za rok. Například počet lidí připojených k internetu není potřeba měnit často.

Na základě těchto dat odhadujeme, jaký region může být zajímavý, protože zde je popularita sportu, který umíme dobře pokrýt, a zároveň trh roste v příjmech i uživatelích.

Mám pocit, že řešíte strašně moc různých domén a máte spoustu práce. Jak tohle zvládáte?

Mně se to taky zdá hodně. Je to otázka priorit. Měli jsme tým, do kterého stále chodí požadavky, a budou chodit dál. Nikdy nesplníte všechny.

Zároveň potřebujete mít interní roadmapu, abyste viděli dál a připravovali se na podnikové plány, procesy, produkty.

Například nyní pomáháme s recommendation enginem při onboardingu, když doporučujeme oblíbené týmy.

Měl byste mít ve svých týmech určitou připravenost i dovednosti, protože přijde úkol, který musíte zvládnout, nebo to udělá někdo jiný.

Další problém při rostoucím týmu je definice procesů a odpovědností. Bez jasných rolí věci často propadnou.

Seniorita a nadšení lidí jsou zásadní – buď jsou všichni zapálení a dokumentují vše, nebo musíte věci natvrdo přikázat.

Například já se nespoléhám, že pokud něco dělám já a ještě další dvě osoby, že to stačí říct jen jim. Měl by to vidět celý tým.

Máme pravidelné statusy, meetingy, zapisujeme, dokumentujeme informace.

Čím je tým větší, tím více je třeba to organizovat. My jsme asi 10-11 lidí, což není velký tým, ale i tak, když jsou dva nebo tři, stačí vše říct osobně.

Vaše týmy fungují různě, tak je občas nutné to společně vyřešit.

Používáme také zralostní model, kterým sledujeme náš posun – od základů až k predikci, jak se věci budou vyvíjet.

Nadále je naším cílem otevřít analytiku uživatelům formou self-service.

Jsme centralizovaní, ale s dedikovanými lidmi pro jednotlivé týmy, kterým říkáme domény.

To vyžaduje posun lidí, protože když tým roste, potřeba je specializace.

Když je vás jeden, děláte všechno, dva – pořád hodně, tři – začínáte specializovat například na webovou analytiku.

V tuto chvíli je ideální, aby se lidé více specializovali a našli své místo.

Lidé v týmu jsou často generalisté, kteří umí trochu Python, SQL a další možnosti.

Proto potřebuji, aby tady byli skill leadeři, tedy lidé, kteří v určité oblasti excelují (statistika, Python, SQL, Tableau) a ostatní se nebojí s nimi poradit.

Je totiž k ničemu, když všichni umí průměrně všechno.

Neříkám, že to máme dokonale, ale za ta léta jsem zjistil, že T-shaped profil je lepší – tedy mít specializaci a zároveň širší znalosti.

Díváte se na to teď skrz nějakou kompetenční matici?

Ano, to jsem před časem začal dělat. Vytvořil jsem interní dotazník pro lidi.

Neznal jsem termín kompetenční matice, ale zjistil jsem, že to v podstatě je to, co dělám.

Lidem jsem rozdal dotazník s tématy a kategoriemi, kde se hodnotili od 0 do 5 – 0 znamená, že o daném tématu nic nevědí, 5 znamená, že jsou v něm experti a ostatní by je měli následovat.

Toto udělal celý tým asi před rokem. Druhá část dotazníku byla téměř stejná, ale lidi hodnotili, kde by se chtěli za 2-3 roky posunout.

Když výsledky obarvíte do tabulky vedle sebe, krásně vidíte oblasti, kde tým má nízké znalosti (nuly a jedničky) a kde je překážka.

Je pak otázka, zda to chcete řešit a podporovat vzdělání.

Horší situace je, když lidé nechtějí v daných oblastech růst, a pak je nakonec potřeba je vyměnit, což je poslední možnost.

Řešíte to někdy externě? Pomůže vám někdo zvenčí?

Někdy ano, protože některé věci jsou opravdu specifické a je lepší přizvat specialisty…

Něco složitého je třeba ten Tableau server. Najít někoho, kdo by se o to chtěl starat. Třeba interně se o to moc nestaráme, řešíme to vždycky s nějakou externí firmou, protože se o to u nás vlastně ani nikdo moc nechce starat, ale je to prostě klasická spíše devops záležitost. A já se nebudu držet jako devopsák v týmu. Na druhou stranu se hrát někoho interně na devopsa je zase dost náročné, protože firma ti neposkytne úplně člověka jen na devops, na nějaký Tableau server. Takže je to takové - chvilku jsem se o to staral já, ale pak mě to přestalo bavit, takže si hodně pomáháme zvenku. Někdy je lepší ty věci opravdu outsourcovat. Nebo možná je to důvod pro Looker. Ano, nakonec to tak může být. Vždycky jsem říkal, že není vždycky psáno, že budeme mít Tableau. Třeba jednou skončíme v nějaké cloudové technologii, protože to fakt bude dávat smysl. Teď mi to smysl dává, ale...

Tvoje mini-analýza ukázala, že některé technologie a nástroje jsou extrémně populární a všichni v nich chtějí pracovat, zatímco jiné, které jsou mnohem potřebnější, tak populární nejsou. Super bylo, že lidé chtěli dělat SQL. To bylo důležité. A věci kolem BigQuery a těchto nástrojů, což pro mě bylo důležité. Většina lidí byla v pohodě s Tableau a ještě se chtěli v tom posouvat.

Nemyslím si, že si pamatuji, že bych tam objevil nějaký větší problém... Trochu jsme tam vlastně měli mezeru v oblasti strojového učení, a teď tam bylo, že se v tom chtěli posunout, ale spíš jako chtěli se o tom dozvědět víc. A data engineering. To je to, co tam teď trošku... Jednoho machine learning specialistu nebo datového inženýra máme. Ten nám šikovně řeší, hodně nám pomáhá u spousty věcí. A druhá stránka je, že sehnat dneska datového inženýra, snažím se o to už téměř dva roky.

Michal Buzek o tom před mnou mluvil, říkal, že nemůže sehnat business lidi, kteří umí ty insighty, a že jsou data inženýři plní. To bych však s vámi musel napsat opak. Já zase potřebuji... Vyměníš. Vyměníš. Lepšího kandidáta, datového inženýra. Mohu potvrdit, že nejsou. A ještě kdybych chtěl datového inženýra na Google Cloud, tak podle mě je v Čechách pět lidí. Nevím, fakt jednoduše nejsou. Je to problematické. Asi jsou, ale všichni mají podle mě dobré pozice. Jsou v fullzávěrčkách dobře zaplacení a jsou rozmázlí. Firmy si je hýčkají. Takže je to o tom, že buď ty lidi interně vychovat, ale je to specifická profese, blízká spíše softwarovému vývoji, software engineeringu, a spousta lidí chce kontakt s uživatelem a... Měl jsem pár nadějných pohovorů, bohužel to nevyšlo. Věřím, že to zlomíme.

Problém je, že jak Google Cloud, tak upřímně řečeno, tyto technologie se zřejmě rozbíhají asi půl roku až dva roky, takže ty lidi teprve přijdou. Musí se na tom trhu vychovat. Vezměte v potaz, že teď byly velké propouštění. Blbé je, že většinou až na výjimky to jsou lidé, které nechceš.

Pando, možná poslední otázka z mé strany. Jak by bylo tvoje skutečné zapojení dnes? Máš něco mezi malým a středním týmem, deset lidí, jsi stále hands-on, nebo už jsi čistě manažer, nebo ještě potřebuješ pracovat na velkém backlogu aktivit a zoufale se snažit někoho nahireovat? Jak by vypadala tvoje kompetenční matice?

Ano. Je pravda, že sám o sobě občas říkám, že nejsem data-driven, ale fear-driven, řízený strachem. Strachem z toho, že kdybych ztratil nějakou dovednost, mohlo by mě to v budoucnu mrzet. Na druhou stranu je třeba si připustit, že sedět na dvou židlích naplno není možné. Když jsem měl tým tří, čtyř lidí, tak asi 40-50 % mé práce byla analytika.

V současnosti, jsem i dlouhodobě zapojený do e-commerce v obchodních věcech, strategii a podobně, často i do firemních záležitostí, protože my poskytujeme KPIs a metriky a diskutujeme s firmou, jaké metriky si mají stanovit. Hodně jsem v manažerské roli.

Tady je to spíše obchodně strategická role, zároveň cítím manažerské povinnosti v řízení týmu, odpovědnosti a tak dále. Sám pro sebe se snažím vyhradit například pátky, alespoň částečně nebo týdně, kdy se věnuji analytickým úlohám.

Co dělám, je to, že protože jsem ve firmě dlouho, spousta lidí mi píše rovnou mně s různými dotazy. Pak se snažím to řešit. Samozřejmě to má za následek, že často otravuji spoustu lidí s tím, že i když mám nějaký Data Discovery Tool, nemám ho ještě dokonale popsaný. Takže často otravuji lidi s tím, že: Hele, je to tabulka, tohle je správně, udělej mi review toho SQL. Trochu ho zneužívám.

Ale mám pocit, že chci zůstat v obraze, nechci to úplně pustit. Nějaké SQL se tedy snažím ovládat. R nebo Kotlin jsem už hodně opustil, ale snažím se držet aspoň Tableau, SQL a mít obecný přehled o datech.

Někdy zapadám. Jsem původně webový analytik, takže co se týká Google Analytics, umím je nastavit i s Google Tag Managerem, takže to mám v pohodě. Přes různé věci se tak odbavuji.

Takže bych řekl, že jsem hands-on zhruba na 10-20 %. Záleží na situaci. Když se plánuje začátek roku, myslím, že jsem méně hands-on, ale doufám, že budu zase více. Třeba nějaké týdny, kdy bych chtěl být padesát procent hands-on.

Nechci se dostat do klasického problému, kdy ti vadí, že jsi hands-on, ale když nejsi, vadí ti opak. Ano, je to o balancu někde mezi tím, ale myslím, že… Nedokážu si představit, že bych měl být výrazně víc hands-on.

Kdybych měl tým třeba o stovce lidí, už by mi to bylo jedno. Ale takhle u malého nebo středního týmu v Udofka bych úplně nechtěl odpadnout a nic nevědět, protože nikdy nevím, jak dlouho tu budu. A data mě vždy bavila, takže rád se v nich udržuji.

Přejeme ti, abys našel správnou rovnováhu mezi delegováním a vlastní prací. A ať se vám v LifeSportu daří. Myslím, že jedete pecky bomby a je to jedna z firem, která má i globální charakter z naší doliny, což je vždy super.

A ať najdeš ty správné lidi, kteří vám pomohou posunout se dál.

Díky, Tendo.

Tak jo, díky moc za pozvání. Díky, že jste si pustili Data Talk až do konce.

Jak se vám tahle epizoda líbila? Co byste na našem podcastu zlepšili? Koho byste chtěli pozvat příště? Dejte mi prosím vědět, co si myslíte.

Můžete to udělat osobně na příštím Data Mesh Meetupu, nebo hned teď na mail jirka@data-talk.cz.

Pokud se vám epizoda líbila, doporučte ji prosím dál. Klikněte na srdíčka, na hvězdičky, přihlaste se k odběru, ať nám dashboardy svítí zeleně, grafy dělají hokejku a všichni stakeholdeři schvalují extra rozpočet.

Ještě jednou děkuji. Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu: Big Hubu, Deep Note, Atakamně a Manitě.

Pokud máte návrhy, tipy na hosty nebo témata, pořádáte vlastní event, nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět.

Díky. Nechť vás provází data.