Dejte lidem data a nechte je tvořit

 … aneb jak v Liftagu dělá BI 2/3 firmy.

V Liftagu aktuálně hledáme třetího BI specialistu. Přitom pár měsíců dozadu BI v Liftagu prakticky neexistovalo. Možná někoho zaujme, nebo třeba i inspiruje, příběh tohoto boostu.

Známá poučka říká, že bychom lidem neměli dávat ryby, ale raděj je naučit ryby chytat. Naše myšlenka byla taková, že místo statických dat či reportů, bychom mohli lidem dát hřiště na hraní.

V mladých firmách je autonomnost a schopnost rozhodování naprosto zásadní aspekt úspěchu. Neustále totiž hledáte nový směr. Podpůrnou roli v průkopničení hrají data.

Reporting

V Liftagu používáme Tableau. Každé ráno v něm naši datoví nadšenci najdou počet jízd za předchozí den, konverzi, nové pasažéry a všechny vymazlené metriky, které jsme za ta léta vyrobili. Prostě reporting.

Dlouho jsme si tak vystačili s následujícím stackem:

Primární data - Mongo, MySQL -> processing tool -> visu tool

V jistou chvíli nás ale začaly limitovat umělé hranice, které jsme si do celého flow zakomponovali. To bude předmětem tohoto článku.

Liftago není jen appka, ve skutečnosti je v engineeringu jen jedna třetina celé firmy. Zbytek zajišťuje řidiče, pasažéry, business klienty. S oblibou kandidátům říkám, že je to end-to-end business. Naprogramovat věci není lehké, ale často je složitější věci vymyslet a vyladit.

Naše kultura je taková, že chceme, aby na našem produktu participoval každý. Nápadů máme plný backlog již léta, prioritizace je často oříškem. Představte si, že jako zběhlý engineer máte podezření, že vás napadla krásná nová featura. Ověřit si ideu v datech je základ, protože nechcete mít prázdné ruce, ale naopak držet argumenty.

Klasický přístup ověření spočívá v kontaktování BI týmu, aby vám začal do Tableau počítat novou meriku či vytvořil nějaký board, jenž by vám pomohl s argumentací. To často narazí na dva problémy:

• BI je typicky zahlcené mnoha prioritami, které měly být již včera hotové
• protože vy jste owner nápadu, nikdo vám moc nevěří a tak v tom často nevidí prioritu

A tak celý nápad putuje do backlogu.

Ohh wait. A co kdybyste si ty metriky do Tableau vyrobili sami?
To by zkrátilo cyklus od nápadu k realizaci na minimum.
No dobře, pojďme se podívat, co by to obnášelo, a jak by to bylo složité.

Bariéry a kameny úrazu

Celý tenhle příběh bariér jsme si začali uvědomovat dva roky dozadu, kdy jsme měli GoodData, náš předchůdce Tableau. Je to jistě skvělý kus softwaru. Bohužel postavený nad svým vlastním vnitřním modelem. Ten model zajišťuje hladší práci při visualizaci.

Jenže tenhle doménově-datový model přidává další vrstvu složitosti. Implementují vám ho lidé z GoodData. Jeho změnu určitě dokážete udělat i vy, ale je to velmi složité. Naprosto to odporuje potřebě startupu a rychlých změn nad daty. Nakonec to byl hlavní důvod proč zavedené věci měnit.

Muset kvůli změně struktury dat volat konzultanty jsme si nemohli dovolit.

Nově použité Tableau sice žádný doménový model nemá, ale instalovat si pro změny v reportech speciální desktopovou aplikaci, není také žádná hitparáda. V době SaaS aplikací? Kor když chcete dělat jednoduché věci. Časem šly určité změny dělat i na webu, ale přirozená křivka odporu byla již tehdy veliká.

To je první velká bariera. Ikdyž byste tohle překonali, nemáte vyhráno.

V dalším kroku potřebujete přesvědčit Keboolu, abyste do té visualizační tooly ty data dostali. Keboolu máme všichni rádi. Zjednodušuje věci.

Jenže když požádáte vašeho BI kolegu, aby vám ukázal váš graf transformací, zaručuju vám, že vás ten obrázek k smrti vyděsí. Jako děti čert. Já si na ten moment přesně vzpomínám. Ztratil jsem všechny iluze, že tu změnu dokážu udělat já sám v krátkém čase.

Naštěstí tenhle problém není neřešitelný. Věci je potřeba refaktorovat. Ať je to kód nebo transformace. Nicméně vrásky na čele vám to přidá.

Poslední kámen úrazu na vás čeká ve vašich datech — primárním zdroji dat. S ním nechcete dělat vůbec nic, pouze mu dobře porozumět. V případě monga je skrytá komplexita jinde než byste čekali. Mongo nevyžaduje z principu žádné pevné schéma, takže set fieldů vašich entit se historicky vesele měnil. Vytáhnout vše najednou je nemožné. Proto musíte reinkarnovat vývojáře, kteří na tom historicky pracovali, a zjistit jak se věci měly. Potom se vám podaří vytáhnout všechno.

A teď si představte, že nejste engineer, ale méně technicky zdatný člověk. Máme jich 2/3 firmy. Ten nemá vůbec žádnou šanci něco změnit, něco ověřit.

Hledali jsme cestu jak z toho ven.

MapD z pytle ven!

Byly časy, jasně si na ně vzpomínám, kdy jsem se snažil prorazit výše uvedenou cestu. Měli jsme už Snowflake. Ten splňuje vše co žádám: velmi snadno dosáhnete svého. V té době jsem si v zoufalství stavěl reporting nad Snowflakem tak, že jsem agregovaná data tahal do excelu a tam si dělal grafy. Šlo to totiž udělat velmi rychle.

Jednoho dne ale přišel náš kolega, říkejme mu třeba Tibor, s localhost instancí nástroje MapD. Teď se jmenuje OmniSci.

Tenhle moment způsobil datovou revoluci v Liftagu.

MapD totiž umožňovalo naprosto zásadní pokrok. Prerekvizitou pro něj byl jen jeden krok:

Nic víc nepotřebujete. V MapD totiž umí něco skvělého.

Za real-time si visuelně nad těmi všemi daty vytváříte vlastní reporty. Přidáváte grafy, pie, histogramy. Počítáte metriky SQLkem. Visualizace je radost.

A teď si představte, že výsledky vaši hypotéz vidíte instantně teď hned!

Měli jste nápad? Sem s ním. Chcete vědět, co se dělo včera ve večerní špičce?

Vezměte si histogram požadavků, omezte si ho na včerejší čas. Máte podezření, že bylo v ostravském centru málo řidičů? Naklikejte si jejich počet do grafu vedle. Jaká byla struktura jejich chování? Hodtě si vedle pie chart.

Měli jste podezření? Za deset minut máte jasno. Visuelně.

Je to dobrý, jo?

Je to skvělý!

• Během pár minut víte výsledek, sami
• Vše děláte visuelně, takže nepotřebujete umět programovat — zvládnou to i ty 2/3 firmy
• MapD zvládá miliony řádků, takže neřešíte performance, indexy atp.
• V grafech můžete, ale nemusíte, přidávat SQL — je to vhodné i pro složitější věci

V MapD si doteď v Liftagu naklikalo report už hodně lidí. Od té doby slyším po kuchyňkách, ne-engineeringových kanclech a často i hospodách, lidi mluvit jak věci řeší a hledají v datech. Že chtějí příští sprint něco vyrobit, protože data.

Předtím jsme si říkali, jak chceme být data driven. Opravdový přístup k datům mělo jen pár nadšenců. Teď ho mají všichni. Teď konečně fungujeme data-driven.

Protože jsem se dost rozepsal, v navazujícím článku ukážu jak přesně to děláme.