Ako vybrať kľúčové funkcie softvéru na mieru

Na začiatku má nový firemný softvér často vyriešiť jeden konkrétny problém. Postupne však pribudnú požiadavky na reporting, mobilnú aplikáciu, interný chat, desiatky exportov a špecifické potreby jednotlivých oddelení. Rozpočet rastie, termín sa posúva a pôvodný cieľ projektu sa stráca.

Tomuto vývoju sa dá predísť, ak firma ešte pred začiatkom implementácie rozlíši funkcie, bez ktorých systém nesplní svoj účel, od tých, ktoré môže bezpečne doplniť neskôr.

Pri vývoji softvéru na mieru preto uprednostnite funkcie, ktoré:

• riešia konkrétny firemný problém,
• podporujú hlavný proces,
• budú sa používať pravidelne,
• prinášajú merateľnú úsporu alebo znižujú riziko,
• sú nevyhnutné na bezpečné a spoľahlivé používanie systému.

Doplnkové funkcie možno zaradiť do ďalších etáp podľa ich prínosu a náročnosti.

Prečo viac funkcií neznamená lepší softvér

Personalizovaný softvér, označovaný aj ako softvér na mieru, vzniká podľa konkrétnych procesov a potrieb firmy. Jeho výhodou je, že sa nemusíte prispôsobovať univerzálnemu riešeniu. Táto flexibilita však môže viesť k nesprávnej predstave, že do systému treba zaradiť všetko, čo by sa firme raz mohlo hodiť.

Každá nová funkcia pritom ovplyvňuje:

• rozsah analýzy a návrhu,
• čas potrebný na vývoj,
• testovanie a nasadenie,
• cenu projektu,
• zložitosť používania,
• náklady na budúcu údržbu a zmeny.

Cieľom preto nie je vyvinúť čo najviac funkcií. Cieľom je vytvoriť riešenie, ktoré čo najefektívnejšie odstráni konkrétny problém firmy. Ak ešte len zvažujete, či je pre vás vhodnejšie hotové alebo personalizované riešenie, pomôže vám článok Kedy a prečo uprednostniť personalizovaný softvér pred hotovými riešeniami.

Pozor na nekontrolované rozširovanie projektu

Počas vývoja sa prirodzene objavujú nové nápady. Problém nastáva vtedy, keď sa pridávajú bez posúdenia ich dopadu na cieľ, rozpočet a harmonogram. Tento jav sa označuje ako scope creep, teda nekontrolované rozširovanie pôvodného rozsahu projektu.

Často sa začína nenápadne:

„Keď už systém vyvíjame, mohli by sme pridať ešte túto jednu funkciu.“

Jedna požiadavka však môže ovplyvniť ďalšie časti systému, používateľské oprávnenia, dátový model, integrácie aj testovanie. Výsledkom môže byť nielen vyššia cena, ale aj komplikovanejšie riešenie, v ktorom sa používatelia horšie orientujú. Ako udržať hranice projektu pod kontrolou, podrobnejšie vysvetľujeme v článku Ako sa vyhnúť zbytočnému komplikovaniu softvérového projektu na mieru.

Začnite problémom, nie zoznamom funkcií

Jednou z najčastejších chýb je formulovať požiadavky ako hotové technické riešenia.

Firma napríklad povie:

• potrebujeme dashboard,
• chceme mobilné notifikácie,
• potrebujeme interný chat,
• chceme export do viacerých formátov.

Dodávateľ však potrebuje v prvom rade rozumieť tomu, prečo danú funkciu požadujete.

Požadovaná funkcia	Skutočná potreba
Grafický dashboard	Rýchlo vidieť nevybavené zákazky
Mobilné notifikácie	Upozorniť obchodníkov na nové úlohy
Export do PDF a XLSX	Posielať účtovníctvu pravidelný report
Interný chat	Zrýchliť schvaľovanie objednávok

 

Keď vývojový tím pozná problém, môže navrhnúť jednoduchšie alebo efektívnejšie riešenie, než aké si firma pôvodne predstavovala.

Pri každej navrhovanej funkcii si preto položte tri otázky:

1. Aký problém ňou chceme vyriešiť?
2. Komu pomôže a ako často ju bude používať?
3. Dá sa rovnaký výsledok dosiahnuť jednoduchšie?

Viac praktických odporúčaní nájdete v článku Ako opísať vaše firemné potreby ITčkárovi bez IT žargónu.

Päť kritérií na určenie priority

O každej funkcii by sa malo rozhodovať podľa rovnakých kritérií. Diskusia sa tak neopiera iba o osobné preferencie alebo o to, kto svoju požiadavku presadzuje najhlasnejšie.

1. Súvisí s hlavným cieľom projektu?

Ak je cieľom skrátiť spracovanie objednávok, prioritu majú funkcie, ktoré tento proces priamo zrýchľujú. Doplnky bez jasného vplyvu na objednávky môžu počkať.

2. Ako často sa bude používať?

Funkcia používaná každý deň desiatimi zamestnancami má spravidla vyššiu hodnotu než funkcia, ktorú jeden človek využije niekoľkokrát ročne.

3. Aký prínos prinesie?

Prínos môže mať viacero podôb:

• úspora času,
• zníženie chybovosti,
• odstránenie manuálneho prepisovania,
• rýchlejšia obsluha zákazníka,
• lepšia dostupnosť informácií,
• splnenie legislatívnej alebo bezpečnostnej požiadavky.

4. Čo sa stane, ak funkciu odložíme?

Niektoré funkcie sú nevyhnutné na fungovanie systému. Iné možno dočasne nahradiť existujúcim postupom bez vážnejšieho dopadu.

5. Aká je náročnosť realizácie?

Funkcia môže pôsobiť jednoducho, ale vyžadovať zložité dátové prepojenie, zmenu viacerých procesov alebo zásah do existujúcich systémov.

Najvyššiu prioritu majú spravidla požiadavky s vysokým prínosom a primeranou náročnosťou.

Rozdeľte funkcie do štyroch skupín

Jednoduché rozdelenie na „nutné“ a „pekné“ často nestačí. Praktickejšie je pracovať so štyrmi kategóriami.

Kategória	Rozhodovacia otázka
Musí byť	Zlyhá bez nej hlavný proces?
Mala by byť	Spôsobí jej absencia významné obmedzenie?
Môže byť	Zlepší komfort, ale neblokuje výsledok?
Teraz nebude	Má nejasný prínos alebo rieši okrajový prípad?

 

Musí byť

Bez tejto funkcie systém nesplní svoj hlavný účel, nebude bezpečný alebo ho nebude možné reálne používať.

Príklady:

• evidencia a spracovanie objednávok,
• prístupové oprávnenia,
• nevyhnutná integrácia s účtovným systémom,
• spracovanie údajov požadované legislatívou.

Mala by byť

Funkcia prináša významnú hodnotu, ale systém možno na obmedzený čas používať aj bez nej. Môže ísť napríklad o automatizáciu činnosti, ktorú je v prvej fáze ešte možné vykonávať manuálne.

Môže byť

Funkcia zvyšuje komfort alebo rozširuje možnosti systému, no nemá zásadný vplyv na jeho hlavný prínos.

Teraz nebude

Neznamená to, že sa požiadavka definitívne zamieta. Firma iba vedome rozhodla, že ju nezaradí do aktuálnej etapy. Takéto rozhodnutie pomáha chrániť rozpočet aj termín a zároveň ponecháva priestor na budúci rozvoj.

Čo má obsahovať prvá použiteľná verzia

Pri firemnom softvéri sa často používa pojem MVP, teda prvá verzia s najmenším rozsahom, ktorý už prináša hodnotu a možno ho overiť v praxi. MVP však neznamená nekvalitné alebo provizórne riešenie. Aj prvá verzia musí byť bezpečná, spoľahlivá a použiteľná v reálnych procesoch.

Mala by obsahovať najmä:

• hlavný firemný proces, ktorý má softvér podporovať,
• nevyhnutné používateľské roly a oprávnenia,
• potrebné dáta a ich migráciu,
• kritické integrácie,
• bezpečnostné a legislatívne požiadavky,
• základnú správu a podporu systému.

Napríklad servisná firma nemusí v prvej etape vyvíjať rozsiahly manažérsky reporting, zákaznícky portál a mobilnú aplikáciu. Najprv môže zaviesť centrálnu evidenciu zákaziek, ich priraďovanie technikom a sledovanie stavu. Keď tím začne systém používať, firma získa reálne údaje a spätnú väzbu. Ďalšie investície potom môže smerovať do funkcií, ktoré majú preukázateľný prínos.

Nezabudnite na integrácie a menej viditeľné požiadavky

Pri prioritizácii sa firmy často sústredia iba na to, čo používateľ vidí na obrazovke. Pre fungovanie systému však môžu byť rozhodujúce aj technické a prevádzkové požiadavky.

Patria medzi ne napríklad:

• prepojenie s účtovným alebo skladovým systémom,
• migrácia existujúcich údajov,
• zálohovanie,
• auditná stopa,
• bezpečnostné oprávnenia,
• dostupnosť a výkon systému,
• exporty vyžadované obchodnými partnermi alebo legislatívou.

Ak má nový softvér komunikovať s existujúcimi aplikáciami, je potrebné včas preveriť dostupnosť dát, rozhraní a technickej dokumentácie. Viac sa o tejto téme dozviete v článku Čo vlastne znamená integrácia softvérov a systémov?.

Ako zapojiť tím bez straty kontroly nad projektom

Ľudia, ktorí s procesmi denne pracujú, často najlepšie poznajú ich slabé miesta.

Vedia identifikovať:

• opakované manuálne úkony,
• zbytočné prepisovanie údajov,
• časté chyby,
• chýbajúce informácie,
• tabuľky a obchádzkové riešenia vytvorené mimo oficiálnych systémov.

Ich skúsenosti sú pri návrhu softvéru dôležité. Neznamená to však, že každá požiadavka musí byť automaticky zaradená do vývoja.

Osvedčený postup zahŕňa:

1. krátke rozhovory so zástupcami jednotlivých rolí,
2. spoločné pomenovanie problémov,
3. zapísanie požiadaviek do jednotného zoznamu,
4. hodnotenie podľa vopred dohodnutých kritérií,
5. konečné rozhodnutie zodpovednej osoby.

Firma by mala určiť vlastníka projektu, ktorý rozumie jeho obchodnému cieľu a má právomoc rozhodovať o prioritách. Bez jasnej zodpovednosti sa môže projekt zmeniť na kompromis medzi požiadavkami jednotlivých oddelení.

Ako môže vyzerať prioritizačná tabuľka

Na začiatok postačí jednoduchá tabuľka v Exceli alebo Google Sheets.

Požiadavka	Prínos	Fáza
Centrálna evidencia zákaziek	Menej chýb a rýchlejší prehľad	1
Automatické podklady na fakturáciu	Úspora manuálnej práce	1
Manažérsky dashboard	Rýchlejšia príprava reportov	2
Mobilná aplikácia	Vyšší komfort práce v teréne	2
Interný chat	Nahraditeľný súčasným nástrojom	Nezaradiť

Pri každej požiadavke si zároveň zaznamenajte:

• problém, ktorý rieši,
• používateľov, ktorí ju potrebujú,
• frekvenciu používania,
• očakávanú úsporu alebo prínos,
• dopad jej odloženia.

Takto pripravený zoznam je kvalitnejším východiskom pre rozhovor s analytikom alebo dodávateľom než rozsiahly katalóg funkcií bez vysvetlenia ich významu.

Požiadavky sa môžu meniť, ale zmena musí mať pravidlá

Nie je realistické očakávať, že sa počas vývoja neobjaví žiadna nová potreba. Firma môže získať nové informácie, zmeniť proces alebo identifikovať situáciu, ktorá nebola na začiatku viditeľná.

Každá nová požiadavka by však mala prejsť rovnakým rozhodovaním:

• Aký problém rieši?
• Je nevyhnutná pre aktuálnu etapu?
• Aký má dopad na cenu a termín?
• Ovplyvní už navrhnuté časti systému?
• Čo sa musí odložiť, ak ju zaradíme teraz?

Rozhodnutie pridať novú funkciu nie je iba rozhodnutím o funkcii. Je to rozhodnutie o zmene rozsahu projektu. Ak sa zmena implementuje narýchlo alebo bez ohľadu na architektúru systému, môže navyše vytvoriť technický dlh. Ten sa neskôr prejaví zložitejšími úpravami, náročnejšou údržbou alebo vyšším rizikom chýb.

Checklist pred stretnutím s dodávateľom

Pred prvou konzultáciou nemusíte mať hotovú technickú špecifikáciu. Mali by ste však vedieť zodpovedať základné otázky.

Oblasť	Čo si pripraviť
Cieľ	Čo má byť po zavedení softvéru lepšie?
Problémy	Kde vznikajú chyby, zdržania alebo manuálna práca?
Používatelia	Kto a ako často bude systém používať?
Systémy	S čím sa musí nové riešenie prepájať?
Priority	Bez čoho prvá verzia nemôže fungovať?
Obmedzenia	Aký je časový a rozpočtový rámec?

 

Podrobnejšia softvérová analýza následne pomôže zmapovať procesy, overiť predpoklady, pomenovať riziká a pripraviť realistický rozsah riešenia.

Dobrý rozsah nevzniká škrtaním, ale správnym poradím

Prioritizácia funkcií neznamená, že sa firma musí vzdať svojich dlhodobých ambícií.

Znamená, že určí správne poradie:

1. najprv vyrieši hlavný problém,
2. overí riešenie v reálnej prevádzke,
3. získa spätnú väzbu od používateľov,
4. ďalšie funkcie doplní podľa preukázaného prínosu.

Aj jednoduchšia prvá verzia môže priniesť výraznú úsporu, ak presne zodpovedá firemným procesom. Naopak, rozsiahly systém plný málo používaných funkcií môže byť drahý, komplikovaný a nepraktický. Dobrý softvér preto nezačína množstvom funkcií. Začína jasným cieľom a porozumením tomu, čo firma naozaj potrebuje.

Najčastejšie otázky