Podcast

Dobrý den, moje jméno je Jirka Vychařek a vítám vás u dalšího dílu DataTalku. Dneska je tady se mnou Vojta Kopal, Director of Engineering v MUSE, zodpovědný za Data Science. Ahoj, Vojto.
Ahoj, Jirko.

Pro kohokoliv startupového je MUSE obrovský brand. Patříte mezi ty nejpopulárnější a nejsledovanější české startupy, i díky vaší velikosti a valuaci. V tom datovém světě ale si nejsem tak jistý, jestli lidi vědí, co MUSE dělají. Mohl bys začít tím, co je MUSE?

Tak MUSE mění tím, jakým způsobem funguje hospitality. My se snažíme zpříjemnit zážitky hostům. Chceme, aby když cestujete někam, nemuseli jste se zdržovat ve frontě na check-in. Základní teze je, že trávit čas ve frontě na recepci prostě není součástí žádného zážitku z cestování.

My stavíme cloudová řešení pro hotely. Umožňujeme řídit provoz hotelu. Je to klíčový systém, na kterém stojí veškeré informace o zákaznících, hostech a pokojích. K tomu potom stavíme další řešení přímo pro hosty, řešení pro integrační partnery a celý svět fintechu a platební automatizace pro hotely.

A kolik vás už je?
Teď nás je…

Jste ještě startup?
Já si už nemyslím, že bychom byli startup. Už spíš preferujeme pojmenování scale-up nebo growth stage company. Momentálně máme 650 lidí, většina je v Praze, zbytek po Evropě. Obsluhujeme 3 000 zákazníků. To jsou hotely, hostely, ale kdykoliv někdo prodává prostor v čase nebo služby v čase v nějakém prostoru, naše řešení je i pro něj.

Co tím myslíš? Máš nějaký tip na zákazníka, kterého bys na první pohled do hospitality nezařadil?

Přesně tak. Začali jsme hledat další zdroje příjmů pro hotely, jedním z nich je využití jejich prostor. Může jít například o coworkingová centra, parkovací místa nebo pronájem prostor pro různé události v čase. Ať už jde o dlouhodobé, krátkodobé nebo hodinové pronájmy, to všechno se začalo rozvíjet během covidu, kdy lidé necestovali, ale hotely měly prázdné prostory, které potřebovaly využít.

No a ty se tedy staráš o Data Science. Jak velký tým teď máte v MUSE, nebo jaký je status quo?

Aktuálně mám dva týmy – Data Engineering a Data Projects. Celkem je nás jedenáct. Sídlujeme v rámci platformy v Engineeringu, ale máme také Data Analytics a Data Scientists přímo v produktových týmech. To všechno je pořád součástí Engineeringu nebo Techu. Vedle toho máme i BizOps tým a další datové role, například datové analytiky v marketingu, sales a customer success.

Jak ses sám dostal do MUSE?

Přišel jsem ze světa digitálních agentur, vývoje webových aplikací, Flashu, Flexu, mobilních aplikací, hlavně hybridních cordova řešení a podobně. Pak jsem hledal, jak se vrátit zpátky k tomu, co jsem studoval. Vystudoval jsem teoretickou informatiku…

Opravený text:

U nás, v návaznosti na machine learning, měl MUSE potenciál začít pracovat s daty a využívat je i pro tvorbu produktů a vývoj pokročilejších metod datové vědy. Já jsem tedy nastoupil první rok do společnosti.

Hledal jsem oblast frontend developmentu, kde bych mohl nabídnout nejvíce zkušeností a pomoci s vedením týmu. Už po prvním roce jsme však viděli prostor pro vybudování datového týmu. Právě o tom bych se s tebou dnes chtěl bavit, protože mi přijde, že jste prošli velmi zajímavou evolucí. To, jak máte teď tým organizovaný, je opravdu inspirativní a může sloužit jako vzor i pro jiné společnosti. Na druhou stranu není mnoho firem jako News, které by to mohly jednoduše převzít, protože, jak jsme se bavili, škála firmy je hlavním faktorem určujícím organizaci týmu.

Rád bych s tebou prošel evoluci týmu – jak to všechno začínalo, jak se budovala datová věda ve startupu a ScaleUpu, který rychle roste, jak se přidávají nové role a jak se to integruje v rámci firmy.

Dobře, začněme tedy na začátku. Přišel jsem do firmy News v okamžiku, kdy tam působilo přibližně 55 lidí, na konci roku 2017. V té době byla datová část – reporting a BI – primárně řízená z financí, konkrétně Pavlou, naší CFO. Ta nastavila v Power BI kompletní automatizaci finančního reportingu, snažila se omezit používání Excelu a zajistit, aby všechna data byla dostupná všem ve firmě prostřednictvím jednodušších datových pipeline a Power BI.

To je skvělé, velký dík patří vaší CFO, že si postavila první datovou pipeline a Power BI s možnou pomocí vašeho engineeringu. Začínat na financích je navíc standard, protože zde je reporting nejdůležitější.

Když jsem tedy přišel, fungovalo Power BI a první produktová pipeline. Byl jsem asi jediným datovým specialistou ve firmě. Začali jsme narazit na první problémy – rostli jsme, máme každý den více zákazníků, větší objem dat a s novými zákazníky přichází více rezervací. Začali jsme mít problémy s řešením v Power BI – data už se tam nevešla. Co s tím dál?

V té době jsem začal budovat tým, nejdříve sám, postupně jsem najímal další lidi – prvního data scientista, data analytiky, data inženýry. Začali jsme řešit, jak se koukat na data s agregacemi, abychom ušetřili místo, provádět první optimalizace a zavádět lepší nástroje pro zpracování dat. Používali jsme například Azure Data Factory.

Dostali jsme se do fáze, kdy datový tým fungoval jako služba pro zbytek firmy. Z různých stran nám chodily požadavky – co vylepšit, co zapracovat do reportů. My pak seděli a rozhodovali, jak to prioritizovat – co je důležitější? Požadavky od B2C produktového týmu, B2B týmu, byznysu nebo financí…

Zde je opravený text:

Způsob, jak rozhodovat, co má prioritu, byl pro nás v té době výzvou. Hledali jsme nové řešení, jak uspořádat datovou organizaci. Jedním z modelů, který by toto vyřešil a ke kterému jsme přistoupili, byl hybridní setup – přesun některých datových analytiků přímo do produktových týmů. Hybridní ve smyslu, že část zůstává centralizovaná a část decentralizovaná.

Standardně se totiž předpokládá, že máš buď centrální datový tým, nebo decentralizovanou strukturu – dva protichůdné principy, ze kterých si musíš vybrat. My jsme zvolili kombinaci obojího. Jeden centrální tým zůstal jako centrum excelence, data engineering tým, který podporoval datové analytiky přesunuté do produktových týmů, aby mohli přímo pomáhat týmům a zmenšili tak doménu, ve které se musí orientovat.

To zní, jako byste měli napříč B2B, B2C, business, finance… tedy čelit velkému context switchingu. Ten samý datový požadavek z jiného oddělení má jiný kontext a jinou aplikaci, takže na něj musíš přistupovat jinak. To muselo být velmi náročné.

Ano, pro jednoho analytika bylo těžké přecházet mezi světem B2C orientovaném na hosty a světem payments a fintech, kde se řeší transakce, finance. Obzvlášť když se během týdne střídaly úkoly z těchto oblastí, bylo to náročné a pochopení jednotlivých oblastí klíčové pro správné řešení problémů.

Přesunem datových analytiků do produktových týmů mohli lépe zaměřit svoje znalosti, pokračovat ve vzdělávání v dané oblasti, více spolupracovat s produktovým týmem a přejít od reaktivního k proaktivnímu přístupu. Stali se plnohodnotnou součástí cross-funkčních týmů, účastnili se stand-upů, plánování a od začátku pomáhali řešit budoucí datové problémy.

Nešlo už o situaci, kdy produktový tým vyvine novou funkci a až potom si vzpomene, že by chtěl sledovat její dopad, potřebuje historická data, aby viděl, jestli mu funkce pomohla nebo ne. Datový analytik byl už od začátku součástí týmu a mohl říct, máme data, abychom mohli porovnat výsledky v momentě nasazení.

Právě v tom vidíme největší přínos datových analytiků v produktových týmech – týmy se naučily přemýšlet o datech dopředu a přiblížily se k vlastnictví řešení. Už od počátku se starají o to, aby měli k dispozici všechna data potřebná k testování hypotéz.

Můžeš dát nějaký konkrétní příklad produktového týmu nebo…

Pokud chceš, mohu text ještě více upravit nebo zjednodušit.

Jasně, tady je opravený text s lepší srozumitelností a gramatikou:

Nějaká část produktů před tím, než tam embedoval svého člověka, vs. potom? Co jsou ty triky? Jestli nás teď poslouchá někdo, kdo není datový analytik, ale spíš na produktové nebo vývojové straně, tak jaké jsou základní zásady, typy, triky, které vlastně přinesli tvoji lidi do týmů?

Tak já jsem popsal ten případ, kdy produktový tým přijde pozdě. To většinou byl scénář, kdy si data tým ze service vzpomene, že je potřeba vyřešit a spočítat dopad nějakého nového rozšíření produktu – v momentě, kdy to nasadili. Protože je to vlastně něco, co řeší v momentě, kdy to potřebuji.

Ten dopad myslíš usage, nebo jestli to zefektivní optimalizaci pokojů, nebo něco takového?

Můžeš si to představit tak, že třeba u Booking Engine, což je nástroj na vyřizování rezervací, na začátku sleduješ počet uživatelů, kteří začnou používat aplikaci, a kolik jich dokončí rezervaci, tedy nějaký success rate a průchod aplikací. Je potřeba měřit, vidět úspěšnost. Nasazuješ tam nové obrazovky, třeba měníš tlačítka, přidáváš možnost upsellu – a nějakým způsobem to ovlivňuje celkovou metriku. A pokud nemáš baseline předchozího stavu, tak nemáš vůči čemu to poměřovat.

Přesně tak. Od toho okamžiku, kdy jsme měli jeden datový tým ze service, k embedded datovým rolím přímo v produktových týmech, co to umožnilo?

Většinou ti analytici umožnili spolupráci na testování různých hypotéz. Například jsme testovali efektivitu – pojďme posílat SMSky místo e-mailů hostům v momentě, kdy mají udělat online check-in, tedy vyplnit údaje před tím, než dorazí do hotelu. Běžně posíláme e-maily, začali jsme testovat zprávy přes SMS, potřebovali jsme to porovnat. Protože tam od začátku byl analytik, mohl přinést i základní principy A/B testování a poradit, jak využít aktuální nastavení aplikace či systému k rozumnému A/B testování.

Využívali jsme náhodné části v identifikátorech uživatelů, abychom mohli rozdělit skupinu na ty, kterým posíláme SMSky, a ty, kterým posíláme jen e-maily. Podobně jsme optimalizovali správný čas, kdy posílat tyto zprávy – kdy je nejlepší odeslat e-mail o online check-inu, aby byla velká šance, že uživatel to vyplní, bude připravený na další den, přijde do hotelu a prakticky jen projde recepcí, aniž by se trápil s komunikací.

Když jsme se připravovali na tenhle rozhovor, tak jsem si hořkosladce vzpomínal na toto období a smál ses, že to bylo super pro data v Mews, ale pro tvůj – nemyslím si, že Mews je korporace, ale pro tvůj korporátní postup – kdybys byl v nějaké jiné organizaci, která na to víc hraje, tak by to bylo velmi bolestivé.

Lidi, kteří byli pod tebou ve struktuře, si najednou museli dát do jiných týmů a vlastně jsi ztratil tu korporátní důležitost – tedy kolik lidí „paseš“. Jak to vlastně bylo s tím organizačním uspořádáním v tu chvíli? Máš nějaký tým, který je centralizovaný…?

Pokud chceš, můžu ještě pomoci s doladěním nebo pokračováním textu.

Tady je opravený text (opravil jsem gramatiku, stylistiku a interpunkci, aby text byl srozumitelnější a plynulejší):

Vaný je tvůj, a najednou chceš vytvořit teda embedded. Byli to noví hires, kteří byli hajrovaní do těch produktových týmů, anebo jsi musel své dobré lidi vlastně vyslat do světa?

Ten druhý případ. Já jsem to vlastně řešil v týmu, ptal jsem se, jakým způsobem kdo chce kam, k čemu mají nejblíž – jestli chtějí zůstat v rámci datového týmu, nebo se přesunout do produktových týmů. A byl to pro mě moment, kdy jsem se musel rozloučit s lidmi, se kterými jsem stavěl ten tým třeba dva roky, tedy z přímé spolupráce i z pohledu starání se o jejich osobní rozvoj v rámci firmy i jejich profesionální kariéry.

Takže tohle bylo pro mě velký moment. Ano, opustili hnízdo a pokračovali dál, a pak jsem je už jenom trochu z povzdálí sledoval, jak si vedou dál. Někdy přijedou vyprat si hlavu. Ano, občas mám skip one-on-ones i s nimi na nějaké měsíční bázi. Takže se potkáme, jak to jde, jestli si můžeme nějak vzájemně pomoct. Ale už je to vlastně zodpovědnost úplně té druhé části našeho inženýringu, protože jsou součástí product inženýringu a já jsem vlastně v platformě.

Je z toho nějaká lesson learned, třeba pokud se někdo rozhoduje o své roli, jestli tam byly nějaké typy lidí, pro které bylo přirozenější být víc u produktu, a jakým typům profesionálů – analytiků nebo scientistů – bys doporučil být spíš v centralizovaném týmu, když to řeknu takhle?

Určitě hrozně záleží na zkušenostech a celkovém skill setu. Když teď někoho nabíráme, a je to spíš juniornější role, já osobně preferuju je nejprve provést datovým týmem, spolupracovat s nimi na prvních projektech a dát jim k dispozici zázemí týmu. Naučit je nějaké standardy, ať mohou být funkční a mají přechodné období, během kterého spolupracují, protože na dálku je to těžší. Určitě.

Teď konkrétně my spolupracujeme s Čekytas, kde zajišťujeme coaching a mentoring jednotlivých týmů. Čekytas obecně umožňují transformovat nebo proměnit kariéru, proměnit profesní dráhu ženám a dívkám prakticky odkudkoliv, s jakýmkoliv backgroundem.

Na jaře jsme tam pomáhali s vedením týmu a po prvním běhu jsme úspěšně nabraly jednu kandidátku, Moniku. Ta teď právě první měsíce s námi v týmu tráví tím, že se seznamuje s technickou částí – jakým způsobem věci fungují, jak vyvíjíme naše reporty. Po té úvodní fázi jsme s ní dělali takové „kolečko“ po jednotlivých produktových týmech, kde se seznamuje s doménou jednotlivých produktů, což by o něco hůř nasbírávala přímo v datovém týmu, protože my už přímo nepodporujeme jednotlivé produktové týmy.

Je to vlastně jedna z cest, jak se seznámit s tím, co ten produktový svět MUSE dělá. A potom někdy příští rok v lednu, až absolvuje tu cestu, si bude moct vybrat, jestli chce zůstat s námi v týmu, případně jestli…

Pokud chceš, mohu ti pomoci s doplněním nebo úpravami další části, která je přerušena.

Opravený text:

Produktové týmy o ní budou mít zájem, takže jestli chce pokračovat jako produktová datová analytička přímo v těch produktových týmech. A ty role máte rozdělené jak? Kde končí „píseček“ platformního datového týmu a kde začíná „píseček“ jednotlivých produktových týmů? Je to tam nějak vymezené? Nebo vlastně jste devops pro dataře na příč MUSE? Tohle se, myslím, hodně vyvíjí v čase i díky nástrojům, které používáme. Aktuálně je to tak, že role datového analytika v produktovém týmu trochu hraničí s analytic engineering rolí. Oni jsou totiž zodpovědní i za stavbu těch agregací a datových modelů, které potřebují pro svůj produktový tým. My z platformy se to snažíme dělat tak, aby oni to mohli dělat co nejefektivněji, a to buď skrze Looker, který ve své podstatě umožňuje datovým analytikům být BI inženýry a navrhovat si datový model přímo v Lookeru, anebo adaptací DBT a jednoduchou prací s SQL modelovat další transformace nad tím, co už pro ně postavil datový engineering nebo dataplatformový tým.

Jsem rád, že zmiňuješ nástroje a dataset, který máte teď. Na začátku jsi mluvil o vaší CFO a Power BI jako o centrálním mozku nových datových řešení. Jaká byla vlastně cesta z jednoho Power BI do nynějších řešení jako Databricks, Looker a celého týmu, který spolupracuje a přes DBT to propojuje?

Asi bych začal tím, v jakém kontextu my fungujeme, což je obecně tech stack, na kterém MUSE operuje. Naše technologie jsou hodně postavené na Microsoftu, z čehož vyplývá využívání Azure pro veškeré cloudové služby. Běží na tom celý náš systém, produkty i aktuálně interní IT infrastruktura. Do toho zapadá Power BI jako nástroj, který je součástí vyšších licencí Microsoft 365. Přesto ale máte Looker?

Ano. Proč používat něco, za co musíme platit, když Power BI máme prakticky zadarmo? No, skoro. My rosteme – jak v počtu zákazníků, tak i v objemu dat, která musíme zpracovávat. A už se nám všechno nevešlo, takže jsme museli hledat nová řešení. A také jsme přemýšleli o tom, jak chceme stavět datová řešení. Když jsme vybírali Databricks, nebylo to proto, že je to „cool“, ale dělali jsme proof of concepty a porovnali jsme tehdy Snowflake, Databricks a také Azure Synapse.

A o jakém roce mluvíme?

Začátek roku 2020. Tehdy se Snowflake teprve začal přibližovat k světu dalších programovacích jazyků, jako je Python, a umožňovat vyvíjet věci nejen pomocí SQL. Můj mindset i mindset týmu byl takový, že jsme neměli tak blízko ke klasickému data warehousingu, ze kterého Snowflake pochází, ale spíš k nasazování věcí s CICD, testování a kolaboraci nad kódem pomocí pull requestů. A to bylo nejblíže právě Databricks a potenciálně i PySpark.

Tady je opravená a upravená verze tvého textu:

RK projekty, kde jsme si mohli všechno uložit pěkně do GitHubu, vidět ten kód, co dělá, a nasazovat si to tak, jak jsme zvyklí. Mně to přijde sympatické, protože s každým dalším hostem, tématem a nějakým insightem, který dostávám, mám pocit, že svět software engineeringu nebo naopak svět data science a datové analýzy se teď masivně inspiruje a přebírá koncepty, pravidla a principy software engineeringu. Proto mi přijde sympatické, že jsi profesně přišel právě z téhle strany, protože mi to dává velký smysl.

A připadá mi vtipné, že můžeme vzít buzzword, který byl před pěti lety populární v engineeringu, a teď je to buzzword, který funguje i v datech, například CICD. Mám pocit, že v engineeringu je to už do značné míry vyřešené – tím samozřejmě nechci říct, že všichni mají automatické deploy, testy a všechno krásně, to není ideální, ale alespoň na teoretické úrovni už to není téma. Všichni k tomu nějakým způsobem směřují a berou to jako ideální standard. Když to myslíš vážně, tak potřebuješ mít prakticky CICD v engineeringu a teď i v data oblasti.

Nástroje se k tomu vlastně posouvají z obou stran. I když jsme si vybrali Databricks, postupem času se samozřejmě vyvíjel i Snowflake a i Databricks samotný. Mám pocit, že se ty nástroje začínají přibližovat z různých, i opačných stran, takže nakonec bude se časem asi jedno, který nástroj budete používat – prostě ten, který vám bude bližší.

Databricks se čím dál víc blíží konceptu datového skladu prostřednictvím lakehouse architektury a díky Delta Tables. Dokonce koupili firmu Ridesh, kterou implementovali jako Delta Lake Cycle, takže najednou máme data, která sedí někde v datalakeu a dříve byla rozházená po CSV, JSON souborech, nyní jsou většinou uložena v Delta formátu, což nám umožňuje přistupovat k datům přímo přes SQL endpointy v Databricksech, aniž bychom je museli někam kopírovat dál.

Do této oblasti směřuje i Microsoft Azure se svými nástroji, jako je Synapse, a nově Azure SQL nabízí tier Hyperscale, který funguje na podobném principu, kdy škálování dat probíhá přes využívání Blob Storage a datalake. Snowflake má obdobný koncept oddělení výpočetních jednotek od datového úložiště. Mám například prototypy, kde máme jedno datové úložiště a nad ním běží jak Databricks, tak i Synapse, které přistupují ke stejným datům v tom samém datovém formátu. Celý systém tak funguje jen proto, že některé další nástroje zatím nejsou napojené na Databricks.

V Lucru je to trochu jinak. Je to právě tato obrovská přidaná hodnota Lucru? Měl jsem vždycky pocit, že ta demokrati…

(Tady věta končí nedokončená, pokud chceš, mohu ti pomoci i s jejím dokončením.)

Pokud chceš, můžu text ještě více zestručnit nebo upravit styl tak, aby byl formálnější či naopak uvolněnější. Dej vědět!

Jistě, tady je opravený text:

Jejich kombinaci do datového modelu a definici těch metrik, které zase v Lookeru máme jako výhodu, že ty metriky musíme definovat jenom jednou. V Power BI bylo potřeba při každém reportu znovu přijít na to, jak se vlastně ty věci počítají. Existovaly nějaké varianty, trochu víc na enterprise úrovni, kde bychom si mohli stavět nějaký Analysis Server a Analysis Services server a modelovat si tam jeden centrální datový model, ale to už jsme zase zpátky u klasického data warehousing přístupu a nasazování změn pomocí nějakých windowsovských nástrojů nebo Visual Studia přímo do běžící instance.

Takže rozhodně Looker a Databricks nám pomohly, abychom mohli mezi sebou spolupracovat a umožnili komukoliv v Muse přijít s projektem, s rozšířením, které chtějí nasadit. My potom jen ověříme, že je vše v pořádku, testy proběhly, kód odpovídá našim guidelines, a my ho jen e-approveujeme a potvrdíme. Automaticky se to nasadí, a při dalším běhu, pokud jde o datové pipelines, už všechno běží, jak má. V případě Lookeru se to nasadí a můžeme přímo začít vyvíjet další dashboardy.

Právě toto dělají ty embedded datové role primárně. Nebo tam máte i velké množství citizen data scientists, nebo pojem business power users? Jsou to primárně produktoví datoví analytici, máme i v rámci business operations, a nyní trénujeme i nové lidi, kteří nastoupili například do marketingu nebo do sales, aby mohli využívat Looker přímo i k vlastní analýze a modelování. My jako datový tým potom už nezodpovídáme třeba za kvalitu toho kódu.

Obecně v rámci Muse tam není nějaká centrální autorita, ale máme princip second level reviewers, kteří jsou zodpovědní za finální verifikaci a potvrzení, že je to architektonicky v pořádku, a jejich approval je dostatečný k nasazení změn. Můžeš mi to, prosím, říct konkrétněji? Jsi ty osobně second level approver, nebo je to tým lidí?

Já jsem a je to primárně podle seniority jednotlivých analytiků nebo vývojářů. Po nějaké době, kdy víme, že jsou schopni dělat kvalitní code reviews a zajistit kvalitu kódu v codebase, absolvují – není to povýšení, ale přesun do levelu 2. V ten moment mají plnou zodpovědnost za to, co se nasadí, a když oni approve-nou, je to už součástí codebase. A toto je už rozdistribuováno i mezi stávající datové analytiky – například Markéta Lawrence nebo Ota, kteří jsou už senior data analysts, jsou také second level reviewers. Už to tedy není jen na mně jako úzkém hrdle, které musí všechno approve-nout.

No a jak jsme se bavili o vašem tech stacku nebo data stacku, zmínil jsi i dbt. Kdy jste ho začali používat a proč? Je to nějak významná součást?

Začali jsme, řekl bych, v březnu, někdy na začátku téhle role. Přišel s tím Guillermo, nový team lead pro data engineering, data p…

Pokud budete chtít, mohu dále pomoci s doplněním nebo úpravou textu.

Zde je opravený a stylisticky upravený text:

Platformu. Pro nás to byl nový nástroj, takže jsem byl zpočátku skeptický. Není to totiž tak silný nástroj jako projekty v PySparku, kde PySpark umožňuje pracovat s datovými typy a poskytuje lepší přehled o tom, s čím vlastně pracujeme. Ale postupem času jsem viděl, jak i dbt umožňuje analytikům a analytickým inženýrům provádět transformace a měnit data podle svých potřeb, což je pro ně mnohem jednodušší.

Moment, kdy jsme potřebovali začít používat dbt, nastal tehdy, kdy od analytiků začaly přicházet konkrétní požadavky na data engineering tým: „Tady je moje query, ověřil jsem si, že to funguje, potřebuji takovýto výstup. Prosím, naimplementujte to.“ Nejprve jsme tyto požadavky řešili v rámci PySpark projektů, což ale nedávalo smysl, protože to byla prakticky kopie z SQL, a bylo náročné pro analytiky tyto změny ověřovat či upravovat.

Používáním dbt se ale změnil i proces code review. Nejprve to dělali výhradně členové data engineering týmu, ale postupně jsme zapojili i datové analytiky. Ti přesně vidí definovaný SQL kód, mohou si ověřit, že je vše v pořádku, případně přidávat nové změny. Nyní už analytici sami mohou přidávat vlastní transformace, nechat je schválit a nasadit datové pipeline do Databricks skrze dbt. Tým data engineeringu do toho zasahuje už jen jako druhá úroveň kontroly, finálně kód schvaluje a nasazuje do produkce.

Původní data engineering tým jsme přejmenovali na data platformový tým. Namísto psaní datových pipeline a ETL procesů je jejich rolí poskytovat ostatním možnost tyto procesy vytvářet, zajistit přehled o chodu pipeline, jejich monitoring a alerting a starat se o developer experience a data engineering experience pro ostatní, aby mohli stavět vlastní produkty na platformě, kterou spravují.

Co se týká toho, co děláme v rámci MUSE a budování data platform týmu, změnilo se to tak, že část práce, kterou dříve dělal datový engineering team, nyní zvládají samotní analytici. My se proto můžeme více věnovat rozvoji platformy.

Máme dva týmy: data projects a data platform. Data platform tým má na starost platformu a infrastrukturu a jeho cílem je umožňovat ostatním vyvíjet datové produkty. Momentálně testujeme Unity katalog v rámci Databricks, který nám umožní lepší kontrolu přístupu k datům a lepší přehled o tom, co se s daty děje. To souvisí i s dalšími projekty, jako je Data Lineage, …

Pokud chcete, mohu připravit korekturu i pro zbytek textu.

Opravený text:

Případně Data Observability.

To měl poskytnout dost dobrý přehled, ale paralelně s tím testujeme i nástroj jako Monte Carlo, abychom zajistili i nějakou data health napříč datovými pipeline. A všechno to směřuje k tomu, aby to nebyly nástroje, které budou používat pouze týmy data platformy, ale aby to byly nástroje, které umožní všem ostatním stavět datová řešení. Konkrétně nyní v rámci Azure provádíme nějaké migrace, přesouvali jsme Databricks workspaces a od jednoho workspace se posouváme k používání více workspaces. To by nám mělo umožnit lepší spolupráci a otevřít naši platformu například i finančnímu oddělení nebo people týmu, aby mohli použít stejnou platformu se svými podstatně citlivějšími daty, a aby mohli důvěřovat našemu řešení, aniž bychom měli přístup k jejich datům, ale přitom byla možná spolupráce na projektech, které ovlivní celou firmu.

Takže teď řešíš nějakou autorizaci v rámci systému, je to tak? Zabezpečení dat, access control, přístup k jednotlivým datasetům a lepší pravidla – jakým způsobem přidělujeme přístup k datasetům na základě příslušnosti k týmům či oddělením, nebo podle úrovně manažer versus individual contributor. K čemu mohou mít přístup a s čím mohou pracovat v základním nastavení, k čemu si musí požádat o speciální přístup, který jim bude automaticky přiznán, a kde je potřeba schválení jejich manažera, aby mohli s daty pracovat. Začíná to být velké téma, zejména kvůli různým auditům, práci na SOC2 a směřování k pokročilejším projektům ve fintechu. Všechno tohle mě teď zaměstnává hlavně proto, abychom s daty pracovali tak, jak ostatní očekávají.

Jak bys to zhodnotil? Zní to, že od doby, kdy bylo těžké prioritizovat, jste se zase dostali do fáze, kdy je toho extrémně hodně. Jak prioritizuješ, nebo jak vůbec tvoříš plán? Jedná se o pravidelné meetingy s vedením, určování OKR, nebo jak to vlastně strukturojete?

Já se v tomhle hodně spoléhám na celkový framework, jak funguje R&D u nás. Organizujeme se v rámci čtyřměsíčních cyklů, kterým říkáme tertily – třikrát do roka plánujeme následující čtyři měsíce, a commitneme se k tomu, co dodáme. Před začátkem těchto čtyř měsíců probíhá sběr insightů od všech ve firmě – nápadů, příležitostí, na čem můžeme pracovat. Z toho stavíme jednotlivé iniciativy, hodnotíme jejich potenciální přínos (value) a pak během posledního měsíce před začátkem dalšího tertilu s stakeholdery sjednáváme priority, tedy pořadí, ve kterém budeme tyto iniciativy řešit…

Text jsem opravil, aby byl gramaticky správný a stylisticky plynulejší:

h iniciativách jsme. Oni k nám k tomuhle nějaký feedback dali a v rámci konce tertylu máme all hands planning, kde se společně – jak produktový tým, tak i platforma v rámci R&D, všechny týmy – potkaly.

Odprezentovali jsme hlavní myšlenky a zásadní iniciativy, které považujeme za důležité a na kterých bychom chtěli pracovat. Během celodenní akce jsme také spolupracovali na upřesnění závislostí mezi jednotlivými týmy. Případně jsme se dozvěděli o last minute iniciativách jiných týmů, které potřebují naši pomoc nebo mají vyšší prioritu, takže jsme museli přeplánovat, čemu se přesně budeme věnovat.

Když říkáš iniciativy, co je taková typická iniciativa? Typická iniciativa by například byla nutnost přesunout velké množství prostředků v Azure z jedné subscription do druhé, protože licenci, kterou jsme původně používali – pay as you go – od Microsoftu už nemůžeme dál využívat a musíme přejít buď na Enterprise Agreement, nebo na CSP. Jedná se o FinOps záležitost.

Tato iniciativa vyžadovala projít všechny naše resources, zjistit jejich závislosti. Trvá to relativně dlouho, protože ne všechno lze jen překliknout v Azure a přesunout. Některé služby jsme museli znovu postavit, nakonfigurovat a otestovat. To je příklad takovéto iniciativy.

Trochu smysluplnější iniciativa by byla například měření user disengagementu. User disengagement je pojem, se kterým přišli naši produktoví designéři. Produktový design je skupina, která u nás vlastně otáčí běžný přístup, kdy aplikace, hlavně v B2C světě, se snaží uživatele udržet co nejdéle v aplikaci – to je engagement. Sleduje se například doba strávená na obrazovce (screen time). Cílem je maximalizovat čas, který uživatel aplikaci věnuje.

My chceme dělat pravý opak. Chceme, aby naši uživatelé v B2B světě trávili s naším řešením co nejméně času, ideálně vůbec žádný. Vše by mělo být automatické, aby uživatel nemusel nic řešit ani klikat. Potřebuješ, aby se provedl check-in? Prostě se to stane samo.

Takže představou je, že toto budeme schopni dobře měřit. Je to projekt – iniciativa, na které budeme spolupracovat jako data projects tým. Potřebujeme k tomu spolupráci s data platformovým týmem i s product designem a leadershipem, aby se nastavilo, jakým způsobem se tyto údaje zaznamenávají v jednotlivých produktech, jak to produktové týmy budou spravovat a nastavovat, aby nakonec vznikl report, přehled nebo insights, které budou produktoví designéři využívat k vyhodnocení dopadů změn UX nebo UI na user disengagement.

Moc se mi líbí koncept user disengagement. Vznikl interně, nebo je založený na nějakém chytrém frameworku ze startupového či scale-upového prostředí?

Pokud chceš, mohu ti pomoci i s formulací odpovědi na tu poslední otázku.

Akticky to máme v sobě od začátku. Tenhle mindset, způsob, jakým přistupujeme k tomu, jak vyvíjíme naše řešení. My se snažíme ušetřit čas hotelům. Takže to tam vždycky bylo. Tenhle výraz přišel od našeho VP of Design, Juana, který teď tlačí tento trend skrze Product Design do R&D. Skvělé. Každopádně jsme teď hodně probírali, jak stavíte týmy a organizaci napříč, a tím pádem jsme se hodně bavili o infrastruktuře a také o data engineeringu. Tvoje role je ale Director of Engineering pro Data Science a tohle jsme se vlastně ještě úplně nedotkli. Takže co za Data Science bychom mohli najít v News a jak je na tom Data Science v News?

Jaké tam máte projekty?

Historicky jsme pracovali na projektech, které primárně sloužily tomu, aby náš systém fungoval, jak má. Implementovali jsme například detekování a rozpoznávání anomálií při komunikaci s integračními partnery. Pro různé typy našich integračních partnerů je jejich způsob používání našeho API různý, chyby jsou občas na denním pořádku a někdy jedna chyba může být fatálním problémem. To byl jeden z projektů, který jsme realizovali už před dvěma, třemi lety.

Abychom se mohli dostat k data science, je potřeba nejdříve vybudovat infrastrukturu. To bylo hlavní zaměření posledních rok či dva, konkrétně implementace Databricks. Už teď ale vidíme první výsledky, že máme data scientist role přímo zapojené v produktových týmech. Konkrétně v našem fintech světě, v oblasti Payments, máme Ariannu, která začala implementovat opět detekci anomálií v tom, jak zpracováváme finanční transakce od našich hostů. Kontrolujeme, jestli je vše v pořádku, jestli náhodou něco netrvá příliš dlouho – od zadání platby až po vyrovnání a moment, kdy je transakce zaúčtována.

Je tu i velký projekt na optimalizaci nákladů na jednu platební transakci. Svět platebních metod, platebních bran a transakcí je dost různorodý po celém světě. Různé regulace v Evropě a Americe, platební společnosti, chargebacky, interchange fees, skimming – to vše ovlivňuje náklady na realizaci jedné platební transakce a není to vždy předvídatelné. Máme před sebou hosta a nevíme přesně, kolik nás zaplacení transakce tímto hostem bude stát. Záleží také na typu karty, odkud je karta vystavená, z jaké země a banky, jestli proběhne druhá úroveň autentifikace.

Všechny tyto faktory ovlivňují finální náklady, a my se zlepšujeme v naší schopnosti predikovat, kolik nás transakce bude stát, abychom mohli lépe plánovat finanční rozpočet a další růst firmy.

Vy také stavíte infrastrukturu pro data science? Nebo používáte jednu a tu samou infrastrukturu?

To je výhoda Databricks. Je to jedna a ta samá infrastruktura pro nás, kde Databricks funguje jako SQL prostor, kde používáme SQL, stavíme dashboardy a dotazujeme data uložená v lakehouse, takže i…

Opravený text:

Ten data science prostor, kde máš k dispozici notebooky, kde můžeš sestavit vlastní modely, trénovat je a vyvíjet vlastně jakákoliv data science řešení. Super. No a takhle technologicky to máte na jednom místě. Tak jak jste hybridní? Máš víc týmů, máš data projekty a máš data platformu, máš tam datové analytiky, datové inženýry, data scientists, do toho ti tam skáčou nějaký pokročilí business uživatelé a nabíráš holky z Čikitas.

Tak jak to vlastně funguje? Je tam nějaká funkce toho, jak fungujete dohromady? Nějaký knowledge sharing nebo něco takového? Protože teď mi to zní, že je to hodně rozstřelené. Ten váš produkt a ty věci, co řešíte – tak že váš data platform tým je nějaké lepidlo, nějaká infrastruktura, ale to ještě pořád neznamená, že se data scientistka z fintechového týmu vůbec zná a ví o tom, co dělá analytička v data platform týmu.

To je velmi dobrá otázka. My už jsme organizace o 650 lidech, což je pro mě hodně, pro někoho to může být asi pár tisíc. A jakým způsobem udržujeme ty podobné role pohromadě? Máme koncept Guild. A to je něco, co vzniklo u nás v rámci inženýringu. Už dřív jsme měli Counter-Strike Guild jako první, Botko Guild, Guildmaster, Frontend Guild, Backend Guild, kde se frontendní inženýři a backendní inženýři napříč produktovými týmy i platformou potkávali a dělili se o své znalosti a sdělovali si poslední aktuality o tom, co se vlastně v té firmě nebo v inženýringu děje v jejich oblasti.

Podobně máme Data Science Guild. A ta je o něco širší, protože jsem se ji snažil rozšířit za rámec R&D. Je otevřená komukoliv v rámci MUSE, kdo nějakým způsobem má blízko k datům. Takže ta guilda funguje primárně skrze meetingy, které máme každé dva týdny, kdy se potkáváme. Lidé mohou navrhnout témata, o kterých chtějí mluvit, které chtějí prezentovat. Snažím se všechny ve svém okolí v MUSE tlačit k tomu, aby se vzdělávali. Vždycky říkám, že by měli mít alespoň půl hodiny denně ráno na to, aby si něco přečetli, něco se naučili, a přemýšleli o tom, jakým způsobem to, co se naučili, využít u nás v MUSE. Poslechnout si datový podcast, například s Vojtou o tom, jak fungují datové organizace, a potom to proměnit v nějakou přednášku, talk pro nás všechny. Podělit se o to, co se naučili.

Protože to je vlastně primární úloha toho meetingu, toho setkání, kde si navzájem sdílíme naše zkušenosti, co jsme se naučili a jakým způsobem z toho může MUSE postavit nový byznys. Není to jen o sdílení znalostí, je to i nástroj, jak zlepšovat datovou organizaci. Takže kromě toho, že si takto s kolegy povídáme, je to pro mě i prostor získávat zpětnou vazbu od ostatních, návrhy, co bychom měli zlepšit. Následně se bavíme o dalším postupu, kdo si co vezme na starost, případně vytvoříme nějakou skupinku, která bude pracovat na tom, jak zlepšit třeba psaní SQL – například obecné postupy, guidelines, jak psát SQL, protože používáme spoustu různých…

Tady je opravený text:

Nástrojů bylo několik, naposledy DBT, předtím Looker, předtím jsem psal i klasické SQL přímo v databázích. Jsou to různá prostředí a je potřeba domluvit se na tom, jakým způsobem budeme pracovat, co je náš standard, jak chceme SQL psát, abychom si mohli vzájemně přidávat projekty.

Zajímavé, a kolik vás tam tak obvykle bývá?

V špatném počasí bylo maximum asi 30 lidí, co jsem tam viděl. Máme zdravé jádro analytiků, se kterými denně pracujeme, ale je to vlastně otevřené. Většinou si přijdou nováčci něco vyzkoušet. Všechno nahráváme – je to součást otevřenosti v rámci MUSE, kde jsou všechny tyto meetingy nahrávány a nahrávky jsou k dispozici na learning channelu na Slaku. Vložím sem příspěvek: tady je nahrávka z posledního guild meetingu. Ještě se ověří, kolik lidí si ji reálně zpětně pouští, na to jsem se zatím nedíval. Potenciálně je ale otevřená všem, aby se mohli dovzdělávat a poslechnout si meeting, pokud jim nevyhovuje čas, kdy se setkání koná – protože s šesti lidmi je už těžší se potkat všem na jednom místě ve stejný čas.

Mně toto sdílení zkušeností a potkávání lidí je velmi blízké, proto i vzniklo tohle setkání.

A já jsem rád, že tady ukazuješ, jak to funguje u vás. Když bychom se měli podívat na tvých pět let a shrnout to, co jsme tady řekli – padlo hodně věcí, ať už o vašem datovou stacku, nebo o tom, jak tvoříte týmy, hybridní týmy a tak. Co by podle tebe byly ty hlavní myšlenky, hlavní principy?

Já bych řekl, že velmi záleží na kontextu, ve kterém fungujete. Je potřeba si to uvědomit. Teď tady asi nemohu vašim posluchačům přímo doporučit, co mají dělat, jaký setup nebo organizaci si vybrat. My momentálně fungujeme v kontextu tří tisíc zákazníků a šest set padesáti lidí ve firmě, denně zpracováváme asi osmdesát tisíc rezervací. Současně musíme myslet na budoucnost a přemýšlet o tom, že na konci příštího roku budeme pravděpodobně mít deset tisíc zákazníků. Musíme tedy plánovat, co to pro nás znamená.

Celý průběh, jak jsme pracovali a nastavovali týmy a jaké nástroje jsme používali, vycházel hodně z toho, co bylo v té době k dispozici a s čím jsme mohli pracovat. Nástroje se vyvíjely, umožňovaly nám růst nebo i určovaly, jaký nástroj si vybereme.

Takže bys dneska například po Snowflakeu sáhl?

Je to možné. Je to možné, že bych dnes už zvolil Snowflake a řekl si, že na určitou část věcí, co děláme, je to ideální. Pravděpodobně bych ho zkombinoval s Databricks, ale nesnažil bych se používat Databricks tolik. I Power BI se za těch pět let hodně vyvinulo. Microsoft hodně zapracoval a vytvořil spoustu nástrojů, které řešily některé problémy, které jsme tehdy měli, a kvůli kterým jsme se rozhodli posunout se jinam.

Takže tady záleží na těch nástrojích…

Pokud chcete, mohu text ještě více upravit, například rozdělit na kratší odstavce nebo přidat lepší strukturu.

Jistě, tady je opravený text:

Rojích, které jsou dostupné, ovlivní, jaké nastavení týmů potřebujete. Je to také určitý trend – s lepšími chytrými nástroji už možná nebudete potřebovat tak velké týmy, které se o všechno starají, a můžete více spoléhat na to, že nástroj to za vás vyřeší. Už nebudete potřebovat tolik data inženýrů, vše bude automatizované a budete potřebovat jen data scientisty a data analytiky. Třeba někdy to tak bude, ale dneska asi ještě ne.

Neexistují univerzální rady, záleží na kontextu vaší firmy, vašeho byznysu a na stavu technologického stacku v daném čase. Přesně tak. Záleží také na tom, čeho chcete dosáhnout, jakou úlohu má tým v daném období a jak si představujete nové projekty a produkty – jak bude vypadat jejich návrh a fungování. Protože způsob, jakým navrhnete organizaci a umožníte týmům existovat a vzájemně komunikovat, ovlivňuje výsledek.

Můžeš dát příklad?
Příklad může být například z prostředí mikroservis. Pokud si představujete, že budou komunikovat například pouze přes API, nedocílíte toho pomocí týmů, které budou úzce provázané a komunikovat denně každý s každým. Takové dva týmy vyprodukují řešení, které bude fungovat v rámci jejich úzké spolupráce, protože takto spolupracují.

To ovlivní výsledek. Organizace práce lidí ovlivňuje organizaci produktu a naopak. Pokud chcete mít produkt navržený nějakým způsobem, tým musíte navrhnout odpovídajícím způsobem. Je potřeba myslet na to, že bez toho to nepůjde. Pokud chcete změnit architekturu, vychází to z Conwayova zákona – způsob, jakým nastavíte organizaci týmů, ovlivňuje, jak bude vypadat výsledná architektura projektu.

Co je Conwayův zákon?
Je to tvrzení, že nastavení organizace týmů ovlivňuje to, jak je provázán a navržen výsledný kód a architektura.

Máš ještě příklad z MNEWS, kde jste tohle řešili z hlediska jak lidí, tak produktu?
Ano. Mám tým, který byl původně Data Engineering Team, a nyní ho přeměňujeme na Data Platform Team. Rozdíl je v tom, že Data Platform Team se stará o infrastrukturu, udržuje ji, škáluje a umožňuje ostatním týmům na ní stavět, ale neřeší ad hoc požadavky na stavbu datových pipeline.

Tím, že tímto přejmenováním přicházejí o možnost stavět ad hoc řešení, ostatní týmy se musí této změně přizpůsobit. Už k nim nebudou chodit s požadavky typu „postavte nám ETL pipeline“, ale „umožněte mi pipeline postavit sám“.

Skvělé, děkuju moc.
Díky.

Pokud chceš, mohu upravit text ještě více do formálnější nebo naopak hovorové podoby.

Tady je opravená verze textu:

Děkuju, že jsi se tady za mnou dneska zastavil, a díky za skvělý průřez tím, co děláte a jak vypadají data v News.
Přišlo mi to fascinující, děkuju za otevřenost a ten deep dive.
Držím vám moc palce a věřím, že se tu brzy uvidíme znovu nad nějakým dalším tématem.

Díky moc, Jirko, a těším se brzy na slyšenou.

Díky, že jste doposlouchali Data Talk až sem. Jak se vám tahle epizoda líbila? Co byste na našem podcastu zlepšili? Koho bychom měli pozvat příště?
Dejte mi prosím vědět, co si myslíte. A to můžete buď osobně na příštím datameš meetup, nebo hned teď na e-mail jirka@data-talk.cz.

A pokud se vám tahle epizoda líbila, doporučte ji prosím dál. Klikajte na srdíčka, na hvězdičky, dávejte subscribe, aby nám svítily dashboardy zeleně, křivky dělaly hokejku a všichni stakeholders schvalovali extra budget.

Ještě jednou vám moc děkuju. 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, Atacamě a Mantě.
Pokud máte tipy na hosty či témata, dělá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.

Pokud chceš, můžu text ještě trochu zpřehlednit nebo upravit styl.