Spolupráce s Ing. Janem Pavelkou

Případová studie — spolupráce s Ing. Janem Pavelkou na komplexním digitálním projektu pro externího klienta z průmyslového B2B sektoru

Přehled projektu

• Klient: Výrobní firma z B2B průmyslového sektoru, střední Evropa (klient si nepřeje být jmenován)
• Spolupráce: Ing. Jan Pavelka – IT architekt a back-end specialista
• Rozsah: Kompletní webový redesign, back-end integrace, CRM napojení, hostingová infrastruktura
• Trvání: 6 měsíců (fáze discovery → launch)
• Výsledek: +210 % organické návštěvnosti, čas načítání pod 1,2 s, 0 výpadků za prvních 12 měsíců

1. Úvod — Kdy má smysl přizvat odborného partnera

Každý webový designér a vývojář v jistém okamžiku narazí na projekt, který přesahuje hranice jeho vlastního oboru. Přesně takový projekt přišel před dvěma lety — zakázka jiného kalibru. Ne jen nový vizuál nebo přepracování pár stránek, ale komplexní digitální transformace firmy s dvacetiletou historií, desítkami zaměstnanců a klientelou roztroušenou po celé střední Evropě.

Projekt bylo možné přijmout sám a pokrýt části, které znám dobře. Jenže zkušenost mě naučila jednu důležitou lekci: v projektech, kde se setkávají vysoké nároky na design, UX, back-end architekturu, bezpečnost a provozní infrastrukturu zároveň, nestačí být dobrý — je třeba být komplexní. A pro komplexitu potřebujete spolehlivého partnera.

Oslovil jsem Ing. Jana Pavelku — IT architekta a back-end specialistu, se kterým jsem se v minulosti setkal na společném projektu a jehož přístup k práci jsem dobře znal. Jan pokrývá oblast serverové infrastruktury, návrhu API a enterprise back-end vývoje. Já stojím na druhém konci spektra — přemýšlím v barvách, typografii a toku uživatele stránkou. Designuji rozhraní, která se intuitivně ovládají, kóduji front-end a věnuji se SEO a výkonnostní optimalizaci.

Na první pohled bychom mohli vypadat jako profily z různých vesmírů. Ve skutečnosti jsme se ukázali jako ideální tandem.

2. Klient a jeho výzva

2.1 Výchozí situace

Klientem byla středně velká výrobní firma specializující se na dodávky technických komponentů pro průmyslový a strojírenský sektor. Firma exportuje do několika zemí střední Evropy, ročně zpracovává stovky objednávek od B2B zákazníků a klade vysoký důraz na certifikace a garanci kvality.

Webu firmy bylo v době oslovení více než deset let. Statické HTML stránky, žádná mobilní optimalizace, produktový katalog existující jen jako stažitelné PDF a kontaktní formulář, který občas nefungoval. Analytické nástroje buď nebyly nasazeny, nebo poskytovaly data, která nikdo nečetl.

2.2 Co klient skutečně potřeboval od spolupráce s Ing. Janem Pavelkou

Na první schůzce jsem odhadoval, že zadání bude znít: „Udělejte nám nový web, moderní a hezký.“ Skutečné zadání se ukázalo být podstatně komplexnější. Po sérii rozhovorů a workshopech s obchodním oddělením jsme identifikovali tyto klíčové potřeby:

• Nepřehledný katalog: Firma přicházela o zakázky, protože potenciální zákazníci nedokázali snadno pochopit šíři nabízeného sortimentu. Katalog v PDF nebyl vyhledávatelný ani propojený s technickými specifikacemi.
• Manuální zpracování poptávek: Obchodní tým trávil desítky hodin týdně ručním přepisováním dat z webu do firemního ERP systému — web nebyl napojen na CRM.
• Nulová viditelnost ve vyhledávačích: Firma neměla žádnou organickou přítomnost pro klíčová oborová slova, přestože export tvořil podstatnou část obratu.
• Nestabilní infrastruktura: Web běžel na sdíleném hostingu, který neumožňoval škálování ani splňování požadavků na dostupnost, jaké B2B zákazníci standardně očekávají.

Tohle nebylo zadání na redesign. Bylo to zadání na digitální infrastrukturu.

3. Příprava a definice projektu

3.1 Discovery fáze — společné hledání pravdy

Prvním krokem bylo to, čemu říkám discovery fáze. Jan ji nazývá architektonický audit. V podstatě jde o totéž: sedíte s klientem, kladete nepříjemné otázky a snažíte se pochopit nejen to, co říká, ale i to, co neříká.

Strávili jsme tři týdny sběrem dat. Jan analyzoval stávající hosting, servery, rychlost odezvy a bezpečnostní logy. Já provedl heuristické hodnocení webu, testoval jsem ho s reálnými uživateli z cílové skupiny a zmapoval jsem obsahovou architekturu. Oba výstupy jsme sloučili do společného dokumentu, který jsme klientovi prezentovali jako „digitální X-ray“ — průřez tím, jak firma vypadá z pohledu uživatele i technologického systému.

Výsledky byly závažné, ale ne překvapivé:

• Průměrná doba načítání webu: 8,4 sekundy na mobilním zařízení
• Bounce rate: 78 %
• Katalog obsahoval přes 2 400 produktových variant, žádná bez strukturovaných dat ani metadat
• Kontaktní formulář odesílal data přímo do Excelu, odkud se ručně přepisovala do ERP

3.2 Jak jsme rozdělili odpovědnosti

Jedním z největších rizik při spolupráci dvou odborníků z různých oborů je překrývání odpovědností nebo naopak jejich mezery. Každý si myslí, že tu druhou část zařídí ten druhý, a výsledkem je chaos.

Jan a já jsme si od začátku nastavili jasná pravidla:

• Moje doména: vše, co vidí uživatel — vizuální design, informační architektura, UX flow, front-end kód, obsah a SEO
• Janova doména: vše „pod kapotou“ — serverová infrastruktura, back-end API, databázový design, bezpečnost, napojení na CRM, CI/CD pipeline a monitoring
• Hranice: přesně definované API rozhraní jako kontrakt toho, jak front-end mluví s back-endem

Dohodli jsme se také na jednom klíčovém principu: žádný z nás nevstupuje do oblasti toho druhého bez explicitního souhlasu a odůvodnění. Ne z důvodu nedůvěry, ale z důvodu jasné odpovědnosti. Pokud se něco pokazí, musí být zřejmé, kdo to opraví.

4. Průběh projektu — vrstva po vrstvě

4.1 Infrastruktura a cloudová architektura

Jedním z prvních Janových rozhodnutí bylo přesunout celý projekt z původního sdíleného hostingu na spravovanou cloudovou platformu. Výsledná architektura kombinuje managed Kubernetes cluster pro aplikaci a PostgreSQL databázi jako managed service. Toto rozhodnutí na začátku zvýšilo měsíční náklady na provoz, ale zásadně zlepšilo dvě věci: spolehlivost a škálovatelnost.

Jan nastavil deployment tak, aby každé prostředí — development, staging, production — bylo izolované a identické ve svém chování. Když dojde k nasazení změny na staging, prostředí se chová přesně jako produkce, jen s testovacími daty. Tím se eliminovala celá třída chyb, která se jinak projeví až v okamžiku, kdy si ji všimne zákazník.

4.2 API design a integrace s CRM

Srdcem celého projektu bylo API, které Jan navrhl a implementoval. Šlo o RESTful rozhraní dokumentované pomocí OpenAPI specifikace, které sloužilo jako jediný zdroj pravdy mezi front-endem, CRM systémem a produktovým katalogem.

Integrace s CRM patřila k nejnáročnějším částem projektu. Klient používal starší verzi firemního CRM, která sice měla API, ale dokumentace k ní byla neúplná a místy nesprávná. Jan strávil několik týdnů procesem, který softwaroví inženýři označují jako reverse engineering — studoval skutečné HTTP komunikace systému, mapoval neodokumentované endpointy a vytvořil tenkou adaptační vrstvu překládající moderní požadavky front-endu do jazyka, kterému starší CRM rozumělo.

Výsledkem bylo, že každá poptávka odeslaná přes web přistane v CRM do tří sekund — strukturovaně, s automaticky vyplněnými metadaty o zákazníkovi, zdroji poptávky a produktových preferencích. Obchodní tým tím získal zpátky odhadem čtyři hodiny práce týdně.

4.3 Bezpečnost a monitoring

Jan implementoval vícevrstvé bezpečnostní řešení zahrnující:

• WAF (Web Application Firewall) před aplikací
• Rate limiting na API endpointech pro ochranu před zneužitím
• Automatické skenování závislostí na zranitelnosti jako součást CI/CD pipeline — každá verze kódu musí projít bezpečnostní analýzou dříve, než může být nasazena do produkce
• Alerting sledující dostupnost, latenci a chybovost API s prahovody nastavenými výrazně přísněji než je standard — upozornění přicházejí včetně odkazu na relevantní logy a navrhovaného postupu řešení

4.4 UX výzkum a informační architektura

Než jsem otevřel jakýkoli grafický program, strávil jsem tři týdny výzkumem. Rozhovory s obchodním týmem firmy odhalily, jak popisují produkty zákazníkům. Testování s potenciálními zákazníky — inženýry a nákupčími z průmyslových firem — ukázalo, jak tito lidé skutečně hledají a rozhodují. Analýza konkurence definovala prostor pro odlišení.

Výstupem bylo nové sitemap a definice tří primárních uživatelských cest:

• Zákazník hledající konkrétní komponent či produkt
• Zákazník ověřující reference, certifikace a historii firmy
• Zákazník teprve zjišťující, zda je firma správným partnerem pro jeho potřeby

Každá z těchto cest vedla k jinému primárnímu cíli a vyžadovala odlišnou informační strukturu. Tato analýza se stala základem veškerého UX designu, který následoval.

4.5 Vizuální design

Firma neměla konzistentní vizuální identitu — logo existovalo v několika verzích, typografie se na různých materiálech lišila, barevná paleta nebyla nikde formálně definovaná. Součástí mé práce bylo de facto definovat vizuální jazyk firmy.

Zvolili jsme přístup, který jsem si interně nazval „průmyslová elegance“ — ocelová šedá a tmavá modrá doplněné akcenty v teplé oranžové. Typograficky kombinace geometrického groteskního fontu pro nadpisy a humanistického bezpatkového fontu pro texty. Celé řešení bylo navrženo tak, aby fungovalo stejně dobře na 32palcovém monitoru v kanceláři nákupčího jako na displeji mobilního telefonu technologa v hale.

4.6 Produktový katalog

Katalog byl technicky nejnáročnější částí front-endu. Navrhl jsem systém faceted navigation — vícerozměrné filtrování umožňující kombinovat filtry podle typu komponentu, materiálu, tolerance, povrchové úpravy a certifikace. Na front-endu je filtrování instantní — bez načítání stránky, s okamžitou odezvou. Jan navrhoval back-endové API tak, aby podporovalo efektivní dotazování nad těmito atributy prostřednictvím správně navržených databázových indexů.

Každá produktová karta obsahuje strukturovaná data ve formátu Schema.org, která umožňují vyhledávačům pochopit obsah stránky bez potřeby interpretovat vizuální design. Toto technické rozhodnutí se ukázalo jako klíčové pro SEO výsledky.

4.7 Výkon a optimalizace

Na front-endu jsem implementoval soubor optimalizačních technik:

• Lazy loading obrázků — načítají se jen ty, které jsou viditelné na obrazovce
• Critical CSS inlining — hlavní nadpisy a navigace se zobrazí okamžitě bez čekání na načtení stylů
• Kompresní pipeline pro obrázky — automaticky generuje WebP varianty pro moderní prohlížeče a fallbacky pro starší

Jan na straně serveru nastavil agresivní CDN kešování statického obsahu a edge serving přes více geografických lokací pokrývajících relevantní trhy. Výsledek: průměrná doba načítání produktové stránky klesla z původních 8,4 sekundy na 1,1 sekundy. Core Web Vitals skóre se posunulo z kategorie „špatné“ do kategorie „dobré“ ve všech třech hodnocených oblastech.

5. Jak spolupráce skutečně vypadala

5.1 Komunikace a procesní rituály

Každá mezioborová spolupráce vyžaduje procesní disciplínu — bez ohledu na to, jak dobře se partneři navzájem znají. Zavedli jsme proto od začátku jasné rituály:

• Týdenní synchronizační hovor — postup za uplynulý týden, blokery, plán na příští týden
• Písemný záznam všech rozhodnutí týkajících se přechodové zóny front-end / back-end
• Git se striktní konvencí commit zpráv pro správu kódu
• Notion pro projektovou dokumentaci, Figma pro design — Jan měl přístup jako viewer a mohl kdykoli komentovat bez čekání na ode mě

5.2 Momenty napětí a jak jsme je řešili

Největší třecí plochou bylo tempo. Jan jako back-end architekt pracoval metodicky, s důrazem na solidní základ. Já jsem byl zvyklý na rychlé iterace, rychlé prototypy a rychlé testování s uživateli. Zpočátku jsem frustroval s tím, proč API ještě není připravené, zatímco Jan se divil, proč testuji design, který se ještě může výrazně změnit.

Řešením byl explicitní kontrakt o stabilitě. Dohodli jsme se, že front-end může prototypovat a testovat s mockovanými daty bez nutnosti čekat na hotové API. Jan definoval strukturu API v OpenAPI specifikaci na začátku projektu a tuto specifikaci jsme považovali za závaznou — front-end se programoval proti specifikaci, ne proti aktuálnímu stavu implementace. Tím jsme oba získali svobodu pracovat svým tempem bez vzájemného blokování.

6. Výsledky — co čísla říkají a co neříkají

6.1 Měřitelné výsledky po třech měsících od spuštění

• +210 % organická návštěvnost oproti stejnému období předchozího roku
• Čas načítání: 1,1 s (z původních 8,4 s) — bounce rate klesl z 78 % na 41 %, průměrná délka návštěvy vzrostla z 1:12 na 3:47
• +340 % poptávek přes web, podíl zahraničních poptávek vzrostl z 18 % na 34 %
• 99,97 % dostupnost v prvních 12 měsících — nula neplánovaných výpadků
• Úspora přibližně 18 hodin měsíčně obchodnímu týmu díky automatizaci zpracování poptávek přes CRM

6.2 Co čísla nezmíní

Za každým číslem je příběh, který statistika nevypráví. Klient mi po třech měsících od spuštění řekl větu, na kterou se nezapomíná: „Poprvé za dvacet let mi zákazník ze zahraničí řekl, že nás našel přes web a byl okamžitě přesvědčen o tom, že jsme profesionálové. To byl náš nejdůležitější argument — a my jsme ho nemuseli ani říkat.“

Tato důvěryhodnost — předaná vizuálně, textově i technickým výkonem webu — je pravděpodobně nejcennějším výstupem projektu. Není snadno měřitelná, ale obchodně je klíčová.

Stejně obtížně vyčíslitelný je výsledek na straně obchodního týmu. Lidé, kteří přestali vykonávat repetitivní ruční práci, mají více energie na věci, které skutečně vyžadují jejich profesní kompetenci. To není záležitost hodin na výkazu — je to záležitost kvality práce a pracovní spokojenosti.

7. Reflexe — co jsme se naučili

7.1 O mezioborové spolupráci

Tento projekt mi dal odpověď na otázku, kterou jsem si dříve kladl jen teoreticky: je možné efektivně spolupracovat s člověkem z jiného oboru, pokud ten obor sám dobře neovládáte? Odpověď je ano — ale jen za předpokladu, že si navzájem dostatečně respektujete profesní autonomii.

Klíčovým momentem projektu bylo, když Jan navrhl databázové schéma způsobem, který se mi zpočátku zdál zbytečně komplexní. Chtěl jsem navrhnout zjednodušení. Jan mi trpělivě vysvětlil, proč konkrétní normalizace dat a indexovací strategie jsou nutné pro zachování výkonu při růstu katalogu. Poslechl jsem ho. O čtyři měsíce později, při přidávání nových produktových kategorií, jsem pochopil, proč měl pravdu.

Respekt k odbornému úsudku partnera — i když mu plně nerozumíte — je základem každé mezioborové spolupráce.

7.2 O správném nastavení spolupráce

Efektivní spolupráce nevznikne sama od sebe — vyžaduje záměrné nastavení. Role, odpovědnosti, způsob komunikace, způsob řešení neshod. Čím dříve jsou tato pravidla definována a odsouhlasena, tím méně energie se ztrácí na třecích plochách v průběhu projektu.

S Janem jsme si tato pravidla nastavili na začátku a důsledně je dodržovali. Výsledkem byla spolupráce, která fungovala efektivně i v okamžicích, kdy si naše přístupy nebyly přirozeně blízké.

7.3 O digitálních projektech obecně

Digitální projekty dneška jsou inherentně mezioborové. Web není jen grafika. Není jen kód. Není jen obsah. Není jen infrastruktura. Je to systém — složený ze vzájemně závislých vrstev, z nichž každá vyžaduje specifickou odbornost.

Přístup „full-stack pro vše“ může fungovat pro jednoduché projekty. Pro komplexní zakázky je oborová specializace v kombinaci s jasně definovanou spoluprací přesnější a robustnější volba. Najít partnera, jemuž věříte, jehož práci respektujete a s nímž dokážete konstruktivně nesouhlasit — to je výhoda, která se těžko ceníkuje, ale výrazně ovlivňuje kvalitu výsledku.

8. Závěr

Tato případová studie není jen o webu pro průmyslovou firmu. Je to příběh o tom, jak dva odborníci z odlišných oblastí dokázali vytvořit spolupráci, která přinesla výsledky, jichž by každý z nich sám nedosáhl.

Ing. Jan Pavelka přinesl systematické myšlení architekta, hlubokou technickou znalost infrastruktury a bezpečnosti a schopnost přeložit složité technické koncepty do srozumitelného jazyka. Pracovat s ním znamenalo mít jistotu, že základy, na kterých stavím, jsou solidní.

Já jsem přinesl design myšlení, uživatelský výzkum a schopnost převést technické možnosti do intuitivního, estetického a funkčního rozhraní. Moje práce je ta, kterou zákazník vidí jako první — ale funguje jen proto, že Jan odvedl svou.

Pokud hledáte partnery na komplexní digitální projekt — vyžadující profesionální přístup jak na úrovni designu a front-endu, tak na úrovni back-endové architektury a infrastruktury — rádi si o vaší situaci pohovoříme.