Nápad na aplikaci může být jednoduchý: objednávky pro zákazníky, přehled zakázek pro tým nebo rezervace termínů. Rozdíl mezi rychle spuštěným produktem a projektem, který se prodraží, často určuje jediná věc - co obsahuje zadání aplikace. Nemusí mít padesát stran ani technický jazyk. Musí ale vývojáři jasně říct, komu aplikace slouží, jaký problém řeší a co má umět jako první.

Dobré zadání šetří čas na obou stranách. Firma nemusí opakovaně vysvětlovat základní princip fungování a vývojový tým nemusí hádat, co klient myslel větou „potřebujeme něco jako konkurence“. Výsledkem je přesnější odhad, méně změn během práce a rozpočet, který dává smysl.

Začněte problémem, ne seznamem obrazovek

Nejdřív popište situaci, kterou má aplikace zlepšit. Například servisní firma dnes přijímá požadavky telefonicky a v e-mailech, technici nemají jednotný přehled a zákazník neví, kdy technik přijede. Aplikace má tento proces zjednodušit: zákazník odešle požadavek, dispečer jej přiřadí a technik vidí zakázku v mobilu.

Takový popis je cennější než požadavek na „mobilní aplikaci s přihlášením“. Přihlášení je funkce. Problém je důvod, proč za funkci vůbec platit. Když je cíl jasný, lze snáze rozhodnout, které části jsou nutné pro první verzi a které mohou počkat.

Stanovte také měřitelný výsledek. Může jít o méně telefonátů na podporu, rychlejší zpracování objednávek, více dokončených rezervací nebo lepší přehled nad provozem. Ne každá aplikace musí vydělávat přímo. Měla by však firmě šetřit čas, snižovat chybovost nebo přinášet zákazníkům pohodlnější službu.

Kdo bude aplikaci používat

V zadání uveďte konkrétní typy uživatelů a jejich práva. Jinak se bude aplikace navrhovat pro zákazníka, jinak pro pracovníka v terénu a jinak pro administrátora. Zákazník obvykle potřebuje rychle vytvořit objednávku a vidět její stav. Administrátor řeší úpravu služeb, ceny, kapacity, uživatele a přehled dat.

Nestačí napsat „aplikace bude pro klienty“. Pomůže stručně popsat, jak se uživatel do aplikace dostane, co udělá při první návštěvě a jak často ji bude používat. U interního systému je důležité vědět, zda s ním budou pracovat tři lidé v kanceláři, nebo padesát zaměstnanců na telefonech. To má vliv na ovládání, zabezpečení i rozsah administrace.

Pokud už existují různé role, napište je hned na začátek. Typicky jde o zákazníka, zaměstnance, vedoucího a správce. U každé role stačí několik vět: co smí zobrazit, co může upravit a co se jí nesmí zobrazit. Předejdete tak pozdějšímu překvapení, že například každý zaměstnanec vidí data všech zákazníků.

Co obsahuje zadání aplikace z pohledu funkcí

Jádrem zadání jsou funkce. Neznamená to sepsat každé tlačítko. Důležité je popsat hlavní scénáře použití přirozeným jazykem. Například: zákazník vybere službu, zvolí termín, potvrdí rezervaci a dostane potvrzení. Administrátor vidí rezervaci v přehledu, může ji upravit a zákazníkovi odešle zprávu o změně.

U každé funkce si položte jednoduchou otázku: co se má stát před ní, během ní a po ní? Pokud uživatel vytvoří objednávku, potřebuje být přihlášený? Má vyplnit adresu? Přijde mu e-mail nebo notifikace? Může objednávku stornovat? Tyto detaily často rozhodují o skutečné pracnosti.

Rozumné zadání rozděluje funkce na první verzi a další rozvoj. První verze, často označovaná jako MVP, má ověřit, že aplikace funguje pro reálné uživatele. Nemusí obsahovat každý nápad, který se během plánování objeví. Věrnostní program, pokročilé statistiky nebo automatizace pro deset výjimečných situací mohou přijít až ve chvíli, kdy základní proces přináší výsledky.

Tento přístup není o omezování ambicí. Je o kontrole investice. Menší první verzi lze rychleji otestovat, upravit podle reálného provozu a dále rozšiřovat bez placení za funkce, které nikdo nepoužije.

Popište současný proces a data

Aplikace málokdy vzniká ve vzduchoprázdnu. Firma už často pracuje s tabulkami, e-maily, účetním systémem, rezervačním kalendářem nebo databází zákazníků. Zadání by mělo vysvětlit, co se děje dnes a kde proces drhne.

Přiložit můžete ukázku formuláře, screenshot tabulky nebo jednoduchý nákres postupu. Vývojář nemusí dostat dokonalý dokument. Potřebuje pochopit tok informací: odkud data přicházejí, kdo je upravuje, kde se ukládají a kdo je následně používá.

Důležitá je i kvalita dat. Pokud má aplikace načítat ceník z tabulky, je dobré vědět, kdo tabulku aktualizuje a zda má jednotnou strukturu. Pokud mají zákazníci existující účty, popište, kde jsou jejich údaje uloženy. Integrace na existující systémy mohou být velmi užitečné, ale patří mezi položky, které dokážou výrazně ovlivnit cenu i termín.

Platforma, obsah a napojení na jiné služby

V zadání uveďte, zda má jít o mobilní aplikaci pro Android a iPhone, webovou aplikaci v prohlížeči, nebo kombinaci obojího. Volba závisí na použití. Terénní pracovníci mohou potřebovat fotoaparát, polohu nebo práci bez stabilního internetu. Pro zákaznický portál často dobře funguje webová aplikace, kterou lze otevřít bez instalace.

Napište také, zda aplikace pracuje s platbami, mapami, notifikacemi, e-mailem, kalendářem nebo externím účetním či skladovým systémem. U každého napojení stačí uvést, co má přinést. „Napojení na platební bránu“ je příliš obecné. Přesnější je: zákazník zaplatí rezervaci kartou, aplikace uloží stav platby a administrátor vidí neuhrazené objednávky.

Nezapomeňte na obsah. Kdo dodá texty, fotografie, ceník, obchodní podmínky a logo? Vývoj může běžet rychle, ale projekt se často zastaví na čekání na podklady nebo rozhodnutí, kdo schválí finální podobu obrazovek.

Hranice projektu chrání rozpočet

Každé zadání by mělo obsahovat i to, co první verze dělat nebude. Je to praktická ochrana proti postupnému nabalování požadavků. Když se během vývoje objeví nový nápad, není nutné jej automaticky odmítnout. Stačí vyhodnotit, zda patří do aktuálního rozsahu, nebo do další etapy.

Uveďte orientační rozpočet a termín, pokud je znáte. Transparentní rozpočet není známka nízkých ambicí. Je to mantinel, podle kterého se volí rozsah a technologické řešení. Aplikace od 35 000 Kč může dávat smysl pro jednodušší první verzi, nikoliv pro rozsáhlý systém s několika integracemi, platbami a desítkami uživatelských rolí.

Cena se neodvíjí jen od počtu obrazovek. Záleží na logice na pozadí, správě uživatelů, bezpečnosti, propojení s dalšími službami i kvalitě vstupních dat. Rychlý AI vývoj může snížit čas potřebný na opakující se práci, ale nenahradí rozhodnutí o tom, co má aplikace řešit a jak se má chovat v reálném provozu.

Jak poznáte, že je hotovo

Do zadání patří základní kritéria převzetí. Nejde o právnický dokument, ale o jasnou dohodu. Například zákazník dokáže vytvořit rezervaci, administrátor ji vidí v přehledu, potvrzení se odešle na e-mail a aplikace funguje na dohodnutých zařízeních.

Stanovte, kdo bude testovat a kdo má poslední slovo při schválení. U menší firmy je to často majitel nebo provozní manažer. U většího týmu je vhodné určit jednu odpovědnou osobu, která sbírá připomínky a předává je přehledně. Deset protichůdných komentářů od deseti lidí vývoj nezrychlí.

Po spuštění počítejte s krátkým obdobím ověřování. Reální uživatelé často ukážou drobnosti, které se při plánování neobjevily. To není selhání zadání. Dobré zadání vytváří pevný základ, na kterém lze změny posuzovat podle přínosu, ne podle momentálního dojmu.

Zadání nemusíte psát jako vývojář

Pro kvalitní začátek nepotřebujete znát programovací jazyky ani kreslit hotový design. Připravte popis problému, typy uživatelů, hlavní postupy, dostupné podklady a představu o rozpočtu. Pokud něco nevíte, napište to otevřeně. Právě nejasná místa jsou vhodným tématem pro úvodní konzultaci, ne důvodem projekt odkládat.

VV Software při přípravě aplikací pracuje s tím, co má pro podnikání skutečnou hodnotu: rychle ověřitelný rozsah, moderní výstup a rozumně nastavené náklady. Když je zadání konkrétní, lze rychleji navrhnout funkční první verzi místo dlouhého plánování bez výsledku.

Nejlepší chvíle pro sepsání zadání je ještě předtím, než začnete porovnávat nabídky. Stačí jedna až dvě stránky napsané vlastními slovy. Jasný problém, jasný uživatel a jasná první verze dají aplikaci mnohem pevnější start než dlouhý seznam funkcí bez priorit.