Bavilo mě programovat a tak jsem si založil programátorskou firmu. Postupně však programování ubývalo a přicházely role více analytické, organizační a nakonec obchodní. Celý život jsem se v IT pohyboval na straně vývoje a na stranu obchodu nazíral s .... ne s respektem. "Jardo, z vás nikdy obchodník nebude", říkali mi partneři, nebo "Měl jste si radši založit neziskovku".

Dobře, není mi to vrozené, ale můžu se to naučit. Můžu někoho požádat o pomoc. Zákazníka nepřesvědčím množstvím líbivých slov, ale přípravou, kterou si před schůzkou udělám, otázkama, které položím, nebo upřímným zájmem. Existuje mnoho kvalitních materiálů a kurzů, např. od Petera Urbance. Vžyť obchod je jen hra, která, když se dělá z lásky k produktu a lidem, je krásná a zábavná.

Když jsme s bráchou zakládali firmu, říkali jsme si, že to budeme dělat všechno jinak, že tím budeme rychlejší a lepší než všichni okolo. Žádná administrativa, žádné zbytečné rituály, maximální efektivnost.

Jenže, co fungovalo dvěma nadšencům, kteří spolu vyrůstali, bylo nepoužitelné, když začali přicházet noví lidé a firma se začala rozrůstat. Nakreslili jsme si proces průchodu zakázky firmou. Rozdělili ho do etap. Tak, aby na konci každé etapy bylo co ukázat. Tak, aby se změny dělaly co nejdříve a ne na konci před dokončením. Tak, aby se průběžně ověřovalo, zda jdeme správných směrem. Tak, aby se zakázka stihla v domluveném čase a rozpočtu.
Kombinací waterfallu a agilu. Vybavili jsme se nástroji: Jira, Confluence, Bitbucket, Slack, Jenkins, ... a zautomatizovali, co šlo. Příchod Covidu a přechod na totální remote work pomohl vychytat nedostatky a donutil lidi používat nástroje a dodržovat pravidla.

Slýchám majitele firem říkat, že sami si to udělají vždy nejlépe. Mám jinou zkušenost. Lidé potřebují příležitosti a podporu, pak dokáží fantastické věci. Hodně věcí, které jsem předal, dělá dnes někdo jiný lépe, než já.

Před časem jsem řešil - jít studovat MBA nebo si založit firmu a učit se praxí? Zvolil jsem to druhé, ale po letech mi přišlo, že doplnit si teoretické znalosti nemusí být na škodu a může ulehčit nabírání zkušeností metodou pokus omyl. Podle toho, co jsem viděl okolo, jsem očekával, že je to otázka především finanční investice, za kterou získám titul, zajímavé znalosti, kontakty na lidi podobně smýšlející a v podobných životních situacích. Očekával jsem, že mě to posune v pracovním i osobním životě.

Krutě jsem se zmýlil. Studium na Business Institut je založeno především na samostatném vypracovávání postupových prací. Čili si připadám jak ve škole pro spisovatele. Se svým poměrně vysokým pracovním vytížením vyplodit každý měsíc desetistránkovou postupovou práci je docela výzva. Studium jsem si prodloužil a mám velký respekt k nositelům třípísmenkového titulu. Proto, pokud se vrhnete do studia MBA, zjistěte si dopředu, jakou formou studium probíhá a jestli Vám bude příjemná.

Když se řekne Adobe, většina lidí si představí Photoshop, InDesign, Illustrator a nástroje na zpracování grafiky. Adobe je však jedničkou i v enterprise systémech pro podporu prodeje a jedním z takových nástrojů je Adobe Experience Manager (AEM), pokračovatel platformy Adobe LiveCycle, se kterou jsem v minulosti zažil velké věci.
V létě 2018 jsem dostal nabídku se o několik takových instancí AEM starat ve Škoda Auto v Mladé Boleslavi. Taková nabídka se neodmítá ...

Proč se podílet na zahraničních projektech? Protože to velmi obohacuje. A nejen materiálně. Osobně oceňuji možnost cestovat, mít zaplacené letenky a hotel, poznat místní kulturu, vyzkoušet si "chodit do práce" jinde. První den přinést místní sladkosti a speciality. Déle velmi oceňuji zahraniční projektovou kulturu, lepší zacházení, zejména v případě, kdy je třeba udělat něco navíc, co v původním zadání nebylo. Je zcela normální za takové věci zaplatit a netvářit se, že to vlastně v zadání bylo od začátku a když ne, tak to je přece jasné, protože bez toho by to nemělo vůbec smysl.

Zajímavou profesní zkušeností byl proces certifikace na PCI DSS. Jedná se o certifikaci, kterou musí mít každý systém zpracovávající data z platebních karet. V rámci procesu jsme rozdělili celý systém do zón a pro každou zónu definovali pravidla přístupu a pracovní režim. Díky architektuře microsevices to nebylo tak náročné, jako kdybychom trhali klasický J2EE moloch. A tak většina procesu byla o přípravě požadovaných dokumentů. Setkání s auditorem už byla třešnička na dortu. Z pohledu provozu takového systému se vše zesložití, vývojáři ztratí přístup do logů, systém se rozdělí do zón, do každé zóny má přístup o jednoho méně, než je potřeba.

PowaTag byl britský technologický startup přinášející revoluční platební metodu, která propojila prodeje v digitálním a reálném světě. Nascanováním magického QR kódu mohli zákazníci snadno nakupovat, platit a přitom zažívat výhody elektronických prodejů. Na projekt jsem přišel jako řadový programátor pomáhat s tvorbou propojovacích můstků na bankovní systému a eshopy. Protože mě práce bavila, stal jsem se postupem členem užšího týmu a zatímco v Čechách lámal rekordy Šoptet, já v Londýně prováděl integrace a certifikace napojení na technologie jako BT Fresca, Websphere Commerce nebo unikátní Demandware.
Projekt měl své zázemí v nejvyšších patrech Heron Tower, 3. nejvyšší budovy v Londýně. To byl velký zážitek.

Jaký server dokáže obsloužit mobilní aplikaci, kterou ve špičkách používá velký počet uživatelů? Levný bude přetížen a drahý bude mimo špičku nevyužit. Jako vhodné řešení se jevilo použít cloud, který umí škálování - tzn. navyšuje svůj výkon podle potřeby a za ten se platí.
Zvolili jsem Google App Engine. Příjemným bylo nejen vývojové prostředí zdarma, ale i množství dokumentace a existující komunita. Avšak brzy jsme přišli na jistá úskalí, např. když server přestal odpovídat kvůli vyčerpaným limitům. Ukázalo se, že každý dotaz do databáze měl svoji cenu - zápis vyšší, čtení nižší - a v bezplatném režimu byl počet omezen. Když jsme limit vyčerpali, muselo se čekat do dalšího dne. Museli jsme do detailu prostudovat, jak fungují cloudové technologie a aplikaci podle toho upravit. Nakonec jsme spotřebovávali zlomek denního limitu.
Překvapením bylo, když začaly limity docházet pravidelně z ničeho nic v době, kdy se systémem nikdo prokazatelně nepracoval. Ukázalo se, že roboti prohledávající celý internet, narazili na webové rozhraní a natolik je zaujalo, že vyžrali limity do mrtě. To je cenná zkušenost - nikdy nevíš, co tě zítra ráno překvapí.

Když vlivem hospodářské recese Adobe přehodnotilo svoji obchodní politiku a zavřelo pražskou pobočku, byl to pro naši firmu průser. Tým programátorů nebyl připraven na prodej korporátního produktu, jakým byl Adobe Experience Manager. Naše obchodní dovednosti se omezovaly na přípravdu dem, návrhu architektury, diskusi s techniky po boku obchodníka, se kterým jsme přišli na schůzku. Co naplat. Nalili jsme si vlastní medicíny, vzali nástroj Adobe Flash Builder, který jsme do té doby prodávali, a začali v něm programovat mobilní aplikace. Jak ale začít nový business bez ukázek hotových řešení a referencí? Vymyslel jsem následující prohlášení: "Podívejte, my s tím začínáme a reference nemáme. Proto je potřebujeme a bude nám velmi záležet na tom, abyste byli spokojeni a referenci nám rádi dali." Fungovalo to.
Po několika "hračkách" pro kamarády jsme získali první zakázku - mobilní aplikaci pro konferenci. Hrozně jsme se na tom natrápili, zvlášť s iPhonem, který jsme ani neměli. Pronajímali jsme si ho vzdáleně nebo prosili kamarády o otestování. Projekt byl nakonec velmi kladně oceněn, zákazník nám dal jako bonus peníze navíc. To nás velmi povzbudilo a nasměrovalo.

Po úspěchu ve zdravotní pojišťovně jsme zažili další v Pražské Plynárenské. Je nepředstavitelné, kolik toho taková organizace tiskne - denně na pobočkách a měsíčně velké množství dokumentů pro své zákazníky, převážně faktury. Tisky na pobočkách probíhaly rychle v on-line režimu, tisky ve velkém objemu se zpracovávaly dávkově. Platforma Adobe se díky množství různých konektorů snadno napojila na SAP. Řešení se přeneslo z outsorcované služby do interní správy, což kromě významných úspor přineslo především flexibilitu. Později byly některé z tiskových sestav doplněny o elektronický podpis, aby vyhovovaly požadavkům české legislativy. A takto tam tisknou dodnes.

Když jsem se po nějaké době svého podnikání ohlédl zpět, přišlo mi, že nemám nic než příběhy k vyprávění a odstavce v životopise. Živnost je skvělá z hlediska daňových úspor. Nemá ale historii, nedá se prodat, není to nic. Také je vhodná pro určitý typ byznysu. Jiné je očekávání od živnostníka, jiné od firmy. Jiné jsou zakázky, jiný je i přístup. Pro další rozvoj svých aktivit mi už živnost nestačila. Nejnáročnější bylo samozřejmě vybrat jméno, aby bylo volné a něco znamenalo. A tak jsem vymyslel INITED Solutions s.r.o.
Dnes vidím, že jsou dvě typické motivace pro založení firmy:
1. máte skvělý nápad, kterému věříte, tak jdete a založíte něco nového. Najdete si nové zákazníky, vybudujete know-how, začínáte od nuly.
2. děláte něco a vidíte, že by to ve vašich rukou fungovalo lépe. Tak se trhnete, vezmete si s sebou know-how, zákazníky a pokračujete dál, ale po svém.

Kartička pojištěnce se vždy posílala na kontaktní adresu, u nezletilých na adresu zákonného zástupce. Napsal jsem na to proceduru v Oracle PL/SQL, vše jsme otestovali, předali do provozu a zapomněli na to. Jednoho dne pak někdo přiběhl, že na adresu jednoho pojištěnce nedorazilo několik kartiček - pro něj a děti, ale několik beden kartiček! A kdyby alespoň celá zásilka dorazilo najednou, ale ona přicházela v rámci několika dní. "To nemůže být možné", dušovali jsme se, "to zpackali kurýři". Chvíli to trvalo, než jsme našli, kde to vzniká - v mém kódu: pokud je pojištěnec nezletilý, nastavím adresu dodání na adresu zákonného zástupce. Pokud je zletilý, nedělám nic. A to byla ta chyba - adresa dodání se nastavovala pouze při zpracování nezletilého pojištěnce a držela se až do zpracování dalšího. Tak kartičky zletilých pojištěnců chodily na adresu zákonného zástupce posledního nezletilého pojištěnce.

Když vygenerování jednoho reportu zabere pět sekund, kolik dní se bude generovat 100.000 reportů? Pět a kousek. Takové řešení bylo prakticky nepoužitelné - v pondělí se to spustilo a ve čtvrtek se zjistilo, že je tam u někoho chyba, a znova. Důvodem takové pomalosti byla především komplexnost - data bylo třeba získávat z několika různých na sobě závislých systémů.
Navrh jsem jiný způsbo zpracování: místo toho, aby se pro každý individuální report dotazovalo do všech systémů, provedl jsem hromadné exporty ze všech systémů do databáze Oracle do pomocných tabulek, nad nimi spustil zpracování a výstup vracel ve formátu XML, v přesně takové podobě, jako bylo potřeba pro naplnění šablony. Výsledek optimalizace bylo 50 minut. A protože s jídlem roste chuť, spouštělo se generování znovu a znovu, dokud se nevychytaly všechny mouchy až byly výsledné reporty perfektní.

Těsně před vypuknutím krize vznikla v Praze nová zdravotní pojišťovna Média. Z technického pohledu byl projekt zajímavý nasazením nejmodernějších současných technologií, které měly zajistit radikálně jinou kvalitu nabízených služeb. Stala se inkubátorem konceptů, které později převzaly ostatní pojišťovany: přílohy č.2 jako interaktivní formuláře propojující vzhled v PDF a datovou vrstvu v XML, klientský portál, kde se mohl klient podívat, jaké platby a za co komu šly. Oproti okolním pojišťovnám jsme díky technologiím zvládali neuvěřitelné věci. To, co ve VZP dělalo celé oddělení o sto lidech, dělaly v Médii dvě pracovnice. V oblasti digitalizace příchozí pošty jsme se inspirovali reklamou, ve které vedle scanneru stál koš a co se nascanovalo, v něm končilo. Vychytávka bylo zpracování doručené pošty, kdy se všechny zprávy ze všech kanálů (klasická pošta, podatelna, pobočky, portál, datová schránka, ...) konvertovaly do jednotného formátu a dále zpracovávaly stejnou cestou. Při konverzi z papíru se provádělo OCR. Dokumenty bylo možné fulltextově prohledávat. Řešení bylo postaveno na platformě Adobe a získalo ocenění "nejkomplexnější řešení na platformě Adobe LiveCycle".

Vrcholem mé kariéry v oblasti zátěžového testování byla příprava portálu Českého Statistického úřadu na komunální volby v roce 2006. Stoupající popularita i dostupnost internetu znamenaly nutnost posilování webových serverů. V předchozích volbách nebyla výkonnost dostatečná a tak bylo rozhodnuto udělat volby nanečisto a systém na ně připravit. Provedla se analýza chování uživatelů, naprogramovali "klikací" roboti a podle připraveného scénáře se generovala zátěž z hostingového centra. Přitom se měřilo, sledovalo, analyzovalo a navrhlo zlepšení. Systém se upravil, přenastavil a znova. Proběhlo několik takových kol. Test byl nakonec velmi úspěšný. Infrastrukturu portálu se podařilo optimalizovat tak, že reálnou zátěž zvládla skvěle. To nám otevřelo dvěře k dalším případům - na Českou poštu, Českou správu sociální zabezpečení, a další.

Jednou pod návratu z oběda jsem si všiml, že se na stěně zastavily hodiny. Napadlo mě, že vyzkouším, jak dokonale fungují firemní procesy. Otevřel jsem service desk, kde bylo téměř všechno, a našel sekci - zdroje elektrického proudu. Přeskočil jsem zásuvky, prodlužky i přívody motorového proudu 400V a do kolonky "jiné" vepsal, že potřebuji jednu baterii do hodin o napětí 1.5V a požadavek odeslal. Požadavky zpracovávali v Holandsku, poté je předávali do ostatních zemí světa. Většinu musel ještě někdo schválit, někdy i jemu to musel někdo scháválit, to nebylo jen tak. Asi za minutu a půl někdo zaklepal na dveře: potřeboval jste baterii do hodin? Byl jsem v šoku. Nechápu, jak tak dokonalá firma mohla zkrachovat.