Než se začne
automatizovat,
pojmenuj proces.

Z čeho vycházím: U automatizací, publikačních systémů i datových nástrojů se opakovaly stejné otázky. Nejvíc problémů nevznikalo z toho, že by někdo neuměl napsat kód, ale z nejasných hranic procesu.

1. Co proces spouští?

Je to nový e-mail, čas v kalendáři, změna v databázi, ruční tlačítko nebo dávka souborů? Spouštěč určuje, zda může systém pracovat okamžitě, dávkově nebo až po potvrzení člověka.

Popiš také, co se stane, když spouštěč přijde dvakrát. Duplicita není okrajový případ. U plánovaných úloh, webhooků i opakovaného kliknutí se s ní musí počítat.

2. Jaké jsou vstupy a výstupy?

U každého vstupu si zapisuji zdroj, formát, povinná pole a vlastníka. U výstupu potom konkrétní místo, kam se uloží nebo odešle, a jak ho uživatel pozná.

• Odkud data přicházejí?
• Co musí být platné, aby proces pokračoval?
• Jaký výsledek má vzniknout?
• Kdo ho používá nebo kontroluje?

Tohle odhalí rozdíl mezi „přenést data“ a skutečným požadavkem, například „přenést jen ověřené záznamy a upozornit na konflikty“.

3. Co je běžný průchod a co výjimka?

Požadavek často popisuje jen ideální případ. V praxi ale přijde neúplný vstup, expirované přihlášení, změněná stránka, timeout nebo záznam, který už někdo zpracoval.

Výjimky třídím podle dopadu: automaticky zopakovat, přeskočit, zastavit a upozornit, nebo předat člověku. Není nutné vyřešit všechno v první verzi, ale musí být jasné, co se stane.

4. Kde zůstává člověk?

Ne každý krok má být automatický. U citlivého nákupu, odeslání platby nebo publikování může být správné, aby systém připravil výsledek a člověk ho potvrdil.

Ruční zásah není selhání automatizace. Je to řízená hranice odpovědnosti. Důležité je, aby bylo vidět, na co se čeká, kdo má zasáhnout a co se stane po potvrzení.

5. Jaké přístupy a omezení existují?

Před vývojem potřebuji vědět, zda jsou k dispozici API klíče, testovací účet, oprávnění k prohlížeči, limity služby a pravidla pro práci s daty. Přístup k produkci není náhrada za testovací prostředí.

U externích webů a API také vysvětluji provozní rizika. Pokud dodavatel změní přihlášení nebo datový formát, musí existovat způsob, jak problém zjistit a opravit.

6. Podle čeho poznáme výsledek?

„Ušetřit čas“ je dobrý směr, ale pro předání je potřeba měřitelné kritérium. Například zpracovat dávku bez ručního přepisování, snížit počet chyb, zkrátit kontrolu nebo mít dohledatelnou historii.

7. Co do první verze nepatří?

Dobré zadání obsahuje i seznam odkladů. Bez něj se první verze rozroste o reporty, role, další integrace a výjimky, které nejsou nutné pro ověření hlavní hodnoty.

Nejlepší první verze není nejmenší za každou cenu. Je to nejmenší celek, na kterém lze férově ověřit, že proces funguje lépe než dnes.