Zadanie pre softvér na mieru: čo spísať

Zadanie pre softvér na mieru nemá opisovať farbu tlačidiel. Pred prvou ponukou spíšte, kto bude systém používať, ako dnes prebieha práca, odkiaľ prichádzajú údaje, s čím sa má aplikácia prepojiť a podľa čoho hotové riešenie prevezmete. Dodávateľ potom dokáže oddeliť jasný rozsah od rizík, ktoré treba najprv overiť.

Ako spoznáte, že firma prerástla Excel

Excel nie je automaticky zlý nástroj. Na výpočty, jednorazové analýzy alebo jednoduchú evidenciu môže byť vhodnejší než vývoj vlastnej aplikácie. Problém sa nezačína určitým počtom riadkov, ale spôsobom práce okolo tabuľky.

Situácia vo firme	Čo pravdepodobne chýba
Zamestnanci si posielajú súbory s názvami „final“, „final2“ a „oprava“	Jedno miesto s aktuálnymi údajmi
Dvaja ľudia upravia tú istú zákazku a jedna zmena prepíše druhú	Riadenie súbežných zmien a história
Objednávka sa stratí medzi listami	Povinný stav, termín a zodpovedná osoba
Údaje sa ručne prepisujú do OMEGY, ALFA plus, MRP alebo POHODY	Kontrolovaný export alebo integrácia
Každý vidí všetkých zákazníkov, nákupné ceny aj marže	Používateľské roly a oprávnenia
Prevádzka závisí od makra, ktorému rozumie jediný človek	Zdokumentované pravidlá a zastupiteľnosť
Nikto nevie, kto zmenil cenu alebo termín	Auditná história

Do zadania preto nepíšte iba „chceme nahradiť Excel“. Pomenujte konkrétne chyby, zdržania a ručné kroky, ktoré má nové riešenie odstrániť.

Ak ešte neviete, či potrebujete vlastný vývoj, porovnajte si softvér na mieru a hotový program. Hotové riešenie môže byť výhodnejšie, ak sa váš proces dokáže prispôsobiť jeho pravidlám bez ďalších obchádzok.

Čo má obsahovať prvá verzia zadania

Na prvú ponuku nepotrebujete desiatky strán technickej dokumentácie. Potrebujete však päť jednoznačných častí:

1. Používatelia a oprávnenia: kto bude so systémom pracovať, čo musí vidieť a čo smie meniť.
2. Pracovný proces: čo sa deje od prijatia požiadavky po uzavretie zákazky.
3. Integrácie: s ktorými systémami si má aplikácia vymieňať údaje.
4. Existujúce dáta: čo už evidujete, kde sa to nachádza a čo treba preniesť.
5. Akceptačné kritériá: podľa čoho overíte, že dodaná funkcia funguje.

Na začiatok pridajte cieľ vyjadrený jednou vetou:

Chceme odstrániť dvojité zadávanie objednávok a pri každej zákazke vidieť jej stav, termín a zodpovednú osobu.

Takýto cieľ pomáha rozlíšiť potrebnú funkciu od nápadu, ktorý môže počkať na ďalšiu etapu.

Opíšte skutočných používateľov, nie iba účty

Označenia „administrátor“ a „bežný používateľ“ na odhad nestačia. Spíšte úlohy konkrétnych rolí:

• majiteľ sleduje stav zákaziek, náklady, výnosy a oneskorené úlohy,
• obchodník zakladá dopyt, pripravuje ponuku a zaznamenáva jej prijatie,
• vedúci prideľuje zákazku a schvaľuje zmeny,
• technik vidí pridelenú prácu, zapisuje materiál a prikladá dokumentáciu,
• účtovníčka kontroluje fakturačné údaje a odovzdáva doklady do účtovníctva,
• zákazník môže vidieť iba vlastnú objednávku alebo dokumenty určené na prevzatie.

Pri každej roli odpovedzte na tri otázky:

• Čo musí používateľ vidieť?
• Čo smie vytvoriť, zmeniť, schváliť alebo zrušiť?
• Ktoré údaje nesmie vidieť?

Nezabudnite na dočasné zastupovanie, odchod zamestnanca a odobratie prístupu. Oprávnenia sa nemajú určovať iba podľa toho, čo používateľ potrebuje dnes, ale aj podľa toho, čo sa má stať pri zmene jeho pracovnej pozície.

Proces zapíšte krok po kroku

Vyberte jednu bežnú zákazku a zaznamenajte jej cestu v poradí. Napríklad:

1. Dopyt príde z webového formulára alebo e-mailu.
2. Obchodník overí zákazníka a doplní požadovaný termín.
3. Z dopytu pripraví ponuku.
4. Po prijatí ponuky vznikne zákazka.
5. Vedúci pridelí zodpovedného pracovníka.
6. Pracovník zaznamená vykonanú prácu a použitý materiál.
7. Vedúci zákazku skontroluje a uzavrie.
8. Fakturačné údaje sa odovzdajú účtovníctvu.
9. Zákazník dostane dohodnutý výstup.

Pri každom kroku uveďte:

• kto ho vykonáva,
• ktoré údaje potrebuje,
• čo musí byť splnené pred pokračovaním,
• aký stav po kroku vznikne,
• komu sa má zmena oznámiť.

Potom doplňte výnimky. Čo sa stane, keď zákazník ponuku odmietne, zmení objednávku, neuhradí zálohu, dodávka mešká alebo sa zákazka vráti na opravu? Práve nepopísané výnimky často menia rozsah projektu počas vývoja.

Ak firma nevie, kde začať, pomôže najprv určiť, ktorý proces automatizovať ako prvý.

Integráciu nezadávajte jednou vetou

Požiadavka „prepojiť s účtovníctvom“ je príliš neurčitá. Dodávateľ potrebuje poznať konkrétny produkt, používanú verziu, požadovaný smer prenosu a očakávaný výsledok.

Pri každom prepojení spíšte:

• názov a verziu systému,
• údaje, ktoré sa majú prenášať,
• smer prenosu,
• udalosť, ktorá prenos spustí,
• požadovaný čas spracovania,
• správanie pri chybe alebo duplicite,
• spôsob prihlásenia a oprávnenia,
• dostupnosť dokumentácie a testovacieho prostredia.

Rozdiel je, či má aplikácia pripraviť CSV alebo XML na ručný import, pravidelne komunikovať cez API, alebo reagovať na udalosť z druhého systému. Podporované možnosti sa môžu líšiť podľa konkrétneho produktu, verzie, licencie a nastavenia.

Ak oficiálne rozhranie neexistuje, zadanie má určiť, či je prijateľný kontrolovaný import súboru. Automatické ovládanie cudzieho programu cez jeho obrazovku býva citlivé na zmenu okna, formulára alebo rozloženia prvkov a túto závislosť treba v ponuke pomenovať.

Praktický rozdiel medzi ručným prenosom a automatizáciou približuje článok o tom, kedy prepájať objednávky, banku a OMEGU.

Existujúce dáta ukážte bezpečne

Na prvé posúdenie pripravte anonymizovanú kópiu typickej tabuľky, nie ostrý zoznam zákazníkov. Odstráňte osobné údaje, obchodné tajomstvá, heslá, prístupové kľúče a interné poznámky, ktoré dodávateľ na odhad nepotrebuje.

Vysvetlite význam:

• stĺpcov a jednotlivých listov,
• vzorcov a makier,
• farieb, skratiek a značiek,
• povinných a nepovinných polí,
• číselníkov a väzieb medzi záznamami.

Žltý riadok môže pre jedného pracovníka znamenať „čakáme na materiál“ a pre druhého „treba zavolať zákazníkovi“. Ak význam existuje iba v hlavách zamestnancov, pri migrácii sa stratí.

Určte tiež:

• ktorý zdroj sa dnes považuje za správny,
• či existujú duplicitní zákazníci alebo zákazky,
• aké staré záznamy treba preniesť,
• či sa majú zachovať prílohy a história zmien,
• kto rozhodne pri rozpore údajov,
• ako sa overí úplnosť migrácie.

Migrácia nie je obyčajné kopírovanie buniek. Telefónne čísla môžu mať rôzne formáty, číslo objednávky môže byť raz uložené ako text a inokedy ako číslo a rovnaká firma môže vystupovať pod viacerými názvami. Zadanie má pomenovať pravidlá čistenia aj osobu, ktorá schváli sporné prípady.

Napíšte merateľné podmienky prevzatia

Veta „systém musí byť intuitívny“ sa nedá jednoznačne otestovať. Akceptačné kritérium má obsahovať východiskový stav, vykonanú akciu a očakávaný výsledok.

Napríklad:

Ak obchodník vytvorí zákazku zo schválenej ponuky, systém prenesie zákazníka, položky, ceny a termín bez opätovného prepisovania.

Ak účtovníčka exportuje dokončené zákazky, systém označí exportované záznamy a pri opakovanom pokuse upozorní na možné duplicity.

Ak účtovný program import odmietne, používateľ uvidí konkrétnu chybu a záznam zostane označený ako neexportovaný.

Doplňte aj oprávnenia a históriu:

Technik môže upraviť spotrebovaný materiál iba na pridelenej zákazke. Zmenu sumy, času a používateľa systém uloží do histórie.

Takéto kritériá chránia obe strany. Firma vie, čo má dostať, a dodávateľ dokáže odhadnúť implementáciu aj testovanie.

Rozdeľte požiadavky do etáp

Každú požiadavku zaraďte do jednej z troch skupín:

• Nutné pre prvú prevádzku: bez funkcie sa hlavný proces nedá dokončiť.
• Vhodné do ďalšej etapy: funkcia pomôže, ale nebráni spusteniu.
• Nápady na preverenie: prínos alebo technická uskutočniteľnosť ešte nie sú potvrdené.

Pri porovnávaní ponúk kontrolujte, či zahŕňajú rovnaký výsledok. Samostatne si označte:

• úvodnú analýzu,
• návrh a vývoj,
• migráciu dát,
• integrácie,
• testovanie,
• zaškolenie,
• nasadenie,
• dokumentáciu,
• následnú podporu.

Dve ponuky s rovnakým názvom projektu nemusia obsahovať rovnaké práce. Rozdiely v analýze, migrácii alebo podpore môžu byť dôležitejšie než samotná suma. Jednotlivé časti rozpočtu vysvetľuje článok koľko stojí softvér na mieru.

Ako vyzerá kvalitná reakcia dodávateľa

Kvalitná prvá reakcia neobsahuje iba cenu a termín. Dodávateľ sa pýta na:

• nejasné roly a schvaľovanie,
• výnimky v procese,
• objem a kvalitu dát,
• konkrétne verzie prepájaných systémov,
• dostupnosť rozhraní a testovacieho prostredia,
• bezpečnostné a prevádzkové požiadavky,
• spôsob prevzatia výsledku.

Mal by oddeliť to, čo vie odhadnúť, od toho, čo treba najprv technicky overiť. Opatrnosť je namieste, ak niekto bez doplňujúcich otázok sľúbi celé riešenie podľa jednej vety alebo iba navrhne preniesť súčasnú tabuľku do webového formulára. Krajšie rozhranie samo neodstráni nejasné stavy, duplicity ani ručné prepisovanie.

Ak potrebujete proces rozobrať, určiť prvú etapu a pripraviť podklad na odhad, riešime analýzu a vývoj softvéru na mieru. Na prvú konzultáciu stačí anonymizovaná ukážka dát a pravdivý opis súčasného postupu.

Vzor stručného zadania

Potrebujeme evidovať dopyty, ponuky a zákazky na jednom mieste. Systém budú používať obchodníci, vedúci, technici a účtovníčka. Obchodník vytvorí ponuku, vedúci po jej prijatí pridelí technika a účtovníčka po dokončení pripraví údaje na prenos do účtovného programu.

Dnes evidujeme aktívne záznamy v zdieľanom Exceli a prílohy v samostatnom úložisku. V prvej etape potrebujeme odstrániť dvojité zadávanie, zaviesť stavy zákazky, oprávnenia a kontrolovaný export.

Výsledok prevezmeme po úspešnom spracovaní vzorových zákaziek, overení oprávnení jednotlivých rolí a kontrole dohodnutej vzorky migrovaných záznamov.

Pred odoslaním zadania doplňte skutočný počet používateľov, približný objem záznamov, názov a verziu účtovného programu, umiestnenie príloh a presný spôsob kontroly migrácie.

Čo si pripraviť na prvú konzultáciu

Pripravte:

• jednu anonymizovanú tabuľku,
• zoznam používateľských rolí,
• opis jednej bežnej zákazky,
• tri najčastejšie výnimky,
• názvy a verzie systémov, ktoré treba prepojiť,
• zoznam nutných výstupov,
• návrh merateľných podmienok prevzatia.

Výsledkom konzultácie nemá byť iba hrubý odhad vývoja. Potrebujete zrozumiteľnú hranicu prvej etapy, zoznam otvorených rozhodnutí a pomenované riziká, ktoré treba preveriť pred pevným rozpočtom.

Rýchla odpoveď

Zadanie pre softvér na mieru má opísať používateľov a ich oprávnenia, skutočný pracovný proces, integrácie, existujúce dáta a merateľné podmienky prevzatia. Ak firma prerástla Excel, nezačínajte zoznamom obrazoviek. Najprv pomenujte prepisovanie údajov, stratené verzie a ručné prenosy, ktoré má nový systém odstrániť.

Časté otázky

Musíme mať pred prvou ponukou hotovú technickú špecifikáciu?

Nie. Potrebujete pravdivo opísať problém, používateľov, proces, dáta a očakávaný výsledok. Technická architektúra a podrobnosti rozhraní sa môžu spresniť počas analýzy.

Máme dodávateľovi poslať celý firemný Excel?

Na prvé posúdenie pošlite anonymizovanú ukážku. Odstráňte osobné údaje, obchodné tajomstvá, heslá a prístupové údaje. Ostré dáta sa odovzdávajú až dohodnutým bezpečným postupom a iba v potrebnom rozsahu.

Má zadanie obsahovať všetky budúce funkcie?

Nie. Oddeľte nutnú prvú etapu od neskorších rozšírení a neoverených nápadov. Príliš široké zadanie zvyšuje neistotu ponuky a odkladá overenie najdôležitejšieho procesu.

Čo ak nevieme, či účtovný program podporuje API?

Uveďte presný produkt, verziu a požadovaný prenos. Dodávateľ môže preveriť dostupné rozhranie, podporované formáty súborov aj možnosť testovacieho prostredia. Technicky možný prenos nemusí byť zároveň oficiálne podporovanou integráciou.

Ako obmedziť rast rozsahu počas vývoja?

Pomôžu jasné hranice prvej etapy, popísané výnimky a merateľné akceptačné kritériá. Nejasné integrácie a nekvalitné dáta označte ako riziká, ktoré sa majú preveriť pred pevným odhadom.