Ahoj Jakube, děkuji ti, že jsi přijal pozvání pro rozhovor ve Fintree. Bude se jednat o trochu netypický rozhovor. Většina rozhovorů, které se dějí ve světě FinTechu se týká té první části Fin – tedy finanční, my se ovšem spolu podíváme na tu druhou část, za kterou se schovává většina úspěchu, tedy Tech stránku.
Jakube, mohl by si nám popsat svou cestu do Twista, tvou aktuální roli a na čem pracuješ?
Do Twista jsem přišel po zkušenostech s freelancingem, akademickou sférou (FIT ČVUT, Karlova Univerzita), po globální hráče (Atos, Deloitte, KPMG), až po roli CTO a budování startupů na zelené louce v Creative Dock. Oblasti, ve kterých jsem působil, a které mě baví, pokrývají vývoj softwaru, data mining, počítačovou bezpečnost, blockchain a také vzdělávání.
Jelikož jsem už věděl, co to znamená pracovat pro velké firmy i stavět firmu od píky, na Twistu mě lákala možnost posunout lokální úspěšný produkt pro zahraniční trhy. V tandemu s Viktorem (CTO) jsem se soustředil na škálování DEV týmu, co se technologií, procesu, struktury i head countu (tzn. počtu lidí v týmu) týče. Z 20 vývojářů jsme vyrostli k 80+ členému DEVu.
Moji aktuální roli jsme nazvali “Head of Engineering”. Soustředím se na doručování produktových iniciativ poptávaných všemi týmy v Twistu. Byť v tomto “Engineering” streamu aktuálně máme většinu týmu, mimo hiring vývojářů a managerů paralelně budujeme i silnější “Platform” stream a stream, kterému interně říkáme “Competence Lab” a zaštiťujeme pod ním týmy specializované na určitou doménu.
Zásadním milníkem pro nás teď byla akvizice ZIPem. Byli jsme doposud zvyklí navrhovat komponenty pro ~1M zákazníků. Cokoliv vyvíjíme nyní může být použito kdekoliv po světě a do našeho týmu to přináší zajímavé výzvy a příležitosti v podobě větších datových objemů a nových technologii / frameworků. “Global by default” přemýšlení můžu na jednoduchém příkladě ilustrovat tak, že když Sales tým zakládá v našem administračním rozhraní nový eshop, databázový model a různé validace (např. formát čísla účtu) musí respektovat způsob integrace e-shopu, země, ve kterých e-shop existuje, měnu atp. Obdobné ale “povyšujeme”, abstrahujeme a univerzalizujeme i složitější komponenty jako třeba náš risk engine.
Jako poslední bych vypíchnul zkutečnost, že jsme tým posílili o několik “Engineering Managers” (EM), kteří k nám buď přišli z jiných firem, nebo se do role posunuli interně. Člověk je schopen zvládnout jen určitý omezený počet direct reports, kterým se může naplno věnovat, takže mi hrozně pomáhá, když teď kluci šlapou do rozvoje oblastí, u kterých jsme se v minulosti “vymlouvali”, že na ně není čas. EMs do týmu přinášejí nové zkušenosti a dávají si záležet na tom, aby stávající i noví vývojáři v Twisto / ZIP byli spokojeni a měli možnost se profesně rozvíjet a pracovat na iniciativách, kvůli kterým to s námi táhnou.
Vývoj u vás probíhá celý tzv. in-house, nebo využíváte i externích služeb a firem?
Kombinujeme obojí. Preferujeme a dlouhodobě budujeme in-house kapacity, nicméně externí firmy nám pomáhají zvládnout rychlou expanzi. V tomto ohledu bych chtěl zároveň vyzdvihnout, že si hodně zakládáme na kultuře uvnitř týmu, takže k interním a externím vývojářům přistupujeme úplně stejně. Jsme jedna parta, všichni mají stejné slovo.
Samozřejmostí je pro nás hiring v zahraničí. Když přemýšlíme nad novým development hubem, znamená to relokaci jednoho z našich managerů a recruiting lokálního leada, kterému věnujeme maximum péče, co se onboardingu a sdílení know-how týče. Okolo tohoto (team) leada následně stavíme tým vývojářů.
Splněný sen je pak, když se člověku naskytne možnost spolupráce s již sehraným týmem. Hiring více lidí, kteří spolu už v minulosti spolupracovali, zpravidla znamená skvělé delivery od prvního dne.
Alfou a omegou pro každý FinTech je DEV tým. Daří se vám v dnešní době nedostatku specialistů onboarding developerů?
Velikost DEV týmu jsme v minulosti vždy interně mohli poměřovat snad leda s Customer Care, takže na sebe musíme mít vysoké požadavky i co se managementu a procesů týče.
Aktuálně máme tým rozdělený do “delivery teams”, což je tandem product ownera, technického team leada a party vývojářů, kteří end-to-end doručují iniciativy z určité specializované oblasti našeho produktu a starají se o dlouhodobý provoz a údržbu souvisejících komponent. Naše struktura je asi nejvíce podobná Spotify modelu.
Onboarding i při masivním hiringu zatím zvládáme, ale hlavně díky super lidem. Jsme si nicméně moc dobře vědomi, že pro další škálování se zase musíme posunout o krok dál. Chtěli bychom podpořit větší standardizaci, sdílení znalostí a častější rotaci vývojářů mezi jednotlivými týmy. V neposlední řadě se pak budeme soustředit i na interní komunikaci ke stávajícímu týmu. Například co se v poslední době změnilo a na čem se aktuálně dělá v různých oblastech. Už dávno neplatí, že kamarádi, kteří jsou s námi dlouho, vědí pořád všechno. Když se nedávno jeden z našich nejvíce seniorních vývojářů šel mrknout na planning DevOps týmu, zíral, kam se věci posunuly od našeho posledního all-hands.
Daří se společnosti velikosti Twista zachovat startupovou kulturu? Máte nějaké kariérní žebříčky, případnou byrokracii?
Osobně si myslím, že existují dva extrémy – korporát a chaos. Při zavádění nového procesu je potřeba hlavně dobře vědět, jak zefektivňuje práci (např. řízení očekávání, vnesení určité míry předvídatelnosti a klidu do plánování bez neustálých změn priorit). Dále je potřeba se ujistit, že opravdu šetří čas (dělá věci efektivnější), případně vědět, kdo je hlavní stakeholder (např. procesy, které je třeba dodržovat kvůli regulacím a legislativě).
Buď můžu vzít nějakou metodologii typu SCRUM (obdobně i obecnější záležitosti typu OKRs) a nechat pracovat Darwina, kdy nakonec zůstanou jen ty praktiky, které se osvědčily. Nebo můžu procesy budovat “from the ground up”, kdy se sice často vynalézá kolo (obzvláště pokud člověk už podobný problém a jeho řešení zažil), což ale není nutně na škodu. Když se participuji na vytváření procesu, mnohem raději si ho vezmu za svůj.
Tento přístup v Twistu přirovnáváme k situaci, kdy si mezi sebou dvě strany vytvoří API, specifikují required inputs a outputs, přičemž je pak, skrze diskuzi, možné proces osekat na nezbytné minimum, jelikož se challenguji i věci, které by jinak byly považované za samozřejmost. Byť je součástí návrhu třeba nějaká neefektivita jen z důvodu, že na to takhle někdo byl zvyklý z předchozí práce, ale pro naše podmínky to není vhodné..
Aby firma “nezkostnatěla”, je hrozně důležitě si nad procesy zachovat nadhled a průběžně vyhodnocovat (včetně sbírání feedbacku) – co stále funguje / co chceme zachovat, a co už přestalo dávat smysl. Korporát podle mě začíná tam, kde lidi přestali rozumět tomu, proč nějaké pravidlo / “byrokracie” existuje, případně jim připadá brutálně neefektivni a nemohou s tím nic dělat. Procesní overhead je zároveň dobré řešit automatizací.
Poslední důležitý bod, který chci zmínit je transparentnost a neustálé vysvětlování / připomínání, na které jsem už narážel. Ptal jsi se konkrétně na career ladders. Ty v Engineering týmu máme a vycházejí z engineeringladders.com. Podporují nás ve férovém ohodnocování stávajícího týmu i nováčků (tzn. nastavování spravedlivých podmínek) a definují jaká očekávání má zbytek týmu od určité úrovně seniority – tzn. nejen očekávání na delivery daného vývojáře ve vztahu k odměně, ale i jak konkrétně člověka podpořit v jeho preferované kariérní dráze, aby se posunul na další level, ať už se jedná o ryze technickou cestu, nebo přibírání people management zodpovědnosti. Kariérní žebříčky nám zrychlují hiring, profesní růst členů týmu a zároveň nenechávají nikoho v nejistotě.
Líbí se mi, že když i názvy pozic a velikost mzdy diskutujeme společně s team leads, není vnímání negativní, ale naopak nám to všem umožňuje se bavit velmi věcně a na rovinu. Když se někdo chce stát součástí týmu, dáváme při hiringu po úvodním seznamovacím a technickém kole stejně otevřený feedback, pokud nám finanční ohodnocení kandidáta připadá příliš vysoké, ve vztahu ke zbytku týmu, stejně tak když se někdo podhodnotí a jsme přesvědčeni, že jeho seniorita je vyšší.
Nyní bych se možná zaměřil více na procesy vývoje. Sám to vidím u nás – je deset lidí a deset nápadů na vylepšení. Jak děláte takovou prioritizaci nových features?
Každé nové poptávce po kapacitách Product a DEV týmu říkáme u nás “iniciativa”. Může s ní přijít kdokoliv ve firmě. Na novou iniciativu existuje template, vč. pravidel pro prioritizaci, a zdokumentovaný E2E delivery proces od ideace, přes implementaci, až po dlouhodobou údržbu a ownership za ní.
K věcné stránce obsahu přidáváme v Twistu velmi jednoduchý business case a gut-feeling odhad na technickou komplexitu. Žádné obří XLS / Google Sheets soubory, ale promítnutí iniciativy do klíčových metrik typu GMV, MAU, u back-office záležitosti, automatizaci a NFRs například ušetřené FTEs, čas vývojáře strávený na údržbě chybové komponenty atp. (S konzultací velmi rád pomůže Finance team, Data team, Product, nebo DEV, podle typu iniciativy a potřebných vstupů.) Abychom nápady snáze seřadili s ohledem na cenu / výkon, snažíme se často vstupy shlukovat do nějaké jedné čitelné metriky typu ROI. Třeba Pavel, náš Head of Product, teď nově používá Prioritization score. Máme tak jedno číslo a detail uchováváme pro demonstraci toho, jak se ke konkrétní hodnotě došlo a jaké jsou trade-offs.
Než iniciativa dostane prioritu, nechceme popisem a analýzou strávit více než je nezbytné pro porovnání s ostatními úkoly v „krabičce nápadů“, kterých je přirozeně vždycky více než dostupných kapacit. (Což je tak správně, znamená to, že všichni Twisters / Zipsters neustále přemýšlí o zlepšeních pro zákazníky i interní či back office záležitosti.) Máme seřazený seznam, známe kapacity všech týmů – i s ohledem na údržbu, NFRs a mid/small-sized tasky, které si řeší každý tým sám, kde nepotřebujeme dělat strategická rozhodnutí v širší skupině jako u velkých a finančně náročných iniciativ. Pak už je jen potřeba někde udělat čáru a pravidelně aktualizovat roadmap s detailní viditelností na měsíc a větší dynamikou čím dále jdeme do budoucna.
Jak řešíte roadmap a její plnění? Jak zasahuje do tvé práce?
Ownerem roadmap je Product. DEV team je odpovědný za plánování kapacit, tzn., že „nabídneme“ na produktové iniciativy jen takovou utilizaci, abychom sebevědomě mohli prohlásit, že nezanedbáváme „zdraví“ naši codebase. Nic samozřejmě není 100% růžové. Pokud ale někde začne vznikat výrazný technický dluh, je to vizitka horšího plánování a diskuze uvnitř našeho týmu. V této oblasti jsme stakeholders my jako DEV. V Twistu netvoříme umělé deadlines a všechny ostatní týmy si uvědomují, co to z dlouhodobějšího hlediska znamená za sebou nechávat nepořádek.
Rád bych ještě zmínil, že se mi hrozně líbí trend, že když jednotlivé DEV týmy znají své cíle a KPIs, začínají často proces „obracet“ a samostatně přicházet s iniciativami, pomocí kterých jich dosáhnout. Jestli to dotáhneme tak daleko, že tímto způsobem budeme fungovat ve většině případů (jsme na dobré cestě), sednu si s doutníkem a whiskey do houpacího křesla u krbu a budu se kochat, jak nám na dashboardu rostou klíčové metriky.
Photo by Alvaro Reyes on Unsplash
Přijde mi, že se klade velký tlak, aby FinTech vydával nějakou novinku každou chvíli. Například Revolut to tak má. Nevzniká potom technický dluh na “starém” kódu? Případně jak to máte v Twistu?
Určitě. Technický dluh může být taktické i strategické rozhodnutí. Být dříve na trhu, to, že obecně umíme launchovat MVPs, je naše konkurenční výhoda a možnost sbírat rychle zákaznický feedback. Technický dluh stejně tak vzniká s časem a s růstem firmy / produktu. Vzpomeňme si na příklad se zakládáním nového eshopu v našem administračním rozhraní. Když někdo ze Sales teamu zakládal eshop těsně po oznámení našeho záměru se ZIP, uvědomoval si, že dosavadní řešení s validaci jednotlivých údajů typu číslo bankovního účtu pouze pro Česko a Polsko bylo dlouhou dobu naprosto vyhovující. Bylo by teď špatně křičet, že to někdo tehdy při launchi Twista nedomyslel s validacemi pro celý svět. To je nový požadavek, který by se v minulosti mohl jevit jako overegineering.
Důležité jsou dvě věci:
1. Jestli průběžně refaktorujeme a dluh odbavujeme. (Refaktorovat lze donekonečna, kód stárne a vznikají na něj nové požadavky. Je to o tom mít proces podchycený.)
2. Velikost dluhu zároveň reflektuje, jak dobře onboardujeme a informujeme nové i stávající vývojáře, aby komponenty stavěli vypiplané podle našich aktuálních best practice. (Tzn. neprohlubovat něco, na co už máme aktuálnější či vyšší požadavky.)
Byť všechno rozhodně není rainbows and unicorns, jedeme raketovým tempem a máme spoustu oblastí, na kterých musíme zamakat, jsem neskutečně hrdý na to, jak jsem naznačoval před chvíli, že NFRs jsou nyní součástí běžného slovníku mimo DEV tým. Není tomu tak dlouho, co jsem sdílel citát “Stop thinking about your software as a project. Start thinking about it as a house you will live in for a long time.” Když Michal (CEO), nebo Renča (CCO) na našich meetings nově zmiňují, jak po release nemáme zapomenout na post-MVP development, automatizaci back office procesů, vyčlenění kapacit na údržbu atp., skoro mám tendenci uronit slzu, jak v Twistu všichni táhneme za jeden provaz.
Další věc je dokumentace. S čím aktuálně zápasíme je centralizace a údržba všech zdrojů pravdy. Často se nám užitečné dokumenty „válí“ různě na Google Drive, GitHubu, nebo dokonce někde v postu na Slacku. Snažíme se to řešit linkováním všech zdrojů na interní Wiki, ale nejsme ještě v situaci, že by se to dělo „přirozeně“, včetně aktualizace stávající dokumentace. Krom možnosti full-text prohledávání více míst najednou přemýšlíme i nad co největší automatizací tohoto procesu. Nemůžu všechno přečíst a zapamatovat si detail, ale když je pro mě část dokumentace v daný moment relevantní, případně zasahuju do komponent, které s ní souvisejí, něco by mě mělo pingnout a na tuto skutečnost upozornit.
Poslední, co bych rád zmínil je, že jsme ve fázi, kdy už nemůžeme funkcionality jenom přidávat, ale i se zamyslet, jestli něco nechceme odebrat, resp. to už nelaunchovat na novém trhu. Jak jsme se bavili před chvílí, každá feature stojí nejen vývoj, ale i údržbu. Při evaluaci nám mega pomáhá Data / BI team. Jelikož se teď více soustředíme na expanzi a rozšíření stávajících služeb, motivuje nás to přirozeně platformu více „zocelit“ a zacílit.
Více v části 2 🙂
Autor