„Procesy ve vývoji jsou důležité. A teď se nebavím jen o tom, že někdo řekne, že dělá SCRUM. Ten je tak obecný, že jeho aplikace je v každé firmě jiná a skoro v každé špatně. Mluvím o procesech, které začínají už od pre-sales, přes definici, validaci, sledování, performance, design, produkt, testing atd. Jen tak lze zaručit bezvadný produkt.“
Procesy. Slovo, díky kterému spoustě lidí naskakují pupínky. Jenže bez nich to jde jen chvilku. Takzvaně na punk. Jakmile ale firma vyroste, bez procesů už je punk spíš prostý chaos. A rovnat procesy v tuhle chvíli už většinou dost bolí.
Jsou mezi námi ale i tací, kteří mají procesy poladěné ještě před tím, než mají první zákazníky. I to je extrém. Tady se ale vyplatil. Dnes se u Martina Stojky v Jimmy Technologies spousta zákazníků učí, jak má firma procesy implementovat a vzájemně provazovat. Proto jsem si Martina pozval k mikrofonu, abych ho vyzpovídal a zjistil …
🔸Proč jsou procesy ve firmě důležité? A kde začínají?
🔸Jak funguje synchronizace mezi obchodem a delivery?
🔸Jak smysluplně provázat procesy napříč firmou?
🔸Jaké výhody přináší jasně definovaná specializace?
🔸Kdo je Inženýr 2.0?
Na procesu Martin připravil i bonus " Co bych dělal, pokud bych převzal vývojářské studio". Stáhnout si jej můžete níže.
BONUS: CO BYCH DĚLAL, POKUD BYCH PŘEVZAL VÝVOJÁŘSKÉ STUDIO (Kód bonusu: CBDBPS )
JAKÉ VÝHODY PŘINÁŠÍ JASNĚ DEFINOVANÁ SPECIALIZACE (PŘEPIS ROZHOVORU)
Martin Hurych
Dobrý den. Já jsem Martin Hurych a tohle je Zážeh. Dnešní Zážeh bude o plánování výroby v IT agentuře a dotkneme se umělé inteligence v programování. Pokud nám vystačí čas a neutečeme někam jinam, tak se podíváme i na to, jaké výhody pro softwarovou agenturu má specializovat se na několik málo výklenků trhu. Celé to budu probírat s Martinem Stojkou. Ahoj, Martine.
Martin Stojka
Ahoj, Martine.
Koho naposledy zastřelil a proč?
Martin Hurych
Martin je co-founderem společnosti Jimmy Technologies. Když jsem se na tebe připravoval, tak jsem zjistil, že střílíš, že si velmi pravděpodobně chodíš vyčistit hlavu na střelnici. Koho jsi naposledy virtuálně zastřelil? S kým sis vyřídil účty?
Martin Stojka
To by mě zajímalo, jak jsi to zjistil, protože to úplně navenek neříkám. Já nestřílím, že bych si někoho představoval, to si myslím, že bych ten zbroják ani nedostal, kdyby to tak bylo. Je to ale super stress relief, to musím uznat.
Martin Hurych
Naposledy na tom terči tedy nebyl nějaký nespokojený zákazník, se kterým sis to chtěl vyřídit?
Martin Stojka
Šel jsem kvůli nějakým nespokojenostem, nebo nějakým více stresovým situacím z práce, ale že bych si tam někoho představoval, to opravdu ne.
Jaká byla jeho cesta k Jimmy Technologies?
Martin Hurych
Já tady vždy prosím hosty, aby v rámci představení ukázali i svoji zkrácenou životní pouť, protože se mi ukazuje, že ta životní pouť potom vysvětluje úhly pohledu, které tady budeme probírat. Můžeš mi tedy říct, jak jsi se dostal k Jimmy Technologies?
Martin Stojka
Celý můj profesní život hodně ovlivnilo to, že jsem od nějakých 5 do 19 hrál profesionálně hokej. V podstatě jsem byl zvyklý od nějakých 5, 6 vstávat v 6 ráno, několikrát dříve, v pozdějším věku trénovat dvakrát denně a mít dvakrát týdně zápas. To mě naučilo nějaké disciplíně, týmovému duchu a hlavně nesnáším porážky, takže vítězné náladě.
Na hokeji jsem potkal i svého prvního co-foundera, se kterým jsme se rozhodli, že po maturitě nepůjdeme na výšku. O svaťáku jsme místo učení navrhli a částečně naprogramovali naši aplikaci. Od té doby jsme prvně přeskočili takovou tu ságu toho, že někde člověk pracuje a učí se, protože jsme se rovnou vrhli do podnikání. To bylo na jednu stranu dobře, na jednu stranu špatně, protože jsme byli nezkušení, ale hodně jsme se tím naučili. Potom jsem udělal krok zpátky, kdy jsem šel do vývojářské agentury, tam jsem dělal projekťáka a nasbíral jsem ty zkušenosti, které mi v tom našem vlastním startupu chyběly. Zároveň jsem tam byl schopný už přinést zkušenosti z toho byznysu a pomoci klientům s nějakými věcmi. Potom jsem šel dělat konzultanta do Škodovky, Volkswagen Group, a tam jsem potkal své další co-foundery a založili jsme Jimmy Technologies.
Je lepší před založením vlastního startupu vyrazit do světa?
Martin Hurych
Podle tebe je tedy lepší, aby Honza alias Martin vyrazil do světa předtím, než začne podnikat?
Martin Stojka
Já bych to neměnil, ale když se takhle s někým bavím, kdo je na výšce a přemýšlí, co by dělal, tak vždy říkám, že je dobré si něčím projít. Díky tomu, že jsem si prošel menší firmou, vlastním startupem a pak korporátem, jsem viděl, jak to v těch firmách funguje, jak tam fungují a nefungují procesy a to jsem si potom vzal s sebou a aplikoval to ve svém byznysu. Samozřejmě to člověk musí přizpůsobovat tomu, jak ten byznys se rozvíjí. Také jsem tam například viděl, jaký šéf nechci být.
Proč jsou procesy ve firmě důležité? A kde začínají?
Martin Hurych
Asi tuším, odkud vítr fouká, protože jak jsem zmiňoval na začátku, my se dnes budeme bavit o procesech, já tomu dám takové malé pozadí. Už jsme se tady párkrát v Zážehu bavili o tom, jak naplánovat výrobu, nebo delivery softwarového studia. Vím o tobě, že jste hodně v Jimmy Technologies pyšní na to, jak máte nastavené procesy a protože se neznáme krátce, už se nějakou dobu známe, tak vím, že to oceňují i klienti. Jestli dovolíš, tak bych se rád podíval na procesy a co to vlastně znamená, protože před natáčením jsme se bavili, že pro tebe důležitost procesů není jen v samotné firmě během delivery, ale že to začíná mnohem dříve. Můžeš to nějakým způsobem objasnit?
Martin Stojka
My jsme si doopravdy od začátku na těch procesech zakládali. My jsme měli procesy dříve, než jsme měli klienty a je to přesně to, kam se dostáváme, že ten proces už začíná v nějakém salesu, nebo presalesu. Já jsem zažil ve firmách i u klientů v agenturách, že přišel obchodník, bavil se s klientem, ten měl nějakou potřebu, nějakou znalost, ale spíše neznalost toho, co chce postavit. Obchodník samozřejmě chce uzavřít ten deal, což je super, bez dealů by ty firmy nejely, problém je ale ve špatně nastaveném očekávání. To, že slíbí klientovi, že se něco dodá v určitém čase za určité peníze, v určité kvalitě, nebo třeba i určité požadavky, které nejsou realistické, je špatně. Bez nějakého consultingu s tím delivery týmem se podepíše deal, ten obchodník potom pyšně přijde za tím týmem, takhle jim to předá, ti na to kouknou a řeknou, že to nedají. V ten moment ten projekt ještě ani nezačal a ten tým už jede v nějakém krizovém módu, kdy oni musí doručit buď čas, nebo něco nereálného. Teď je samozřejmě možnost se pobavit s tím klientem, že to není možné, ale to většina firem neudělá, protože se ještě ani nezačalo a už bychom klientovi říkali, že to nejde, když jsme mu to slíbili. Už tedy dochází ke kompromisům v kvalitě, kvalitě lidí či velikosti týmu.
Když do toho potom ještě nejsou žádné procesy té delivery, tak je to průser. To se nebavíme jenom o agenturách, to se můžeme bavit i o firmách, které mají vlastní produkt, které to delivery nemají podchycené. Tady je obrovské neporozumění většiny lidí, že nestačí si najmout čtyři vývojáře a dát jim práci a práce bude hotová. To by ti kluci museli být skvělí, že by se mezi sebou měli bavit, jeden by to vzal na sebe, nastavil architekturu a hlídal to. Tam musí být nastavený nějaký proces, nějaká infrastruktura toho projektu. Teď nemyslím infrastrukturu serverů, ale nějaké procesové automatizace, kontrolu kvality a tak dále.
Začíná to tedy tím salesem, kdy třeba u nás primárně děláme sales my jako co-foundeři. Máme nějakou salesovou pipeline a v ní už mám to, že ve druhém a třetím kroku vytáhnu klientova CTO, technického člověka. Pokud není, nevadí, stejně do toho zatahuji našeho CTO, nebo solution architecta, který se na to podívá z toho technického hlediska, získá ty technické požadavky, ale má i přehled o těch produktových. Častokrát ty produktové nejsou vůbec jasné. Většina projektů je agilních, time and material, na začátku je nápad, jak to vypadá na konci, ten core je možná stejný, ale je to trošku jiné. To pomůže dát více přehled o tom, co se děje.
My jsme třeba zjistili před tři čtvrtě rokem, že já musím zahrnout i design. Předtím jsem design úplně nezahrnul a přesně jsme se dostávali do toho, že 20 % bude design a 30 % projekťák. Tak to ale vůbec není, každý projekt je jiný, každý klient je jiný, potřebuje něco jiného, takže já zahrnuji CTO, solution architecta, designéra, teď zahrnujeme product ownery, aby jen třeba dali nějaké produktové věci.
Potom si sedneme, pořádně to zanalyzujeme, nastavíme správná očekávání nějakými odhady a ty odhady se potom přesně už předávají tomu týmu. Máme nějaký proces na to, jak ten tým postavit, samozřejmě záleží, jaké lidi ta firma má, seniory, mediory, juniory, jak postaví ten tým. My konkrétně máme vyloženě framework, který je postavený na scrumu, kde máme vydefinované i detailně některé věci, které máme dělat. Ten tým už potom ví, v jakém procesu bude fungovat, jak bude spolupracovat s klientem, jak bude spolupracovat s product ownerem, s designérem, se solution architektem. Nemusejí se učit žádný nový proces a mohou okamžitě vytvářet tu value pro toho klienta.
Potom na to jsou samozřejmě navázané různé procesní věci, hlídání kvality, jestli nám nehnijí tasky v Jiře, protože více jak dva dny in progress je špatně. To buď znamená, že ten tým to podstřelil, protože ten task by měl být ideálně za jeden, dva dny hotový, nebo tam je nějaký problém. Teď záleží, jestli se ozval ten člověk, že má problém, neozval, nebo čeká, než mu někdo pomůže. Potom jsou třeba pull requesty, chceme, aby se ihned dělalo cold review, schvalovaly se, aby ten kód nehnil, hned se to posílá automaticky na staging a může se to testovat. Klient se na to může kouknout, sledují se různé code smelly, máme Data Studio, kde sledujeme performance toho týmu. Někdo říká, že je špatně sledovat performance jednotlivce, ale pokud já chci poskytovat skvělou službu, tu klientovi slíbím a chci ji zaručit, tak musím koukat na to, že mi ten celý řetězec funguje dobře. Já jsem díky tomu schopný i zjistit, že ten tým odhadl na tuhle user storku 5 story pointů. Většinou se neodhaduje v časech, že něco zabere dva dny, ale odhaduje se to v nějakých story pointech, které reflektují nějakou komplexnost. My víme z minulých sprintů, že 5 story pointů nám zabere jeden a půl dne a najednou vidím, že tato user storka zabrala 5 dní. Už se na to koukáme, product owners, solution architect, delivery managers se na to koukají, co se stalo. Můžeme si z toho vzít nějaké lessons learned, tady jsme to podstřelili a takto můžeme průběžně zlepšovat i ten proces.
Na základě toho to máme celé postavené, ale nad tím je postavená nějaká transparentnost, kdy ten klient do toho vidí. On chodí na ty ceremonie s námi, je v kontaktu s tím týmem, máme společný Slack a toho si ti lidé hodně váží. Dokáží se toho od nás hodně naučit v rámci toho procesu, protože málo firem má doopravdy takto vyladěný delivery proces. Teď jsme třeba stavěli velikou platformu pro klienta a ten přišel a řekl, že se toho spoustu naučili. Je to jen kvůli tomu, že to máme nastavené, ale zároveň ho do toho pustíme. Naše filozofie je, že nedokážeš postavit dobrý produkt bez zapojení byznysu. Takové to, že ti klient předá požadavky, ty zavřeš dveře, něco si kutíš, za tři měsíce to otevřeš, takhle mu to předáš a on na to čumí a říká, že tak to přesně nechtěl. Tomu chceme předejít. My plánujeme s klientem sprint, během toho sprintu on vidí, má přístup do task managementu, mají přístupy do kódu, což se nám jednou i nevyplatilo. Klient nám totiž nezaplatil a ten kód si stáhnul, protože tam nebylo nějaké ošetření od GitHubu, aby si to nemohl stáhnout. Pokud je ten klient ale normální, tak ocení tu transparentnost. My něco naplánujeme, za 14 dní mu dáme demo, na konci sprintu to musíme doručit, ukážeme to tomu klientovi a ten klient vidí, co s tím týmem naplánoval a do čeho investoval peníze a může ihned zareagovat. Najednou dokážeš postavit super produkt, takže ten proces není jen na to, abychom byli schopní něco doručit, ale je to na to, abychom doopravdy s tím klientem postavili hodnotný produkt. Takhle to máme postavené a zatím nám to funguje.
Samozřejmě ta transparentnost se nevyplatí v momentě, kdy máš klienta, který si toho neváží. Během toho procesu se vždy objeví nějaké chyby a tím, že on do toho má přístup, tak je vidí. Když chce, tak toho může využít a přijít s tím, že za to platit nebude. Když je ale normální, tak zjistí, že to celé mu přináší mnohem větší hodnotu. To, že se stala nějaká chyba, stala se, pobaví se s námi o tom na nějaké retrospektivě, řekne svůj názor, my k tomu něco řekneme, ale jedeme dál, protože on ví, že to funguje. Takhle to máme nastavené a pak samozřejmě ti do toho musí zapadat ti lidé, které máš v tom týmu.
Jak procesy přináší benefity do podnikání?
Martin Hurych
Ty jsi na začátku říkal, že jsi měl procesy vyladěné dříve, než jsi měl klienty. Já spíše vidím v IT takovou tu nesprávnou agilitu, že i interně se ženeme do něčeho, co ještě sami nevíme, co bude. Co ti to tedy přináší za výhody podle tebe mít takto vyladěné procesy? Proč bych já měl po tomto podcastu možná trochu zpytovat svědomí a říct si, že v tom mám chaos, že se do věcí pouštím moc rychle a možná si ty problémy s plánováním do značné míry vytvářím sám? Co s tím?
Martin Stojka
Záleží, jaký je tvůj cíl a vize té firmy. Pokud máš firmu a jde ti jen o to získat klienta, něco doručit a dostat paycheck, tak jsi asi v pohodě a nemusíš se starat o kvalitu. Pokud chceš ale doručit řešení, kdy ten klient z toho fakt bude nadšený a pokud nechceš být ve stresu v rámci toho delivery, tak ti v tom procesy pomohou. Samozřejmě i my jsme ve stresu, já jsem také kolikrát ve stresu, když vidím, že spadla velocita sprintu oproti jinému. Za 3,5 roku, co máme firmu, jsme se však jenom dvakrát museli zeptat kluků, jestli mohou dělat přesčasy. V minulých firmách to bylo naprosto běžné a vím, že to je naprosto běžné v jiných firmách. Ty procesy ti přesně pomohou k tomu, že jsi schopný doručit kvalitu a hodnotu, prostě hodnotný produkt.
Co mě vždy strašně trápilo v IT, je jedna věc, že to není hmatatelné. Postavíš aplikaci a za 5 let nefunguje. Když tady postavím barák, bude stát dlouho a mám z toho skvělý pocit. Nejvíce mě ale štvalo, že my jsme na něčem tři čtvrtě roku s týmem dělali a za půl roku ten produkt byl nepoužitelný. Ať už to bylo z toho, že ta firma to napsala špatně, nebo ten byznys prostě krachnul na tom, že dal většinu peněz do IT. My chceme stavět produkty, které tady jsou dlouhodobě, dávají smysl a mají nějakou hodnotu pro ten byznys a pro ty uživatele, co to používají.
K tomu musíš mít postavené procesy. To není tak, že si řekneš, že jsme získali deal, dáme na to čtyři lidi, projekťák si nastaví ten proces a oni to budou doručovat. Jeden z hnacích motorů, proč jsme založili firmu, bylo to, že jsme jako klienti měli problém s dodavateli. Říkali jsme si, že to přece jde dělat jinak a navíc jsme našli nový byznys model toho, že jsme full remote. Byla tam věc, kdy jsme se bavili s jedním známým ze Švédska, který měl hodně velikou outsourcingovou IT firmu, ze které se pak překlopili do SAPu, ale on ji prodal za veliké peníze. On říkal, že nad tím vždy musíš mít nějakého delivery managera. Ten projekťák ti to bude řídit on daily basis, ale ty tam potřebuješ mít zástupce toho tvého byznysu a to, jestli to, co jsi podepsal s tím klientem, se dodržuje a jak to jde. Kolikrát víme, že v těch firmách ti projekťáci jsou ještě juniorní, na nich se šetří, přitom to je ta nejdůležitější role. Je to most mezi tím byznysem, mezi tím klientem a mezi tím vývojářským týmem. Jakmile je ten most vachrlatý, nebo v sobě má díry, tak ten vývoj nebude vydávat tu hodnotu, kterou ten byznys potřebuje.
Ty procesy tedy musí být postavené, ale samozřejmě i my se neustále zlepšujeme. My jsme Jimmy Framework neměli hned na začátku. Měli jsme nějaký proces, ale Jimmy Framework vznikl o rok a půl později právě jako zkušenost, kdy vidíš, jaké máš lidi a můžeš jim to postavit. Nám to hodně pomohlo, my jsme během tří let vyrostli na 30 lidí. Kdybychom neměli procesy, tak by to byl totální mess, to bychom prostě nebyli schopní dodat. My jsme na to ale vždy měli proces a byli jsme připravení udělat ten další větší krok, přeskočit po roce z toho body shopu na vývoj na zakázku. Musíš to samozřejmě rovnat, nešlo to stoprocentně, ale v tom nám pomohlo to, že jsme neměli nějaké veliké problémy v tom, že bychom dodávali nízkou kvalitu. Je ale třeba zajímavé, že my ten proces máme postavený na veliké projekty a na malé nám to úplně tolik nefunguje.
Jak funguje synchronizace mezi obchodem a delivery?
Martin Hurych
Jimmy Technologies si tedy najímejte rovnou na veliké projekty. Já bych se vrátil ještě na začátek toho procesu. Jako člověk, kterého zajímá obchod, znamená to tedy, že do CRM má přístup minimálně ta byznysověji orientovaná technická část firmy? Jak funguje synchronizace mezi obchodem, co už je na spadnutí, jaká jsou procenta zavření, jak se plánují dlouhodoběji kapacity a na jak dlouho vlastně vidíte dopředu?
Martin Stojka
My CRM pravděpodobně používáme špatně, to řeknu na rovinu. Máme tam přístup my jako foundeři, máme tam přístup jako ten board, ale nemáme tam vyloženě nějaké detailní informace, protože ty informace, co dostáváme od klientů, jsou na nějakých drivech. My tedy jedeme na drivu a v moment, jakmile se mi stane, že klient pozve technickou osobu na call, tak já už vím, že z naší strany tam také musí být někdo technický. Já chci, aby to hned ten náš tým technicky načerpal a potom, když se tohle nestane, tak i přesto v druhém kole já si toho CTO do toho zahrnu, aby se potkal s tím klientem. Ten potom zjistí, jestli mají nějaký preferovaný jazyk, jaké jsou jejich byznysové cíle a vize, abychom věděli, jak to řešení navrhnout. My se nemůžeme koukat na to, že teď děláme projekt 6 měsíců, nějak to postavíme a takto to tomu klientovi předáme. My se musíme koukat na to, že on za dva roky chce třeba z té platformy udělat franšízu a my mu nemůžeme postavit řešení teď a on za ten rok a půl přijde, že chce postavit franšízu a budeme to muset celé přepsat, protože to není škálovatelné. Děláme to tedy už jen kvůli tomuto, aby ten klient si to potom i klidně mohl převzít sám a rozvíjet to dále, nebo to mohl rozvíjet, aby to bylo flexibilní vůči těm jeho byznysovým požadavkům.
Martin Hurych
Tomu rozumím, posuňme se kousek dál, mě tam zaujala jedna věc. Uděláte nějaké analýzy, techničtí lidé si vyposlechnou, jaké jsou byznysové záměry, dokáží se tomu přizpůsobit, nicméně sám víš, protože jsi zodpovědný za obchod, že pak je relativně dlouhá fáze po podání nabídky. Spousta firem dělá analýzy a v této fázi techničtí lidé do toho namočení jsou. Co se potom děje, je totální mrtvo, absolutní nekomunikace mezi obchodem a výrobou, byť to nemáš rád a pak je veliké překvapení, když je třeba okamžitě začít. Jak managuješ tohle to?
Martin Stojka
My máme pravidelně dvakrát týdně salesové statusy, kde zapojujeme i toho CTO, nebo mu říkáme o těch novinkách. On je i v našem sales channelu, takže vidí, co se děje a my nejsme tak veliká firma, abychom to měli oddělené. Sedíme vedle sebe, řešíme ty věci spolu a těch projektů nedáme tolik. My nemáme 20 nabídek najednou, my jich máme třeba 7, takže to už si člověk lépe zapamatuje. Samozřejmě pokud budeme dělat nabídek více, tak se asi budeme muset o tom více pobavit, ale zároveň my třeba nechodíme do tendru a to ti docela ušetří čas a starosti. Ten decision making process je tam rychlejší a když to trvá déle, tak já jako obchodník s tím klientem získávám furt kontakt, jak to vypadá a ty informace potom předávám dál tomu týmu. Máme naplánované kapacity, máme nějaký plánovací tool, na to plánujeme kapacity a většinou ti vývojáři jsou od tohoto oddělení. Ty to úplně nezajímá, jestli tady bude nějaký deal, ty zajímá to, že když vidí v tom toolu, že za měsíc jim končí kapacita, jestli budou mít nějakou další práci. V ten moment samozřejmě s nimi v kontaktu jsme a s product ownery to je také tak, ti nějak tak vědí, co se připravuje.
Jak smysluplně provázat procesy napříč firmou?
Martin Hurych
Kdybych si chtěl porovnat vlastní procesy, nebo chaos ve vlastní firmě, dokážeš dát dohromady nějakých 5, 7, 10 bodů, co bych měl v té firmě provádět, abych se alespoň na světelná léta přiblížil k Jimmy Technologies? Já vidím, že logicky když řídíš firmu o pár lidech, tak tam nějaké procesy, byť možná neformální, jsou. Co ale spíše vidím, je, že neexistuje ten core process od začátku do konce, že máš fragment, utržený kousek, kde něco je. Pak jsem hodně v IT zjistil, že se nějakým způsobem soustředí na plánování uvnitř firmy a pak se zase děje něco na konci. Jak to smysluplně provázat tak, abych měl ty benefity, o kterých mluvíš?
Martin Stojka
Já bych určitě začal od začátku, od toho salesu a tam i záleží, na jaké klienty a na jaké projekty cílíš. Jimmy Framework by třeba nebylo úplně aplikovatelné na fix time fix price, kdyby přišel klient a řekl, že potřebuje něco konkrétního za 2 miliony a 3 měsíce. My tím, že jdeme spíše agilně, jsme věděli, že aby to fungovalo, abychom nastavili správná očekávání na začátku, tak si musíme nastavit sales.
Po salesu přichází delivery management, příprava toho projektu od toolu, alokací a potom ten vývoj jako takový. Existují metodiky, vývoje agilní a v tom nějaké frameworky, kanban, scrum, extreme programming, tam si člověk musí říct, co by chtěl dělat, nebo co je v jeho možnostech. Když je to nějaký nízkobudgetový projekt, tak asi nebude dělat extreme programming. Je také důležité se přizpůsobit těm lidem. Aby nám tohle fungovalo ve firmě, tak máme tzv. edukační program Inženýr 2.0, kde chceme, aby ti kluci nebyli jenom u té své klávesnice, nekoukali jenom na ten svůj kód a byli takoví ti coding monkeys. Je potřeba, aby doopravdy nad tím mysleli, že na konci má být produkt, který používá člověk, a já jsem součástí týmu a my jako tým jsme zodpovědní za to, jestli to funguje, nebo ne.
Potom samozřejmě do toho třeba zapadá ten design, testing, jak provázat proces vytváření požadavků a v jaký moment tam má skočit design. Spousta firem navrhne celý design, potom začne dělat vývoj a jenom si to rozdělí, ale to je waterfall. Když chceš, aby ti to běželo paralelně, tak už potom přemýšlíš, ve který moment tam toho designéra do toho procesu pustím. Pravděpodobně ho tam pustím hned na začátku, ale on do toho hned musí zapojit vývojáře, aby s nimi zjistil, jestli je to vůbec reálné.
Tohle všechno je spojené s těmi odvětvími, která my děláme. My víme, že tohle funguje třeba v těch odvětvích jako mobilita, fintech a automotive, ale třeba by to nefungovalo v healthcare. Tam pravděpodobně není úplně prostor na nějakou agilitu a na nějaké chyby, tam to musí být přesně nalajnované.
Jaké výhody přináší jasně definovaná specializace?
Martin Hurych
Jestli tě správně chápu, tak celý obchodní a delivery proces by měl být namapovaný na potřeby zákazníka. Ty jsi tady zmínil tři výklenky, které máte, mobilita, fintech a automotive. Zajímalo by mě, co vás vedlo zrovna k těmto třem. Automotive asi chápu vzhledem k tomu, že jsi nějaký čas svého profesního života prožil ve Škodovce. Byť se to lepší, byť čím dál tím více studií hledá nějakou specializaci, tak co vás vlastně k tomu vedlo a co vám ty specializace mají přinést?
Martin Stojka
I přestože jsem dělal 2,5 roku ve Škodovce, tak zase tak silný v automotive nejsem. Já jsem měl ve Škodovce na starosti new mobility solutions a to byla právě ta mobilita. Kluci, se kterými mám firmu, dělali ještě roky předtím ve Škodovce. Máme člověka, který má Ph.D. v connected car, a tak dále. Tím, že jsme byli v tom prostředí, viděli jsme do toho, dělali jsme i pro to něco, plus ta mobilita, tak se to spojilo. Automotive firmy si teď říkají, že už jsou mobilitní firmy, takže ono to je doopravdy provázané. Nerad to říkám, ale myslím si, že v Česku není specializovanější skupina na mobilitu, než jsme my. Ty služby, které jsme tady postavili těch nějakých už 5, 6 let zpátky, stavíme doteď, ten trh známe velice dobře, známe ty uživatele, ty byznys modely, co funguje, co nefunguje.
Martin Hurych
Umíme nějakou říct, nebo jsme pod NDA?
Martin Stojka
Můžeme říct, co jsme postavili jako Jimmy, což je třeba služba Citya, ta funguje. Většina těch služeb, co jsme dělali, funguje, ale některé služby, co jsme dělali třeba pro Škodovku, už nefungují. Ten fintech zase vyplynul z toho, co dělali mí co-foundeři předtím. Byl to zase nějaký background a i to vyplynulo z toho, že jsme před nějakým rokem a čtvrt, rokem a půl viděli, že ten trh se nějakým způsobem mění. Před třemi roky, kdo tady měl titul vývojář, okamžitě získal práci. Tím, jak se ale zvedaly ty ceny, ekonomika šla dolů, tak ty firmy začaly řešit, kolik dávají peněz do IT. Najednou sem začínají chodit vývojáři z Ukrajiny a z Balkánu, kterým my cenově nemůžeme konkurovat. Za chvíli sem přijdou Indové, já dostávám týdně tři zprávy od Indů, jestli nechceme vývoj, což třeba v Británii, nebo v Americe už je naprosto běžné. My jim ale nejsme schopní konkurovat.
Říkali jsme si tedy, že jsme experti, ale člověk nemůže být expert ve 20 různých věcech. V čem jsme tedy experti? Jsme experti ve vývoji, ale to víme, že už nestačí, protože to říká každý. My jsme experti v té automotive, v mobilitě, ve fintech, kde dokážeme předat produktové znalosti, znalosti trhu i toho byznysu a operations, protože některé služby jsme operovali sami. Tohle bude ten náš niche a my třeba teď už ani neprodáváme to, že jsme vývojářské studio, my prodáváme, že jsme produktové studio pro automotive, mobilitu a fintech. My vám postavíme od nápadu až po nějaké post release fáze produkt v těchto odvětvích a jsme vám schopní předat tu naši znalost. Může to být znalost z toho, co jsme si sami prošli, nebo to jsou lessons learned našich klientů, co vidíme, že funguje a nefunguje. Pomáháme tomu klientovi ten produkt navrhnout a potom ho i pro něj postavíme, než abychom vyloženě dostali zadání a museli se o tom trhu něco učit.
Teď mi ve fintech říkal jeden klient, že už by na to nemohl pustit normálního vývojáře i seniorního, protože ten vývojář musí vědět, jak ten finanční trh funguje, aby ten produkt mohl navrhnout. V ten moment jsem si říkal, že to je přesně to, proč my to děláme. Ten klient si nás najme, že potřebuje vývoj, ale on ví, že potřebuje toho specialistu na ten fintech, nebo na tu mobilitu. My jsme schopní poskytnout tu přidanou hodnotu a tu prodáváme a odlišit se třeba i od zbytku trhu. Už tady nejde jenom o ten vývoj.
Kolik programátorů propustil kvůli AI?
Martin Hurych
Je logické koupit si výrobek a ne ruce a nohy. Teď se hodně mluvilo a i tady to proběhlo Zážehem, jak AI bude likvidovat počty ajťáků ve firmách. Chtěl jsem se tě zeptat, kolik už jsi jich vyházel ty?
Martin Stojka
Pár ajťáků jsme vyházeli, ale ne kvůli AI. Já nejsem člověk, který tady říká, že nás AI připraví o práci. Někde se to stát může, ale asi ne v nějakém větším měřítku. Zároveň nejsem úplně vývojář, abych mohl hodnotit, ale už teď víme, že například OpenAI funguje dobře na to, že máš nějaký program v jednom jazyku a chceš to přepsat do druhého. Není to úplně perfektní, musí k tomu přijít furt člověk, aby to doladil, ale to ušetření času je tam poměrně veliké. Vím, že na to vznikají už i startupy, ale nevidím tam ještě využití toho, že by sis s tím postavil nějaký komplexnější produkt. Když si budeš chtít postavit nějakou landing page a mít tam formulář, tak to může fungovat, ale v nějakém kontextu větších aplikací, co třeba my stavíme, to je ještě nedává smysl. Tam už je nějaká architektura, musí to přesně odpovídat vizi toho byznysu a tam tomu úplně nevěřím.
Na druhou stranu už teď, jak je to poměrně pokročilé, se to bude určitě rozvíjet dál a pokud si vývojáři budou chtít udržet práci, tak se z nich přesně budou muset stát Inženýři 2.0. To je člověk, který se nad tím zamýšlí z větší perspektivy a nejen z té technické, protože ve výsledku ten kód toho finálního uživatele vůbec nezajímá, jeho zajímá, co mu ten produkt přinese. Ten kód je jenom tool na to, aby se ten produkt postavil. Pokud ten vývojář do toho přinese ten lidský faktor, že si dokáže propojit ten byznys toho klienta, co ten byznys potřebuje, znalost toho trhu, expertizu a na to postavit nějaké řešení, tak nevěřím tomu, že mu může AI konkurovat. Pokud to ten vývojář neudělá, tak si myslím, že to brzy nebude stačit. My máme vývojáře, který dělal seniorního vývojáře v Revolutu, v Deutsche Bank, v J.P. Morgan, a ten přijde k fintech projektu a řekne, jak by to mělo fungovat a kde může nastat security problém. Přinese ti do toho úplně jinou perspektivu než jen to, že to nějak vypadá, naprogramuje to a možná to bude fungovat, ale doopravdy ti navrhne to řešení k tomu byznysu. To podle mě AI nezvládne.
Kdo je Inženýr 2.0?
Martin Hurych
Kódeři tedy ve sklepech už zůstanou a jestli to dobře chápu, ten zbytek se bude měnit. Pochopil jsem správně, že Inženýr 2.0 je tedy spíše byznys konzultant?
Martin Stojka
To je náš termín, který my používáme. Náš CTO tomu říká t-shape, že doopravdy není jenom zaměřený na ten svůj kód, ale umí komunikovat i s tím klientem. Vyloženě to ale není byznys osoba, stále je to inženýr. Dokáže do té své technické expertizy přinést i znalosti produktové, nebo se nad tím minimálně zamyslí. Tohle nevěřím, že AI je schopná postavit. Ta ti udělá nějaký formulář a jestli to je UXově dobře, nebo ne, už je jiná věc. Myslím si, že se podle toho teď bude hodnotit seniorní vývojář, ne podle toho, jak má čistý kód. Junioři a medioři to budou mít asi složitější, ti do toho budou muset asi více vnášet ten konzultační vhled a mezitím pracovat ještě na té kvalitě toho kódu. Uvidíme, ale to je jenom moje teorie.
Martin Hurych
Přeji ti, ať máš hromadu velikých projektů na Jimmy Framework a ať se z vás sypou Inženýři 2.0 a třeba se výhledově dostanou i někam jinam. Díky za návštěvu.
Martin Stojka
Díky moc.
Martin Hurych
Tak to vidíte, dá se vyrábět kód i efektivně. Pokud jste se rozhodli zrevidovat vaše procesy a to nejen v IT agenturách, tak jsme rádi, že jsme vás nějakým způsobem inspirovali. Pokud to tak je, tak určitě likujte, sdílejte, komentujte, cokoliv, co na platformě, na které nás momentálně používáte, je možné. Určitě mrkněte na moji webovou stránku, www.martinhurych.com, kde v sekci Zážeh je nejenom tato, ale i všechny ostatní epizody. Bude tam i bonus, který z Martina ještě dodatečně vyrazím. Díky, mějte se fajn.
(automaticky přepsáno Beey.io, upraveno a kráceno)