Podcast

Dobrý den, moje jméno je Jirka Vicherek.

Dobrý den všem, moje jméno je Hinek Wagner. A vítáme vás u dalšího dílu DataTalku.

Dneska jsme si pozvali do studia mého kolegu z Vodafone, Tomáše Wernera, který tam pracuje jako principální produktový manažer. Vítej, Tomáši.

Děkuji za pozvání.

Ahoj, Tome.

My jsme si Tomáše pozvali, protože patří mezi takové diamanty, pár lidí na českém trhu, kteří spojují dva různé obory – Data Science a produktový management. A vlastně tvá cesta byla od Data Science k produktovému managementu. Jak začala tvá dráha a kde se poprvé objevil produkt?

Po dokončení kybernetiky na ZČU, tedy na Fakultě aplikovaných věd, jsem se přihlásil do Seznamu, kde jsem byl zhruba třetím výzkumníkem, tehdy pod Radimem Řehuřským a později pod Jirkou Maternou. Pracovali jsme na výzkumu. Já jsem velký fanoušek sci-fi, takže mě vždycky bavily umělé inteligence, Star Trek a vše, co je nové. Hrozně mě bavilo, že se mohu vrtat v datech, dělat klasifikátory, generovat dobré výsledky hledání. Byla to skvělá příležitost se hodně naučit. Pracovali jsme na relevanci hledání, generování snippetů a podobných věcech.

Postupem času jsem čím dál více cítil, že hledání řešení problémů je zábava, a také jsem přemýšlel, že bych chtěl ovlivňovat, co se dělá, a formovat, jak to vypadá, nejen algoritmicky, ale i jako uživatelský zážitek. Už tehdy jsem začal přemýšlet, jak se do toho dostat.

Pak se objevila příležitost v O2, kde vznikl Big Data tým. Telekomtýmy poměrně pozdě poznaly, že mají data, že je mohou používat a za ně dostávat peníze. Vznikl tak Big Data tým a já jsem dostal roli Head of Data Science. Tam jsem se přiblížil k roli, kdy už jsem neřešil jen algoritmy, ale také jak mohou koncové produkty vypadat. Bylo to velmi zajímavé, protože strojové učení na Čechách patřilo od počátků k extrémně vysoké úrovni, což si myslím, že platí i dodnes.

Pracovali jsme na relevanci hledání, generování snippetů a podobných věcech. Postupně jsem čím dál víc cítil, že řešení problémů je zábava. Také jsem přemýšlel, že bych chtěl ovlivňovat, co se dělá a jak to vypadá nejen algoritmicky, ale i po uživatelské stránce. Už tehdy jsem přemýšlel, jak se do toho dostat.

Pak se kromě toho v O2 objevil Big Data tým, kde telekomunikační firma objevila, že má data, byť trochu pozdě, ale nakonec zjistila, že s nimi může pracovat a vydělávat. Takže vznikl Big Data tým, kde jsem byl jmenován vedoucím Data Science. Tam jsem se víc přiblížil roli, kde už jsem neřešil jen algoritmy, ale i jak koncové produkty vypadají.

Bylo to velmi zajímavé, protože na české nebo světové úrovni si myslím, že produkty, které jsme dělali, byly zajímavé. Například jsme vyvíjeli produkty pro mobilitu, které se analyzují dodnes. Pak vznikl Data Clair, který stále nabízí mobility služby, například objednání analýzy pohybu lidí, podle které se plánuje otevírání poboček, otvírací hodiny a podobně.

A v Data Clair jste stavěli takové produkty sami, nebo byla to spíše konzultační činnost?

Ty produkty jsme stavěli přímo pro O2. Používali jsme dva zdroje dat: jednak mobilizační data, protože všechny telefony se připojují k sítím, a to umožňuje usuzovat, kde se uživatel nachází. Dále jsme měli interní data ze smluv, například demografii, což jsou velmi cenná data. Měli jsme také data z HTTP profilování, tedy co lidé sledují. Z těchto zdrojů se dá vytvořit komplexní obraz o uživateli.

Výstupy jsme využívali pro různé CRM a targeting. Vytvořili jsme DMP (Data Management Platformu), která byla napojena na ostatní reklamní platformy, takže jsme mohli data o uživatelích monetizovat.

Co bylo ale zajímavé, je, že v Česku, které má deset milionů obyvatel – což je velikostí srovnatelné s New Yorkem – je velmi obtížné projekt naškálovat tak, aby byl ekonomicky smysluplný. Co funguje ve Spojených státech, často vydělává miliony či miliardy, u nás je těžké, aby projekty přežily a zůstaly otevřené. To platí pro mnohé use case.

Naštěstí u mobility to dávalo smysl, a to se stále dělá. Po mém odchodu tam vzniklo mnoho dalších dobrých use case, předpokládám.

A v Data Clair jsi měl na starosti také nějaké role, které by odpovídaly klasickému produktovému manažerovi? Už jsi dělal roadmapu, mluvil s uživateli? Bylo to poprvé, kdy tě pustili do takové role?

Ten tým se tenkrát ještě nejmenoval Data Clair, byl to Big Data tým. Ten později založil Jirka Honza Romportl, respektive Honza Romportl. Mobility produkty jsme ukazovali zákazníkům, bavili jsme se s nimi, co chtějí, navrhovali jsme, jak to má vypadat, kde a jak to mají integrovat do svých systémů. Bylo to první seznámení s rolí, kdy už jsem neprogramoval jen podle zadání produktového manažera, ale byl jsem v kontaktu se zákazníky, prodávali jsme analýzy, vysvětlovali výsledky a přizpůsobovali je zpětné vazbě.

O jakém období se bavíme?

Bylo to zhruba v letech 2013–2015.

Takže role produktového manažera byla v té době ještě poměrně v plenkách, že?

Ano, bylo to spíše o product ownerech než o úplných produktových manažerech; role PM byla v Česku ještě dost nedostatečně definovaná. Customer research a uživatelský výzkum se začaly více rozvíjet později s nástupem human centered designu.

Jak jsme to v Seznamu dělali? Měli spoustu dat, velkou uživatelskou základnu a dobrou infrastrukturu pro analytiku. Měli jsme integraci algoritmů, anotační systém, kde desítky anotátorů každý den označovaly data, což umožňovalo testovat nové nápady rychle, takže bylo snadné ověřit, zda jsou produkty úspěšné. Přišlo také A/B testování, což je pro velké firmy jako Seznam naprosto klíčové.

Ovšem v menších firmách, jako ve firmě, kde nyní pracuji, nejsou miliony uživatelů, a proto spíše musíme jít za jednotlivými uživateli, mluvit s nimi, pochopit jejich potřeby. To je úplně odlišný přístup ke správě produktů – spíše kvalitativní než kvantitativní.

Živě se tedy bavíme o kvalitativním versus kvantitativním přístupu?

Přesně tak. Seznam pravděpodobně využívá obojí, což je nejlepší varianta, ale tam je méně prostoru dělat chyby, než když máte méně uživatelů a ne všude jsou dostupné metody statisticky významného testování.

Když se vrátíme k Big Data týmu, jak jste s tímto problémem škálovatelnosti bojovali? Zmiňoval jsi, že to byl krok už na jiné úrovni.

Problém škálovatelnosti nebyl, pokud jde o to, co dělat, ale spíše o úspěch produktu – zda ho nechat existovat, či ne, a kolik vydělává. Vědět, co dělat a jak, nebyl problém, bylo to spíše data science náročné.

Měli jsme data scientisty a vlastní platformu založenou na SQL, která byla snadno použitelná. Data scientisti nebyli tak hardcore jako v Seznamu – kde to byli specialisté z MatFyzu, kteří rozuměli algoritmům do hloubky. U nás šlo spíše o aplikovanou úroveň – věděli jsme, že potřebujeme něco klasifikovat, a produkt byl „dobrý natolik“, pokud to takto uděláme.

Což je značný rozdíl proti tomu, když děláte product management pro produkt v Seznamu, například vyhledávání, navázané na metriky a reklamu, kde zvýšení CTR reklamy znamená milionové příjmy. U malých firem to tak často není.

Malé firmy často nemají takto jasný, přímý dopad na zisk jako velké firmy typu Google, Seznam nebo Facebook.

Ale i zde je jedna nevýhoda – data scientisti se často velmi zaměřují na metriky a méně na uživatelský zážitek.

Po tom, co jsem se stal PM, bych popsal svůj přechod tak, že jsem nedělal jen datascience v Seznamu, pak jsem dva roky dělal datascience v O2, a potom jsem se stal produktovým manažerem zase v Seznamu.

Protože jsem byl datascientistou, snažil jsem se být PM pro datové produkty, zejména machine learningové. Stal jsem se produktovým manažerem v oblasti cílení v reklamních systémech. Poté jsem vedl produktový tým pro cílení, doporučování a produktovou analytiku.

Rok jsem dokonce sám řídil doporučování, než přišel další PM. Byla to radost, protože jsme měli data a mohli dělat současně deset A/B testů.

Občas se nám ovšem stalo, že jsme se příliš ponořili do algoritmů a zapomněli na to, jak to vypadá z pohledu uživatele. Vytvářeli jsme složité algoritmy tam, kde by stačila heuristika.

Datascientisti se heuristikám zpravidla brání, protože to vede k méně čistým datům a komplikacím v analýzách, ale někdy jsou nejlepší jako začáteční řešení.

Je totiž často velmi těžké spojit metriky s uživatelským zážitkem. Obvykle jsme řešili, že jednoznačně nemůže být měřítkem jen CTR, protože tam zasahovalo i představenstvo.

Přišli jsme s myšlenkou, že pokud chceme zlepšit uživatelský zážitek, potřebujeme novou metriku. Například u videí jsme již nepoužívali CTR, ale měřili jsme dobu sledování.

To mělo velký dopad na kvalitu doporučování videí – video už tolik nedoporučovalo clickbait, ale naopak videa, která diváci sledovali déle.

Tento trend potvrzovaly i studie a ostatní firmy, které doporučují video, se tímto směrem ubíraly.

Důležité je podle mě přemýšlet o uživatelském zážitku i jako datascientista a uvědomovat si, co uživateli chceme poskytnout.

Kromě toho, co jsi právě zmínil, máš také unikátní cestu – byl jsi datascientistou v Seznamu a poté jsi se tam vrátil jako produktový manažer nebo vedoucí produktového managementu.

Byly i další momenty, kdy jsi si jako datascientista vytvářel představy o produktovém managementu, pak ses naopak dostal do role PM a zjistil, že to funguje jinak? Mě zajímá ten změnový mindset – ty jsi byl v roli datascientisty, rozvíjel se tam, zajímal tě dopad, byl jsi empatický k uživatelům. Kdy přišel moment, kdy sis řekl, že chceš být produktovým manažerem? Nebo ti to upravovala firma? Nebo tyto dvě role byly tak propojené, že jsi to nepovažoval za kariérní změnu?

V Seznamu jsem měl trochu výhodu, že jsem si mohl vybrat, co chci dělat. Samozřejmě jsem plnil úkoly, ale měl jsem prostor pro vlastní volbu.

Například – abych se pochlubil – Seznam měl embeddingy dokumentů už v letech 2011–2012, kdy jsem je naprogramoval a hrozně nahekoval a přidal do robota. V testech to tehdy nefungovalo moc dobře, a asi po třech letech to bylo zase odstraněno, protože nebylo připravené.

Chtěl jsem tím říci, že hodně věcí jsem si už vybíral sám. Žil jsem v pocitu, že si mohu dělat zhruba to, co chci, a že to je zábava.

Největší změnou mindsetu bylo, že jako produktový manažer neděláš řešení, ale definuješ problém.

Často je chyba, že lidé hned skočí do řešení, místo aby si dali práci s přesnou definicí problému a dali ostatním příležitost, aby ho vyřešili.

To je velký problém, jak definovat problém tak, aby mu porozuměli datascientisti, UX designéři i vývojáři. To je opravdu zásadní téma.

Takže největší změna je neřešit hned problém, ale dobře ho definovat, aby ostatní mohli přispět svým řešením, místo aby jim bylo předkládáno hotové řešení.

Tento přístup je často přehlížený, protože developeři a datascientisti jsou často zvyklí, že jim PM přesně řekne, co mají vytvořit.

Já ale zastávám názor, že spolu musíme problémy hledat a řešit je společně.

Co mi ale pomáhá je, že datascientisti mají velkou výhodu v tom, že uvažují v pravděpodobnostních rozděleních. Nerozlišují svět černobíle, chápou nejistotu, že experimenty nemusí vyjít.

To je podle mě velmi důležité i v produktovém managementu.

Já sám přímo neprogramuji a nepracují s algoritmy, ale pracujeme se zákazníky, stanovujeme hypotézy a testujeme řešení. To je podobné jako v datascience, a podle mě by se tyto dva přístupy měly vzájemně přibližovat.

Nebyl tedy žádný „aha“ moment, kdy ses podíval na vizitku a řekl si „jsem produktový manažer“?

Ne, bylo to relativně postupné. Už v Seznamu jsem si občas mohl volit, co chci dělat. V O2 jsem se k tomu přibližoval a nakonec jsem si řekl, že to je ta cesta.

(Úvod další věty je chybně přerušen, další text nereprodukován z dané délky.)

Nebudu kecat a snažil jsem se vědomě neříkat jim, jak mají dělat data science. Protože už, co si budeme povídat, když jsem se stal manažerem, tak po třech letech jsem už nebyl schopný dělat data science tak jako oni. Za ty tři roky se to měnilo. Třeba přibylo pandas, což si myslím, že byla extrémní revoluce v tom, jak se dělá data science. Možná to není pravda, ale když jsem to dělal já, tak jsem měl všechno v polích, musel jsem si všechno ošetřit sám, připravit data. Data se totiž stále připravují, ale kdybych tehdy měl pandas, byla by to úplně jiná úroveň produktivity než když jsem si všechno musel strukturovat do vlastních polí.

Takže jsem si vědom, že v praktické čisté data science jsem už za nimi zaostal. Současně jsem byl sebe kritický a vyhodnotil jsem, že jsem nebyl jeden z nejlepších data scientistů, takže pro mě nebyl problém to opustit. Připadalo mi, že nejsem extrémně dobrý datový vědec, ale moje přidaná hodnota byla v tom, že rád mluvím s lidmi, nerad sedím osm hodin u počítače a programuju, rád o věcech diskutuji a vidím je v širší perspektivě. Proto pro mě bylo super snadné změnit roli na produktového manažera, protože jsem nebyl zamilovaný do data science. Přijde mi to zajímavé, praktické, ale když jsem udělal prototyp a začalo to jako fungovat, frustrovalo mě, že musím strávit dva týdny, než systém funguje úplně bez chyby.

Rozumím. Když jsi změnil roli a najednou byl produktovým manažerem pro machine learningové projekty, měla to obrovskou konkurenční výhodu, že jsi znal oba světy datových vědců a manažerské stránky. Čistý PM, který nezná data science, neměl takový vhled a často mu to bylo handicapem, nebo naopak se dělá PM dobře i bez hlubokých znalostí oboru. Na těchto produktech je to ale velká výhoda. Umím s datovými vědci komunikovat tak, co potřebují slyšet nebo co by chtěli slyšet.

Nemyslím si, že je to však podmínka, protože když je člověk dobrý, správně si nastaví spolupráci s týmem, umí se dobře doptat a definovat úkoly, není to nutné. Měl jsem kolegyni, která o data science nevěděla nic, převzala po mně práci na cílení a byla lepší PM než já, právě protože uměla rozčlenit věci, dokázala lidem vysvětlit, co chce, doptávala se, nenechala se obalamutit, šla až na dřeň a chtěla lidské vysvětlení. Takže to není podmínkou, ale myslím, že je snazší pro datového vědce stát se produktovým manažerem pro data science týmy než pro úplně cizího člověka. Takových lidí je ale málo.

Super, to je pro mě velké téma, které chci probrat – spolupráce PM a data science. Dokončeme tvůj životní příběh produktového manažera.

V Seznamu jsem už měl tým produktových manažerů, pracovali jsme s miliony uživatelů, měli infrastrukturu na A/B testování, všechno šlo krásně. Začal jsem se však nudit, protože jsem se cítil zbytečný. Jako manažer produktového týmu jsem začal být produktovým manažerem, ale po dvou letech jsem nebyl moc dobrý, protože jsem neměl hluboké znalosti a neměl jsem zkušenosti s mentorováním produktových manažerů, když sám jsem se stále učil.

Rozhodl jsem se proto jít do zahraniční firmy, abych pracoval anglicky. Přišel jsem do Citrixu jako PM pro chatbota, vyměnil jsem miliony uživatelů za desítky až stovky, ale zase to byl SaaS produkt, a tam jsem se učil „kraft“ produktového manažera ve velké firmě, která vytváří software. Tam jsem zůstal dva roky, dokud nezavřeli pobočku v Praze.

Nyní pracuji ve Workday jako produktový manažer pro People Analytics, vlastně na machine learningových funkcích, kde je náš úkol více v kvalitativní oblasti než v kvantitativní, protože máme miliony uživatelů a musíme najít cestu, jak získat tisíce až desetitisíce kvalitativních dat metodami spíše než spoléhat na kvantitativní data.

Super, Tomáši, díky. Myslím, že jsem přešel k hlavnímu tématu tohoto podcastu, které jsme pracovně nazvali „spolupráce Data Science a Product Managementu Data Science“. Možná začnu bulvárním titulkem: co je největší slepá skvrna datových vědců v oblasti spolupráce s PM? Asi jsou to příliš vysoká očekávání od produktových manažerů.

Myslím, že se to hodně zlepšuje a samozřejmě to záleží na okolnostech, ale pořád je to o tom, že datoví vědci se musí naučit dobře komunikovat s „laikem“, tedy umět jednoduchým způsobem vysvětlit složité věci. To bylo i jedna z hlavních věcí, na které jsem se zaměřoval při najímání – jestli jsou kandidáti schopni jednoduše vysvětlit složité koncepty. Obvykle jsou chytrí, takže to dokážou, ale je třeba to neustále používat, protože často ten skill máme, ale zapomínáme ho používat.

Nejdůležitější mezi spoluprací data science týmu a produktu je pracovat na daných věcech společně, protože produktový manažer neví, co je možné, není datový vědec, a datový vědec zase nemusí znát, co uživatelé opravdu chtějí a jaký je jejich problém. Proto by bylo vhodné, aby hodně spolupracovali.

Datový vědec nesmí čekat, že dostane jednoduché, jasně definované zadání typu „vytvoř algoritmus pro toto“. Musí se naučit pracovat v týmu, kde společně s PM definují problém a pak hledají řešení. Je to složitější, protože u machine learningových projektů je třeba zapojit UX designery, řešit performance problémy, starosti o data, technologie a legacy systémy. Je to komplexnější než u běžných webových aplikací.

Proto je nejdůležitější zapojit tyto lidi do definice problému. Často vidím, že datoví vědci, kteří jsou hloubaví, tam chtějí být. Je těžší však toto zajistit konzistentně.

Pokud si představím začínajícího data scientista, který chce být součástí definice problémů, tak co by měl dělat? Měl by začít pochopením produktu. Každý, kdo na produktu pracuje, jej má znát a používat, pokud ho vyvíjí delší dobu. To je základ, aby věděl, jak produkt funguje, jaké jsou jeho silné a slabé stránky.

Dostat se na každou uživatelskou detekční schůzku je obtížné, ale máme nahrávky, shrnutí, review, lze se tam dostat. Je třeba být proaktivní – ptát se, číst, bavit se s produktovým manažerem, klást otázky jako „proč to tak nepoužívají?“ a validovat to s uživateli.

Je to o tom opravdu být proaktivní a nesedět pořád u algoritmů, ale zajímat se, jak uživatelé používají produkt a jaké mají problémy. Máme analytiku, uživatelské logy, metriky, ze kterých lze data hledat. Jde také o to tlačit na produktového manažera, aby byl aktivní, protože pokud není, často se stává pohodlným a nespadne na něj dostatek kritických otázek od týmu.

Vzpomeneš si na nějaký příklad z tvé kariéry, kdy jsi jako datový vědec málo pokládal otázky nebo byl naopak dost tázán, a díky tomu jsi byl „proháněný“ produkták?

S úctou musím přiznat, že když jsem dělal datového vědce pro Seznam Search, vlastně jsem tento vyhledávač jako uživatel moc nepoužíval. Používal jsem ho jen při zkoušení, ale že bych byl heavy user Seznamu a jeho vyhledávače během čtyř a půl roku, to ne. Používal jsem ho pracovně tak, abych viděl, že něco dělá, ale ne aktivně, což je retrospektivně ostuda a doporučoval bych to nepřepokládat.

A od té doby jsi to jistě napravil a používáš ho dneska každý den?

Ne, pořád ne. Už tam ale nepracuju, takže nemusím. A většina vyhledávání, které provádím, je anglicky. Například při pracovním hledání papírů nebo zpráv, jsem četl spíš o golfu a Formuli 1 ve světě. Neměl jsem tedy nutnost ho osobně aktivně používat, i když jsem to měl zkoušet. To není žádná omluva.

Teď se snažím být expert na produkt, což u produktového manažera snad není překvapení. Co znamená být expertem? Znamená to každý den si produkt pročítat a používat, sledovat support případy, snažit se pochopit problémy uživatelů a jejich konfigurace a hledat řešení samostatně, aby člověk nebyl neustále odkázán na podporu.

Myslím, že zpětná vazba od klientů a supportu je jedno z nejlepších míst, kde se objevují problémy, zejména pokud organizace nemá nastavený systém zpětné vazby.

Například i v menších firmách než je Seznam je podpora zdrojem zpětné vazby.

V naší současné firmě aktivně pořádáme výzkumné sezení s uživateli, spolupracujeme s nimi na vývoji produktu. Dále máme případy podpory, kde nám uživatelé říkají, co funguje a nefunguje. Tyto operativní věci sice nezmění budoucnost produktu za dva roky, ale je důležité znát základní bolestivé body – proč něco nemohou nakonfigurovat nebo proč si myslí, že produkt nefunguje tak, jak má. Takovou zpětnou vazbu získají i naši data scientisté, kteří jsou na „on call“ podpoře.

Když se vrátíme k otázce slepých skvrn pohledem produktového manažera na data science tým – říkal jsi už, že hlavní je „být jeden tým“ a překračovat úzce definované hranice. Možná bys mohl rozvést, co to znamená být dobrý produktový manažer datových věd?

Myslím, že jde o správné vysvětlování toho, co chceš, tedy správné nastavení očekávání uživatele, schopnost říct, jaké jsou důležité metriky a spolupracovat s datovými vědci na definici a zadání, čeho chceme dosáhnout a jak to optimalizovat.

Často data scientisti dostanou problém jako úkol, ale není jasné, jak dobré má být výsledné řešení. Proto je důležité spolupracovat na tom, co je „dobré dost“ a pomoci také měřit výsledky. Pokud nemáme A/B testování nebo anotace, může být obtížné zjistit, jakou metriku měřit a co je dostačující úroveň kvality.

Pokud něco není dostupné, je třeba prioritizovat vytvoření infrastruktury na měření úspěchu produktu – například anotace, testování a podobně.

Nelze se zaměřit jen na to, aby algoritmus „zklasifikoval ženy a muže“, ale je třeba pomáhat i s okolními procesy a prostředky, aby datoví vědci mohli svou práci efektivně odvést.

Dále PM musí pochopit, že data science není deterministický proces. Data science je stochastický proces, kde dva nebo tři měsíce výzkumu nemusí vést k úspěchu, který se původně očekával.

Na začátku to může vypadat jednoduše, data scientisti říkají „to vyjde, víme, co děláme“, ale ukáže se, že to nefunguje tak, jak by mělo, všichni jsou nervózní, protože se slíbilo dodání za půl roku, a systém není bezchybný.

PM musí chápat, že to není jako běžný software development, ale že data science je výzkumný proces, kde budou pokusy, které neuspějí.

PM musí toto umět vysvětlit i nadřízeným a stakeholderům, kteří nemusí rozumět tomu, že projekt může mít iterace, přinášet velkou hodnotu, ale zároveň se může prodlužovat kvůli nestochastické povaze.

Ještě bych se vrátil k slepým skvrnám datových vědců z mé manažerské i produktové role: data scientisti jsou kreativní lidé, kteří rádi zkouší různé věci. Je proto důležité jim nastavovat správný fokus, aby zůstali na požadované cestě.

Mají spoustu příležitostí, kde si můžou „hrát“ a často přednostně vybírají tyto aktivity před prioritami.

Pro manažera data science týmu, ale i produktového manažera, je důležité nechat je hrát, ale když je něco důležitého, vést je k tomu a správně prioritizovat úkoly, aby se tým posouval správným směrem.

Když se vrátíme ke spolupráci PM a data science versus PM a IT, jaký to má vliv na koordinaci práce? Jaké frameworky fungují na IT a nefungují na data science? Co z toho by měl PM zahodit, protože tam funguje jinak? A naopak, co je tam ještě důležitější?

To je dobrá otázka, protože v…

Software development, kde se používá Scrum nebo Kanban, je na to zvyklý, protože mají odhadování, celý framework, takže to běží už automaticky, prostě mají ty návyky. Vědí, že občas něco pozmění, když něco nefunguje, vyzkouší nějaký nový framework, z toho si něco vezmou a pak třeba jedou Scrum.

U data science je to poměrně těžší, protože úlohy jsou velké, a data scientisti, alespoň z mé zkušenosti, nechtějí strukturovat práci do tak malých úkolů jako software inženýři, kteří jsou pravděpodobně náturou s větší generalizací trochu jiní. Místo aby si vytvořili úkol na vyčištění dat, na napsání algoritmu a podobně a mohli si to naházet do Scrumu, se to většinou nedělo. Když jsme to zkoušeli, vznikalo celkem velké pnutí. Takže máme víc strukturované a méně strukturované data scientisty a narvat je do jednoho frameworku bylo většinou docela obtížné.

Pokusy přiblížit to software inženýrství se postupem času ukázaly jako problematické, a tak jsem to osobně přestal vyžadovat, protože podle mé vlastní zkušenosti by mě to, kdyby po mně někdo chtěl na všechno vytvářet tiket, hodně štvalo a nebavilo, protože mám raději flexibilitu. Na druhou stranu, jak vyřešit problém sledování pokroku a pochopení, co se děje a co přijde dál, řeším tak, že si s lidmi povídám, mám s nimi one-on-one schůzky, nebo na stand-upu projednáme progres verbálně. Většinou se všem informacím, které potřebuji, tak či tak dozvím bez nutnosti mít všechny úkoly na tabuli.

Kdybych teď předvedl ďáblova advokáta, tak s ohledem na vrozenou kreativitu data scientistů, o které se zmiňoval, to může mít velký potenciál rozplynout se do ničeho. Jak tedy zachovat kreativitu, nenapasovat veškerou výzkumnou práci do jasně definovaných týdenních úkolů, ale zároveň dodat něco, na čem se domluvíme s byznysem? Já to řešil tím, že jsem v kontaktu a bavím se s lidmi. Před pandemií bylo samozřejmě jednodušší, když jsme byli v kanceláři. Můj oblíbený sport byl obíhat stoly, ptát se náhodných lidí a vytrhávat je z práce, jak na tom jsou, podle toho, jak jsem si vzpomněl. Během pandemie to bylo horší, ale zároveň vzrostla struktura, protože bylo více meetingů, které se lépe naplánovaly.

Je to o tom, ptát se lidí a sledovat progres sám v hlavě, což chápu, že nemusí fungovat pro každého. Takže protože máme různé datascientisty, různých PM a různé potřeby, já popisuji, že pro mě jako nestrukturovaného člověka je v pohodě si to oběhat, zapamatovat nebo si to někam zapsat, i když to pak často ztratím, ale neměl jsem s tím zásadní problém, když jsem s lidmi v kontaktu a oni chtěli dodávat.

Jak už jsem zmínil, je důležité jim připomínat, že mají pracovat na tom, na čem opravdu potřebují pracovat. Když se to nedělo, nemám problém dát zpětnou vazbu, že právě nemají dělat něco jiného, že se musí na to, co je prioritou, zafokusovat. Potřebuji něco udělat teď a teď, a pak se s nimi občas bavím častěji než jen na stand-upu.

Je to tedy o tom, že si to jako produktový manažer sám pohlídám. A nastavení týmů – když se sejdou strukturovaní lidé, mohou si dělat úkoly, když je tam více roztěkaných, musí se domluvit. Přirozeně to vyplyne z toho, jak lidé pracují a jak si budují vztahy, což je asi vždycky nejdůležitější, protože tak vznikají vztahy fungující pro všechny.

Samozřejmě vzniká pnutí, protože z vlastní zkušenosti vím, že někteří lidé nebyli úplně spokojení s tím, že já nejsem strukturovaný, že to nevyžaduju a že mi je to vlastně jedno. Oni to jeli, pak mi ukazovali tikety a já si říkal: „Hezké, ale proč bych za to chválil? Posunulo se to nějak?“

Z mého laického pohledu vnímám, že product management udělal obrovský krok vpřed, že se víc formalizoval a profesionalizoval. Zatímco v roce 2013 jste možná měli product manažera v Seznamu, dnes je product manager asi v každé IT softwarové firmě. To se hodně posunulo.

Na druhou stranu boom a revoluce v datových vědách a machine learningu, a to ani nemluvím o letošním roce, ale za posledních pár let, je neskutečný. Z hostů, které zde míváme, je často vidět posun data science směrem k softwarovému inženýrství, například CI/CD, pipeline-first, code data engineering, a až po podporu celého produktu.

Když máte své data scientisty na onkologii, vnímáte v tom nějaký trend, že to bude trochu jinak? Co říkáte?

Každý jsme jiný a najdeme si systém spolupráce, nějaký framework, ve kterém můžeme tvořit hodnotu, a to platí stále.

Mění se nějak váš přístup nebo nástroje, které používáte?

Myslím, že se hodně posunuly, protože na začátku, když jsem začínal, se zaváděl Scrum u inženýrů, potom jsme to zkoušeli u data scientistů. Teď, co vidím, je to velmi blízko softwarovému inženýrství.

Když jsem zmínil, že někdo si dělá malé úkoly, tak samozřejmě jedou Scrum, všechny ty ceremonie tam jsou – review kódu a podobně. My jsme před 12 lety recenze kódu nedělali, což byla velká nevýhoda, protože jsme se nezlepšovali, vznikaly chyby a tak.

Takže všechno se hodně posunulo, a velký rozdíl nevidím v nástrojích softwarového developmentu a data science, ale spíš v přístupu, jak jsou ty role používány. Nástroje jsou velmi podobné.

Teď je vše testováno, jsou platformy na model management a podobně, všechno je hodně blízké softwarovému inženýrství.

Musím říct: zaplať pánbůh za to, protože tam je menší prostor pro chyby. Všechno je automatizované a dobře vyvíjené, takže data scientisti mají podle mě mnohem větší jistotu, že se stane méně chyb.

Neposouvá to ale data science z toho dřívějšího, až skoro čistě R&D směrem do inženýrství? Nebo si myslíte, že budou čistě datoví scientisti za nějakou dobu méně? Nebo že jich bude méně?

To je dobrá otázka. Dříve jsme měli data scientisty, kteří moc neprogramovali, nebo programovali méně kvalitně než programátoři s víc zkušenostmi. Teď víc vidím chytré data scientisty, kteří umí zároveň perfektně software engineering. Krásná kombinace.

Jsou data scientisti, kteří dělají data science, ale jsou silně zaměření i na software engineering, protože vystudovali školu a byli v tom hodně zkušení.

Takže na tom asi něco je, ale všichni se uplatní, protože ty dovednosti a druhy práce jsou různé. Pro různé typy na škále se vždy najde uplatnění.

Hardcore data scientisti to budou mít těžší, protože si musí najít firmu, kde mohou dělat hluboký machine learning. Dnes je možné dělat data science bez hluboké znalosti algoritmů, a často se to i tak praktikuje.

Algoritmy jsou komoditizované, jsou dostupné, a pokud víte, jak s nimi pracovat, i bez znalosti každé nuance dosáhnete dobrých výsledků.

A když máte extrémně chytrého data scientista, který umí jít opravdu do hloubky, musí si vybrat firmu, která mu umožní dělat hardcore research.

Myslím, že pro firmy je to dobře, protože hardcore research je plytvání talentů, pokud jim stačí někdo, kdo udělá dostatečně dobrý produkt bez nutnosti vše ladit do detailů.

Současně mě přijde, že se stále bude potřebovat inovovat, ale zároveň se to vše posouvá někam jinam.

S hypem kolem jazykových modelů – kdo jim rozumí do detailu? Všichni je chtějí používat a všichni je používáme, a všichni jsme tak trochu experti na AI.

Je to těžké sledovat, protože progres je tak rychlý, že když na to nemáte čas, nestačíte sledovat každý týden nový článek. Stačí si třeba přihlásit odběr newsletteru, co já dělám, nebo sledovat Reddit, kde je o tom hodně informací.

To také ovlivňuje firmy, protože management si vzpomněl na existenci AI. Kdo ji nemá, neuspěje, například na Wall Street.

Všechny firmy proto označují své produkty jako machine learningové nebo AI, aby byly u toho, což je velká příležitost pro nás všechny.

Ti, kteří pracují s data science, mají nyní větší expozici a mohou toho využít.

Současný hype pravděpodobně povede k vystřízlivění; je třeba být velmi opatrný, kam se pustíte a co začnete dělat, protože za rok ten samý management může chtít vědět, proč není něco hotového, nebo proč jste investovali do výzkumu něčeho, co mohlo být předem jasné, že nemusí být úspěšné.

Jak v takové budoucnosti navigujete? Pociťujete tlak, že není možné sledovat všechno, že byznys požaduje inovace a implementace všude, ale není to možné?

My máme teď jednodušší situaci, protože děláme příběhy.

Storytelling je pro nás velká příležitost a zároveň nám pomáhá získat větší podporu.

Nemohu přesně odpovědět, protože nevíme, jak se to bude rychle vyvíjet, jaké schopnosti budou modely mít za rok.

AI se například naučila dobře komunikovat, což je velké plus, a my to využijeme. Místo šablon začneme používat jazykové modely.

Umí dobře sumarizovat, takže můžeme uživateli sdělit, co máme v aplikaci, aby se nemusel proklikávat vším.

Chci tedy stavět na těch největších jistotách, co jazykové modely umí, konkrétně uvedené případy užití, které jsou celkem jasné, že by mohly pomoci.

Nechceme experimentovat s vlastním učením modelů, protože na to nemáme znalosti. OpenAI a Google to dělají roky.

Mnoho lidí si sílu těchto modelů uvědomilo až s příchodem ChatGPT, který se naučil lépe přibližovat mentálnímu modelu člověka.

V tu chvíli jsem si uvědomil, jak je škoda, že jsme tuto příležitost neviděli dřív, ale to bylo proto, že jsme ten výzkum nedělali.

Přišel až s novými pracemi o human reinforcement learningu, což je podle mě to hlavní, co lidi baví a co je na těch modelech magické.

Samozřejmě existují i další důvody, proč jsou tyto modely tak silné.

Pro management je to podobné jako dřívější hype okolo Big Data.

Když jsem nastupoval v O2, projel jsem si hitem Big Data, ale když jsem viděl, že máme méně dat než někteří jiní, přijde mi, že hype přišel pozdě, protože tyto technologie už měly být dávno běžné.

Teď mám pocit, že machine learning konečně umí to, co jsem si představoval před 12 lety – tedy něco více než jenom tabulková data a nekonečné učení klasifikátorů.

Jsem rád, že jsme tu, kde jsme.

Jak navigovat, aby z těch hypeů něco vzešlo?

Můj osobní názor je, že se máme zaměřit na to, co model umí, proč byl naučený a jaké aplikace umožňuje.

Například využití jazykových modelů jako aplikací, které dříve nebyly možné.

Kdybych měl říct, jak si představujete machine learning nebo inteligenci za 10–12 let, abychom se mohli připravit?

Pro mě je nejdůležitější to, co dobře tyto modely umí, což je copilot.

Z produktového pohledu je největší problém softwarového vývoje jeho drahota a to je úzké hrdlo, produktivita.

Mám deset věcí, které bych chtěl dělat, a vybrat si můžu jen jednu, kterou dostanu za půl roku.

Software development je extrémní bottleneck.

Pokud bychom mohli zvýšit produktivitu desetkrát, zásadně by se změnil svět a možnosti toho, co bychom mohli vybudovat.

Chápu obavy, že někdo může přijít o práci, ale pokud chceme létat do jiných galaxií nebo řešit klima či jiné společenské problémy, bez zvýšené produktivity práce to podle mě není možné.

Doufám, že za deset let AI sama o sobě nevyřeší klima, ale pomůže zvýšit produktivitu softwarového vývoje a tím nám umožní těžit z vyšší inteligence a vyvinout více.

Tím by to nemuselo dopadnout tak tragicky, jak to teď vypadá podle mého pohledu.

Možná za 20–30 let začneme konečně létat do vesmíru způsobem, jaký jsme přestali – na Měsíci jsme nebyli 40 let, na Mars nikdo kromě Muska, kterému nevěřím, že tam chce, v podstatě nepoletí.

Doufám, že mnoho lidí nepřijde o práci, nebo si najdou lepší, a že naše děti budou optimisticky schopny podívat se do vesmíru a nezůstanou uvázané na Zemi.

Tohle je podle mě dokonalé závěrečné slovo, tak to zde ukončíme.

Děkujeme moc, Tomáši, přeji nám všem, ať nezůstaneme uvázlí na zemi, a tobě přeji, ať nezůstanete frustrovaný ve své práci, ať dál posouváš hranice a hledáš nové výzvy.

Velmi děkujeme, že jsi přišel a sdílel svou cestu a zkušenosti z JEMKu a data science.

Díky moc.

Děkuji, potěšení.

A to je vše. Díky, že jste doposlouchali další díl Datatolk.

U. Díky také našim partnerům: Big Hubu, Vypnoutu, Mantě, Notinu a tak dále, mně, Jeembimu, Seznamu.cz a MUSE.

Pokud vás zajímají více informace ze světa datových technologií a z československé datové scény, navštivte naše stránky datatolk.cz.

Nechť vás provází data.