Na začátku projektu často slyšíme: „Nevím, jak to přesně popsat.“ Je to naprosto v pořádku. Zadání nemusí psát programátor, nemusí být technické a už vůbec nemusí mít desítky stran. Jeho úkolem je, aby vývojáři pochopili váš byznys, vaše lidi a vaše cíle a mohli navrhnout řešení, které dává smysl. Technické detaily se dají doplnit později, porozumění problému ne.
V tomto článku vás provedeme postupem, který se nám osvědčil. Nemusíte projít všechny body do posledního detailu. Každý z nich ale ušetří čas na obou stranách a sníží riziko, že vznikne aplikace, která sice funguje, ale neřeší to hlavní.
Proč na dobrém zadání tolik záleží
Vývoj softwaru je řetězec rozhodnutí. Jak bude vypadat databáze, které obrazovky aplikace bude mít, co se stane, když uživatel udělá chybu, s jakými systémy se bude propojovat. Každé takové rozhodnutí stojí na předpokladech o tom, jak vaše firma funguje. Když jsou předpoklady špatné, chyba se často ukáže až ve chvíli, kdy aplikaci začnou používat skuteční lidé. Oprava je pak výrazně pracnější, než kdyby se na ni přišlo na začátku.
Dobré zadání proto neslouží jen k odhadu náročnosti. Je to společný základ, ke kterému se vy i vývojáři vracíte během celého projektu. Pomáhá rozhodovat, co má přednost, co se dá odložit a co do projektu vůbec nepatří.
Začněte problémem, ne funkcemi
Nejčastější chybou je začít seznamem funkcí: „Chceme přihlášení, tabulku objednávek, export do Excelu a notifikace.“ Takový seznam je užitečný, ale neříká, proč tyto funkce potřebujete. Místo toho nejdřív popište, co vás dnes trápí. Třeba: „Objednávky chodí e-mailem, ručně je přepisujeme do tabulky a občas se nějaká ztratí nebo se vyřídí dvakrát.“
Z takové věty vývojář pozná mnohem víc. Ví, že klíčová je spolehlivost a přehled o stavu objednávky, ne samotný formulář. Může navrhnout, aby objednávky do systému chodily automaticky, aby každá měla jasný stav a aby bylo vidět, kdo na ní pracuje. Často se ukáže, že nejlepší řešení vypadá jinak, než jste původně čekali, a bývá i jednodušší.
Pomoci vám mohou tyto otázky:
Co dnes děláte ručně, opakovaně a neradi?
Kde vznikají chyby, zpoždění nebo nedorozumění?
Na co si stěžují zákazníci nebo kolegové?
Co by se stalo, kdybyste problém neřešili ještě rok?
Popište, kdo bude aplikaci používat
Zákazník na mobilu, obchodník v terénu a účetní u počítače mají úplně jiné potřeby. Zákazník chce rychle a bez zbytečné registrace dokončit objednávku. Obchodník potřebuje vidět data i se slabým signálem. Účetní ocení přehledné exporty a jistotu, že čísla sedí. Pokud tyto skupiny v zadání chybí, vývojáři je budou muset odhadovat.
Uveďte všechny skupiny uživatelů a ke každé napište:
co v aplikaci potřebuje udělat a co by naopak vidět neměla,
jak často s aplikací bude pracovat, jestli denně, nebo jednou za měsíc,
na jakém zařízení a v jakém prostředí, například v kanceláři, ve skladu nebo na cestách,
jak je zběhlá v práci s počítačem.
Z toho se odvodí oprávnění, design i technologie. Aplikace pro skladníky v pracovních rukavicích bude mít velká tlačítka a minimum psaní. Interní nástroj pro analytika snese hustší obrazovky plné dat.
Sepište hlavní scénáře
Scénář je krátký příběh: kdo, co a proč dělá a jak to dopadne. Na rozdíl od seznamu funkcí ukazuje souvislosti. Například:
Zákazník si na webu vybere termín, zaplatí rezervaci online a dostane potvrzení e-mailem.
Recepční vidí přehled rezervací na celý týden a může termín přesunout. Zákazník se o změně dozví automaticky.
Majitel dostane každé pondělí souhrn tržeb a obsazenosti za minulý týden.
Pět až deset takových scénářů obvykle stačí k tomu, aby bylo jasné, co má aplikace umět. Nezapomeňte ani na méně příjemné situace: co když zákazník rezervaci zruší, platba neprojde nebo recepční omylem smaže termín? Právě výjimky bývají v projektech nejpracnější a je dobré o nich mluvit včas.
U každého scénáře se hodí poznamenat, jak se dnes řeší. I popis typu „posíláme si to e-mailem a pak to někdo přepíše“ je cenná informace, protože ukazuje, odkud data přicházejí a kdo s nimi pracuje.
Ujasněte si, co je nutné a co by bylo hezké
Během přípravy zadání nápady přibývají. To je dobře, ale ne všechno musí být v první verzi. Rozdělte požadavky do tří skupin:
Nutné: bez čeho aplikace nemá smysl a nedá se používat.
Další verze: co výrazně pomůže, ale dá se doplnit po spuštění.
Nápady do budoucna: co by bylo zajímavé, ale zatím to nikdo nepotřebuje.
První verze by měla obsahovat jen první skupinu. Rychleji se dostanete k uživatelům, dříve začnete šetřit čas nebo vydělávat a další vývoj můžete řídit podle skutečné zpětné vazby, ne podle odhadů. Velmi často se ukáže, že funkce, které vypadaly na začátku zásadně, nikdo nepoužívá, a naopak vznikne potřeba, na kterou nikdo nepomyslel.
Nezapomeňte na návaznosti a data
Aplikace málokdy žije sama. Napište, s čím má spolupracovat: účetní systém, e-shop, platební brána, sklad, CRM, firemní e-mail nebo třeba tabulky, které dnes používáte. U každého systému se hodí vědět, jestli má rozhraní pro napojení (API), kdo ho spravuje a jestli jde jen o čtení dat, nebo i o jejich zápis.
Stejně důležitá jsou data, která už máte. Budete do nové aplikace převádět zákazníky, produkty nebo historii objednávek? V jakém formátu jsou a jak jsou čisté? Převod dat bývá podceňovaný, přitom na něm často závisí, jestli lidé novou aplikaci přijmou. Nikdo nechce začínat s prázdným systémem, když měl dřív všechno po ruce.
Propojení s dalšími systémy a převod dat jsou nejčastějším zdrojem překvapení, proto je dobré o nich vědět hned na začátku.
Myslete na provoz, bezpečnost a pravidla
Kromě toho, co má aplikace dělat, je důležité i to, jak má fungovat. Zamyslete se nad těmito otázkami:
Kdo smí vidět jaká data a kdo je smí měnit?
Pracujete s osobními údaji, na které se vztahuje GDPR, nebo s citlivými firemními informacemi?
Musí aplikace fungovat i mimo pracovní dobu a jak rychle je potřeba řešit výpadek?
Je potřeba vědět, kdo a kdy co změnil?
Má být aplikace jen v češtině, nebo i v dalších jazycích?
Na tyto otázky nemusíte znát odpověď. Stačí, když je zmíníte. Vývojář pak ví, na co se má zeptat a s čím počítat v návrhu.
Přidejte příklady a podklady
Obrázek často řekne víc než stránka textu. Do zadání přiložte cokoli, co ukazuje, jak to dnes funguje nebo jak byste si to představovali:
snímky obrazovky aplikací, které se vám líbí nebo naopak nelíbí,
vzory dokumentů, například fakturu, objednávku nebo předávací protokol,
export dat nebo ukázku tabulky, se kterou dnes pracujete,
fotku papírového formuláře nebo nákres na papíře.
Podklady nemusí být dokonalé. Stačí, když ukazují realitu. Každý takový příklad ušetří hodiny dohadování a sníží riziko, že si obě strany pod stejným slovem představí něco jiného.
Určete, podle čeho poznáte úspěch
Co se má po spuštění změnit? Méně ruční práce, méně chyb, rychlejší vyřízení objednávky, víc poptávek z webu, lepší přehled o zakázkách. Když cíl pojmenujete předem, můžete se k němu při vývoji vracet a rozhodovat, které funkce mají přednost. A po spuštění snadno ověříte, jestli se investice vyplatila.
Ideální je, když cíl jde nějak změřit, třeba časem stráveným určitou činností nebo počtem chyb. Pokud to nejde, stačí i popis: „Chceme, aby vedoucí viděl stav všech zakázek na jedné obrazovce a nemusel obvolávat kolegy.“
Jednoduchá osnova zadání
Pokud nevíte, kde začít, můžete použít tuto osnovu. Každý bod klidně stačí popsat pár větami:
Kdo jsme a co děláme.
Jaký problém chceme vyřešit a proč právě teď.
Kdo bude aplikaci používat.
Hlavní scénáře, včetně výjimek.
Co je nutné pro první verzi a co může počkat.
S jakými systémy a daty má aplikace pracovat.
Požadavky na bezpečnost a provoz.
Příklady a podklady.
Jak poznáme, že se projekt povedl.
Termíny, na kterých záleží, například sezóna nebo plánovaná akce.
Zbytek doladíme spolu
Zadání je výchozí bod, ne smlouva vytesaná do kamene. Na úvodní konzultaci s vámi projdeme scénáře, doplníme, na co se zapomnělo, a upozorníme na místa, která mohou být technicky náročná. Navrhneme řešení i postup po etapách, abyste co nejdříve měli v rukou něco, co se dá používat.
Pokud zadání zatím nemáte, nevadí. Napište nám pár vět o tom, co plánujete, a začneme od toho. Správné otázky vám rádi položíme sami.