Co kontroluji v zadání softwaru na míru, než se pustím do návrhu

Než nakreslím první obrazovku, hledám v zadání místa, kde se návrh může vydat špatným směrem. Nehodnotím přitom délku dokumentu. Dvacet stran textu může obsahovat méně použitelných informací než půlhodinový rozhovor s člověkem, který každý den vyřizuje objednávky.

Následující žebříček řadím podle dopadu pozdní změny. Nahoře jsou otázky, jejichž špatná odpověď mění účel systému, datový model nebo odpovědnost lidí. Níže jsou věci, které také mohou prodražit vývoj, ale obvykle je lze opravit bez zásahu do základního návrhu.

Sedmá položka proto není nedůležitá. Je jen levnější zjistit pozdě, že tlačítko má být jinde, než po třech měsících zjistit, že systém ukládá zakázku pod nesprávným zákazníkem.

1. Jaký problém má software skutečně odstranit

Věta „potřebujeme nový informační systém“ pro mě není zadání. Je to začátek rozhovoru. Potřebuji vědět, co se dnes děje, kolikrát týdně, kdo tím tráví čas a jak vypadá chyba.

Místo požadavku na „automatické zpracování objednávek“ si nechám popsat konkrétní postup. Například: obchodník přijme 40 objednávek denně, každou přepíše z e-mailu do účetního systému a u tří až pěti chybí povinný údaj. Tady už lze navrhovat řešení. Zároveň lze po nasazení změřit, zda se něco zlepšilo.

Tato kontrola se hodí pro každý vývoj na míru, zvlášť když zadání vzniklo jako seznam funkcí. Nestačí tam, kde firma proces ještě vůbec nemá. V takovém případě nejdřív pomůže proces odzkoušet ručně. Postup, jak ho popsat a změřit před nákupem nástroje, rozebírám v článku o prvních třech krocích automatizace.

2. Kdo rozhoduje a kdo jen pracuje se systémem

U každého důležitého kroku hledám tři role: kdo zadává data, kdo rozhoduje a kdo nese odpovědnost. V malé firmě to může být jeden člověk. Návrh s tím ale nesmí automaticky počítat.

Typický problém vypadá nevinně. Zadání říká, že zaměstnanec vytvoří cenovou nabídku. Neříká však, kdo ji smí odeslat, kdo schválí slevu nad 10 procent a co se stane během dovolené vedoucího. Bez odpovědi může vzniknout buď zbytečně složité schvalování, nebo systém, ve kterém má každý příliš široká oprávnění.

Tahle kontrola je zásadní pro CRM, HR, účetní oběhy a interní schvalování. U jednoduchého osobního nástroje pro dva uživatele může být méně důležitá. Rozhodnutí však nestačí odsunout větou „určíme později“. Oprávnění doplněná až do hotové aplikace bývají drahá a nepříjemná.

3. Co je pravidlo a co výjimka

Procesy se při prvním popisu často tváří jednoduše. Pak přijde otázka „platí to vždy?“ a během pěti minut se objeví zahraniční zákazník, ruční sleva, rozdělená fakturace a kolega, který postup už osm let řeší jinak.

Nechci sepsat všechny historické zvláštnosti. Hledám výjimky, které mají skutečný obchodní nebo provozní důvod. U každé chci znát četnost, odpovědnou osobu a očekávaný postup. Výjimka jednou za dva roky může zůstat ruční. Výjimka u každé páté zakázky už patří do návrhu.

Tato kontrola se hodí pro firmy s různými typy zákazníků, cen nebo schvalovacích cest. Méně důležitá je u úzce vymezeného nástroje s jedním stabilním postupem. Ani tam bych ji však nevynechal. Slovo „vždy“ v zadání často nevydrží první běžný provoz.

4. Odkud data přicházejí a který systém jim velí

Když má aplikace zobrazit zákazníka, potřebuji určit, zda hlavní záznam je v CRM, účetnictví, e-shopu nebo nové aplikaci. Nestačí napsat, že se systémy propojí. Musí být jasný směr přenosu, identifikátor záznamu a postup při konfliktu.

Ptám se například: Co se stane, když někdo změní adresu zákazníka na dvou místech? Jak poznáme duplicitní firmu? Má se smazání přenést dál? Jak stará data ještě dávají smysl migrovat? Praktický vzorek 50 až 100 skutečných záznamů mi obvykle řekne víc než věta „data máme v Excelu“.

Tohle je klíčové pro integrace a náhradu starého systému. Pro samostatnou aplikaci bez importu je kontrola jednodušší. Není vhodné automaticky přenášet všechno. Starý nepořádek po migraci nezíská hodnotu, jen se objeví v novém rozhraní.

5. Co se má stát při chybě nebo výpadku

Zadání obvykle popisuje běžný průběh. Objednávka přijde, služba odpoví a uživatel klikne správně. Je ale potřeba popsat i situace, kdy účetní systém neodpovídá, soubor má špatný formát nebo se požadavek odešle dvakrát.

U důležitých kroků potřebuji určit, zda se operace zopakuje, uloží do fronty, předá člověku nebo bezpečně zastaví. Součástí návrhu je i to, kdo dostane upozornění a podle čeho pozná, co už proběhlo. U externích služeb hlídám hlavně opakované spuštění. Dvě faktury nejsou dvojnásobná automatizace, ale dvojitá práce.

Kontrola je nutná pro integrace, platby, AI a dávkové zpracování. U pomocného interního přehledu může stačit chybová zpráva a ruční opakování. Pro procesy závislé na externí službě se hodí předem určit frontu a náhradní cestu, jak popisuji u přípravy procesu na výpadek AI služby.

6. Co musí vidět člověk a co smí rozhodnout software

Automatizace může připravit podklady, seřadit požadavky nebo doporučit další krok. V zadání ale musí být jasná hranice mezi doporučením a rozhodnutím. Ptám se, zda uživatel může výsledek změnit, zda uvidí důvod a zda se jeho zásah zaznamená.

Hodí se to všude, kde výsledek ovlivní zákazníka, zaměstnance, cenu nebo dostupnost služby. U prostého přepisu údajů není lidské potvrzení pokaždé nutné. U citlivého rozhodnutí ale věta „to vyhodnotí AI“ nepředstavuje návrh procesu. Neříká, kdo odpovídá za výsledek a jak se řeší chybný případ. Hranici podrobněji rozebírám v textu o rozhodování, které má zůstat na člověku.

7. Jak poznáme, že první verze stačí

Nakonec kontroluji rozsah první verze. Každá funkce by měla mít konkrétního uživatele, situaci použití a důvod, proč je potřeba hned. Pokud je odpověď „mohlo by se to hodit“, přesouvám ji stranou.

Pro malou firmu často dává smysl spustit nejdřív jeden průchod procesu pro pět až deset uživatelů. Po dvou až čtyřech týdnech provozu se ukáže, co lidé skutečně používají a kde zadání minulo realitu. Nehodí se to pro změnu, kterou nelze bezpečně rozdělit, například když starý systém končí k pevnému datu.

První verze nemá být ořezaná tak, že práci nedokončí. Má vyřešit jeden celý problém od vstupu po výsledek. Tuto hranici jsem dřív několikrát podcenil. Přidal jsem funkce „když už jsme u toho“ a následně déle testoval věci, které nikdo nepotřeboval. Skromný rozsah tak není nedostatek ambicí, ale způsob, jak ověřit celý proces dřív, než se rozšíří.

Dobré zadání nepoznám podle počtu stran. Poznám ho podle toho, že umí popsat běžný průchod, důležité výjimky, vlastníka dat a chování při chybě. Když některá odpověď chybí, vývoj se nemusí zastavit. Musí však být zřejmé, že jde o otevřené rozhodnutí, kdo ho udělá a do kdy. Nejasnost sama o sobě není problém. Problém nastává, když se nevyřešená otázka tváří jako hotový požadavek.