Jak vybrat klíčové funkce softwaru na míru

Na začátku má nový firemní software často vyřešit jeden konkrétní problém. Postupně však přibývají požadavky na reporting, mobilní aplikaci, interní chat, desítky exportů a specifické potřeby jednotlivých oddělení. Rozpočet roste, termín se posouvá a původní cíl projektu se ztrácí.

Tomuto vývoji lze předejít, pokud firma ještě před zahájením implementace rozliší funkce, bez kterých systém nesplní svůj účel, od těch, které může bezpečně doplnit později.

Při vývoji softwaru na míru proto upřednostněte funkce, které:

• řeší konkrétní firemní problém,
• podporují hlavní proces,
• budou se pravidelně používat,
• přinášejí měřitelnou úsporu nebo snižují riziko,
• jsou nezbytné pro bezpečné a spolehlivé používání systému.

Doplňkové funkce lze zařadit do dalších etap podle jejich přínosu a náročnosti.

Proč více funkcí neznamená lepší software

Personalizovaný software, označovaný také jako software na míru, vzniká podle konkrétních procesů a potřeb firmy. Jeho výhodou je, že se nemusíte přizpůsobovat univerzálnímu řešení. Tato flexibilita však může vést k mylné představě, že je třeba do systému zařadit vše, co by se firmě jednou mohlo hodit.

Každá nová funkce přitom ovlivňuje:

• rozsah analýzy a návrhu,
• čas potřebný k vývoji,
• testování a nasazení,
• cenu projektu,
• složitost používání,
• náklady na budoucí údržbu a změny.

Cílem proto není vyvinout co nejvíce funkcí. Cílem je vytvořit řešení, které co nejefektivněji odstraní konkrétní problém firmy. Pokud teprve zvažujete, zda je pro vás vhodnější hotové, nebo personalizované řešení, pomůže vám článek Kdy a proč upřednostnit personalizovaný software před hotovými řešeními.

Pozor na nekontrolované rozšiřování projektu

Během vývoje se přirozeně objevují nové nápady. Problém nastává tehdy, když se přidávají bez posouzení jejich dopadu na cíl, rozpočet a harmonogram. Tento jev se označuje jako scope creep, tedy nekontrolované rozšiřování původního rozsahu projektu.

Často to začíná nenápadně:

„Když už systém vyvíjíme, mohli bychom přidat ještě tuto jednu funkci.“

Jeden požadavek však může ovlivnit další části systému, uživatelská oprávnění, datový model, integrace i testování. Výsledkem může být nejen vyšší cena, ale také komplikovanější řešení, ve kterém se uživatelé hůře orientují. Jak udržet hranice projektu pod kontrolou, podrobněji vysvětlujeme v článku Jak se vyhnout zbytečnému komplikování softwarového projektu na míru.

Začněte problémem, ne seznamem funkcí

Jednou z nejčastějších chyb je formulovat požadavky jako hotová technická řešení.

Firma například řekne:

• potřebujeme dashboard,
• chceme mobilní notifikace,
• potřebujeme interní chat,
• chceme export do více formátů.

Dodavatel však potřebuje v první řadě rozumět tomu, proč danou funkci požadujete.

Požadovaná funkce	Skutečná potřeba
Grafický dashboard	Rychle vidět nevyřízené zakázky
Mobilní notifikace	Upozornit obchodníky na nové úkoly
Export do PDF a XLSX	Posílat účetnímu oddělení pravidelný report
Interní chat	Zrychlit schvalování objednávek

 

Když vývojový tým zná problém, může navrhnout jednodušší nebo efektivnější řešení, než jaké si firma původně představovala.

Při každé navrhované funkci si proto položte tři otázky:

1. Jaký problém jí chceme vyřešit?
2. Komu pomůže a jak často ji bude používat?
3. Lze stejného výsledku dosáhnout jednodušeji?

Více praktických doporučení najdete v článku Jak popsat své firemní potřeby IT specialistovi bez IT žargonu.

Pět kritérií pro určení priority

O každé funkci by se mělo rozhodovat podle stejných kritérií. Diskuse se tak neopírá pouze o osobní preference nebo o to, kdo svůj požadavek prosazuje nejhlasitěji.

1. Souvisí s hlavním cílem projektu?

Pokud je cílem zkrátit zpracování objednávek, prioritu mají funkce, které tento proces přímo zrychlují. Doplňky bez jasného vlivu na objednávky mohou počkat.

2. Jak často se bude používat?

Funkce používaná každý den deseti zaměstnanci má zpravidla vyšší hodnotu než funkce, kterou jeden člověk využije několikrát ročně.

3. Jaký přínos přinese?

Přínos může mít několik podob:

• úspora času,
• snížení chybovosti,
• odstranění ručního přepisování,
• rychlejší obsluha zákazníka,
• lepší dostupnost informací,
• splnění legislativního nebo bezpečnostního požadavku.

4. Co se stane, pokud funkci odložíme?

Některé funkce jsou nezbytné pro fungování systému. Jiné lze dočasně nahradit stávajícím postupem bez závažnějšího dopadu.

5. Jaká je náročnost realizace?

Funkce může působit jednoduše, ale vyžadovat složité datové propojení, změnu více procesů nebo zásah do stávajících systémů.

Nejvyšší prioritu mají zpravidla požadavky s vysokým přínosem a přiměřenou náročností.

Rozdělte funkce do čtyř skupin

Jednoduché rozdělení na „nutné“ a „pěkné“ často nestačí. Praktičtější je pracovat se čtyřmi kategoriemi.

Kategorie	Rozhodovací otázka
Musí být	Selže bez ní hlavní proces?
Měla by být	Způsobí její absence významné omezení?
Může být	Zvýší komfort, ale neblokuje výsledek?
Teď nebude	Má nejasný přínos nebo řeší okrajový případ?

 

Musí být

Bez této funkce systém nesplní svůj hlavní účel, nebude bezpečný nebo jej nebude možné reálně používat.

Příklady:

• evidence a zpracování objednávek,
• přístupová oprávnění,
• nezbytná integrace s účetním systémem,
• zpracování údajů požadované legislativou.

Měla by být

Funkce přináší významnou hodnotu, ale systém lze po omezenou dobu používat i bez ní. Může jít například o automatizaci činnosti, kterou je v první fázi ještě možné provádět ručně.

Může být

Funkce zvyšuje komfort nebo rozšiřuje možnosti systému, ale nemá zásadní vliv na jeho hlavní přínos.

Teď nebude

Neznamená to, že se požadavek definitivně zamítá. Firma pouze vědomě rozhodla, že jej nezařadí do aktuální etapy. Takové rozhodnutí pomáhá chránit rozpočet i termín a zároveň ponechává prostor pro budoucí rozvoj.

Co má obsahovat první použitelná verze

U firemního softwaru se často používá pojem MVP, tedy první verze s nejmenším rozsahem, která již přináší hodnotu a kterou lze ověřit v praxi. MVP však neznamená nekvalitní nebo provizorní řešení. I první verze musí být bezpečná, spolehlivá a použitelná v reálných procesech.

Měla by obsahovat zejména:

• hlavní firemní proces, který má software podporovat,
• nezbytné uživatelské role a oprávnění,
• potřebná data a jejich migraci,
• kritické integrace,
• bezpečnostní a legislativní požadavky,
• základní správu a podporu systému.

Například servisní firma nemusí v první etapě vyvíjet rozsáhlý manažerský reporting, zákaznický portál a mobilní aplikaci. Nejprve může zavést centrální evidenci zakázek, jejich přiřazování technikům a sledování stavu. Když tým začne systém používat, firma získá reálné údaje a zpětnou vazbu. Další investice pak může směřovat do funkcí, které mají prokazatelný přínos.

Nezapomeňte na integrace a méně viditelné požadavky

Při prioritizaci se firmy často soustředí pouze na to, co uživatel vidí na obrazovce. Pro fungování systému však mohou být rozhodující také technické a provozní požadavky.

Patří mezi ně například:

• propojení s účetním nebo skladovým systémem,
• migrace stávajících údajů,
• zálohování,
• auditní stopa,
• bezpečnostní oprávnění,
• dostupnost a výkon systému,
• exporty vyžadované obchodními partnery nebo legislativou.

Pokud má nový software komunikovat se stávajícími aplikacemi, je třeba včas prověřit dostupnost dat, rozhraní a technické dokumentace. Více se o tomto tématu dozvíte v článku Co vlastně znamená integrace softwaru a systémů?.

Jak zapojit tým bez ztráty kontroly nad projektem

Lidé, kteří s procesy denně pracují, často nejlépe znají jejich slabá místa.

Dokážou identifikovat:

• opakované ruční úkony,
• zbytečné přepisování údajů,
• časté chyby,
• chybějící informace,
• tabulky a náhradní řešení vytvořená mimo oficiální systémy.

Jejich zkušenosti jsou při návrhu softwaru důležité. Neznamená to však, že každý požadavek musí být automaticky zařazen do vývoje.

Osvědčený postup zahrnuje:

1. krátké rozhovory se zástupci jednotlivých rolí,
2. společné pojmenování problémů,
3. zapsání požadavků do jednotného seznamu,
4. hodnocení podle předem dohodnutých kritérií,
5. konečné rozhodnutí odpovědné osoby.

Firma by měla určit vlastníka projektu, který rozumí jeho obchodnímu cíli a má pravomoc rozhodovat o prioritách. Bez jasné odpovědnosti se může projekt změnit v kompromis mezi požadavky jednotlivých oddělení.

Jak může vypadat prioritizační tabulka

Na začátek postačí jednoduchá tabulka v Excelu nebo Google Sheets.

Požadavek	Přínos	Fáze
Centrální evidence zakázek	Méně chyb a rychlejší přehled	1
Automatické podklady pro fakturaci	Úspora ruční práce	1
Manažerský dashboard	Rychlejší příprava reportů	2
Mobilní aplikace	Vyšší komfort práce v terénu	2
Interní chat	Nahraditelný stávajícím nástrojem	Nezařadit

U každého požadavku si zároveň zaznamenejte:

• problém, který řeší,
• uživatele, kteří jej potřebují,
• frekvenci používání,
• očekávanou úsporu nebo přínos,
• dopad jeho odložení.

Takto připravený seznam je kvalitnějším východiskem pro rozhovor s analytikem nebo dodavatelem než rozsáhlý katalog funkcí bez vysvětlení jejich významu.

Požadavky se mohou měnit, ale změna musí mít pravidla

Není realistické očekávat, že se během vývoje neobjeví žádná nová potřeba. Firma může získat nové informace, změnit proces nebo identifikovat situaci, která na začátku nebyla viditelná.

Každý nový požadavek by však měl projít stejným rozhodováním:

• Jaký problém řeší?
• Je nezbytný pro aktuální etapu?
• Jaký má dopad na cenu a termín?
• Ovlivní již navržené části systému?
• Co se musí odložit, pokud jej zařadíme nyní?

Rozhodnutí přidat novou funkci není pouze rozhodnutím o funkci. Je to rozhodnutí o změně rozsahu projektu. Pokud se změna implementuje narychlo nebo bez ohledu na architekturu systému, může navíc vytvořit technický dluh. Ten se později projeví složitějšími úpravami, náročnější údržbou nebo vyšším rizikem chyb.

Checklist před schůzkou s dodavatelem

Před první konzultací nemusíte mít hotovou technickou specifikaci. Měli byste však umět odpovědět na základní otázky.

Oblast	Co si připravit
Cíl	Co má být po zavedení softwaru lepší?
Problémy	Kde vznikají chyby, zdržení nebo ruční práce?
Uživatelé	Kdo a jak často bude systém používat?
Systémy	S čím se musí nové řešení propojovat?
Priority	Bez čeho první verze nemůže fungovat?
Omezení	Jaký je časový a rozpočtový rámec?

 

Podrobnější softwarová analýza následně pomůže zmapovat procesy, ověřit předpoklady, pojmenovat rizika a připravit realistický rozsah řešení.

Dobrý rozsah nevzniká škrtáním, ale správným pořadím

Prioritizace funkcí neznamená, že se firma musí vzdát svých dlouhodobých ambicí.

Znamená to, že určí správné pořadí:

1. nejprve vyřeší hlavní problém,
2. ověří řešení v reálném provozu,
3. získá zpětnou vazbu od uživatelů,
4. další funkce doplní podle prokázaného přínosu.

I jednodušší první verze může přinést výraznou úsporu, pokud přesně odpovídá firemním procesům. Naopak rozsáhlý systém plný málo používaných funkcí může být drahý, komplikovaný a nepraktický. Dobrý software proto nezačíná množstvím funkcí. Začíná jasným cílem a pochopením toho, co firma skutečně potřebuje.

Nejčastější dotazy