Preskočiť na obsah

Zadanie pre softvérové štúdio: vzor briefu pre interný systém

Na prvý rozhovor nepotrebujete zoznam päťdesiatich obrazoviek. Potrebujete vysvetliť jednu prácu, ktorú firma dnes robí zbytočne ťažko. Dobré zadanie ukáže jej začiatok, koniec a človeka, ktorý vie posúdiť výsledok.

Ak napíšete „chceme CRM s AI“, dostanete ponuky na veľmi rozdielne veci. Jeden dodávateľ nacení databázu kontaktov, druhý obchodný systém a tretí asistenta nad e-mailmi. Všetci pritom môžu tvrdiť, že zadanie splnili.

Nasledujúci brief pomáha pripraviť porovnateľné ponuky. Je vhodný pre interný systém, vlastné CRM aj aplikáciu pre jedno oddelenie. Technické riešenie dopracujete s dodávateľom. Pravidlá vašej práce však musí vysvetliť váš tím.

1. Pomenujte problém jednou konkrétnou situáciou

Opíšte posledný prípad, pri ktorom sa práca zasekla. Kto na koho čakal? Kde bol potrebný údaj? Čo bolo treba zapísať druhýkrát?

Namiesto „potrebujeme zefektívniť prevádzku“ napíšte napríklad: „Po prijatí servisnej zákazky koordinátor prepisuje adresu a dohodnutý rozsah z e-mailu do tabuľky technikov. Zmenu termínu musí oznámiť zvlášť.“

Pridajte dôsledok, ktorý viete pozorovať. Môže ísť o počet ručných zápisov, chýbajúce prílohy alebo čas čakania. Ak zatiaľ nemáte meranie, označte údaj ako odhad. Pred pilotom ho môžete overiť na malej vzorke.

2. Ukážte pracovný postup aj s výnimkou

Spíšte päť až desať krokov od podnetu po dokončenie. Pri každom uveďte zodpovednú rolu a miesto, kde vzniká záznam. Príklad servisnej zákazky môže vyzerať takto:

  1. Zákazník pošle dopyt e-mailom.
  2. Koordinátor doplní miesto a rozsah práce.
  3. Technik overí dostupnosť a potrebný materiál.
  4. Zákazník schváli ponuku a termín.
  5. Technik vykoná zásah a priloží protokol.
  6. Administratíva dostane podklady na fakturáciu.

Potom pridajte jednu výnimku: zákazník zmení adresu po potvrdení termínu alebo technik pri zásahu zistí ďalšiu poruchu. Práve výnimky často odlišujú jednoduchú evidenciu od systému, ktorý tím skutočne potrebuje.

Dodávateľ sa má vedieť spýtať, čo sa zmení v ponuke, kalendári a dokumentoch. Ak rieši iba farbu tlačidla, ešte nepozná podstatnú časť zadania.

3. Používatelia nie sú len počet licencií

Uveďte roly a ich prácu. Koordinátor plánuje, technik spracuje pridelený zásah a účtovník kontroluje fakturačné podklady. Každý môže potrebovať inú obrazovku aj iný rozsah údajov.

Zapíšte tiež, čo daná rola vidieť nesmie. Externý technik môže mať prístup iba k prideleným zákazkám. Vedúci pobočky môže pracovať iba s vlastným tímom. Tieto pravidlá ovplyvňujú dátový model, integrácie aj testovanie.

Rozlíšte dnešný počet používateľov a očakávaný rast. Nežiadajte neurčitú „neobmedzenú škálovateľnosť“. Užitočnejšie je povedať, koľko ľudí pracuje naraz a koľko zákaziek pribúda za týždeň.

4. Pripravte vzorku údajov

Na začiatok stačí zoznam tabuliek, dokumentov a systémov. Pri každom určte, kto zaň zodpovedá a čo z neho má zostať zachované. Pred zdieľaním príklady anonymizujte.

Dodávateľovi pomôžu tri odlišné záznamy: bežný prípad, problémový prípad a historický prípad, ktorý sa po rokoch znovu otvoril. Ukážu vzťahy aj staré výnimky.

Pri migrácii sa pýtajte na prílohy a históriu, nielen na počet riadkov. Export klientov nemusí obsahovať väzby na pobočky, dokumenty alebo zmeny kontaktných osôb. Dohodnite, čo sa prenesie a čo zostane prístupné v archíve.

5. Integrácie opisujte ako operácie

„Napojenie na účtovníctvo“ je príliš široké. Uveďte, či chcete načítať zákazníkov, založiť objednávku, poslať podklady k faktúre alebo sledovať úhradu. Pri každom prenose určte smer a okamih spustenia.

Pridajte názov systému, verziu, dostupnú dokumentáciu a človeka, ktorý vie vybaviť prístup. Možnosti licencie a API treba preveriť pred pevnou cenou. Podrobnejší postup nájdete v článku o CRM integráciách.

V zadaní má byť aj otázka na chybu: kto zistí, že prenos neprešiel, a kto ho opraví? Dobré demo ukáže opakovaný import bez nechcenej duplicity, nielen prvý úspešný prenos.

6. Určte prvú verziu a jej hranice

Vyberte jeden postup, ktorý sa bude dať dokončiť celý. Ak prvá verzia eviduje dopyt, ale koordinátor musí ponuku aj termín viesť v starej tabuľke, pôvodný problém zostáva.

Zároveň napíšte, čo zatiaľ nestaviate. V servisnom príklade môže mimo prvej verzie zostať sklad, mzdy a zákaznícka mobilná aplikácia. Tento zoznam chráni rozpočet lepšie než všeobecná veta „všetko potrebné“.

Ďalšie nápady si nechajte v samostatnom zozname. Každý nový nápad nemusí meniť termín práve pripravovanej verzie. Pomôže vám postup zavádzania systému po častiach.

7. Napíšte, podľa čoho systém prevezmete

Podmienku prevzatia píšte ako prácu používateľa s očakávaným výsledkom. Napríklad: „Koordinátor zmení potvrdený termín. Technik uvidí nový termín a systém zachová pôvodný údaj v histórii.“

Pre prvú verziu pripravte aspoň scenáre bežnej práce, výnimky, odmietnutého prístupu, importu a neúspešnej integrácie. Určte človeka, ktorý ich vyskúša. Dodávateľ môže pomôcť scenáre doplniť, ale prevádzkovú správnosť musí vedieť posúdiť vaša firma.

Zistené chyby oddeľte od nových požiadaviek. Ak pôvodne dohodnutý krok nefunguje, ide o opravu. Ak sa počas skúšky rozhodnete pridať ďalšiu rolu, môže ísť o rozšírenie rozsahu.

Vyplnený modelový brief

Toto je ilustračné zadanie servisnej firmy, nie opis konkrétneho klienta:

  • Problém: Koordinátor prepisuje údaje z prijatých dopytov do plánu technikov a zmeny oznamuje zvlášť.
  • Prvá verzia: Dopyt, schválená ponuka, termín, pridelený technik a protokol zo zásahu.
  • Používatelia: Koordinátor spravuje zákazky. Technik vidí pridelenú prácu. Administratíva číta podklady k fakturácii.
  • Údaje: Klienti, prevádzky, zariadenia, príležitosti a dokumenty. Import aktívnych zákaziek zo súčasnej tabuľky.
  • Integrácia: Export schválených podkladov do účtovníctva; konkrétny formát sa overí pred ponukou.
  • Mimo rozsahu: Mzdy, skladové hospodárstvo a mobilná aplikácia pre zákazníkov.
  • Prevzatie: Tím dokončí bežný zásah aj zmenu termínu bez paralelného zapisovania do tabuľky.
  • Otvorené otázky: Formát účtovného importu, kvalita historických príloh a pravidlá prístupu externých technikov.

Takýto brief nie je konečná špecifikácia. Je to spoločný základ, na ktorom dodávatelia dokážu pomenovať predpoklady a naceniť rovnakú prvú verziu.

Čo má prísť späť v ponuke

Vyžiadajte si rozsah, výluky, cenu jednotlivých etáp, predpoklady integrácií a spôsob zmeny zadania. Ponuka má oddeliť vývoj od licencií, hostingu, migrácie a prevádzkovej podpory. Potrebujete tiež vedieť, čo musí váš tím pripraviť a dokedy.

V projekte Transfer International sú klienti, pracovníci, pridelenia a dokumenty samostatné prepojené oblasti. Takéto vzťahy sa oplatí odhaliť už v briefe. Zoznam obrazoviek by ich sám nevysvetlil.

Pošlite nám opis jedného procesu. Prejdeme, čo v zadaní chýba, ktoré časti treba najprv overiť a čo môže obsahovať prvá použiteľná verzia.

Ďalšie články.

  1. Ako vybrať dodávateľa podnikového softvéru a overiť jeho sľuby

    Otázky a praktické skúšky pre výber dodávateľa: rozsah, zmeny, API, AI, testovanie, odovzdanie a zodpovednosť za prevádzku.

  2. Ako zaviesť firemný informačný systém postupne a udržať firmu v chode

    Praktický plán zavádzania firemného systému: pilot, migrácia, prijatie tímom a podmienky rozšírenia. Ako využiť rýchlejší vývoj s AI bez preskakovania overenia.

  3. Integrácie CRM: ako prepojiť obchod, web a účtovníctvo bez dvojitého zapisovania

    Ako posúdiť CRM integrácie, API a webhooky. Vlastníctvo údajov, duplicity, opakovanie prenosov, kontrola chýb a príprava na AI.

Všetky články

Chcete sa poradiť o svojom projekte?

Dohodnite si hovor a spolu prejdeme vaše možnosti.

JurajCEO, QikBuild

Z hovoru si odnesiete

  • Návrh, čo by sme postavili ako prvé
  • Orientačnú cenu
  • Odpoveď, či sa vám oplatí softvér na mieru
Dohodnúť 30-minútový hovor

Alebo napíšte na hello@qikbuild.com