Jak neprotopit statisíce při vývoji e-shopu: Průvodce zadáním

Představte si, že spouštíte nový e-shop na míru. Máte schválený rozpočet 500 000 Kč a termín spuštění za tři měsíce. V polovině vývoje si ale vzpomenete, že by bylo skvělé mít pokročilý věrnostní systém. Pak zjistíte, že napojení na váš ERP systém (třeba ABRA Flexi) vyžaduje úpravu datové struktury, o které nikdo na začátku nemluvil. Vývojáři začnou posílat faktury za vícepráce, termín se posouvá o kvartál a původní rozpočet je dávno v červených číslech.

Tento scénář není výjimkou, ale smutným standardem. V MirandaMedia se při auditech P&L klientů často setkáváme s tím, že největší „černou dírou“ na peníze nejsou ani tak licence, jako spíše nekoncepční vývoj a opravy věcí, které měly být vyřešeny v zadání. Podle analýz 92 % projektů selhává právě kvůli nedostatečnému řízení rozsahu práce.

Past zvaná „scope creep“ aneb jak se z projektu za 100 tisíc stane propadák#

Scope creep v projektovém řízení označuje situaci, kdy se rozsah projektu postupně rozrůstá o další a další funkce, aniž by došlo k úpravě rozpočtu nebo harmonogramu. 52 % softwarových projektů se s tímto jevem potýká pravidelně. Pro majitele e-shopu to znamená jediné: nekontrolovaný nárůst nákladů, který může dosáhnout až čtyřnásobku původně plánované částky.

28 % projektů podle reportu Project Management Institute z roku 2023 doplatilo na to, že zadání nebylo na začátku vytesáno do kamene. Problémem jsou často „malé“ UX revize nebo dodatečné požadavky na reporting, které se zdají být nevinné, ale v součtu rozbíjejí architekturu kódu. 17 % rozpočtu se v průměru vypaří jen proto, že projekt jako celek selže kvůli špatné komunikaci priorit.

V naší praxi s českými a slovenskými e-shopy je položka, která operátory skoro vždy překvapí, právě kumulativní efekt drobných změn. Jeden den chcete změnit barvu tlačítka, druhý den přidat pole do registračního formuláře. Bez silného technického zadání a procesu řízení změn se z vašeho e-shopu stane „technický dluh“ ještě dříve, než prodáte první produkt. Globální technický dluh má přitom do roku 2026 dosáhnout závratných 1,52 bilionu dolarů.

Pravidlo deseti: Proč se vyplatí investovat do plánování#

70 % všech produktových vad vzniká během fáze plánování, designu nebo přípravy. Pokud tyto vady neodhalíte včas, jejich cena roste exponenciálně. V softwarovém inženýrství pro to existuje takzvané „Pravidlo deseti“ (Rule of Ten). Toto pravidlo říká, že náklady na opravu chyby se v každé další fázi vývoje zvyšují desetinásobně.

100 EUR stojí oprava chyby, kterou vývojář najde během unit testování (testování jednotlivých funkcí). Pokud se tato stejná chyba dostane až do fáze akceptačního testování (kdy e-shop zkoušíte vy jako klient), cena za její opravu už vyskočí na 10 000 EUR. A pokud chybu najdou až zákazníci po ostrém spuštění? Připravte si 100 000 EUR na přímé náklady, ušlé tržby a poškození reputace (Code Intelligence, 2025).

1 000krát dražší je tedy oprava v produkci oproti fázi návrhu. Každé 1 EUR investované do komplexního testování a precizního zadání ušetří 5 až 10 EUR na budoucích opravách. Přesto mnoho e-shopařů spěchá na „kódování“ a fázi analytické přípravy považuje za zbytečné zdržování. Výsledkem je, že vývojáři tráví 35 % až 50 % svého času pouhým laděním chyb místo tvorby nových funkcí.

Jak postavit „neprůstřelné“ technické zadání#

Vaše zadání musí být natolik podrobné, aby vývojář nemusel hádat. Pokud vývojář hádá, vy platíte. Kompletní uživatelská story (User Story) by měla být základním stavebním kamenem. Nesmí v ní chybět narativní popis (kdo, co a proč chce), vizuální schéma a jasná pravidla hry.

Wireframy jako zkratka k pochopení#

Wireframy poskytují 80 % potřebných informací s pouhými 20 % úsilí ve srovnání s tvorbou pixel-perfect prototypů ve Figmě. Zatímco návrh celého layoutu může stát stovky eur, jednoduchý wireframe jasně definuje, kde bude jaké tlačítko a co se stane po kliknutí. V MirandaMedia doporučujeme vložit wireframe přímo do zadání ke každé klíčové funkci. Pokud se text zadání a wireframe liší, měl by mít text vždy přednost.

Akceptační kritéria: Definice hotového#

Akceptační kritéria jsou měřitelné podmínky, které definují, kdy je úkol hotový a bezpečný. Například pro funkci „přidání do košíku“ nestačí napsat „tlačítko musí fungovat“. Kritéria musí znít:

1. Po kliknutí se produkt přidá do košíku bez obnovení stránky.
2. Zobrazí se potvrzovací modální okno s rekapitulací.
3. Pokud je produkt vyprodaný, tlačítko je neaktivní a nápis se změní na „Vyprodáno“.

45 % firem reportuje roční ztráty přesahující 5 milionů dolarů kvůli špatné kvalitě softwaru. Jasná akceptační kritéria jsou vaší pojistkou, že nebudete platit za polovičatou práci.

Výběr dodavatele: Kdy stačí poptávka a kdy potřebujete RFP#

Projekty na platformě Shoptet, která drží 49,1 % trhu v ČR a SR s přibližně 33 000 aktivními obchody, často nevyžadují složitá výběrová řízení. Pokud se ale pouštíte do stavby e-shopu na míru nebo rozsáhlé migrace, musíte zvolit správný formát poptávky.

40 000 EUR (cca 1 milion Kč) je hranice, pod kterou je rozsáhlé RFP (Request for Proposal) často ztrátou času. U menších projektů se více vyplatí nezávislé srovnání dodavatelů a referencí. Pokud je ale rozpočet vyšší, RFP vám pomůže filtrovat partnery na základě faktů, nikoliv sympatií.

2 % je maximální podíl otevřených otázek, které by mělo vaše RFP obsahovat. Pokud se dodavatelů ptáte příliš obecně, dostanete neporovnatelné odpovědi a proces výběru se neúměrně protáhne. Nezapomeňte do zadání zahrnout mapu vašeho stávajícího softwarového ekosystému. Vývojář musí vědět, zda se bude napojovat na Pohodu přes XML nebo na moderní cloudové ERP.

Fixní cena vs. Time & Materials: Kdy zvolit který model#

Volba platebního modelu přímo ovlivňuje riziko scope creepu. Každý model má své místo v závislosti na tom, jak moc „střelené“ máte zadání.

1. Fixed-price (Fixní cena): Vhodný pro jasně definované projekty se stabilními požadavky. Riziko nese dodavatel, proto si k ceně často připočítává rizikovou přirážku. Pokud ale během vývoje začnete zadání měnit, fixní cena padá a nastupují drahé vícepráce.
2. Time & Materials (Čas a materiál): Ideální pro agilní vývoj e-shopu, kde se požadavky přirozeně vyvíjejí. Platíte za skutečně odvedený čas. Tento model vyžaduje vaši vysokou angažovanost a silnou kontrolu priorit, jinak se rozpočet může utrhnout ze řetězu.

Kombinace scope creepu a slabé kontroly změn je nejčastější příčinou překročení rozpočtu. U projektů s fixní cenou proto doporučujeme striktní „Change Management“ proces. Každá změna nad rámec zadání musí být naceněna a schválena jako samostatný mini-projekt.

Shrnutí: Jak ochránit svůj rozpočet#

Vývoj e-shopu v roce 2026, kdy český e-commerce trh dosahuje obratu 206 miliard Kč, vyžaduje profesionální přístup k řízení rizik. Už nestačí „mít nápad“ a najmout si programátora. Úspěšné projekty, které mají téměř dvakrát vyšší míru úspěšnosti, se vyznačují jasně definovanými kritérii úspěchu a systémy pro měření výkonu.

Při plánování pamatujte na to, že vytvoření webu „pro budoucnost“ místo pro aktuální potřeby často vede k vyhazování peněz za zbytečné funkce. Lepší je spustit MVP (minimální životaschopný produkt) a ten postupně rozšiřovat na základě reálných dat od zákazníků. Fázování vývoje (nejprve katalog, později personalizace) může snížit počáteční investici o 25–40 %.

Časté otázky#