Průvodce

Co si připravit před vývojem interní aplikace

Dobré zadání interní aplikace nevzniká seznamem obrazovek. Začíná popisem procesu, rolí, dat a míst, kde dnešní práce drhne.

Krátká odpověď

Před vývojem interní aplikace si připravte popis současného procesu, role lidí, typy dat, stavy práce, výjimky a výstupy, které firma potřebuje. Není nutné mít hotovou specifikaci obrazovek. Důležitější je vědět, co se dnes děje, kde vznikají chyby a co má první verze zlepšit.

Nezačínejte seznamem funkcí

U interních aplikací se často začne tabulkou funkcí: přihlášení, administrace, export, dashboard, notifikace. To ale samo o sobě neříká, proč má aplikace vzniknout a jak poznáme, že pomohla.

Lepší začátek je obyčejný popis dnešní práce. Kdo proces spouští, co do něj vstupuje, kdo rozhoduje, kde se čeká a jaký výstup musí být na konci.

Popište proces tak, jak opravdu běží

Není potřeba kreslit dokonalý diagram. Stačí napsat běžný průchod procesem a přidat místa, kde se objevují výjimky. Právě výjimky často rozhodují o tom, jestli bude aplikace v praxi použitelná.

  • kdo proces zahajuje
  • jaká data se zadávají
  • kdo má další krok
  • kdy se proces schvaluje
  • kde dnes vznikají chyby
  • co se má stát po dokončení

Role jsou důležitější než přihlašovací obrazovka

Interní aplikace skoro vždycky pracuje s více rolemi. Někdo zadává, někdo kontroluje, někdo schvaluje, někdo jen čte přehled. Pokud se role nevyjasní na začátku, systém se později začne ohýbat podle výjimek.

RoleTypická otázkaDopad na návrh
ŽadatelCo musím vyplnit a co se stane potom?Jednoduchý formulář, validace a jasný stav.
SchvalovatelCo mám rozhodnout a podle čeho?Přehled podkladů, historie a možnost vrátit k doplnění.
AdministrátorJak upravím číselníky, uživatele nebo pravidla?Správa bez zásahu vývojáře tam, kde to dává smysl.
VedeníJaký je stav a kde se proces zdržuje?Dashboard, filtry a exporty.

Vyberte první verzi, ne celou budoucnost

Interní aplikace se dá snadno nafouknout. Každý tým přidá jednu drobnost a z první verze je najednou velký systém. Proto je dobré oddělit, co je nutné pro první funkční provoz, a co může přijít později.

První verze má vyřešit jeden jasný proces nebo jeho nejbolavější část. Pokud po spuštění lidé aplikaci používají, další rozvoj se plánuje mnohem přesněji.

Co poslat dodavateli před první schůzkou

Stačí stručný podklad. Není cílem napsat zadávací dokumentaci na desítky stran. Cílem je dát druhé straně dost kontextu, aby se na schůzce neřešily jen obecné otázky.

  • stručný popis procesu v pěti až deseti bodech
  • ukázku dnešní tabulky, formuláře nebo reportu
  • seznam rolí a týmů, kterých se proces týká
  • příklad výjimky, která se řeší ručně
  • co má být v první verzi určitě a co může počkat

Checklist: podklady pro zadání interní aplikace

Současný stav

Popište, jak proces běží dnes. Klidně neformálně, ale konkrétně.

Role

Sepište typy uživatelů a co každý z nich v procesu dělá.

Data

Ukažte, jaká pole, dokumenty, přílohy nebo reporty se dnes používají.

Stavy

Napište, jaké stavy může požadavek nebo záznam mít.

První rozsah

Oddělte nutné věci pro první verzi od nápadů na další fáze.

Časté otázky

Musíme mít hotové detailní zadání?

Ne. Pro začátek stačí popis procesu, role, ukázka dnešních podkladů a cíl první verze. Detailní zadání často vznikne až v discovery.

Je lepší začít prototypem nebo rovnou vývojem?

U nejasného procesu je lepší prototyp nebo krátké discovery. Vývoj bez vyjasněných rolí a stavů obvykle vede k předělávkám.

Co když proces dnes není dobře popsaný?

To je běžné. Právě mapování procesu bývá první část práce. Důležité je přinést reálné příklady, ne ideální verzi z prezentace.