Jak sestavit technické zadání pro vývoj aplikace

Jedním z nejčastějších důvodů, proč softwarové projekty překročí rozpočet, se zpozdí nebo skončí úplným neúspěchem, je špatně připravené technické zadání. Nebo žádné zadání vůbec. "Chceme aplikaci jako Uber, ale pro venčení psů" není technické zadání -- je to nápis na ubrousku, ze kterého každý vývojář pochopí něco jiného.

Dobrá zpráva je, že nepotřebujete být programátor, abyste vytvořili kvalitní technické zadání. Potřebujete systematický přístup, jasné myšlení o tom, co má aplikace dělat, a odvahu nechat některé věci otevřené. V tomto článku vás provedeme procesem krok za krokem.

Co je technické zadání a proč ho potřebujete

Technické zadání (někdy nazývané specifikace, brief nebo SRS -- Software Requirements Specification) je dokument, který popisuje, co má software dělat. Ne jak to má dělat (to je úloha vývojářů), ale co -- jaké problémy řešit, jaké funkce nabízet, jakého uživatele obsluhovat.

Kvalitní zadání plní tři klíčové funkce:

1. Sjednocuje očekávání. Zadavatel a vývojářský tým mají společné chápání toho, co se staví.
2. Umožňuje realistický odhad. Bez jasného zadání je každý časový a cenový odhad hádem -- a obvykle hádem optimistickým.
3. Slouží jako reference. Když se v průběhu projektu objeví nejasnosti (a objeví se), zadání je místo, kam se všichni mohou vrátit.

Krok 1: Popište problém, ne řešení

Začněte tím, že jasně artikulujete, jaký problém aplikace řeší a pro koho.

Špatný začátek

"Chceme mobilní aplikaci s registrací přes email a Facebook, dashboardem s grafy, push notifikacemi a možností platit kartou."

Lepší začátek

"Naši zákazníci jsou malé a střední firmy, které spravují 5-50 služebních vozidel. Aktuálně sledují náklady v Excelu, což vede k nepřesnostem a ztrátě přehledu. Aplikace jim má umožnit jednoduše evidovat tankování, servisy a pojištění a automaticky generovat měsíční přehled nákladů."

První verze je seznam funkcí bez kontextu. Druhá verze říká, pro koho aplikace je, jaký problém řeší a co je očekávaný výsledek. Z toho vývojář může posoudit, jaké funkce dávají smysl a jaké ne.

Krok 2: Definujte uživatele a jejich role

Každá aplikace má více typů uživatelů. Identifikujte je a popište, co každý od aplikace očekává.

Příklad

• Řidič -- zadává tankování a servisy, vidí historii svého vozidla
• Flotilový manažer -- vidí přehled všech vozidel, generuje reporty, spravuje řidiče
• Účetní -- exportuje data pro účetnictví, vidí náklady podle středisek
• Administrátor -- spravuje uživatelské účty, nastavuje oprávnění

Pro každou roli si položte otázku: "Co tato osoba chce od aplikace a proč?" Odpovědi formují základní funkcionalitu.

Krok 3: Pište user stories, ne technické požadavky

User stories jsou způsob, jak popsat funkcionalitu z pohledu uživatele. Formát je jednoduchý:

Jako [role] chci [co], abych [proč].

Příklady

• Jako řidič chci zadat tankování pomocí fotky účtenky, abych nemusel přepisovat data ručně.
• Jako flotilový manažer chci vidět měsíční náklady po vozidlech, abych mohl identifikovat neobvykle vysoké náklady.
• Jako účetní chci exportovat data do CSV, abych je mohla importovat do účetního systému.

User stories jsou silné, protože:

• Udržují fokus na uživateli, ne na technologii
• Jsou srozumitelné pro netechnické lidi
• Přirozeně vedou k diskuzi o tom, co je skutečně důležité

Kolik user stories potřebujete?

Pro typický MVP (minimální životaschopný produkt) očekávejte 20-50 user stories. Pro kompletní produkt 50-200. Pokud máte více než 200, pravděpodobně definujete příliš podrobně a měli byste seskupit.

Krok 4: Přidejte akceptační kritéria

Každá user story potřebuje akceptační kritéria -- měřitelné podmínky, podle kterých poznáme, že funkce funguje správně.

Příklad

User story: Jako řidič chci zadat tankování pomocí fotky účtenky.

Akceptační kritéria:

• Uživatel může vyfotit účtenku přímo v aplikaci nebo nahrát existující fotku
• Systém z fotky automaticky rozpozná datum, částku a počet litrů (OCR)
• Uživatel může rozpoznaná data upravit před uložením
• Pokud OCR selže, uživatel může data zadat ručně
• Tankování se automaticky přiřadí k vozu, ke kterému je řidič přiřazen
• Po uložení se zobrazí potvrzení a záznam se objeví v historii

Akceptační kritéria eliminují nejistotu. Bez nich se může stát, že vývojář implementuje funkci jinak, než si zadavatel představoval, a nikdo to nezjistí až do akceptačního testování.

Krok 5: Wireframy, ne pixel-perfect designy

Wireframy jsou jednoduché drátové modely obrazovek, které ukazují rozložení prvků a navigaci. Nepotřebujete grafického designéra -- stačí ruční nákres nebo jednoduchý nástroj.

Proč wireframy a ne hotové designy

• Wireframy jsou rychlé. Nakreslíte je za hodiny, ne dny
• Wireframy jsou levné na změnu. Přeškrtněte a nakreslete znovu
• Wireframy neodvádějí od podstaty. Nikdo neřeší barvu tlačítka, všichni řeší, jestli tam to tlačítko vůbec patří
• Designy mohou přijít později. Když je jasné, co aplikace dělá, designér to vizuálně dotvoří

Doporučené nástroje

• Papír a tužka -- nejrychlejší, nejlevnější, nejflexibilnější
• Excalidraw -- bezplatný, jednoduchý, skvělý pro sdílení
• Figma (free tier) -- pokud chcete něco propracovanějšího
• Balsamiq -- nástroj přímo určený pro wireframy

Ke každému wireframu přidejte krátký popis: co uživatel na této obrazovce dělá, jak se sem dostal a kam může pokračovat.

Krok 6: Definujte, co je mimo rozsah

Stejně důležité jako definovat, co aplikace má dělat, je explicitně říci, co dělat nemá. Toto předchází scope creep -- postupnému nabalování požadavků.

Příklad

Mimo rozsah první verze:

• Integrace s účetním systémem Pohoda (plánováno pro v2)
• Mobilní aplikace pro řidiče (v1 bude web, mobilní verze v2)
• Automatická predikce servisů na základě nájezdu
• Vícejazyková podpora

Tento seznam zachrání spoustu času a peněz. Když se uprostřed vývoje někdo zeptá "a nemohla by aplikace taky...," existuje jasná odpověď: "To je plánováno pro další verzi."

Co do zadání nepatří

Implementační detaily

Nepíšete: "Použijte PostgreSQL databázi s tabulkou vehicles a sloupci id, make, model, year." Píšete: "Systém musí uchovávat informace o vozidlech včetně značky, modelu, roku výroby a SPZ."

Výběr databáze, strukturu tabulek a technický návrh nechte na vývojářích. Vy definujete co, oni rozhodnou jak.

Konkrétní technologie (pokud k tomu nemáte důvod)

Nepíšete: "Aplikace bude v React Native s Node.js backendem a MongoDB." Píšete: "Aplikace musí fungovat na iOS i Androidu, musí zvládnout 500 souběžných uživatelů a data musí být zálohována denně."

Výjimka: pokud máte existující systém nebo tým se specifickými znalostmi, zmínka o preferované technologii je na místě.

Pixel-perfect vizuální návrh

Technické zadání není místo pro finální vizuální návrh. Wireframy ano, barvy a fonty ne. Vizuální design je separátní fáze, která následuje po schválení zadání.

Nejčastější chyby v technických zadáních

Po letech spolupráce s klienty na technických zadáních vidíme stále stejné vzorce:

1. Specifikace screenshotem

"Chceme to jako tady ta aplikace" s přiloženým screenshotem. Screenshot neukazuje logiku, datový model, edge case ani obchodní pravidla. Dva lidé se dívají na stejný screenshot a vidí dvě různé aplikace.

2. "Udělejte to jako X, ale jinak"

"Chceme to jako Airbnb, ale pro pronájem kancelářských prostor." To není zadání -- to je startovací bod pro konverzaci. Airbnb má tisíce funkcí. Které z nich chcete? Které ne? Co chcete jinak?

3. Příliš podrobné zadání

Zadání o 200 stránkách, které specifikuje každý pixel a každý chybový stav. Než ho dočtete, bude zastaralé. A nikdo ho nepřečte celé.

4. Příliš vágní zadání

"Aplikace pro správu projektů s obvyklými funkcemi." Jakými obvyklými? Jira má jiné "obvyklé funkce" než Trello. A obě se liší od Basecamp.

5. Ignorování nefunkčních požadavků

Kolik uživatelů bude aplikaci používat současně? Jaká je očekávaná doba odezvy? Musí aplikace fungovat offline? Jaký je požadovaný uptime? Tyto požadavky zásadně ovlivňují architekturu a náklady.

Zadání jako živý dokument

Technické zadání není vytesané do kamene. V průběhu vývoje se vždy objeví nové informace, změní se priority nebo se ukáže, že něco nedává smysl. To je normální a očekávané.

Jak s tím pracovat

• Verzujte dokument. Používejte Google Docs, Notion nebo Git -- cokoli, co umožňuje sledovat změny
• Pravidelné revize. Každý sprint nebo každých 14 dní projděte zadání a aktualizujte ho
• Change log. Každá změna by měla být zaznamenána s datem a důvodem
• Schvalovací proces. Větší změny by měly být explicitně schváleny oběma stranami

Šablona technického zadání

Pro začátek doporučujeme následující strukturu:

1. Úvod a cíle projektu -- jaký problém řešíme, pro koho, co je měřítko úspěchu
2. Uživatelské role -- kdo bude aplikaci používat
3. User stories s akceptačními kritérii -- co každý uživatel může dělat
4. Wireframy -- základní rozložení klíčových obrazovek
5. Nefunkční požadavky -- výkon, bezpečnost, dostupnost, škálovatelnost
6. Integrace -- externí systémy, se kterými aplikace komunikuje
7. Mimo rozsah -- co v této verzi neřešíme
8. Časový rámec a priority -- co je kritické pro MVP, co může počkat

Závěr

Kvalitní technické zadání není o tom napsat co nejvíce textu. Je o tom jasně komunikovat, co chcete, proč to chcete a pro koho to je. Dobré zadání šetří čas, peníze a nervy všem zúčastněným.

Neberte to jako jednorázový úkol, ale jako základní komunikační nástroj mezi vámi a vývojovým týmem. Investice do pořádného zadání se vrací mnohonásobně -- v přesnějších odhadech, méně nedorozuměních a v konečném výsledku v software, který skutečně řeší váš problém.

A pokud si na tvorbu zadání netroufáte sami, neznamená to neúspěch. Nastartovat projekt společně se zkušenými vývojáři, kteří vám pomohou formulovat požadavky a upozorní na skryté pasti, je naopak cesta, jak se vyhnout nejnákladnějším chybám na samém začátku.