Cena za vývoj mobilní aplikace na míru - Co všechno ovlivňuje rozpočet?

Kdy může dávat větší smysl nativní vývoj?

Nativní přístup lze zvážit zejména tehdy, když aplikace ve velké míře využívá specifické možnosti zařízení, má neobvyklé požadavky na práci na pozadí nebo je její fungování výrazně navázané na konkrétní platformu. Naopak u aplikace založené především na uživatelských účtech, formulářích, objednávkách, obsahu nebo práci s daty může být multiplatformní přístup efektivnější. Volba ale vždy závisí na konkrétním zadání. V našem článku o vývoji mobilních aplikací pro iOS a Android rozebíráme jednotlivé možnosti podrobněji.

Backend může tvořit významnou část celé aplikace

To, co uživatel vidí na displeji telefonu, je pouze jedna část výsledného systému. Jakmile aplikace pracuje s účty, objednávkami, rezervačním systémem, platbami nebo jinými dynamickými daty, zpravidla potřebuje také serverovou část. Backend řeší například ukládání a zpracování dat, přihlášení uživatelů, oprávnění, obchodní logiku, komunikaci s dalšími systémy nebo administraci.

U jednoduchého projektu může mobilní aplikace využít už existující backend. U jiného je nutné serverovou část vytvořit společně s mobilní aplikací. Rozdíl má na výslednou cenu zásadní vliv. Modelovým příkladem může být e-shopová aplikace. Pokud pouze využívá dobře připravená data a funkce existujícího e-shopu, lze velkou část logiky převzít.

Jestliže ale současný systém neposkytuje potřebná data, neumí pracovat se zákaznickými účty nebo neumožňuje požadované operace, je potřeba upravit či vytvořit také serverovou část. U projektů kombinujících mobilní a webové prostředí může být relevantní také vývoj webových aplikací, protože obě rozhraní mohou využívat společná data a aplikační logiku.

Integrace s dalšími systémy mohou rozsah projektu výrazně rozšířit

Firemní mobilní aplikace často není jen izolovaný produkt. Může potřebovat komunikovat například s:

• CRM

• ERP

• účetnictvím

• e-shopem

• skladem

• platební bránou

• dopravcem

• interním informačním systémem

• externí datovou službou

Samotné technické připojení přitom není jedinou prací. U každé integrace je potřeba vyřešit, která data se přenášejí, jakým směrem, jak často a co se má stát, pokud druhý systém neodpovídá nebo vrátí chybu. Představme si objednávku zaplacenou v mobilní aplikaci. Nestačí pouze poslat informaci do ERP. Systém musí vědět, co udělat v případě, kdy platba proběhla, ale ERP je právě nedostupné. Stejně důležité je zabránit vytvoření duplicitní objednávky při opakovaném přenosu. Kvalita dostupného API propojení proto může mít na pracnost integrace velký vliv. Pokud se aplikace napojuje na zákaznická data, může být relevantní také napojení na CRM.

UX a UI ovlivňují cenu ještě před zahájením programování

Mobilní aplikace má na malé obrazovce omezený prostor a uživatel očekává, že rychle pochopí, co má udělat. Návrh aplikace proto není pouze otázkou barev a vzhledu. UX a UI řeší například strukturu aplikace, pořadí jednotlivých kroků, formuláře, navigaci, stavy systému i výsledný vizuální styl.

Dobrý návrh zároveň pomáhá řídit rozpočet. Pokud se způsob používání promyslí ještě před programováním, lze včas odhalit chybějící scénáře nebo zbytečně komplikované části. Úprava návrhu bývá jednodušší než přepracování již hotové funkce, která je napojená na backend a další části aplikace.

Prototyp mobilní aplikace nemusí být jen grafika

U složitějších projektů může před vývojem vzniknout interaktivní návrh, na kterém lze hlavní scénáře projít podobně jako v hotové aplikaci. Takové prototypování aplikací pomáhá ověřit logiku ovládání a získat zpětnou vazbu dříve, než začne samotná implementace.

Rozsah návrhu by ale měl odpovídat projektu. Jednoduchá první verze produktu nepotřebuje nutně rozsáhlý design systém se všemi hypotetickými budoucími stavy. Na druhou stranu úplné přeskočení návrhu může pouze přesunout rozhodování do fáze vývoje, kde bývají změny pracnější.

MVP může snížit počáteční investici, pokud má jasně vymezený cíl

Při vývoji nového produktu není vždy nutné vytvořit všechny plánované funkce před prvním spuštěním. MVP představuje první použitelnou verzi, která obsahuje to, co je nutné k ověření hlavní hodnoty aplikace. Smyslem není vytvořit nekvalitní nebo „co nejlevnější“ produkt, ale odložit funkce, jejichž přínos zatím není ověřený. U rezervační aplikace může být pro první verzi podstatné například:

• vytvoření účtu

• výběr služby

• volba termínu

• vytvoření rezervace

• potvrzení uživateli

• základní správa rezervací

Věrnostní program, pokročilé reporty nebo další personalizace mohou následovat později, pokud pro ně vznikne reálná potřeba. U zavedených firem je situace jiná. Pokud aplikace nahrazuje konkrétní provozní proces, některé funkce nelze vynechat jen proto, aby byla první verze levnější. Servisní aplikace například nemusí plnit svůj účel bez offline režimu nebo přístupu k potřebným údajům o zakázce. Rozsah MVP je proto potřeba určit podle cíle aplikace, nikoliv podle předem zvoleného počtu funkcí.

Testování je součást vývoje, ne volitelný doplněk

Mobilní aplikace se používají na různých zařízeních, velikostech displeje i verzích operačních systémů, proto je potřeba její fungování důkladně ověřit ještě před spuštěním. Testuje se nejen správnost hlavních funkcí, ale také přihlášení a oprávnění, chování při slabém nebo přerušeném připojení, platby, notifikace, integrace s dalšími systémy nebo ukládání a synchronizace dat.

Součástí kontroly jsou také nestandardní a chybové scénáře, které se mohou objevit při běžném používání. U aplikací pracujících s citlivými informacemi je důležité řešit už během návrhu také zabezpečení, protože se promítá do práce s uživatelskými účty, daty, přístupy, API i infrastruktury. Kvalitní testování sice nemůže zaručit aplikaci zcela bez chyb, výrazně ale snižuje riziko, že zásadní problém odhalí až uživatelé po spuštění. Opravy lze díky tomu řešit dříve, než začnou ovlivňovat provoz aplikace nebo zkušenost zákazníků.

Publikace do App Store a Google Play je další část projektu

Dokončením programování práce nekončí. Pokud má být aplikace veřejně dostupná, je potřeba připravit také její vydání. Publikace do App Store a Google Play může zahrnovat například:

• vytvoření a nastavení vývojářských účtů

• přípravu instalační verze

• název a popis aplikace

• ikonu a screenshoty

• informace o zpracování dat

• potřebná oprávnění

• testování produkční verze

• řešení případných připomínek během schvalování

Konkrétní požadavky se liší podle typu mobilní aplikace a funkcí, které používá. Proto je vhodné s publikací počítat už v harmonogramu projektu a nenechávat ji až na okamžik, kdy má být aplikace oficiálně spuštěna.

Analytika pomáhá rozhodovat o dalším rozvoji aplikace

Po spuštění je důležité sledovat, jak lidé aplikaci skutečně používají. Samotný počet instalací totiž často neukáže, zda produkt plní svůj účel. Podle typu aplikace může být důležitější například dokončení registrace, aktivace účtu, vytvoření objednávky nebo rezervace, opakované používání, práce s jednotlivými funkcemi nebo místa, kde uživatelé proces opouštějí. Součástí sledování by měly být také technické chyby a pády aplikace.

Analytiku je vhodné promyslet už během vývoje mobilní aplikace, aby bylo možné potřebné události a cíle navrhnout společně s funkcionalitou. Dodatečné doplňování měření do hotové aplikace totiž může vyžadovat další zásahy do mobilní i serverové části a zbytečně prodražit následné úpravy.

Údržba mobilní aplikace je dlouhodobou součástí rozpočtu

Mobilní aplikace není produkt, který se jednou publikuje a už se ho není potřeba dotýkat. Operační systémy, externí služby i použité knihovny se průběžně mění. Firma navíc může chtít upravovat funkcionalitu podle zpětné vazby uživatelů nebo podle vlastního dalšího rozvoje. Při plánování investice proto není vhodné počítat pouze s náklady do dne prvního spuštění. Důležitý je také očekávaný životní cyklus produktu. Následná správa může zahrnovat:

• aktualizace technologií a knihoven

• opravy nalezených chyb

• přizpůsobení novým verzím iOS a Androidu

• údržbu integrací

• monitoring provozu

• kontrolu bezpečnosti

• zálohování důležitých dat

• rozvoj nových funkcí

Co může při srovnání nabídek zkreslit výslednou cenu mobilní aplikace?

Dvě cenové nabídky se mohou lišit nejen sazbou dodavatele, ale hlavně rozsahem zahrnutých prací. Jedna nabídka může obsahovat jen implementaci podle dodané specifikace, druhá také analýzu, UX/UI, testování, projektové řízení, publikaci a podporu po spuštění. Nižší výsledná částka proto automaticky neznamená levnější projekt v celém jeho životním cyklu. Pokud budete porovnávat cenové nabídky za mobilní aplikaci na míru, položte si zejména následující otázky:

• Je součástí analýza a upřesnění zadání?

• Obsahuje cena návrh UX/UI?

• Je započítaný backend?

• Které integrace jsou součástí odhadu?

• Jaký rozsah testování dodavatel provádí?

• Kdo řeší publikaci do obchodů?

• Jak se naceňují změny zadání?

• Jak je řešená podpora po spuštění?

• Jaká dokumentace a přístupy budou klientovi předány?

Jak získat přesnější odhad ceny mobilní aplikace?

Čím více relevantních informací je známých před odhadem, tím přesněji lze projekt rozdělit a nacenit. Nemusíte přitom přicházet s hotovou technickou dokumentací. Pro úvodní konzultaci je užitečné připravit především:

1. Účel aplikace - Jaký problém má řešit a proč má vzniknout?

2. Cílové uživatele - Půjde o zákazníky, zaměstnance, obchodní partnery nebo jinou skupinu?

3. Hlavní scénáře - Co mají lidé v aplikaci skutečně dělat?

4. Klíčové funkce první verze - Bez kterých funkcí nedává spuštění smysl?

5. Existující systémy a data - Má aplikace navazovat na CRM, e-shop, ERP, databázi nebo webovou aplikaci?

6. Požadované platformy - Potřebujete od začátku iOS i Android, nebo má projekt jinou strategii?

7. Plán dalšího rozvoje - Jaké funkce pravděpodobně přijdou v dalších etapách?

Na základě těchto informací lze lépe rozhodnout o technologii, rozsahu první fáze i oblastech, které mohou mít na rozpočet největší vliv. Technická specifikace může vzniknout až následně jako součást přípravy projektu. U rozsáhlejších systémů pomáhá přesně zaznamenat požadavky také projektová dokumentace.

Realistický rozpočet začíná správně vymezeným projektem

Cena za vývoj mobilní aplikace na míru není výsledkem jediné položky. Ovlivňuje ji kombinace funkcí, platforem, backendu, integrací, návrhu, testování i požadavků na další provoz. Nejnižší vstupní cena proto nemusí být nejlevnějším řešením z dlouhodobého hlediska. Stejně tak ale není důvod navrhovat složitou architekturu a funkce, které projekt v dané fázi nepotřebuje.

Cílem je najít rozsah a technologii odpovídající skutečnému využití aplikace. Pokud máte nápad na mobilní aplikaci nebo potřebujete digitalizovat konkrétní firemní proces, kontaktujte nás!. Projdeme s vámi požadavky, potřebné funkce, integrace i možnosti dalšího rozvoje a na jejich základě lze připravit smysluplnější odhad rozsahu projektu.