Podcast

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

Naším dnešním hostem je Paťa Gogová z digitální agentury Aktum Digital. Vítej, Paťo.
Ahoj.

Jak už jste si určitě všimli, dnešní díl je speciální. A to hned ze dvou důvodů.

Prvním důvodem je, že ani já, ani Barbara, ani náš host nejsou Jiří Vycherka. Ale nemusíte se bát, váš oblíbený hlas Jiřího Vycherky určitě uslyšíte v jednom z příštích dílů.

Druhým důvodem je, že Paťu nám doporučili – nebo přesněji, Paťu jsme oslovili díky velmi dobrým ohlasům na její přednášku na Tableau User Group. Takže věřím, že se dnes máte na co těšit. Byla nám jednoznačně doporučena naším posluchačem, což nás velmi těší.

Paťa k nám do podcastu přišla s tématem, které jsme během přípravy lehce bulvárně nazvali „softskillová slepá skvrna datových analytiků“. Myslím, že se ale nebudeme držet pouze tohoto tématu, ale obecně se budeme bavit o tom, jak v rámci konzultační práce pracovat s reportingem a s BI.

Ještě než se však do tohoto tématu vrhneme, pojďme si, Paťo, projít tvou cestu k datům. Nebyla to úplně triviální nebo klasická cesta, že? Jak to u tebe všechno začalo?

OK, děkuji, že mě tu máte. Co se týká mé cesty, je pravda, že k datům jsem přišla takovou menší obchůzkou přes marketing. Začala jsem v jedné brněnské marketingové agentuře v podstatě v kreativě, ale to byla stáž, takže bych to za úplný začátek úplně nepovažovala, i když jsem to už zmínila, tak to nevadí.

Každopádně tam jsem začala v nějaké kreativní práci a postupně jsem přišla k PPC, kde se začala projevovat moje analytická osobnost – čísla, nastavování kampaní a technická část práce. Uvědomila jsem si však, že mě příliš nebaví samotné nastavování kampaní a kreativní práce s nimi spojená, ale spíše samotné hraní si s čísly, analýza výsledků a také část reportingu.

V té agentuře jsme totiž pracovali s klienty, takže bylo potřeba vybrat, co klientům reportovat tak, aby to byly relevantní informace. Tady jsem se vlastně poprvé dostala k reportingu, který mě provází dodnes.

V ten moment, kdy jsem si uvědomila, že mě baví především čísla, jsem začala hledat datové role. Moje první in-house role byla ve firmě Onlio, kde to bylo stále trochu spojené s PPC, ale zároveň jsem dostala skvělou příležitost starat se o reporting, který byl původně postavený v Power BI.

V té době už byly reporty sestavené někým jiným, já je měla pouze udržovat. Nebyla jsem si úplně jistá, co je hlavní informace a co je důležité zobrazovat. Proto jsem se pak začala učit pracovat i s nástrojem Tableau.

A v kterém roce jsme se bavili o začátcích tvé práce s reportingem?
To bylo v roce 2020, tedy před třemi lety.

Jaký pro tebe byl přechod z těchto méně datových, netechnických rolí? Protože většinou to bývá tak, že člověk začíná třeba programovat, studuje různé matematiky nebo statistiky, a chce je pak uplatnit, nejčastěji třeba reportováním. Jak sis tento přechod představovala?

Vlastně pro mě to nebyla tak radikální změna, protože už v marketingu jsem měla k reportingu docela blízko. Nebylo to tedy, že bych začala úplně od nuly v novém oboru, šlo spíš o plynulý přechod.

Samozřejmě práce s nástroji je jiná věc. Je rozdíl postavit report v Google Analytics, kde se hodně věcí stane automaticky, a začít třeba pracovat s Tableau, které může být hodně technicky náročné – hodně záleží na tom, jak si to člověk nastaví a udělá.

A tvá cesta pak vedla do Deloitte, že?
Ano.

To bylo pro tebe změnou?
Jo, to bylo trochu vtipné. Již během vysoké školy jsem pracovala v marketingové agentuře a v Onliu. Po ukončení studia jsem si řekla, že je čas opustit Brno a vydat se do velkého světa, takže jsem se dívala po fulltime pozici. Když Deloitte hledal roli spojenou s Tableau, což mě nadchlo, protože jsem byla v té době „tableau nadšenec“, rozhodla jsem se tam přihlásit.

Někdo mě vzal, tak jsem pak asi týden po státnicích nastoupila do Deloitte. Bylo to v roce 2021 na juniorském místě a od té doby jsem tam.

Co vlastně znamená pozice juniorního Tableau konzultanta v Deloitte?
Dobrý dotaz, můžu to pojmout z několika stran. Deloitte je konzultační firma a tahle pozice je v rámci consultingu. Deloitte má i jiné divize, ale consulting je mi blízký.

Někdy lidé konzultanty vnímají jako někoho, kdo hlavně mluví a nic nedělá, ale mě to velmi vyhovuje. Já jsem se tam naučila strašně moc věcí rychle, protože tam je hodně šikovných technických lidí.

Musím říct, že jsem měla trochu předsudky o konzultantech, ale byla jsem překvapená, kolik lidí tam opravdu umí věci technicky. Byl to pro mě velký milník v kariéře.

V konzultingu často měníme klienty a jejich problémy, což je skvělá příležitost učit se.

Můžeš nám popsat nějaký konkrétní projekt nebo klienta?
Určitě, nemohu jmenovat konkrétní jména, ale mohu říct, že jedna zajímavá role byla senior marketing data analyst v nadnárodní kyberbezpečnostní firmě, která má sídlo v Praze na Pankráci.

To byla super zkušenost a naučila mě hodně.

Co pro tebe byla největší škola v kariéře, co tě dovedlo k tomu, čemu věříš a co děláš nyní?
Nejvíce mě naučila práce s klienty. Každý klient má jiné problémy a projekty, ale existují věci, které se opakují a lze je přenést z jednoho projektu do druhého.

Často když se s něčím setkáš desetkrát, při jedenáctém máš už nastavený systém, jak to řešit. Bylo pro mě důležité být na projekty připravená, protože problémy v datových projektech bývají často podobné.

Nezůstala jsi v Deloitte a kam vedly tvoje další kroky a proč?
Má cesta pokračovala do Aktumu, digitální agentury, menší než Deloitte.

Líbilo se mi to tam, protože je to menší firma a není to takový obrovský korporát jako Deloitte. Mám pocit, že jsem blíže k rozhodování a strategickým věcem, což v Deloitte je sice možné, ale trvá to déle.

Projekty a náplň práce jsou v podstatě stejné, ale jsem tak blíže klientovi a mám větší dopad na výsledky své práce než v obrovském týmu.

Nechci, aby to vyznělo, že jsem Deloitte odešla kvůli něčemu špatnému – byla to pro mě obrovská zkušenost a milník v kariéře.

Děkujeme, Paťo. Pomalu se dostáváme k hlavnímu tématu, které jsi nazvala Reporting Development Lifecycle.

Myslím, že to hodně navazuje právě na práci pro klienty v rámci konzultačních firem a na proces, který jsi nám načrtla. Můžeš nám představit, jak přistupujete k vytváření těchto řešení pro klienty?

OK, nejprve bych chtěla zmínit, že to není jen moje zásluha, vzniklo to ve spolupráci s kolegy Tadášem a Adamem, takže aby to bylo spravedlivé.

Reporting Development Lifecycle, tedy životní cyklus reportingu, vznikl z toho, že při práci s vícero klienty jsme rozpoznali opakující se kroky a problémy.

Řekli jsme si, že by bylo dobré si vytvořit nějakou osnovu nebo plán, který budeme při projektech dodržovat.

Samozřejmě není to jako pravidlo, že každý bod musí být striktně splněný, spíš je to doporučení, které se nám osvědčilo především při spolupráci jako externí dodavatelé.

Jaké jsou tedy konkrétní fáze tohoto lifecycle?

Začínáme fází přípravy (preparation), pak scoping, development, nasazení (deployment) a nakonec údržba a provoz (maintenance, operation).

Můžeme si postupně vysvětlit jednotlivé fáze, ale předtím mě zajímá, jestli jste v praxi zažili nějaký velký problém nebo průšvih, kvůli kterému jste si tento lifecycle vymysleli?

Kdyby to náhodou poslouchal nějaký klient, tak mohu říct, že žádný velký průšvih jsme neměli, žádný extrémní „fuck up“, kdy bychom hned balili věci a odcházeli.

Byly menší komplikace, občas jsme přišli na nedostatky v datech nebo požadavcích, které se při nasazení ukázaly jako nevyhovující.

Právě to je výhoda mít takový proces popsaný a jasný, protože fáze na sebe navazují a každá má svá finální zadání a výsledky.

Například během fáze akceptačního testování uživatel může chtít ještě nějaké další údaje, ale pak se musí vrátit zpět k definici požadavků a někdy to může být komplikované zejména, pokud nejsou data v datovém modelu dostupná.

Takže může dojít k několikerému kolu úprav, což není o plýtvání časem, ale o nutnosti správné přípravy.

Zatím jsme však nezažili žádný extrémní průšvih.

To dává smysl. Jako konzultant totiž potřebuješ mít kontrolu nad tím, co prodáváš a co dodáváš.

Já zároveň vnímám, že data jsou čím dál více vnímána spíše z hlediska inženýringu, to znamená, že ten proces vývoje je podobný jako u softwaru – máme specifikace, vývoj, nasazení a údržbu.

Máš pocit, že to tak klienti vnímají i v praxi? Nebo se to mění?

Určitě souhlasím. Je zajímavé, jak klienti a technici mohou mít rozdílný pohled. Často je frontend a business část vnímána jako konzultanti – že to jen obkecají a není to hmatatelná práce jako kus kódu.

Podle mě je proto důležitá fáze přípravy a spolupráce s byznysem. Být mostem mezi business týmem a techniky, protože nejde jen o vytvoření pěkných grafů, ale o to, aby informace byla správně prodána a efektivně užita.

Není jednoduché jen hodit pár grafů a čekat, že to business pochopí.

A tím se vlastně dostáváme k první fázi – příprava (preparation), která souvisí s definicí byznysové hodnoty, že, Paťo?

Ano, v té fázi preparation jde o přípravu spolupráce, zejména proto, že jako externí dodavatel přicházíme ke klientovi, kde je potřeba si navzájem nastavit očekávání a pochopit se.

Ta fáze má svá specifičnosti a výsledky (deliverables), ale nebudu posluchače příliš zatěžovat teorií, raději to shrneme klíčové body v jednotlivých fázích.

Co v té přípravné fázi děláme? Především si necháme od byznysu vysvětlit věci opravdu jednoduše, jako „pro mateřskou školku nebo základní školu“. Často se totiž dostáváme do role takového „hlupáka“, nebo jak se to dá říci…

(Tady text končí, ale je patrné, že pokračování by mělo navazovat na to, jak si vysvětlit požadavky a komunikovat s business týmem.)

Jak negativně, teď s nějakou negativní konotací, ale prostě ten člověk, který se stále ptá „proč“, „kdo“, „kde“, „jak“ a „co s tím“, a tak dále. A to je například role, o které si myslím, že možná pár lidí je s ní úplně komfortních, že být v takové roli – jakože víš, že jsi nějaký odborník na něco, ale potom před tím klientem vystupuješ, jako bys nevěděl, co je dva a dva.

Takže to je fáze nějakého toho úvodu, řekněme. Potom, co se často u těch klientů dělá, je, že se snažíme získat nějaké materiály, které už oni mají. Takže, když je to zrovna nějaká zpráva, tak prostě s tím, na čem pracují teď, se snažíme to vnímat a co nejlépe pochopit use case a tu oblast.

Protože například, řekněme, když jsme pracovali s nějakou kyberbezpečnostní firmou nebo s klientem z oblasti nemovitostí, tak se data často opakují. A například, ať už říkáš „ok, tak je to kyberbezpečnost,“ ale například pracuješ s finančními daty. Nebo „je to nemovitost,“ ale zase pracuješ s finančními daty. Takže dostat se do toho, co to znamená, jak s tím pracují, jaká jsou tam specifika, to je velmi důležité.

S tím pak velmi úzce souvisí nastavení nějakých rolí a to si myslím, že je možná ta nejdůležitější část přípravné fáze. Jednak samozřejmě – jako jsou naše role, ale ty jsou v podstatě předdefinované. A potom role na straně klienta, protože je tam několik rolí. Možná kdybych jen vyjmenovala pár:

Například „report business owner“, takže někdo, kdo je zodpovědný za ten report a za jeho dodávku na straně klienta. Takže většinou je to někdo, často bývá to head of finance, head něčeho, tedy člověk, který na vysoké úrovni velmi rozumí té problematice, ale není to úplně ten člověk, který bude s námi každý den sedět na meetingu. Proto právě jsou tam role businessového counterparta a technického counterparta. Tito lidé tomu rozumějí velmi detailně, ale už mají zásah z času, možná.

Potom samozřejmě jsou role, které jsou specifické hlavně pro fázi přípravy a následně scopu – to jsou například „requirements contributors“, tedy lidé, kteří nám dodávají požadavky na ten report, a pak „viewers“, tedy uživatelé reportu. Takže jsem vyjmenovala všechny role a myslím si, že je to strašně důležité, protože si je musíte definovat a zároveň definovat zodpovědnosti, které z toho vyplývají.

To bych možná ještě více zdůraznila, protože mě to přivádí k případu, kdy jsme se trochu spálili – definovali jsme role, řekli jsme si „contributors“, „consumers“ a obdobně jsme je přidělili, ale vůbec jsme nekládli důraz na zodpovědnosti. Takže jsme prostě neřekli: tvoje role je toto, jsi zodpovědný za toto a ty schvaluješ tohle. A následek byl takový, že když ty teď schválíš, že něco dělat nebudeme, a za dva měsíce přijde někdo a řekne: „Hele, já to tam chtěl,“ tak si ty s ním budeš hádat, ne my, protože je to tvoje zodpovědnost.

Takže ty zodpovědnosti jsou tam strašně důležité.

Následně bych asi zmínila ještě tu časovou osu (timeline), kterou si tam nastavujeme. Je to něco, co se dá po zkušenostech relativně lépe odhadnout, ale není to nikdy zcela přesné, že si to naplánuješ na týden dopředu úplně přesně – není. Je důležité pracovat s tím, co víme v danou chvíli.

Takže spíš říct třeba: „Nevím přesně, tak radši nic,“ nebo říct: „Dobře, s tím, co máme, to potrvá tolik a tolik,“ a pak to na nějaké události nebo schůzce upřesnit. Ta časová osa je důležitá, aby tam byl nějaký odhad, jak náročné to bude.

Z mých zkušeností lidé často potřebují vědět měsíc dopředu, že je budeš potřebovat na jedno odpoledne. A takové sladění není vždy jednoduché, takže je potřeba čas dobře řídit v této přípravné fázi.

Co podle tebe z těchto věcí, které jsi zmiňovala, mají největší potenciál vybuchnout? Protože vše tohle logicky dává smysl, ale…

Klasické projektové řízení, že? Pravda. Ale i když existuje projektové řízení, píše se o tom všude a dělají se knížky, stále to není vyřešené. Stále se to někde pokazí. Tak co z tvých zkušeností jsou největší „miny“, které tam číhají?

Určitě role a možná předpoklad, že je to jasné, a že zodpovědnost, která z toho vyplývá, je taky jasná a že je to samozřejmé. Jak jsem říkala, klient často nemá zkušenost s tím, že mu přijdou nějací lidi něco vysvětlovat na data nebo s nimi pracovat. My už máme z toho nějaký bias, že to prostě chápe. Takže rozhodně role a zodpovědnosti jsou klíčové.

A pak ta časová osa (timeline), nastavení očekávání klienta, co kdy má očekávat, a obecně nastavení očekávání celého projektu či reportu. To je opravdu důležité.

Teď jsme tedy ve fázi, že všichni vědí, jaké jsou jejich role, zodpovědnosti, kdy co bude a co máme dodat. Co se děje potom?

Pak přecházíme do fáze scopu, což je vlastně nastavení toho, co se očekává a sladění očekávání ohledně výsledku spolupráce v nějakém časovém horizontu. V této fázi je hodně různých definic a výstupů (deliverables).

Zdůraznila bych uživatelovu příběhovou metodu („user story“), což jsou v podstatě obchodní požadavky. Pracujeme metodologií sbírání user stories, kde si definujeme personu, cíl a důvod, takže to zní často jako „já jako uživatel XYZ chci toto, protože…“.

Zvlášť bych zdůraznila část „protože“ (reason), protože z našich zkušeností lidé většinou popisují vizuál, který by chtěli – například „chci tabulku“, „Python“ – Ježíš, Python nespomínej, ale chtějí tabulku a vlastně 20 sloupců! Chtějí všechny produkty, všechno vědět, všechno hned a dvakrát. Někdy je potřeba klienta trochu moderovat a s obchodní rolí ho trochu vyzvat, zda opravdu chce vidět například všechny produkty, když je převážně zajímá jen určitá část.

Například při realitách – zajímá ho, které produkty se nejvíce prodávají. Takže je potřeba hodně diskutovat a neskĺzávat jen k tomu, jaký bude typ grafu, ale zaměřit se na informaci.

Zároveň mi přijde, že v této fázi si už dovolíš mít názor. Chápu to tedy tak, že v první fázi chceš být maximálně naslouchající, trochu dělat, že nechápeš, ale tady se ta role trochu otočí, ne?

Ano, určitě, připadá mi, že hlavně v této fázi sběru požadavků je role ptáka i důležitější a výraznější – ptáš se „proč“ a „jaká je informace“, co uděláš s tím výstupem. Když vidíš, že graf není úplně přehledný, tak co má být dalším krokem – aby to neznělo jako „mělo by to být ten či onen graf“, ale fakt jít pod povrch informace a ptát se na ni.

Samozřejmě je tam prostor i pro expertní pohled – říct „myslím si, že by to mělo být jinak“ nebo „bylo by efektivnější…“, takový UX přístup k návrhu výsledku.

Následně, když máme všechny požadavky, pracujeme na wireframech. Už tam přemýšlíme o tom, jak bude report vypadat, jak co doručit co nejefektivněji.

Lidé často používají například výsečový graf (pie chart) pro nějakou kategorii, ale například na top 15 kategorií výsečák není přehledný, když vidíš maximálně dvě největší, ale ostatní nikoli. Takže když tě zajímají první tři, proč se tam bude vše škaredit?

Já mám taky ráda výsečové grafy, proto jsem je zmínila, jsou přehledné.

(Poznámka – autor textu ještě zmínil, že výsečové grafy (pie chart) jsou šílené a ještě lepší je donut chart.)

Jak to řešíš, když ve fázi scopu zjistíš, co je důležité a co ne, ale v přípravě už jsi mluvil o roadmapě, očekáváních a konkrétních položkách? Jak to vyvážit?

To je dobrá otázka. Občas se stává, že se to zjistí až ve scopu, někdy ještě později. Ale timeline je v té chvíli nejlepší odhad, který máš v daný okamžik. A důležitá je komunikace – otevřeně říkat klientovi, že se odhad změnil, protože jsme neměli všechny informace nebo se něco objevilo nového.

Taky není dobré klienta „balamutit“ nebo lhát mu – to nikdy nekončí dobře.

Říct: „Hele, spletli jsme se v odhadu, teď to bude jinak,“ a to je v pořádku.

Kdy tedy probíhá finální ocenění projektu? Můžeš na začátku říct, že report bude stát třeba 10 mandays?

Na úplném začátku v přípravné fázi to nejde. Pak bych oddělila projekt a report.

Pokud jde o report, po skončení fáze scopu, kdy víš, co přesně budeš dělat, lze už odhadnout lépe. Jsou tam hlavní milníky: požadavky, data, wireframy.

Řešíme také data – tzv. datapoints – body, které vycházejí z požadavků. Zde již vstupuje backend a technický člověk, který řeší, kde jsou data, v jaké agregaci a granulaci, jestli je vůbec možné report sestavit.

Ukazuje se, že například granulita dat bývá problém. Máme klienta z realit, kde některá data jsou na úrovni celé nemovitosti, jiná na úrovni jednotlivých jednotek.

Takže není možné říct, že všechno lze libovolně segmentovat; s granulitou je třeba umět pracovat.

Další klíčovou částí jsou wireframy – statické návrhy, jak by report mohl vypadat, které umožňují vizualizovat požadavky.

Klient mnohdy při jejich zhlédnutí vzpomene na věci, které by chtěl přidat nebo mu něco nedává smysl.

V této fázi je hodně iterací, dokud nedojde k finálnímu odsouhlasení wireframů a potom je možné udělat reálnější odhad náročnosti.

Můžeš nám prosím blíže popsat, co je to wireframe a jak s ním pracujete?

Definice z internetu nemám po ruce, ale my s tím pracujeme tak, že je to statický návrh reportu, jak bude vypadat.

V této fázi máme obchodní požadavky, tedy spoustu textu, a paralelně i backend řeší, kde jsou data.

Teď je potřeba to propojit a ukázat obchodnímu týmu, který většinou nemá technický background, jak by to mohlo vypadat.

Ukazuje se, že je to velice prospěšné.

Někdy to však může i „vymstít“, pokud je wireframe špatně připraven, ale spíše platí, že vizuální prvek je extrémně důležitý. Když něco dlouho slyšíš, nemusí to být úplně tak, jak to vidíš.

Wireframe tedy znázorňuje návrh rozložení a vizuální podobu reportu a zahrnuje i požadavky, které v něm validujeme, abychom ověřili, že vše, co bylo řečeno, report opravdu obsahuje.

Často se stává, že obchodní požadavek může znít „chci tabulku“, ale ve skutečnosti není jasné, jak by měla tabulka vypadat nebo co konkrétně má obsahovat.

(Poznámka: Poslední věty ve zdrojovém textu jsou přerušené, proto je převedeny věrně v rámci možností.)

Skutečnost je taková, že se používá nějaký jiný graf, aby to bylo pro danou osobu pochopitelné a aby to splňovalo její požadavky. Jasně. Vnímám to tak, že toto cvičení může ušetřit spoustu času v dalších fázích, protože nejde jen o to klientovi ukázat hotový report a on pak řekne „jo, ale já tady chtěl jinou vizualizaci dat nebo něco podobného“. Určitě.

Velkou výhodou wireframů je, že se dělají například v nástroji Figma nebo v jiném grafickém nástroji. Když klient řekne: „Tohle tam nechci,“ tak se prostě pár sloupců či oblastí smaže a může se poskládat něco jiného. Když to děláš přímo v tom nástroji, klient tam rozhodne, že to nechce, takže už máš za sebou nějaký datový model, máš to poskládané, ale opravy nejsou tak jednoduché, jak jsem si myslela – není to jen otázka smazání malé části.

A co kromě tabulek a donut pie chartů jsou největší hříchy grafického designu reportu? Je to nějaký konkrétní typ grafu nebo struktura? Protože já si to představuji takhle, pro mě je to úplně jasné, ale zároveň je jasné, že to vůbec nemusí být jasné ostatním. Když mám k tomu takový přístup a ty už jsi viděl desítky těchto wireframů, co jsou časté věci, kterým uživatelé nerozumějí, co nemá smysl?

Nepovažuji, že by existovaly nějaké zásadně špatné grafy kromě pie chartu a donut chartu. Donut chart je přesně ten případ, za který jsem si téměř myslela, že neexistuje. Takže nemyslím si, že je špatný nějaký konkrétní graf, ale problém může být špatně zvolený graf. Je to trošku slovíčkování, ale je strašně důležitý kontext, což jsem měla i v té prezentaci, o které jsme mluvili – bez kontextu je graf buď dobře, nebo špatně složený, a taky může vypadat hezky nebo ošklivě, ale správnost a kvalita informací závisí právě na kontextu.

Často si lidé myslí, že jde jen o krásné grafy a data jsou až druhořadá. Často jsou skeptičtí vůči pěkným grafům, mají pocit, že grafy mají něco zakrýt nebo že hezký vzhled není důvěryhodný. Ale podle mého názoru je hodně důležité vybírat takové grafy, které efektivně ukazují informace, aby člověk rozuměl tomu, na co se dívá a co má s těmi daty dělat. To, že to vypadá hezky, je jen taková třešnička na dortu.

Hodně mluvíš i o tom, jak na sebe informace navazují, jestli tam není mezera mezi jednotlivými částmi, jestli je tam nějaký padding, a jestli u toho přemýšlíš z pohledu web designu nebo obecně designu. Můžeš nám říct nějaké best practices nebo zásady, které dodržuješ při skládání těch reportů? To je přeci něco, co posluchači chválili na tvé prezentaci na User Group.

Jasně, OK. Nějaké best practices, kdyby to mělo být jedno univerzální pravidlo, kterého by se měli posluchači držet, tak je to: keep it simple (udrž to jednoduché). Často všechny vizualizační nástroje, Figma, grafika a podobně lákají k tomu, že se tam snaží nacpat úplně všechno – aby to hezky vypadalo, aby tam bylo všechno, nějaké fancy grafy. Například Tableau nedávno přidalo možnost Sankey diagramů, což je super graf, ale hodně specializovaný a má úzké použití. Takže prostě keep it simple.

Před tim, než se pustíte do nějakého nástroje, je dobré začít úplně jednoduše. My jsme měli několikrát workshopy s klientem, kde jsme vyndali velký papír formátu A2, fixy a malovali to. Nesnažili jsme se klienta zahlcovat ani mu vnucovat konkrétní typ grafu.

Důležitá je pak práce s white space – tedy prostor mezi a kolem grafů. A dále je třeba nepoužívat všechno jenom proto, že to můžeme použít. Takže jednoduchost a konzistence jsou základní, pak ještě práce s hierarchií v reportu.

Záleží na typu reportu, zda je explanatory (vysvětlující) nebo exploratory (prozkoumávací). To je vždy specifické. Když jde o explanatory, snažíme se na začátek dát odpověď na základní otázky, které klient může mít, například jaké byly prodeje, jak klesly, jak si vedeme, a provozovat tam určitý level detailu, například po kategoriích.

Pak je dobré ponechat prostor na bottom-up přístup, aby si uživatel mohl sám filtrovat a objevovat vlastní insighty.

Je důležité nesnažit se měnit způsob, jakým lidé informace vnímají – například lidé na západě čtou zleva doprava a shora dolů. Viděl jsem reporty, kde byla osa Y časová osa a graf vypadal úplně jinak, což lidi může zmást a podkopat důvěryhodnost i když jsou data správná.

Super, vraťme se teď k hypotetickému ideálnímu konzultačnímu projektu. Myslím, že už dobře chápeme, co chceme postavit, jak to má vypadat, i byznys s tím souhlasí. Co se děje potom?

Je důležité říct, že role se často prolínají. Například je zásadní mít jasného vlastníka (ownera), který řekne: „OK, tohle je to pravé a jdeme dál.“ V této fázi máme hotové a odsouhlasené wireframy, pak přecházíme do fáze developmentu.

V nástroji na vizualizace či reporting začínáme pracovat s datovým modelem, který už máme zhruba připravený, a podle wireframů se report začíná vytvářet. Na back-endu mezitím probíhá práce na datových pipelinech, tedy získávání a zpracování datových zdrojů.

Výběr technického stacku kromě Tableau závisí na tom, kde data jsou a co klient používá. U některých klientů už technologický stack existuje, jinde třeba probíhá hodnocení, který nástroj je nejlepší podle požadavků klienta. U současného klienta například vyšla volba na Tableau a Kebulu, kdy Kebula se používá pro práci s mnoha datovými zdroji, které je potřeba sjednotit.

Jakmile máme vyvinutý a sestavený report, přecházíme do fáze testování – User Acceptance Testing (UAT). Při testování může dojít k tomu, že něco není podle očekávání vlastníka nebo se objeví potřeba změn.

Testování často komunikuje přímo s vývojem, někdy jde o paralelní proces. Na začátku jsou vybraní testeři, kteří report v testovacím prostředí kontrolují, zda jsou splněny všechny požadavky.

Pokud dojde k nedorozumění nebo chce vlastník něco nového přidat, může to být nepříjemné. Mohou nastat malé úpravy, například přidání jednoho sloupce nebo filtru, což zvládneme snadno a rychle. Ale může se stát, že změna je výraznější – třeba rozšíření detailu nebo přestavění datového modelu, což už je složitější a nechceme klientovi po několika měsících práce říkat: „Omlouváme se, musíme začít znovu a bude to stát další peníze“.

Takový scénář je nejhorší možný, ale většinou jde jen o menší úpravy – třeba změny vizuálu nebo barvy. Mám historii, kdy jsme hodinu diskutovali o tom, jaký odstín modré použít, protože to byl požadavek CEO.

Obecně vzniká potřeba filtrovat data, což může být jednoduchá změna, ale pokud je report složitě propojený a obsahuje kalkulace, není to vždy otázkou několika kliknutí. Proto je důležité s klientem komunikovat a vysvětlovat možnosti, nastavovat očekávání a hledat alternativní řešení.

Co se týče deployování po testování, jakmile je report otestovaný a případné změny zapracované, nasazujeme ho do produkce. My například využíváme Tableau Cloud, kde report přesuneme do složky přístupné jen definovaným osobám.

Často následuje úvodní školení nebo představení reportu širšímu týmu, protože ten, s kým jsme pracovali celou dobu, je pár lidí, ale používajících report může být třeba i 200. Je důležité vysvětlit, jak s nástrojem pracovat, protože pro nás je to jasné, ale pro nové uživatele mnohdy není.

Součástí této fáze je i dokumentace, což je široké téma. Po schválení vlastností a definování rolí je cílem konzultanta nebo externího dodavatele podpořit širší adopci reportu v celé firmě, což zajišťuje dlouhodobost spolupráce s klientem.

Můžeš nám říct, jak k tomu přistupujete a jak předáváte report celé organizaci a zapojujete další uživatele?

Klíčová je role business ownera reportu. I když to není ten, kdo report vytvořil, je to jeho „dítě“ a má zájem to firmě prodat. Aby se report používal jako zdroj pravdy – i když je to klišé, je to pravda.

Je důležité mít na palubě někoho přímo od klienta, koho ostatní poslouchají a komu věří, nebo aspoň má autoritu, a kdo říká: „Toto je dobrá věc a používejte to.“

K tomu dospíváme tím, že s týmem klienta kontinuálně pracujeme od začátku až do konce developmentu, aby viděli, co se děje a jaká je přidaná hodnota.

Dále už adaptace a adopce v celé organizační struktuře zůstává na firmě samotné.

Představte si to takhle… Naše role, respektive role mého týmu v oblasti odezev, je v podstatě technická a velmi se zapojujeme v částech přípravy, definování rozsahu, vývoje a nasazení. Ale pak už tento náš podíl klesá a jak jsem už dříve zmínila v souvislosti s křivkami zapojení, zase nasazení se znovu zvyšuje na straně klienta, a následné používání a adopce jsou jejich záležitostí. Určitě je tam potřeba velká spoluúčast klienta.

Máte u vás nějaké metriky? Například právě teď jsme vytvořili report v Tableau a sledujeme, jak moc jej uživatelé používají. Když report nepoužívají, víme, že musíme s klientem znovu začít spolupracovat a snažit se o to, aby report používali, případně zjistit, proč tak nečiní.

Možná ještě obecnější otázka: Co je vlastně vaše metrika úspěchu? Je to adopce? Protože si myslím, že toto je velmi náročná úloha — ve výsledku chcete dodat hodnotu podnikání tak, aby se začalo chovat jinak, případně aby se mu dařilo lépe, kde adopce může být dobrou praxí nebo nemusí.

To je dobrá otázka. Abych byla úplně upřímná, přímo tvrdá čísla nesledujeme. Samozřejmě monitorujeme návštěvnost reportů a v Tableau, když má někdo přiřazené licence, vidíme, že se tam vůbec nepřihlásil. Ale těžko říct, co z toho můžeme opravdu vyvodit, zda to znamená, že lidé jsou s reportem spokojení a opravdu jej používají. Takže to zatím sledujeme hlavně tímto způsobem.

Ještě k celému tomuto cyklu — jak moc je reálné ho iterovat, nebo do jaké míry jde o jednorázovou činnost? Abych to vysvětlila: Probíhá u vás vždy v rámci projektu tak, že se provede příprava, nacenění, vývoj a nasazení, po kterém už se nevracíte, nebo je možné iterovat například tím způsobem, že nejdříve dodáte jedno KPI, projdete ten celý cyklus, když je odsouhlaseno, začnete znovu a takto opakujete?

Podle mé zkušenosti se to zatím nerozpadá na takovou úroveň detailu, že bychom se bavili o jednom KPI. Určitě je to stále rámec a hodně záleží na projektu, na jakou fázi se zaměříme, která fáze je nejdůležitější, která se vynechá. Ze zkušenosti například pracujeme na reportech, které procházejí několika kvalitativními uvolněními, takže už v přípravné fázi nebo scoping fázi definujeme nějaké MVP (minimálně funkční verzi), protože reporty bývají rozsáhlé, složité, obsahují různé datové zdroje. Proto je to iterativní proces — často se vracíme mezi scopingem a vývojem, pořád probíhá několik konzultací, není to tak, že uděláme teď toto, potom tamto, ale proces probíhá paralelně a upravuje se podle potřeby.

Tedy aktuálně, když máme konkrétní report nasazený a předaný a doufáme, že jej firma bude používat, čeká nás ještě nějaké předání klientovi. Předáváte například nějakou udržovací fázi přímo klientovi? Řeknete mu: Tady máš report, tady jsou datové pipeliny, dělej tohle, aby ti to fungovalo?

Ano. Předání, tedy handover, je rozdělený na frontendovou a backendovou část a jsou velmi úzce propojené. Předáváme klientovi reporty v Tableau, samozřejmě také administrativní věci, protože někdo na straně klienta je pak vlastníkem těchto komponent a je odpovědný dál za jejich správu.

Dále předáváme byznysovou logiku, například při datovém modelování nebo složitějších kalkulacích, které jsou ideálně zdokumentované. Backend pak zahrnuje předání datových toků, skriptů a dalších komponent. Poté se postupně posouváme do fáze údržby, kde záleží na dohodě, jak moc jsme stále zapojeni my a jak moc se už o vše stará klient.

Fáze údržby obvykle zahrnuje přidávání nových pohledů, nových uživatelů reportu, případně řešení nových požadavků. Report se používá půl roku a uživatelé mohou říct, že by bylo dobré přidat další pohled, a tak se celý proces může opět rozjet. Takže člověk jde zpátky do hry.

Abych to tedy uzavřela: Ano, fáze udržování existuje a v ní je většinou zapojení našeho týmu menší, protože na straně klienta je už někdo, kdo to zvládne pokrýt a udržovat reporty v chodu.

Ještě na závěr bych se možná zeptala tak trochu na „cheap“ otázku, ale ze zkušeností, které jste získal ze všech těch projektů a fází, co je hlavní poučení, které byste chtěl sdílet? Co je klíčem k tomu, aby vše dopadlo dobře?

Myslím si, že to asi bude znít jako nějaký konzultantský klišé, kterému jsem se chtěla vyhnout, ale asi bych řekla, že je to velmi otevřená komunikace. Když se něco pokazí, je potřeba to jasně říct a hledat řešení, nesnažit se problém zamést pod koberec. Ta komunikace a zajištění, že všichni rozumíme a chápeme, co druhá strana myslí.

Veškeré problémy totiž většinou nevznikají proto, že by někdo něco špatně udělal, navrhl či vyvinul, ale spíše proto, že lidé se nepochopili.

Děkuji moc za rozhovor. Moc děkujeme za tenhle skvělý a praktický návod. Velmi oceňuji, že jsme povídání proložili konkrétními typy, co dělat a co nedělat.

A hlavně jsme to zvládli i bez Jirky, který nemusel přiběhnout z vedlejší místnosti s rukama v oplácích.

Děkujeme za pozvání a mějte se krásně.

Také nashledanou.

Nashledanou.

A to je vše. Děkujeme, že jste doposlouchali další díl Datatolku. Také děkujeme našim partnerům Bighubu, Vypnoutu, Mantě, Notinu, Atakamě, GeneBeamu, Seznamu.cz a Mews.

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

Nechť vás provází data.