Podcast

Dobrý den všem, moje jméno je Hynek Walner a vítám vás u dalšího dílu DataTalku. Dnešní díl bude, jak jinak než speciální, a to z mnoha důvodů. Prvním důvodem je, že v moderatorské části stolu uslyšíte jenom mě. Druhým speciálním důvodem je, že to možná ani nebude klasická moderatorská část stolu, protože jsme si do studia pozvali Jacka Jana Soubustu z GoodData, abychom spolu udělali takový neformálnější tematický díl ohledně inovací v rámci product developmentu — jak inovovat, jaké jsou best practices a možná i naše chyby a zkušenosti z naší historie. Chtěli bychom si o tom popovídat a pozdílet zkušenosti. Ahoj, tady je Jacek. Po dvou letech. Jacku, po dvou letech tě vítám u nás. To je možná i poslední speciální důvod — nejsi tady poprvé. Já bych tě na úvod pro lidi, kteří neslyšeli díl 104, kde se představoval, rád přivítal. Jacek, ty máš oficiálně titul Distinguished Software Engineer v GoodData. Co to vlastně znamená?

To znamená, že když pracujete v jedné firmě hodně dlouho, tak jim dojdou klasické tituly a začnou vymýšlet nové. Distinguished, občas se tomu také říká Staff Engineer v Americe, je titul, který se už relativně zavedl. Dává se lidem, kteří jsou ve firmě velmi dlouho a už se více dívají do šířky než do hloubky. Pak ale došly i tyto role, a proto se ještě vymyslel titul Senior Distinguished, kterým já zatím nejsem. Toho máme ve firmě jen jednoho, takže pro něj to je jako vstupenka na vyšší pozici.

Já se možná ještě zeptám, co v roli software inženýra znamená koukat do šířky ve firmě?

To znamená hodně věcí. Znamená to dívat se do šířky z pohledu celé technologie nebo platformy, ne jen za jednu komponentu. Člověk není zodpovědný pouze za jednu část, ale vidí celou architekturu. To souvisí i s netechnologickým přesahem, který by takový člověk měl mít. Umí věci navrhovat, umí vymyslet architekturu a hlavně ji umí předat ostatním inženýrům tak, aby ji byli schopni správně vyrobit. Takže softwarové dovednosti jsou také velmi důležité — myslím, že těch technických schopností mají inženýři většinou dost, ale softskillsu často chybí.

S inženýry je to často tak, že jsou trochu nerdové v uvozovkách, třeba z češtiny měli ve škole čtyřku, ale raději si povídali s počítačem. To je super, ale když potom potřebují napsat design dokument, který ostatní inženýři pochopí a podle kterého správně pracují, musí být dokument opravdu dobře napsaný. Musí složité věci umět vysvětlit jednoduše, srozumitelným jazykem, a zároveň nemohou ten dokument psát půl roku. To je prostě dovednost sama o sobě.

Myslím, že k tomu se ještě dostaneme ohledně třeba kompozice týmu, seniority a jaký skillset by měli mít lidé, kteří staví inovativní produkt na straně engineeringu. Ale ještě než se pustíme do našeho hlavního tématu, ty jsi tady ve studiu před dvěma lety popisoval situaci v GoodData, že to nainnovujete, st...

Máte novou platformu a děláte docela zásadní pivot ve firmě. Mohl bys nás tím ještě jednou trochu provést, co to bylo a hlavně co se za těch dva roky stalo? Strávíme tady teďka půl hodiny. Mně přijde, že ty dva roky byly jako sto let. Když jsem tady byl před dvěma rokama, mluvil jsem o tom, že GoodData se pokusila udělat restart. GoodData dlouhodobě vyvíjela business intelligence platformu, kterou hodně lidí i na české scéně zná, a zlomila nad ní hůl. Po určité době se to začalo projevovat i businessově. Prostě to šlo dolů a vypadalo to, že trh je nasycený. Rozhodli jsme se tedy udělat restart a protože jsme úplně nevěděli, co budeme dělat, udělali jsme ho od základů. Vznikla firma ve firmě, tedy tým uvnitř firmy izolovaný od všeho ostatního, který se pokusil postavit novou platformu od nuly.

Cílem bylo vyvarovat se těch věcí, které nám bránily být se starou platformou úspěšní. To trvalo třeba tři roky, pak jsem přišel sem a mluvil jsem o tom, jak jsme to ty tři roky dělali. Teď se už dva roky snažíme vlastně těžit z toho, co jsme vyrobili, zjednodušeně řečeno. Projevuje se to interně i externě. Interně výrazně vzrostla rychlost práce developerů, jak rychle jsou schopní dodávat a vyvíjet. Tím, že se zjednodušil celý technologický stack, je všechno průhlednější a jednodušší na rozvoj. A navenek samozřejmě chcete platformu prodat, protože jde o peníze, děláte business. Abychom to mohli prodávat, musíme být vidět a schopni předat správnou zprávu potenciálním zákazníkům a lidem na trhu. Právě to se za ty dva roky dělo jak businessově, tak technicky.

Poprvé v GoodData jsme se snažili cílit i na technické publikum marketingem, což vedlo ke vzniku developer advocacy. Zároveň se redesignoval a posiloval marketingový tým, který dělal businessový marketing směrem k těm, co mají peněženky – tedy ne k architektům a datovým inženýrům. Na tom jsme intenzivně pracovali, prodeje na nové platformě rostou dost rychle, zatímco se stará platforma už skoro vůbec neprodává. Prodává se jen ta nová a za pochodu zjišťujeme, co funguje, co nefunguje, co v ní chybí, a snažíme se tomu vycházet vstříc. Zároveň těžíme z toho, že naše schopnost inovovat je mnohem větší. Když zjistíme, že jsme něco nedomysleli při stavbě nové platformy, snažíme se rychle dohnat ten dluh a docela se nám to daří.

Co se týká developer advocacy, a to se týká i mě osobně – proto koneckonců sedím i tady – mluvil jsem o tom už před dvěma roky, že se to vlastně po mně chce. Poslední dva roky jsem se tak snažil dělat. Je to velká zkušenost. Hodně jsem chodil na meetup akce v Čechách, ale pak jsem začal jezdit i do zahraničí na konference. Mluvil jsem třeba na DBT Coalesce konferenci nebo na Data Council Summitu tady v...

Stín, co bylo na jaře a tak, což je úplně nová zkušenost, dost děsivá zkušenost. Takže to taky pro mě byla velká změna v těch posledních dvou letech. Během toho si můžu říct, že jsme měli dost velké úspěchy. Na začátku, před pěti lety, bylo rozhodnutí, že potřebujeme nějakým směrem otočit GoodData, a teďka po pěti letech mluvíš o tom, že se zvýšila rychlost vývoje, že nová platforma nahradila tu starou. S tím bych byl ale opatrný. Mít dva produkty, přičemž v tom starém produktu jsou stále důležití zákazníci, je obrovská výzva. A to je třetí věc, se kterou se potýkáme – poslední dva roky jsme hodně přemýšleli o tom, jak podpořit migrace, někdy i za cenu obětování některých zákazníků. Provoz staré platformy je samozřejmě netriviálně náročný a zároveň do ní už nevyvíjíme nové funkce, čímž vytváříme tlak na zákazníky, aby migrovali. Je to prostě choulostivé téma, není to vůbec jednoduché.

Záměrně jsme v některých věcech neudělali platformy kompatibilní, protože starý způsob nebyl dobrý. Migrace tedy není úplně přímočarý proces. Vidíme zákazníky, kteří říkají, že je to v pohodě, že starý datový produkt i tak zastaral, a že raději postaví řešení na zelené louce, stejně jako jste to vlastně udělali vy. Ale někteří zákazníci chtějí migrovat, protože jejich koncoví uživatelé si zvykli na určitou zkušenost (user experience), a tady nám nezbývá nic jiného, než posilovat novou platformu i v oblastech, kde původně nebyl náš záměr to dělat. Važme si ale těch starých zákazníků, kvůli nim to někdy musíme udělat, a v některých případech jsme to už udělali.

No super, Rensko, myslím, že tímto se dostáváme k našemu hlavnímu tématu. Pojďme se vrátit pět let zpátky – ke vzniku inovace v GoodData. Odkud to přišlo? Bylo to byznysové rozhodnutí, kdy se řeklo, že něco musíme změnit, a dostali úkol produktoví manažeři? Nebo to byl spíš grassroots projekt – pár inženýrů přemýšlelo, jak si zjednodušit práci, pak zjistili, že takto by mohli zjednodušit práci nejen sobě, ale že by se z toho dala postavit nová platforma. Pak někomu došlo, jak by to mohlo pomoci byznysu, a postupně se prošlo přes fázi "fit business", kdy se ověřovalo, že má smysl do toho investovat. Jaká byla tvoje zkušenost?

Už jsem o tom trochu mluvil před dvěma lety v kontextu tří let vývoje. Takže tohle shrnu a pak řeknu, kam jsme se posunuli dál. Na začátku byl prostý problém. A to byl ten, že nám klesaly prodeje, nebyli jsme schopni najít nové zákazníky. Byznys si zanalizoval situaci a zjistil, kde jsou slabá místa. Například jedno z hlavních slabých míst bylo to, že zákazníci museli přesunovat data do našeho privátního cloudu, což jednak způsobovalo dodatečné náklady, a navíc přinášelo prodlevu, než data byla k dispozici v analytice. Navíc jsme to měli udělané jako deset let starý...

...á technologie, takže to prostě bylo trochu komplikované. A takových problémů tam bylo víc a biznis to viděl. Chtěl ty konkrétní problémy řešit a s tím za námi přišel. Ale to samozřejmě vůbec neříkalo nic o tom, jak by ta nová platforma měla vypadat. Určité aspekty byly jasné, například nechceme nutit zákazníka přesouvat svoje data, ergo musíme být schopni běžet nad jeho data warehousem. To bylo jednoduché, ale byly tam i složitější problémy, které biznis vůbec neviděl. A když jsme jim kladli otázky, tak jsme nedostávali odpovědi. Takže to bylo tak nějak půl na půl. Část zadání byla, část jsme museli vybudovat od základů a ty tři roky jsme se snažili vymyslet ten cíl a dojít k němu. Zároveň jsme se měnili i procesně a organizačně, protože po mnoha letech vývoje na té staré platformě bylo hodně věcí usazených, zakonzervovaných a tak. A když jsme najednou začali hrozně rychle utíkat dopředu s nějakými inovacemi, tak ta organizace na to nebyla připravená procesně a nebyli na to připravení ani lidi, často proto, že když děláš něco velkého, složitého, tak na to dáš ty nejlepší lidi. A těmi nejlepšími lidmi byli ti, kteří předtím mnoho let pracovali na staré platformě a měli určitou představu o status quo. A z toho vznikaly konflikty samozřejmě s těmi novými lidmi. Já jsem se v tu dobu považoval ještě za relativně nového člověka, takže jsem byl na té druhé straně. A tohle byl problém, který bylo potřeba řešit, stejně tak i organizačně – jak odstínit ty lidi od zbytku firmy, aby nebyli rozptylovaní, a jak je donutit třeba rychle iterovat a rychle dodávat nějakou hodnotu, být co nejvíc agilní, co nejrychleji, aby i top management viděl, že se něco děje, a ne aby rok čekal na něco velkého a pak vlastně dostal něco, co nechtěl.

No a jak se ti to povedlo? Já se možná ještě trošku vrátím přímo k tomu začátku. Vznikl nový tým, jehož úkolem bylo inovovat. Povedlo se vám říct: „Dobře, nedělejte nic jiného, nekoukejte na nic jiného, nebavte se moc s ostatními lidmi, ať si neskazíte tu vaši inovativní vizi?“ Myslím, že to bylo hodně o lidech – že museli překonat sami sebe – a pak to bylo hodně o manažerovi, který to řídil, což byl konkrétní člověk – já ho tady klidně pojmenuju, Jakub Franz, který je můj manažer dodnes a původem je vystudovaný psycholog, což byla docela dobrá přidaná hodnota. A ten člověk nám prostě neustále šlapal na paty a občas byl na nás docela přísný. Na mě třeba byl hodně tvrdý jednu dobu, a i když jsem to tehdy neměl rád, hodně mě to posunulo. Inženýři obecně mají schopnost vidět spoustu problémů a mají potřebu všechny je vyřešit, než něco prezentují navenek, protože se za to třeba stydí nebo něco. A to je problém, protože pak čekáš půl roku na něco velkého, na velký krok v té nové platformě, a nevíš vlastně, co se děje. Pak najednou dostaneš něco velkého a zjistíš, že to není ono.

Jako byznys je vidět třeba v týdenních, dvoutýdenních inkrementech nějaké kousky, které ti napovědí, jak bude celek vypadat, a včas zakřičet: „Stop, tohle není to, co chci, já chci něco jiného.“

Je to těžké, protože mám pocit, že konkrétně v inženýringu je spousta detailů, které jsou složité. A mám pocit, že správný inženýr chce na 100 %, do posledního epsilon všechny ty detaily vychytat. Ale to bude trvat čas. Je to tak. To souvisí s tím, co jsem říkal na začátku – že se musí překonat i ti lidé. Ti lidé musí být schopni dodat jenom kostru toho kódu, která funguje, a neřešit ty detaily hned. Třeba nerefactorovat to, nedělat to hezké, nepsát testy. Na spoustu věcí se vykašlat a jenom dodat tu hodnotu, kterou chce vidět ten zadavatel – ať už je to product owner, manažer nebo i top management.

Druhá věc je potom rozsah (scope). Seniornější inženýr je schopen pochopit, jak ten rozsah zapadá do celku; ten byznys to zatím do určité míry také vidí, ten seniorní inženýr. A když dostane nějaký konkrétní úkol, řekne si: „No jo, ale když ten uživatel bude tohle dělat, tak to pro něj vlastně nebude dobré, tak já tam přidám ještě tohle a toto, aby uživatelská zkušenost byla co nejlepší.“ A pak po týdnu přijde zadavatel a inženýr mu řekne: „Mám hotovou jen třetinu, protože jsem si myslel...“ A právě tehdy přišel Jakub Franz a řekl: „Najděte si to, tohle já nechci, chci jenom tohle, vykašlete se na to.“ Tak jsme se hádali a postupem času byly ty hádky konstruktivnější a méně emotivní. Přijde mi, že dneska už je to business as usual – že se vlastně hádáme a obecně platí, že řešení konfliktů je dovednost, kterou je potřeba se naučit.

My jsme dokonce na to měli školení, které nám Jakub zařídil, a myslím, že jsem ho absolvoval dvakrát. Všechny tyto dovednosti jsou hrozně důležité, obzvlášť pro inženýry, kteří jsou autisti a mají s tím problém.

Teď si pár minut zpátky zmínil větu „udělat to dobře ze strany inženýrů“. To mě také hodně zajímá, protože moje zkušenost – kterou možná můžu posluchačům přiblížit – je teď už skoro dva roky stará. Mám na starosti vývoj aplikací v českém Workday a za poslední rok se snažíme vyvinout nový produkt a využít naši původní platformu, kterou jsme přinesli do Workday ze Stories.

V podstatě jde o produkt People Analytics, který je zaběhlý, je v produkci, čtyři roky ho používají stovky firem a vlastně nás všechny živí. Snažíme se jej odseparovat, vytvořit platformu pod tím, říct, že People Analytics je jen aplikační byznysová logika, a zkusit udělat nový prototyp a zjistit, jestli by to bylo finančně zajímavé.

Ale abych se vrátil k tématu, jak to udělat dobře – když jsme začali dělat ten projekt, většina inženýrů šla do toho s tím, že máme menší tým, který jsme odseparovali, a že teď to můžeme udělat dobře. Teď si to můžeme vyvarovat...

Všechny ty chyby jsme chtěli teď opravdu napsat dobře, nebudeme to prasit, nebudeme tam nic hardkorovat, všechno bude generické, uděláme to pořádně, žádný technický dluh. Ale vůbec to nefungovalo. To by nám natáhlo veškerou delivery asi pětkrát, takže jsme to museli lidsky přeformátovat jinak.

Zajímalo mě, jestli tohle bylo i u vás, jestli do toho lidi šli s tím, že máme šanci napsat novou platformu, tak pojďme fixnout všechny problémy, všechno čistě, žádný technický dluh. Ale je to strašně drahé, tahle nadloha je velká. Je to tak, to je zajímavé téma. Myslím, že je to hodně o lidech, a u nás se to podařilo líp než jinde, i proto, že jsme vyměnili lidi.

Jsou totiž lidé, kteří jsou perfekcionisti od přírody, s nimiž je obtížné hýbat, a bolí to hodně – stojí to strašně moc psychických i fyzických sil. Někdy prostě nemáš na výběr. Ono to také trochu souvisí s generační obměnou ve firmě. Když firma funguje patnáct let jako GoodData, může tam být stále někdo, kdo je tam od začátku, ale není to úplně obvyklé. Většinou k generační obměně dojde, protože jak firma roste, přicházejí mladší lidi, a časem ty starší už to přestává bavit a chtějí změnu.

Nebo je k tomu dotlačíš něčím takovým, což si myslím, že se v tomto případě do určité míry stalo. Nelíbilo se jim, že se věci zanedbávají a nedělají perfektně, že se to dělá jinak, přitom jejich způsob byl nejlepší. My je nevyhodili, ale postupně sami odešli, protože převládla nová „klika“. Management začal víc poslouchat novou generaci, protože viděl lepší výstupy.

To je ultimátní argument. Nakonec jde o to, jestli zadavatel vidí pozitivní změnu ve způsobu dodání. Dívá se sice i na kvalitu, ale kvalita kódu ho tolik nezajímá, zajímá ho třeba kvalita UX. Když vidíš pozitivní změnu, lidi, kteří s tím nejsou komfortní, postupně ztratí vliv a odejdou. To pak vede k obrazné změně, kdy noví inženýři navyknou pracovat jinak. Za dalších pět či deset let budou oni zase v pozici lidí, co tehdy odešli. Je to nekonečný cyklus, nevyhnutelný kruh života softwarového inženýra. Je to tak.

Každopádně si myslím, že ten technický dluh, který nutně vznikne při prototypování, budeš muset v nějaký moment zaplatit. Jak s tím pracovat? Schovávat si to do šuplíku a pak si po čase říct: Dobře, teď musíme zpomalit a zafixovat základy, nebo se nám to za pět let rozpadne v produkci.

Jejda, to je ale bolestivé téma. Hele, po těch pěti letech tam ty problémy už jasně vidíme – jsou jak technologického, tak i architektonického rázu. Těch dluhů je tam hodně, ale nemáme moc síly ten dluh odbavovat, protože inovujeme na max, akcelerujeme, prodáváme stále víc a víc, prostě na to není prostor. Je to fakt těžký. Hasíme jenom ty největší požáry, které nám brání rychle dodávat, a na to pak čas dostaneme, protože si tu investici dokážeme obhájit.

Jediné, co k tomu můžu ještě říct, je to, že roli může hrát genialita konkrétních lidí. Například do nové Gooddaty jsme vyvinuli komponentu, kterou teď i marketingově propagujeme – říkáme jí Flexquery. Je to komponenta, která se stará o inteligentní cache v BI a spoustu dalších věcí. Zároveň je velmi modulární a otevřená směrem ven, takže třeba teď jsme uvolnili možnost, že si u sebe nastartuješ službu, která s Gooddatou umí komunikovat. Gooddata ji reprezentuje jako dataset někde v BI a ty tam můžeš přidat machine learningovou logiku nebo benchmarking a podobné věci.

To všechno je možné jen proto, že jeden konkrétní člověk – klidně ho můžeme jmenovat, Lobo Slivka, architekt, který byl na začátku projektu – tu architekturu vymyslel strašně dobře, modulárně a vizionářsky, takže tam dluh je rapidně menší. Je to hlavně kvůli otevřenosti a modularitě. U zbytku platformy se to vždycky nepodařilo, tak teď s tím prostě žijeme, a když nás to fakt hodně brzdí, zatáhneme záruční brzdu a věnujeme čas odbavení dluhu. Byznys si už vyžádá své.

Je to asi všechno stejný v podstatě. Jacku, ty jsi teď popsal lidský setup a přístup týmu, ale co organizační stránka? Byli jste například úplně oddělení jak na úrovni týmu, tak i codebase? Jak vlastně funguje rozhraní mezi týmem, který vlastní komponenty, ty „staré“ – nechci říct zastaralé, ale velké produkční části – což je takový velký moloch, a týmem, který využívá část codebase a musí běžet 20x rychleji? Velká evoluce.

Je to velmi obsáhlé téma. Na začátku jsme se rozhodli jít cestou „na zelené louce“, takže reuse byl minimální. Nějaký ale byl a nebyl úplně zanedbatelný. Postupem času jsme zjistili, že ani tenhle reuse nechceme, takže jsme ještě víc přepsali. I srdce, rodinné stříbro Gooddaty, které umožňuje psát metriky v našem vlastním jazyce a pak je překládat do SQL.

Jo a taky to skokově zrychlí. Fascinující byl celý rozhodovací proces, protože často člověk dojde k závěru: jo, ale je to šíleně blížší než gabát, museli bychom to celé napsat znova, tak to vezměme odsud, protože už je to napsané. Ale u vás spíš proběhlo to, že jste si řekli: tyjo, my to chceme fakt všechno udělat znovu. Hele, myslím si, že v tomhle konkrétním případě...

O kterém jsem teď mluvil, šlo o konkrétní problémy. Týkalo se to zastupitelnosti lidí. Rodinné stříbro GoodData napsali lidé, kteří už v GoodData nepracovali, kromě jednoho. Ten byl nezastupitelný a to byl problém. Management se proto rozhodoval, zda se pokusí danému člověku přidat další lidi a jít starou cestou, nebo zda použije nové, mladé a šikovné lidi, kteří se už osvědčili a kteří jasně nadizajnovali plán s časovým rámcem, tedy jak rychle dokážou danou věc přepsat a jakou přidanou hodnotu to přepsání přinese. Protože to opravdu přineslo i nějakou přidanou hodnotu.

Management to zvážil a na základě toho se rozhodl. Takže zelená louka, žádná větší codebase se moc nesdílela, izolace lidí trvala nějakou dobu a myslím si, že to bylo individuální. Tito lidé byli samozřejmě velmi intenzivně „zaháčkovaní“ jinde ve firmě, protože byli seniorní, takže na nich stálo hodně věcí a jejich izolace byla složitá a trvalo to měsíce. Po těch měsících to musel hlídat dobrý manažer, který neustále „šlapal na paty“ inženýrům, a na druhé straně byl štítem vůči zbytku firmy a říkal manažerům: „Ne, ne, ten už to pro tebe dělat nebude.“ Oni pak říkali: „Ale to je přece mission critical.“ A manažer odpověděl: „Dobře, uděláme si meeting s CEO a probereme, jestli je to opravdu prioritnější.“ A takhle se neustále bojovalo a nakonec se to vybojovalo.

Izolace lidí a samotný proces vývoje nové platformy... GoodData si prošla úplně všemi metodologiemi. Když jsem přišel do GoodData, bylo Scrum obrovským tématem — všichni byli agilní, měli jsme spoustu Scrum masterů a dalších rolí. Pak jsme zjistili, že to nefunguje tak dobře, takže jsme začali používat Kanban, pak něco dalšího a teď používáme metodologii nazvanou Fusion. Jsou to vlastně jenom názvy, ale klíčové je, jak dokážeš rychle iterovat, jak dokážeš identifikovat minimální další krok a prioritizovat ho, a jak lidé dokážou věci designovat, promýšlet je dopředu a zároveň vybrat ten malý kousíček, který je teď potřeba udělat. Používat metodologii X nebo Y není tak důležité. Spíš jde o trénování lidí, aby takhle přemýšleli a fungovali, a o dlouhodobé „šlapání na paty“, aby neuklouzávali zpátky.

Je pro tebe rychlost iterace ultimátní metrika, na kterou bys měl optimalizovat? Jsou vlastně dvě metriky: rychlost iterace a spokojenost zadavatele. A ty je musíš vyvažovat. Zadavatel samozřejmě má svoje business priority — doufejme. Ne vždy to tak je, ale občas ano. Ideální zadavatel je jako mýtická bytost s rohem na hlavě. Má nějakou představu, kam bys měl dojít třeba za měsíc nebo dva, ty to rozdělíš na části a začneš vyvíjet. Každý kousek mu musíš ukázat a on je buď spokojený, nebo ne...

Jo, je to prostě jednoduchý. A zároveň se dopředu zavazuješ, co dodáš třeba za týden nebo za čtrnáct dní, co můžeš očekávat. A ideální, úplně ideální stav je, když dokážeš některé subčásti ukazovat na nějakém testovacím prostředí i častěji – třeba každý den klidně, v extrému. Já to tak teď dělám. A to má velkou přidanou hodnotu, protože zákazník hrozně brzo dokáže zatáhnout za ruční brzdu a říct, že tohle nechce a že chce vlastně něco jiného. Ale ano, spokojenost je důležitá, a často se právě tam objeví i to, že inženýr vyvíjí víc, než by měl, a nakonec dostane přes prsty.

My jsme teď zmínili ideální, mýtickou bytost – zadavatele se správným byznysovým zadáním, tak pojďme se možná na tohle teďka chytit. Co znamená dobré byznysové zadání? Co vůbec znamená správná příležitost, jak inovovat? To mi přijde jako jedna z věcí, které se taky asi nejvíc změnily u dat, když to srovnám s tím, co se dělo třeba před pěti, sedmi lety. Přišli noví lidé – vždycky je to o lidech a o novém pohledu na věc. A ti noví lidi, hlavně produktoví manažeři, ale třeba i někteří manažeři a UXáci jsou hrozně důležití – přišli do firmy a začali přinášet jiný pohled, začali přinášet různé standardy, které jsou běžné jinde, hlavně na západě. Jeden z nich je třeba continuous discovery, o kterém je i knihy napsané. Ale všechny tyto metodologie ti vlastně neříkají nic jiného než to, jak máš hledat příležitosti na trhu a jak z nich máš udělat nějaké akce, které už jsi schopen exekuovat na své straně, aby sis podpořil tu příležitost na trhu. A pak veškerý ten proces dál – jak to vyvíjíš, jak to doručuješ, jak to dlouhodobě udržuješ a jak bereš zpětnou vazbu od uživatelů a zase ji adoptuješ.

A tohle jsme vůbec kdysi nikdy nedělali. Tohle všechno se nestalo. A teď to jako děláme, myslím si docela dost poctivě a jsou tam i noví lidé, kteří jsou v tom dobří, dělají to soustavně, mají na to kapacitu – všechno. A to je velká změna, si myslím. A pak ty příležitosti můžou být různé. Příležitostí může být, že opravdu sleduješ, co se děje na trhu, díváš se na své konkurenty a z toho vyvodíš, že ti třeba něco chybí nebo že bys měl něco dodělat do platformy. To je jednoduché. Potom můžeš dělat user research a prostě si pozveš lidi, kteří používají Power BI třeba, a začneš je ve výzkumu uživatelů challengovat – oni ti řeknou, co by mohlo fungovat líp nebo hůř, co by se jim hodilo. Jsou to ti praktičtí lidé, kteří někde v konkrétní firmě dělají data engineering nebo business analytiku, a řeknou ti, co opravdu reálný člověk potřebuje – ne nějakej mýtický uživatel, ale dají ti ten pohled zvenku. To je druhá věc. A třetí důležitá věc jsou zákazníci a potenciální zákazníci – prostě bavit se s nimi co nejčastěji a ptát se jich: co jim chybí, co by chtěli, jak to vnímají. A to je velmi cenný vstup. A tohle jsme v GoodData používali i předtím. Na tohleto se hodně hledělo a bylo to hodně customer-driven development, a teď si myslím, že do toh...

Přibyly ty dvě věci, které jsem jmenoval před chvilkou, do toho mixu a ten mix je teď vyváženější. Už to není jenom customer-driven, ale bere se ohled i na nějaké trendy na trhu, na naše konkurenty a také na reálné lidi, kteří opravdu používají tyto produkty pro nějakou konkrétní potřebu v konkrétní firmě, třeba v BAMSE, v pojišťovně nebo jinde. Tenhle mix ti přináší příležitosti (opportunities), a ty se pak musíš rozhodnout, které jsou pro tebe nejprioritnější, což je samozřejmě těžké.

No, jak moc tohle změní plánování na straně vývojového týmu? Vývoj to vlastně nezmění nijak výrazně. Tam jde jenom o to, jak k tobě přicházejí ty prioritizované příležitosti, a podle toho pak vyvíjíš.

Na co jsem zapomněl, tyto příležitosti nemusí vznikat jenom z byznysové strany, od zákazníků a tak, ale mohou vznikat i ze strany technické. Jak jsem už říkal před chvílí, snažíme se třeba dělat i developer advocacy, a zároveň vidíme, že čím dál tím častěji do rozhodovacího procesu, když se někdo rozhoduje o nákupu, vstupují i technické osoby. Není to tak, že člověk, co drží peněženku, rozhodne, že koupí GoodData, ale často ještě než se vůbec vyberou ty tři kandidátní platformy, mezi kterými se bude rozhodovat, dělá shortlist technický člověk – architekt nebo data inženýr. A tito lidé mají jiné preference než byznysoví zástupci, a z toho vznikají jiné příležitosti.

Například teď hodně propagujeme něco, čemu říkáme S-code approach – tedy že všechno můžeš definovat jako kód, doručovat jako kód a dodržovat to s inženýrskými praktikami. To je příležitost, kterou bys nenašel tím, že by ses bavil pouze se zákazníky nebo uživateli, například z banky. Takže příležitosti vznikají i „ze spoda“ a pak se musí správně prioritizovat. Myslím, že u nás je teď tento přístup do určité míry vyvážený – část týmu řeší byznysové příležitosti a část firmy zase tyto technické příležitosti.

Co se týče mé původní otázky, jak moc tohle ovlivní vývoj, možná je to motivováno mou zkušeností z doby, kdy jsme začínali s úspěšným vnitrofiremním POC. Přišli jsme s myšlenkou, že bychom mohli vytvořit nový produkt zaměřený na úplně jiný use case a jiný typ zákazníka. Leadership rozhodl, že super, pojďme mít nějaký x-měsíční sprint, budeme mít skutečné zákazníky, kteří používají Workday a nabídnou nám svůj tenant. My jim dodáme prototyp v kódu, abychom mohli zjistit, jestli je o to na trhu skutečná poptávka a jestli z toho může vzniknout produkt.

Na začátku, během výzkumu, který podle mě byl velice zodpovědný a zahrnoval i podrobné uživatelské rozhovory, jsem byl upřímně nervózní. Měl jsem pocit, že vlastně stojíme na místě, a spíš jsem tlačil na to, abychom začali rychle sypat mockupy a prototypy...

Lát nějaký jenom rychlý prototyp a vystřel na to feedback. Tak mě zajímala vlastně ta tvá zkušenost, protože ty jsi mluvil o hodně vstupů do toho researchu a to všechno trvá. To je zajímavý, co říkáš. Teď, jak to říkáš, si uvědomuju, že jsme tenhle problém možná měli taky úplně na začátku, že se hodně dlouho jenom přemýšlelo a nic se nedělo. A to je samozřejmě problém, to není dobře, nikdy to není dobře, ale teď mi přijde, že to je nějak vybalancované a že i lidi, kteří měli tendenci dlouho přemýšlet, změnili způsob, jakým fungují. A dneska třeba mnohem častěji vzniká aspoň něco ve Figmě, co už můžeš někomu ukázat a otestovat to na něm, i když jsi ještě nenapsal ani řádek kódu. Myslím, že se mnohem rychleji přistupuje k akci a mnohem rychleji můžeš rozhodnout, jestli touhle cestou chceš jít dál, anebo ji zaparkovat. Takže nečekáme.

Druhý aspekt věci je ta paralýza. Když tohle děláš nějakou delší dobu, jsi schopný v jednom streamu vyvíjet a v druhém přemýšlet a vlastně nevadí, že tyhle stojí ve frontě, protože máš co dělat. Takže když si vyrobíš nějaký buffer, můžeš si občas říct: „OK, teďka přemýšlejte,“ i když z toho třeba nic nebude, proč ne.

Jedním z témat, co s tím souvisí, je vůbec jak vyhodnocovat feedback, respektive jak měřit úspěch návaznosti na to. Jak to bylo u vás, když jste začali, padlo rozhodnutí, pojďme zkusit něco novýho, dostali jste nějaká kritéria úspěchu – třeba, že za rok chceme vidět tohle? Nebo ne? Jejda, to je asi nejbolestivější téma. To je těžké, no. Hele, vystavíš takhle komplexní věc na zelené louce a děláš to v průmyslu, který se obecně považuje za jednu z nejneúspěšnějších oblastí historie. Prostě business intelligence platformy nemá nikdo rád, všichni jsou naštvaní, že to nefunguje, a pořád používají Excel. Takový je stav našeho průmyslu, a do toho ty dodáváš novou platformu na zelené louce a snažíš se uhodnout, co by uživatelé chtěli. To je prostě „mission impossible“, že jo.

Měřit úspěch? Určitě se to dá dělat na té nejjemnější úrovni granularitě. Můžeš sbírat telemetrii, dělat různé funnel analýzy, analyzovat chování uživatelů a na základě toho velmi rychle vidět, kde se zasekávají, kde je ztrácíš, a tak. Musíš mít samozřejmě nějaký trial, během kterého jsou schopni absolvovat onboarding experience – ideálně ji ještě podpořit. Jsou nástroje, které embeduješ do trialu a které uživatele provedou, kudy mají jít, dávají třeba i nějakou gamifikaci – třeba body za to, že postoupil do dalšího levelu a tak. To je super a tam dokážeš najít spoustu drobných problémů, VUX třeba a tak. A nejenom VUX, občas jsou bugy i na back-endu. To je super.

Ale měření celkového úspěchu je těžké. Já se úplně necítím kompetentní k tomu vyjádřit se k tomu. Samozřejmě můžeš měřit peníze. To je ja…

Sny. A v chvíli, kdy vidíš, že netníhu roste o desítky procent, jako každý kvartál nebo ročně, tak je to znamení, že to asi neděláš úplně špatně. Ale je to velmi hrubé měření. Neukazuje ti to žádné větší detaily. Neřekne ti to, že za rok začneš zase padat dolů, protože sis něco nedomyslel. Nenašel jsi nějakou důležitou oportunitu. Dám příklad. Představ si, že bys všechno dělal dobře, všechno si měřil na té detailní úrovni. Rostly by ti salesy, všechno by bylo v pohodě. Ale úplně bys ignoroval, že existuje teď ten hype kolem generativního AI. Úplně bys to ignoroval. Tak věřím tomu, že za rok, za dva by ses propadl dolů. Protože bys prostě přehlédl tuto důležitou příležitost. A to je těžké predikovat. To už je o tom, že sleduješ, co se na trhu děje, o čem se píše. Snažíš se vyvarovat toho bullshitu. Protože hodně lidí bullshituje po internetu, že tohle je hype, tohle je hype. To vyžaduje nějakou znalost té problematiky, abys odhalil, co je bullshit a co ne. No a pak si musíš vybrat a doufat, že se trefíš. Jestli si vybereš machine learning, generativní AI, nebo prostě nějaký low-code přístup pro developery, nebo ještě něco jiného. To už je trochu sázka do loterie. Každopádně u vás to vyšlo. Na začátku uvést náš díl, tak jste v Guddatě. Kdy přišel ten moment, kdy se řeklo: "Tohle je fakt úspěšný"? Protože když se koukneš na celou tu dynamiku, tak někde to začalo jako trošku garážový projekt a teď je to ten nový směr, tak někde tam musel být reality check. Když se řeklo: "Hele, tak to fakt dává smysl?" Nebo to bylo spíš postupné a v podstatě se ta sněhová koule nabalovala, až vlastně už bylo jasné, že to jiným směrem nepůjde? K té první fázi Guddaty se úplně nemůžu vyjádřit, protože jsem přišel tak ve druhé třetině té první fáze firmy, kde se určil ten úspěch té první platformy Guddati, nevím. Pak to šlo dolů. Teď to jde zase nahoru a úspěch nám to přijde, nebo mě aspoň osobně to přijde, že to úspěch do značné míry je, ale rozhodně nejsme na konci. Je tam spousta věcí, které je potřeba posunout ještě dál, aby se z nás stal opravdu závažný konkurent těm největším hráčům, jako je třeba Power BI. Zároveň vidíme detraktory v té industrii, třeba Tableau pomalu umírá a hodně lidí se snaží kanibalizovat na tom. Hodně dynamicky se to vyvíjí, je tam spousta příležitostí, kterých se Guddata rozhodně může chopit. A když budeme další dva, tři roky jako teďhle intenzivně pracovat, tak věřím, že dojde k nějakému opravdu ultimátnímu úspěchu. A jak ho změřit, to je otázka. Někdo tě koupí, nebo prostě vstoupíš na burzu, nebo těžko říct. Toto je už trošku mimo mou expertízu, abych upřímně řekl pravdu. No, jasno, vypadá to, že ještě musíte odkopat velké hory práce, a že vás čeká spousta zábavy. Když to takhle zpětně zhodnotíš, tu celou jízdu, co jsi zažil za posledních pět let a všechny vaše úspěchy a možná i neúspěchy, pokusy inovovat – co vyšlo, co nevyšlo – co jsou ty věci, které si chceš přenést teď do budoucí práce? Jaké jsou ty největší lessons learned? Kdy pro tebe to byl…

Jestli jsi zvládl něco fakt těžkého a teď je pro tebe hrozně důležité to správně nastavit a předat dál, určitě na to budu stavět. Ta otázka má dva rozměry – osobní a obecný. Z osobního hlediska budu stavět na tom, k čemu mě okolí „donutilo“. Způsob, jak fungovat, jak řídit jiné lidi, jak pracovat v týmu, jak designovat a architektovat věci – v tom jsem se hodně posunul. Také v tom, jak komunikovat nebo řešit konflikty, na tom budu rozhodně dál stavět.

Z odborné stránky je jedna věc vývoj – jak inovovat produkt nebo nějakou technologii, a druhá věc je komunikace směrem ven. V obou oblastech mám rozhodně ještě co zlepšovat. Co se týče technologie, nové trendy, jako třeba AI, považuji za revoluční příležitost. Není to jen další technologie, kterou budeme adoptovat, jako třeba novou databázi, ale je to změna chování, úplná změna paradigmatu. Změní to způsob, jak pracujeme, ale i platformu, kterou budujeme – a jak bude pomáhat uživatelům být úspěšní třeba s asistenty. Takže to bude obrovská změna.

Komunikace směrem k zákazníkům je také velmi důležitá. Hodně často s nimi mluvím na konferencích, můžu mluvit třeba i na AV Summitu nebo mít keynote, což by bylo pro mě psychicky velmi náročné. Určitě je před námi spousta výzev, kterých lze v příštích letech dosáhnout.

Co říkám člověku, který nastoupí do mého týmu jako nováček? Možná bych si na to měl udělat powerpointovou prezentaci (smích). U nás je problém, že komplexita odvětví je obrovská a onboarding trvá déle než v jiných firmách. Hodně lidí se bojí k nám nastoupit, když to řeknu upřímně. Snažím se jim to „prodat“ – vizi, kam chceme dojít, a jak zajímavé to může být. Pak jim představím firemní kulturu, způsob, jakým fungujeme jako firma – to má spoustu rozměrů. Tým, autonomii lidí, jak moc je neobtěžují procesy atd. A tohle se jim snažím co nejlépe předat a docela často je to úspěšné.

Ale abych byl úplně upřímný, hodně lidí po čase odejde, hlavně kvůli tomu, že onboarding pro ně je příliš náročný. Práce v GoodDatě není jednoduchá a vyžaduje, aby člověk byl seniorní, nebo se jím stal. Vůbec nemáme nic proti náboru juniorů, naopak je to benefit – mohou se rychleji naučit a je to super. Problém ale je, že naše školství často připraví absolventy, kteří nejsou hned plně použitelní. V prvních třech měsících je to stále výzva, takže jim musíme opravdu předat vizi a dát jim podporu.

Žít a pak se o ně dobře starat, aby onboarding probíhal hladce, a pak už prostě, když ten člověk je seniorní a funguje autonomně, tak je to super. Tak já myslím, že tohle je skvělá zpráva všem našim posluchačům. Nebojte se guddaty. Dostanete příležitost pracovat na skvělých, náročných výzvách a hlavně příležitost pracovat s tebou, Jacku. Já myslím, že tohle povídání bylo minimálně pro mě, doufám, že i pro posluchače, extrémně zajímavé – udělat si takovou trošku retrospektivu nebo postmortem na to, jak je to inovovat při rozběhnutém vlaku. A vzhledem k tomu, že vás ještě čeká hodně práce, jaký je tvůj výhled teď na další roky? Představ si, že za dva roky se tu opět sejdeme u dílu 204 CCA, předpokládám – o čem si budeme povídat? O čem bys chtěl, abychom si povídali?

No, chtěl bych, abychom si povídali o tom, že v Guddatě prostě každý zná Guddaty, brand awareness je pořád ještě problém, který musíme vyřešit, a proto tady taky dneska sedím. A je radost v Guddatě pracovat, víc lidí tam pracuje, firma dál roste a ta firma se kvalitativně posune o další level. A já osobně si myslím, že ten další level je prostě v generativním AI. Já osobně teď dělám na projektu, který dodává vychytávky, jako jsou AI asistenti do Guddaty. Nedávno jsem se o tom bavil třeba i se zástupci Kebuly, kteří na tom taky dělají, a vlastně hledáme tu synergii, protože oni dělají ETL a my děláme BI, takže by to mohlo spolu dobře fungovat, asistenti nějak na sebe navázat a tak. Všichni věří tomu.

To je ta další velká věc. Takže já myslím, že za dva roky si prostě budeme povídat o tom, že GoodData vypadá úplně jinak. Už tam nebudou žádné dashboardy, už tam nebude žádný report builder, ale bude tam AI asistent, který ti ráno řekne, co se změnilo od včerejška, kde jsou jaké anomálie, nebo kdo přinesl nové údaje do data warehouseu a jak by se to dalo zajímavě použít na další insighty. Prostě se úplně změní paradigma a my jako GoodData ideálně budeme lídry v tomto směru vývoje a staneme se hodně zajímaví. Začneme třeba i tím, že loni jsme hrozně intenzivně pracovali na Gartner reportu, ve kterém jsme se už druhý rok po sobě objevili. Nakonec – řekněme si to otevřeně – Gartner je trochu bullshit, ale...

Skandální tvrzení od Haleno! Má to ale byznysový rozměr. Prostě ti lidi z velkých firem na to koukají, do určité míry to vyjadřuje tvou zralost, do určité míry to vyjadřuje, jak jsi úspěšný mezi zákazníky, a tak. Takže já tomu věřím, a je vidět z toho Gartnera, proto o tom mluvím – Gartner úplně změnil otázky loni, bylo tam strašně moc otázek zaměřených tímto směrem. Zároveň nám ale Gartner analytici říkali: Hele, to AI ještě nikdo nemá v produkci, to je všechno jenom hype, ale my věříme, že třeba za dva roky už to bude opravdu seriózní věc. Proto teď ty otázky klademe a my jsme tomu šli naproti a vyvinuli jsme prvního AI chatbota už loni, i když byl ještě hodně prototyp. Takže já věřím, že za dva…

Roky prostě Gartner řekne: „Jo, data je lídr právě kvůli tomuhle,“ třeba jako příklad. Tak to já myslím, že je krásný mission statement na další dva roky. A moc ti děkuju, že jsme tady spolu prošli tohle téma, a moc děkuju za návštěvu. Budu se těšit na další dva roky.

No, já děkuji moc za pozvání a věřím, že to třeba nebude až za dva roky.

To je pravda, samozřejmě naše dveře jsou ti otevřeny pořád, takže snad i dřív.

Super, tak jo.

Tak jo, díky moc.

Děkujeme, že jste doposlouchali až sem, a díky taky našim partnerům – členům Data Talk klubu. Těmi jsou intecs, Sazka, BizzTreat, Colours of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, DataMind, Notino a FLO.

A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.