Začnite problémom, ktorý má zmiznúť
Dobré zadanie nemusí byť technická špecifikácia. Na prvý rozhovor je užitočnejší stručný opis problému než dlhý zoznam obrazoviek. Napíšte, kto dnes vykonáva danú prácu, čo ho zdržiava a aký výsledok má nový systém priniesť. Veta „potrebujeme aplikáciu“ je začiatok rozhovoru; veta „chceme mať každú servisnú požiadavku priradenú a dohľadať jej stav“ už opisuje konkrétny cieľ.
Vyberte merateľný ukazovateľ: čas spracovania, počet opráv, oneskorené prípady alebo čas potrebný na report. Zapíšte dnešný stav a želaný výsledok. Ak dnešné čísla nepoznáte, označte ich ako údaj na doplnenie. Odhad nevydávajte za meranie.
- Kto bude systém používať a kto rozhoduje o pravidlách?
- Čo sa dnes robí ručne alebo duplicitne?
- Aký výsledok ukáže, že investícia mala zmysel?
- Čo sa stane, ak sa problém ďalší rok nevyrieši?
Opíšte jeden proces od vstupu po výsledok
Vyberte hlavný tok práce a prejdite ho krok po kroku. Zaznamenajte vstup, zodpovednú osobu, rozhodnutia, stavy a výstup. Doplňte aj výnimky: neúplný údaj, zamietnutie, zrušenie, duplicitu alebo prípad, ktorý sa vracia na opravu. Práve výnimky často určujú náročnosť vývoja.
Pripravte anonymizovanú ukážku formulára, tabuľky alebo reportu, ktorý dnes používate. Nejde o pokyn kopírovať staré rozhranie. Je to podklad na pochopenie údajov a pravidiel. Pri každom kroku odlíšte firemnú požiadavku od zvyku, ktorý vznikol iba pre obmedzenia súčasného nástroja.
Rozdeľte požiadavky podľa priority
Pri každej požiadavke napíšte, prečo je potrebná. Potom ju zaraďte medzi nevyhnutné pre prvú verziu, užitočné pre ďalšiu etapu alebo zatiaľ otvorené. Prvá verzia má umožniť dokončiť hlavný proces, nie iba predviesť pekný začiatok.
Do zadania patrí aj to, čo prvá etapa nebude riešiť. Jasné hranice pomáhajú porovnávať ponuky a posúdiť nové nápady počas vývoja. Ak sú dve funkcie prepojené, zapíšte túto závislosť: schvaľovanie objednávky napríklad potrebuje určené roly a pravidlá schvaľovania.
- Nevyhnutné: bez toho používateľ nedokončí hlavný tok.
- Ďalšia etapa: má prínos, ale prvá verzia môže fungovať aj bez nej.
- Otvorené: treba rozhodnutie, vzorku dát alebo technické overenie.
- Mimo rozsahu: vedome odložené procesy, platformy a integrácie.
Spíšte dáta, napojenia a prístupové práva
Vymenujte existujúce systémy, ktoré majú s novým riešením spolupracovať. Pri každom uveďte, aké údaje sa prenášajú, ktorým smerom, ako často a kto vie poskytnúť dokumentáciu alebo testovací prístup. Dostupnosť API netreba predpokladať; neoverené napojenie označte ako riziko na preverenie.
Pri migrácii určte zdroj údajov, ich vlastníka a rozsah histórie. Zaznamenajte známe duplicity či chýbajúce hodnoty. Prístupové práva opíšte cez činnosti: kto môže vidieť, vytvoriť, zmeniť, schváliť alebo exportovať záznam. Heslá a produkčné kľúče nepatria do zadania; prístupy sa odovzdávajú samostatným dohodnutým spôsobom.
Dohodnite, ako spoznáte hotovú prácu
Ku kľúčovým požiadavkám pridajte overiteľné podmienky prevzatia. Namiesto „report má byť prehľadný“ určte, ktoré údaje obsahuje, kto k nemu má prístup a čo musí sedieť s podkladmi. Testovacie scenáre majú zahŕňať bežný priebeh aj výnimky, ktoré ste pomenovali v procese.
Ujasnite tiež, kto skúša prvú verziu, kto ju schvaľuje a kto pomáha používateľom po spustení. Do rozhovoru patria školenie, dokumentácia, zálohy, podpora a zodpovednosť za prevádzku. Zaznamenajte aj požiadavky na rýchlosť, dostupnosť a množstvo dát; konkrétne limity dohodnite podľa reálneho používania.
Na konzultáciu stačí zrozumiteľný pracovný podklad
Nemusíte mať hotovú architektúru ani vybranú technológiu. Prineste cieľ, hlavný proces, priority, anonymizované ukážky a zoznam otvorených otázok. Doplňte rozpočtový rámec, požadovaný termín a jeho dôvod. Pevný termín odlíšte od preferencie a pomenujte, kto vie priebežne rozhodovať za firmu.
Takýto podklad umožní vývojovému tímu klásť presné otázky a navrhnúť prvú etapu. Ak chýbajú kritické pravidlá alebo sú integrácie neisté, ďalším krokom môže byť analýza či prototyp. V DAVOND môžeme na úvodnej konzultácii prejsť váš problém, zvážiť vhodný typ riešenia a pomenovať, čo treba overiť pred odhadom vývoja.