Vývoj mobilní aplikace pro firmu bez omylů

Mobilní aplikace ve firmě často nezačíná nápadem, ale problémem. Obchodní tým ztrácí čas v terénu, servis zapisuje data zpětně večer, zákazníci čekají na informace, které by mohli mít v telefonu hned. Právě tehdy začíná dávat vývoj mobilní aplikace pro firmu smysl, ne jako doplněk „abychom měli appku“, ale jako nástroj, který zjednoduší konkrétní práci.

Když s firmami řešíme mobilní produkt, většinou se nebavíme nejdřív o technologiích. Nejdřív si potřebujeme ujasnit, kdo aplikaci používá, v jaké situaci, co má udělat rychleji než dnes a co se musí propojit s existujícími systémy. Pokud tohle není jasné, aplikace se dá postavit, ale často nepomůže tam, kde má.

Kdy má vývoj mobilní aplikace pro firmu skutečný smysl

Ne každá firma potřebuje vlastní mobilní aplikaci. Někdy stačí upravit webovou aplikaci pro mobilní používání a tím to končí. Jindy je ale mobilní prostředí zásadní, protože uživatel pracuje mimo kancelář, potřebuje fotoaparát, notifikace, geolokaci, offline režim nebo rychlý přístup jedním klepnutím.

Typicky to dává smysl ve třech situacích. První je interní provoz, například obchodníci, technici, sklad nebo management v terénu. Druhá je zákaznický produkt, kde je mobil hlavní kontaktní bod. Třetí je rozšíření existujícího systému, kdy firma už má web nebo interní platformu, ale část workflow se na mobil přenést vyplatí.

Rozhodnutí mezi mobilní aplikací a responzivním webem není ideologické. Je praktické. Pokud uživatel otevře službu jednou za měsíc, nativní aplikace často nedává ekonomický smysl. Pokud v ní ale pracuje denně a rychlost je podstatná, mobilní aplikace bývá lepší volba.

Co by měla firma vědět ještě před zadáním

Nejčastější chyba není špatně zvolený framework. Je to nejasné zadání schované za obecnou větu typu „chceme moderní aplikaci pro klienty“. Z takového zadání se těžko odhaduje rozsah, priority i reálný přínos.

Dobré zadání nemusí být dlouhé. Mělo by ale odpovědět na několik konkrétních otázek. Kdo je hlavní uživatel. Jaký problém mu aplikace řeší. Co je minimální verze, se kterou má smysl jít ven. Jaké systémy už ve firmě existují a s čím se bude potřeba propojit. A také kdo bude po spuštění rozhodovat o dalších úpravách.

Právě integrace bývají podceňované. Samotná obrazovka v mobilu nebývá to nejtěžší. Složitější bývá napojení na ERP, CRM, sklad, interní API nebo starší backend, který nebyl na mobilní použití připravený. Jestli má aplikace zobrazovat aktuální data a ne jen hezké rozhraní, musí být dobře navržený i zbytek systému.

Vývoj mobilní aplikace pro firmu není jen o aplikaci

Tohle je bod, který je dobré říct naplno. Mobilní produkt není izolovaný projekt. Ve většině případů je to kombinace klientské aplikace, backendu, administrace, autentizace, analytiky, notifikací a provozního dohledu. Pokud se řeší jen to, co bude v App Storu a Google Play, část nákladů i práce zůstane neviditelná až do chvíle, kdy začne být problém.

Například interní servisní aplikace může vypadat jednoduše. Technik vidí zakázky, doplní výsledek, přidá fotky a odešle report. Ve skutečnosti ale potřebujete správu uživatelů, oprávnění, synchronizaci při slabém signálu, práci s přílohami, historii změn a často i webové rozhraní pro dispečink nebo administrátory.

Proto dáváme přednost tomu rozdělit projekt na části a říct si, co je opravdu nutné pro první verzi. Ne kvůli šetření za každou cenu, ale kvůli tomu, aby se první release dal rozumně ověřit v praxi.

Nativní, nebo cross-platform?

Tohle je častá otázka a neexistuje na ni univerzální odpověď. Pokud firma míří na iOS i Android a chce rozumně držet tempo i rozpočet projektu, cross-platform přístup dává často smysl. Pro velkou část firemních aplikací je to pragmatická cesta, zvlášť když je důležitá rychlost dodání a sdílená logika.

Nativní vývoj má výhodu tam, kde je potřeba maximum výkonu, velmi specifická práce s hardwarem telefonu nebo platformně odlišné chování. U některých produktů je to správná volba. U jiných by ale přinesl hlavně vyšší složitost bez odpovídajícího přínosu.

Rozumné rozhodnutí vzniká až ve chvíli, kdy známe použití aplikace, požadavky na integrace a plán dalšího rozvoje. Ne dřív. Technologie má sloužit produktu, ne obráceně.

Jak vypadá zdravý začátek projektu

Dobrý start projektu není o tom strávit měsíce dokumentací. Ale ani o tom skočit rovnou do programování. Mezi těmito extrémy je poměrně praktický střed.

Nejprve si společně s klientem srovnáme rozsah. Co musí být v první verzi, co může počkat a co je zatím jen hypotéza. Potom navrhneme tok aplikace, datový model a technické hranice systému. V této fázi se často ukáže, že část původních představ je zbytečná a jiná část naopak chybí.

Teprve potom má smysl jít do návrhu rozhraní a implementace. Tím se šetří čas na obou stranách. Zakladatel nebo produktový owner neplatí za slepé odbočky a vývojový tým nestaví funkce, které se později vyhodí.

Na čem se projekty zbytečně zadrhnou

Ve firemním prostředí nebývá problém jen technický. Často chybí vlastník produktu, který dělá rozhodnutí průběžně. Když se každá drobnost schvaluje ve čtyřech lidech jednou za dva týdny, projekt se zpomalí bez ohledu na kvalitu týmu.

Druhý častý zádrhel je snaha vměstnat do první verze všechno. Přihlášení, reporting, role, exporty, chat, notifikace, více jazyků, offline režim, BI přehledy a ještě partnerský portál. Jednotlivě to mohou být legitimní požadavky. Dohromady ale často zabijí moment, kdy se měla první verze dostat k reálným uživatelům.

Třetí problém je podcenění provozu po spuštění. Aplikace není hotová tím, že projde schválením v obchodech. Teprve po nasazení se ukáže, jak se chová v reálné síti, na různých zařízeních a při skutečném používání. Pokud za projektem po launchi nikdo nestojí, začne rychle stárnout.

Co sledovat u první verze aplikace

První verze by neměla dokazovat, kolik funkcí se podařilo stihnout. Měla by ukázat, že aplikace skutečně řeší správný problém. To znamená sledovat používání, dokončení klíčových kroků, chybovost a místa, kde uživatel odpadává.

U interních aplikací bývá dobrý signál zkrácení času na úkol, menší chybovost při zadávání dat nebo vyšší disciplína v reportingu. U zákaznických produktů je důležité, jestli se lidé vracejí, jestli aplikaci opravdu otevřou v situaci, pro kterou vznikla, a jestli se bez ní proces zhorší. To je často hodnotnější než sledovat samotný počet stažení.

Jak poznat dobrého partnera pro vývoj

Pokud vybíráte tým pro vývoj mobilní aplikace pro firmu, nehledejte jen dodavatele, který řekne ano na všechno. To se poslouchá dobře na začátku a hůř při předávání. Lepší je partner, který umí říct, co nedává smysl, kde je technické riziko a co by postavil jinak.

Důležitá je i schopnost dodat celek, ne jen kód v repozitáři. Tedy architekturu, backend, aplikaci, release proces, údržbu i další rozvoj. Ve chvíli, kdy aplikace začne být součástí provozu firmy, už nejde jen o projekt. Jde o systém, na který se spoléhají lidé uvnitř firmy nebo zákazníci venku.

U mobilního produktu to znamená hlídat nejen release do obchodů, ale i backend, synchronizaci a chování na reálných zařízeních, ne jen kód v repozitáři.

Vývoj mobilní aplikace pro firmu se vyplatí tehdy, když navazuje na reálný proces a když má někdo disciplínu držet rozsah, priority i další rozvoj. Pokud si na začátku poctivě vyjasníte, komu aplikace slouží a co má změnit v praxi, nevznikne jen další položka v portfoliu. Vznikne software, který si ve firmě opravdu obhájí své místo.