Jak připravit zadání digitálního produktu: praktický checklist

Problém a cíle

Digitální produkt má smysl tehdy, když řeší konkrétní problém uživatele nebo byznysu – bez pojmenovaného problému se obtížně posuzuje, jestli navržené řešení skutečně pomáhá, nebo jen přidává funkce.

Cíl produktu by měl jít propojit s měřitelným dopadem, i když se přesný způsob měření dořeší až v sekci analytiky.

• ›Popište problém, který má produkt řešit, a pro koho ho řeší.
• ›Uveďte obchodní cíl, kterému má produkt sloužit (např. snížení nákladů na obsluhu, nový zdroj příjmů, zrychlení interního procesu).
• ›Popište, jak dnes uživatelé nebo firma problém řeší bez tohoto produktu.

Uživatelé a role

Digitální produkt obvykle slouží více typům uživatelů s odlišnými potřebami a oprávněními – zadání by mělo tyto skupiny popsat, ne mluvit jen o „uživateli“ obecně.

• ›Vyjmenujte hlavní typy uživatelů produktu (např. koncový zákazník, administrátor, obchodní zástupce, externí partner).
• ›Popište, co je pro každou skupinu hlavní motivací k použití produktu.
• ›Uveďte, zda se očekává výrazně odlišná úroveň digitální gramotnosti nebo technického vybavení mezi skupinami.

Scénáře a klíčové úlohy

Funkční rozsah se snáz navrhuje, když je popsaný přes konkrétní scénáře a úlohy, které chce uživatel splnit, ne přes seznam obrazovek nebo funkcí bez kontextu.

• ›Popište klíčové scénáře užívání produktu – co chce uživatel udělat od začátku do konce (např. objednat, schválit žádost, nahlásit problém).
• ›Uveďte, které scénáře jsou nejčastější a které nejdůležitější, pokud se liší.
• ›Zmiňte výjimečné nebo chybové stavy, které je potřeba v návrhu zohlednit (např. co se stane, když platba selže nebo uživatel nemá oprávnění).

Funkční rozsah a MVP vs. plný rozsah

Zadání by mělo rozlišovat mezi minimálním rozsahem, který produkt potřebuje pro první spuštění, a plným rozsahem, ke kterému se má postupně dojít. Bez tohoto rozlišení hrozí, že se první verze zdrží čekáním na funkce, které nejsou pro spuštění nutné.

• ›Vyjmenujte funkce, bez kterých produkt nedává smysl spustit (MVP).
• ›Vyjmenujte funkce, které jsou žádoucí, ale mohou počkat na další fázi.
• ›Uveďte, podle čeho se rozhoduje o zařazení funkce do MVP – podle scénářů, cíle, nebo dostupné kapacity.

Pokud zadavatel neumí sám rozsah rozdělit, je vhodnější popsat scénáře a cíl a rozdělení nechat navrhnout dodavateli, než rozsah odhadovat bez opory v datech.

Data a datový model

Digitální produkt obvykle pracuje s daty, která už ve firmě existují, nebo s daty, která teprve vzniknou. Zadání by mělo popsat, jaká data produkt potřebuje a odkud pocházejí.

• ›Popište hlavní typy dat, se kterými má produkt pracovat (např. zákazníci, objednávky, produkty, dokumenty).
• ›Uveďte, zda tato data už existují v jiném systému, nebo vznikají nově přímo v produktu.
• ›Zmiňte požadavky na historii dat, verzování nebo archivaci, pokud jsou důležité.

Integrace

Produkt málokdy funguje izolovaně – obvykle se propojuje s dalšími systémy firmy. Zadání by mělo vyjmenovat, s čím se má produkt propojit, i když detailní technické řešení integrace navrhuje dodavatel.

• ›Vyjmenujte systémy, se kterými se má produkt propojit (např. CRM, ERP, platební brána, e-mailový nástroj, autentizace).
• ›Uveďte, zda k daným systémům existuje dokumentované rozhraní, nebo je potřeba ho teprve prověřit.
• ›Popište, kdo za jednotlivé systémy na straně zadavatele odpovídá a kdo může poskytnout přístupy nebo dokumentaci.

Oprávnění a role v systému

Pokud produkt rozlišuje více rolí uživatelů, zadání by mělo popsat, co která role smí a nesmí dělat – ne jen vyjmenovat role podle názvu.

• ›Popište, jaká oprávnění má mít každá role v produktu (co vidí, co může měnit, co může schvalovat).
• ›Uveďte, zda se role mohou kombinovat u jedné osoby, nebo jsou striktně oddělené.
• ›Zmiňte, jak se má řešit správa uživatelů a přidělování rolí po spuštění produktu.

Zařízení a platformy

Volba mezi webovou aplikací, mobilní aplikací nebo jejich kombinací ovlivňuje rozsah i způsob práce s produktem. Zadání by mělo popsat, na jakých zařízeních a v jakých podmínkách budou uživatelé produkt používat, a volbu platformy nechat na doporučení dodavatele.

• ›Popište, na jakých zařízeních budou uživatelé produkt používat (počítač, mobil, tablet, terminál) a v jakém prostředí (kancelář, terén, sklad).
• ›Uveďte, zda je nutná práce offline nebo se slabým připojením.
• ›Zmiňte, pokud existuje pevný požadavek na konkrétní platformu (např. z důvodu existující infrastruktury), a proč.

Obsah

I aplikace, která není primárně obsahová, obsahuje texty rozhraní, notifikace, nápovědu nebo chybová hlášení. Zadání by mělo popsat, kdo tento obsah připravuje a v jakých jazycích má existovat.

• ›Uveďte, v jakých jazykových verzích má produkt fungovat.
• ›Popište, kdo připravuje texty rozhraní, notifikace a nápovědu – zadavatel, nebo dodavatel.
• ›Zmiňte, zda existuje terminologický slovník nebo zavedené pojmy, které je potřeba v produktu dodržet.

Přístupnost

Přístupnost by neměla být dodatečnou úpravou na konci projektu, ale požadavkem, který je jasně pojmenovaný už v zadání – hlavně pokud produkt používá veřejnost nebo se na něj vztahují legislativní požadavky.

• ›Uveďte, zda se na produkt vztahují požadavky na přístupnost (např. u produktů pro veřejnou správu nebo širokou veřejnost).
• ›Popište, zda existují specifické skupiny uživatelů se zvláštními potřebami, se kterými je potřeba počítat.
• ›Zmiňte, pokud má být přístupnost ověřena testováním nebo auditem před spuštěním.

Analytika a měření

Aby šlo posoudit, zda produkt naplňuje cíl popsaný v úvodu zadání, potřebuje mít dodavatel jasno, co se má měřit a jaký přístup k datům bude mít.

• ›Uveďte, jaké metriky mají souviset s cílem produktu (např. dokončené objednávky, míra dokončení klíčového scénáře, počet aktivních uživatelů).
• ›Popište, zda existuje analytický nástroj, který se má použít, nebo se má zvolit až v návrhu.
• ›Zmiňte, kdo bude mít přístup k datům a reportům po spuštění produktu.

Právní a bezpečnostní požadavky

Produkty pracující s osobními nebo citlivými daty podléhají právním a bezpečnostním požadavkům, které je potřeba popsat už v zadání, ne řešit až při spuštění.

• ›Uveďte, zda produkt zpracovává osobní údaje a jaké kategorie dat jsou citlivé (např. platební údaje, zdravotní data).
• ›Popište, zda se na produkt vztahují konkrétní regulace nebo interní bezpečnostní politiky firmy.
• ›Zmiňte požadavky na uchovávání dat, zálohování a řešení bezpečnostních incidentů, pokud existují.

Provoz a podpora

Zadání by mělo popsat, co se má stát po spuštění produktu – kdo řeší provoz, technickou podporu a další rozvoj, aby se tato odpovědnost neřešila až ve chvíli, kdy produkt běží a něco nefunguje.

• ›Uveďte, kdo bude po spuštění zajišťovat provoz a technickou podporu produktu.
• ›Popište, jak se má řešit hlášení a náprava chyb po spuštění.
• ›Zmiňte, zda se počítá s dalším rozvojem produktu po prvním spuštění, a kdo ho bude zajišťovat.

Rozpočet

Zadání by mělo uvést orientační rozpočtový rámec, ve kterém se dá navrhnout realistický rozsah produktu – ne jako závazný detailní rozpis, ale jako vodítko pro posouzení, zda je požadovaný rozsah reálný.

• ›Uveďte orientační rozpočtový rámec na vývoj produktu.
• ›Popište, zda je rozpočet fixní, nebo se může upravit podle navrženého rozsahu.
• ›Zmiňte, zda je rozpočet oddělený pro návrh, vývoj a následný provoz, nebo se počítá jako celek.

Termín

Termín spuštění by měl být v zadání uvedený spolu s důvodem, proč je pevný nebo orientační – umožní to posoudit, zda je navrhovaný rozsah v daném termínu reálný.

• ›Uveďte předpokládaný termín spuštění produktu.
• ›Popište, zda je termín vázaný na konkrétní událost (např. sezónní špička, marketingová kampaň, konec podpory starého systému).
• ›Zmiňte, zda je možné termín posunout, pokud by ohrozil kvalitu nebo rozsah MVP.

Odpovědnosti

Vývoj digitálního produktu vyžaduje součinnost na straně zadavatele – dodání podkladů, schvalování návrhů, testování. Zadání by mělo popsat, kdo tuto roli na straně zadavatele zastává.

• ›Uveďte, kdo je hlavní kontaktní osobou zadavatele pro rozhodování o rozsahu a schvalování návrhů.
• ›Popište, kdo se bude podílet na testování produktu před spuštěním.
• ›Zmiňte, kdo odpovídá za dodání podkladů, přístupů a dat potřebných pro vývoj.

Akceptační kritéria

Akceptační kritéria určují, podle čeho se pozná, že je produkt (nebo jeho jednotlivá část) hotový a odpovídá zadání. Bez nich se hodnocení hotovosti stává subjektivní.

• ›Popište, jak se ověří, že klíčové scénáře fungují podle zadání.
• ›Uveďte, zda existují konkrétní podmínky, za kterých je produkt považován za připravený ke spuštění (např. zvládnuté testování, proškolení uživatelů).
• ›Zmiňte, kdo akceptaci provádí a jakým způsobem se dokumentuje.

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

• ✕Zadání popisuje seznam obrazovek nebo funkcí bez vazby na problém, cíl nebo scénáře uživatelů.
• ✕Chybí rozlišení mezi MVP a plným rozsahem, takže se spuštění zdrží čekáním na funkce, které nejsou nutné hned.
• ✕Role a oprávnění uživatelů jsou popsané jen názvem, bez popisu, co která role skutečně smí.
• ✕Integrace na jiné systémy se objeví až v průběhu vývoje, protože nebyly zmíněné v zadání.
• ✕Přístupnost se řeší až na konci projektu, i když se na produkt vztahují požadavky na přístupnost.
• ✕Zadání neuvádí, jaké metriky mají souviset s cílem produktu, takže se úspěch po spuštění nedá objektivně vyhodnotit.
• ✕Chybí popis odpovědností na straně zadavatele, takže se testování a schvalování zpožďuje kvůli nejasné roli.
• ✕Akceptační kritéria nejsou definovaná předem a hotovost produktu se posuzuje až na konci subjektivně.

Checklist zadání

• ✓Je popsaný problém a obchodní cíl, který má produkt řešit?
• ✓Jsou vyjmenovaní hlavní typy uživatelů a jejich role?
• ✓Jsou popsané klíčové scénáře a úlohy z pohledu uživatele?
• ✓Je jasné rozdělení funkcí na MVP a plný rozsah?
• ✓Jsou popsaná data, se kterými má produkt pracovat, a jejich zdroj?
• ✓Jsou vyjmenované systémy, se kterými se má produkt integrovat?
• ✓Je popsané, co jednotlivé role v systému smí a nesmí dělat?
• ✓Je uvedené, na jakých zařízeních a v jakém prostředí budou uživatelé produkt používat?
• ✓Je jasné, kdo připravuje textový obsah a v jakých jazycích má produkt fungovat?
• ✓Jsou uvedené požadavky na přístupnost, pokud se na produkt vztahují?
• ✓Je popsané, jaké metriky budou souviset s cílem produktu?
• ✓Jsou uvedené právní a bezpečnostní požadavky na zpracování dat?
• ✓Je popsané, kdo bude po spuštění zajišťovat provoz a podporu?
• ✓Je uvedený orientační rozpočtový rámec a předpokládaný termín spuštění?
• ✓Jsou jasně rozdělené odpovědnosti mezi zadavatelem a dodavatelem?
• ✓Jsou definovaná akceptační kritéria pro posouzení hotovosti produktu?

Časté otázky

Je tento průvodce totéž jako vzorové zadání digitálního produktu?

Ne. Tento průvodce vysvětluje, jak zadání připravit a co má obsahovat. Vyplněný modelový příklad zadání najdete samostatně jako ukázku zadání pro UX/UI návrh digitálního produktu.

Má zadání rozhodnout, zda vznikne webová, nebo mobilní aplikace?

Zadání by mělo popsat uživatele, scénáře a prostředí použití. Volbu mezi webovou a mobilní aplikací je vhodné nechat na doporučení dodavatele podle těchto vstupů, případně si předem projít srovnání obou přístupů.

Jak rozdělit funkce mezi MVP a plný rozsah, když si nejsem jistý?

Stačí popsat scénáře a cíl produktu a nechat rozdělení navrhnout dodavateli. Odhadovat rozsah MVP bez opory ve scénářích obvykle vede k podcenění nebo naopak zbytečnému rozšíření prvního spuštění.

Musí zadání obsahovat technické řešení integrací?

Ne, stačí vyjmenovat systémy, se kterými se má produkt propojit, a uvést kontaktní osobu, která k nim může poskytnout přístup nebo dokumentaci. Technické řešení integrace navrhuje dodavatel.

Kdy je potřeba v zadání řešit přístupnost?

Přístupnost je vhodné zmínit vždy, hlavně pokud produkt používá veřejnost nebo se na něj vztahují legislativní požadavky. Řešit ji až na konci projektu obvykle znamená dodatečné úpravy návrhu.

Co když firma neumí sama definovat akceptační kritéria?

V takovém případě je vhodné popsat klíčové scénáře a funkční rozsah a akceptační kritéria k nim nechat navrhnout společně s dodavatelem před zahájením vývoje, ne je odkládat až na konec projektu.

Má rozpočet v zadání odpovídat pevné ceně?

Rozpočet slouží jako orientační rámec pro posouzení reálnosti požadovaného rozsahu, ne jako závazná pevná cena. Skutečná cena vychází až z navrženého rozsahu a technického řešení.