Vývojář není věštec. Pokud mu řeknete "chceme moderní web, který bude prodávat", dostanete web, který bude moderní a bude mít košík — ale pravděpodobně ne to, co jste si představovali. Většina webových projektů, které skončí nadměrným přečerpáním rozpočtu nebo zklamáním na obou stranách, neselže kvůli špatné technologii ani špatnému vývojáři. Selže kvůli špatnému zadání. A dobré zadání se nenapíše za hodinu — ale tato hodina vám ušetří měsíce problémů.
Proč špatné zadání stojí víc než dobrý vývojář
Stavební firma nepřijde na stavbu bez projektu. Projektant nespočítá statiku bez výkresů. Přesto spousta firem přijde k vývojáři s tím, že "chce web" a věří, že zbytek nějak vykrystalizuje.
Problém je fundamentální: vývojář vidí svět z pohledu funkcí a technologie. Vy ho vidíte z pohledu zákazníka a byznysu. Pokud tyto dvě perspektivy nesedí dohromady od začátku, každý pracuje na jiné věci — a zjistíte to, až když je hotovo.
Pozdní změny jsou drahé. V softwarovém vývoji platí, že oprava chyby v požadavcích stojí 1 jednotku práce. Oprava téže chyby v hotovém produktu stojí 10–100 jednotek. Jinak řečeno: přidat do zadání celou stránku navíc než předelat hotový web znamená rozdíl mezi hodinou diskuse a týdnem práce.
Praktický tip: Než začnete sepisovat zadání, odpovězte si na tuto jednu otázku: "Jak poznám, že web uspěl?" Pokud odpověď zní "bude hezký" nebo "bude moderní", ještě nejste připravení. Pokud odpověď zní "za šest měsíců od spuštění přijde přes web 30 % nových poptávek", máte základ.
Co do technického zadání patří
Dobré zadání není román ani katalog přání. Je to přesný popis toho, co se má postavit, pro koho a proč. Tady je minimální seznam, co by mělo obsahovat:
Cíle webu. Co má web konkrétně dělat? Generovat poptávky? Prodávat produkty? Informovat o firmě a budovat důvěru? Každý cíl má jiné implikace pro design i technologii. Napište je v pořadí priority — ne všechny cíle jsou stejně důležité.
Cílová skupina. Kdo bude web používat? B2B nebo B2C? Technicky zdatní lidé nebo laici? Mobilní nebo desktopový uživatel? Jazyk cílové skupiny (doslovně — bude web česky, anglicky, vícejazyčně)?
Seznam funkcí. Ne jako wishlist, ale jako strukturovaný přehled. Co je nutné pro spuštění (MVP)? Co je vhodné mít? Co by bylo hezké, ale počká? Tato prioritizace zabraňuje situaci, kdy projekt nestartuje, protože všechno musí být hotové najednou.
Designové reference. Ukažte tři až pět webů, které se vám líbí. A hlavně řekněte proč — líbí se vám barevné řešení, rozvržení, fotografie, nebo způsob, jakým vede uživatele k akci? Reference bez vysvětlení jsou k ničemu.
Technické integrace. Co se musí k webu napojit? CRM? Účetní software? Platební brána? Mailingová platforma? Sklad? Pro každou integraci zjistěte, zda má API a jakou dokumentaci.
Obsah. Kdo dodá texty, fotografie a videa? Kdy? V jakém formátu? Toto je nejčastěji podceňovaná část — projekty čekají měsíce na obsah, i když je technicky vše hotové.
Časový plán a rozpočet. Vývojář potřebuje vědět, s čím pracuje. Pokud máte pevný termín (veletrh, spuštění kampaně, konec sezóny), řekněte to hned. Pokud máte rozpočtový strop, řekněte to také — ušetříte si kruhovou diskusi o rozsahu.
Nejčastější chyby v zadáních
Příliš vágní požadavky. "Web musí být přehledný a rychlý." Ano, alespoň tak by měl vypadat každý web. Co to ale konkrétně znamená pro váš projekt? Přehledný pro koho? Rychlý podle jakého benchmarku? Vágní požadavky generují vágní výsledky.
Chybí "proč". Firma chce srovnávací tabulku produktů. Proč? Protože zákazníci se rozhodují mezi třemi variantami a potřebují porovnat technické parametry — nebo proto, že to má konkurence a "přece nemůžeme být pozadu"? Tyto dvě odpovědi vedou k naprosto odlišnému řešení.
Kopírování konkurence bez přemýšlení. "Chceme totéž, co má firma X." Ale firma X má jiné zákazníky, jiný byznys model a jiné technické zázemí. Navíc nevíte, jestli jejich řešení skutečně funguje — třeba to stálo dvakrát tolik, než se plánovalo, a konverzní míra je bídná.
Příklad z praxe: Pražský distributor kancelářských potřeb zadal vývojáři: "Chceme e-shop jako Alza." Vývojář připravil nabídku na 800 000 Kč. Po podrobnějším rozhovoru vyšlo najevo, že firma prodává B2B zákazníkům, má 200 produktů a potřebuje hlavně poptávkový formulář s možností přiložit ceník v PDF. Výsledné řešení stálo 80 000 Kč a splňuje 100 % reálné potřeby. Rozdíl byl v zadání.
Jak správně popsat funkce
Vývojáři snadno implementují to, co jim řeknete. Problém je, že vám implementují to doslova — ne to, co jste tím mysleli.
Vágní popis: "Chceme kontaktní formulář." Výsledek: formulář se třemi poli (jméno, e-mail, zpráva) a tlačítkem Odeslat.
Reálná potřeba: zákazník si vybere kategorii dotazu (servis / objednávka / obecný dotaz), formulář přiloží soubor do 5 MB, po odeslání dostane potvrzovací e-mail a žádost se automaticky zapisuje do CRM s přiřazením odpovědné osoby podle kategorie.
Nejlepší způsob, jak popsat funkci přesně, jsou uživatelské příběhy (user stories). Formát je jednoduchý: "Jako [typ uživatele] chci [akci], abych [dosáhl cíle]."
Příklady:
- "Jako zákazník chci filtrovat produkty podle kategorie a ceny, abych rychle našel to, co hledám."
- "Jako obchodní ředitel chci vidět přehled poptávek z webu za poslední měsíc, abych mohl vyhodnotit efektivitu kampaní."
- "Jako administrátor chci přidávat a editovat stránky bez zásahu vývojáře, abych nebyl závislý na externím dodavateli."
Každý uživatelský příběh pak rozvijte: co se zobrazí po akci? Co se stane, když akce selže? Jsou nějaké výjimky?
| Přístup | Příklad | Výsledek |
|---|---|---|
| Vágní požadavek | "Chceme přihlášení uživatelů" | Základní login bez jakýchkoli oprávnění |
| Uživatelský příběh | "Jako zákazník chci se přihlásit e-mailem, abych viděl historii svých objednávek" | Přihlášení + zákaznická sekce s objednávkami |
| Kompletní specifikace | Příběh + reset hesla + omezení počtu pokusů + 2FA | Funkční systém připravený pro produkci |
Co se stane, když zadání vynecháte
Scope creep. Česky: plíživé rozrůstání rozsahu. Projekt začne jako "jednoduchý firemní web", a za tři měsíce řešíte zákaznický portál, který nikdo nepopsal, ale "přece je to logické, ne?"
Každá nová funkce, která se přidá po zahájení projektu, je dražší než tatáž funkce v zadání. Důvod je jednoduchý: vývojář musí přepracovat to, co už udělal, přizpůsobit architekturu a otestovat vše znovu.
Příklad z praxe: Brněnská marketingová agentura zadala web: landing page pro jeden produkt, formulář pro poptávku, textový obsah dodají sami. Projekt byl oceněný na 6 týdnů. Ve třetím týdnu přišel požadavek na blog. Ve čtvrtém na vícejazyčnou verzi. V pátém na interaktivní kalkulačku ceny. Žádný z těchto požadavků nebyl v zadání. Projekt skončil po čtyřech měsících a na dvojnásobku rozpočtu. Agentura nebyla spokojená. Vývojář byl vyčerpaný. Přitom stačilo před zahájením projekt správně pojmenovat.
Dalším důsledkem chybějícího zadání je zklamání z výsledku. Vývojář odvedl přesně to, co mu bylo zadáno — ale to nestačí, protože "přece bylo jasné, že to tak nemyslíme". Tato věta je v projektovém řízení nejdražší věta vůbec.
Jak zadání připravit společně s vývojářem
Dobré zadání nevzniká ve vakuu. Nejlepší postup je iterativní: vy připravíte hrubou verzi, vývojář ji okomentuje, vy upřesníte.
Začněte strukturovaným workshopem. Dvě až tři hodiny s klíčovými lidmi z vaší strany — ne e-mailová diskuse, ale živý rozhovor. Projděte cíle, cílovou skupinu, hlavní funkce a priority. Výsledkem by měl být seznam funkčních celků a jejich priorita.
Nechte vývojáře klást otázky. Dobrý vývojář nebo agentura bude klást nepříjemné otázky: "Co se stane, když zákazník zapomene heslo?", "Jak řešíte vrácení zboží?", "Kdo bude web spravovat po spuštění?" Tyto otázky nejsou obtěžování — jsou to věci, které vás budou bolet za půl roku, pokud na ně teď neodpovíte.
Definujte akceptační kritéria. Pro každou klíčovou funkci si předem stanovte, jak poznáte, že je hotová správně. "Kontaktní formulář funguje" je příliš vágní. "Formulář odešle e-mail na info@firma.cz, uloží záznam do CRM a zobrazí poděkování do 3 sekund" je konkrétní.
Praktický tip: Zadání si nechte odložit na dva dny a pak ho znovu přečtěte. Každý požadavek, kde si nejste jistí, co přesně vývojář postaví, je požadavek, který je potřeba upřesnit.
Shrnutí: minimální obsah funkčního zadání
| Část zadání | Proč je důležitá |
|---|---|
| Cíle webu s metrikami | Definuje úspěch projektu |
| Cílová skupina | Určuje UX a obsah |
| Prioritizovaný seznam funkcí | Zabraňuje scope creep |
| Designové reference s komentářem | Zarovná vizuální očekávání |
| Technické integrace | Odhalí skrytou komplexitu |
| Plán obsahu (kdo, co, kdy) | Zabrání zablokování projektu |
| Termíny a rozpočtový rámec | Umožní realistický odhad |
| Akceptační kritéria | Definuje "hotovo" |
V BASAD Studios pomáháme klientům projít přípravou zadání ještě před tím, než začneme cokoliv stavět — protože víme, že hodina dobrého briefingu ušetří týdny práce. Pokud chystáte nový web a nechcete opakovat chyby, které jsme popsali výše, ozvěte se nám nebo se podívejte na naši službu tvorby webových stránek.