Dec 5, 2023
6 min read
Katerina
Jen v samotné České republice mají firmy na výběr mezi velkým množstvím softwarových studií, která dokážou klientovi postavit aplikaci na míru tak, aby pomáhala plnit jeho podnikatelský záměr. Tito klienti se snaží mezi vývojáři zorientovat a vybrat pro sebe toho nejlepšího. Ale pokud neosloví dodavatele na základě doporučení a váhají, často sklouznou k tomu, že se rozhodují podle ceny.
V článku, který ukazuje vývoj aplikace krok za krokem, jsme nastínili, v čem spočívají specifika a výhody agilního vývoje. Většina vývojářů má zavedenou právě tuto metodiku a na faktorech, které cenu aplikace ovlivňují, se víceméně všichni shodují.
Na začátku nového projektu tyto faktory s klientem procházíme v rámci analýzy jeho potřeb, abychom zjistili, jak komplexní si aplikaci představuje. V tomto článku si je shrneme pod pět základních otázek a připojíme k nim zároveň naše doporučení nebo komentář k dobré praxi.
První bod, který je potřeba si vyjasnit, je, kolik aplikací se vlastně bude vyvíjet. Ta, kterou uživatel uvidí a bude ji používat ve webovém prohlížeči, je na frontendu. Další ale poběží v pozadí na backendu a bude organizovat data vložená uživatelem. Potom může být žádoucí vytvořit i mobilní verzi aplikace, jednu pro iOS, další pro Android. Nakonec bude potřeba připravit i administraci, aby si klient mohl sám editovat obsah a grafické prvky. Než jsme se nadáli, už vyvíjíme 5 aplikací.
Pokud není aplikace primárně mobilní, ale webová, doporučujeme až do vzniku první funkční verze (MVP) vyvíjet jen pro jednu platformu – webovou – a potom se rozhodnout, jak pokračovat. Dosavadní vývoj většinou klienta nasměruje a pomůže mu upřesnit jeho očekávání.
Tato otázka navazuje na první, protože technologie se vybírají podle platforem. Situace se nám rozpadá na další dva scénáře.
Aplikace může být plánovaná pro byznys, který už je delší dobu zavedený a má určitou finanční stabilitu. Dá se očekávat, že bude aplikace každý měsíc rozšiřována o nové funkce a bude muset podporovat poslední vychytávky nových smartphonů. V takovém případě je lepší ji psát nativně. Pro Android se použije Kotlin/Java a pro iOS Swift.
Budoucnost ale může být nejistá – klient je například začínající startup, aplikace může být zamýšlena jako zkušební rozšíření portfolia, případně má plnit jen „office“ funkce jako nástavba na informační systém. Takový projekt je lepší psát hybridně, např. v React Native. V těchto situacích se taky dá využít technologie Progressive Web App, tím stáhnout náklady ještě níž a ušetřit čas. Od rozhodnutí o platformách a technologiích se dále odvíjí počet vývojářů v týmu. S hybridním vývojem si poradí i dva programátoři (jeden píše backend a druhý frontend pro web, iOS i Android), kdežto k nativnímu vývoji budou potřeba vývojáři čtyři – jeden na backend a pak tři jednotlivě na web, iOS a Android frontend.
Stejně jako vývojovou fázi i design lze řešit různými způsoby. Nejlevnější a zároveň nejjednodušší variantu pro následný vývoj představuje design vycházející ze stanovených „guidelines“ od společností Apple a Google. Guidelines tvoří ucelený systém standardizovaných prvků designu, které využívají nativní Apple a Google aplikace.
Jaké jsou výhody předepsaného systému? Uživatel se s dotyčnými prvky setkal již mnohokrát a jejich ovládání zná. Je to trochu jako byste se přestěhovali do identického domu, jen s odlišnými barvami na stěnách a novou kuchyňskou linkou. Navíc jsou tyto prvky efektivní. Počítá se s jejich použitím v různých prototypovacích nástrojích. Stačí je poskládat do požadovaného layoutu a přizpůsobit k obrazu svému.
Abychom tomu předešli, raději navrhujeme vlastní guidelines. Je to sice o něco dražší, ale klient dostane unikátní designový systém sestavený jen pro jeho aplikaci. Pak záleží jen na něm, jestli dá přednost originálnímu vzhledu, nebo se spokojí s ekonomickou variantou, v rámci které se guidelines jen „posunou“ do vývojové fáze a staví se z nich aplikace za běhu.
Doporučujeme raději věnovat péči UI designéra opravdu každé obrazovce. Stává se, že guidelines zcela nepokryjí potřeby aplikace a na některých místech je potřeba vymyslet řešení na míru. Ve fázi návrhu lze také pohodlně ověřit, zda mají jednotlivé obrazovky aplikace logickou návaznost a zda je prostředí snadno ovladatelné.
Tato otázka má na cenu největší vliv a větví se do dalších témat. Aplikace může být jednoduchá, obsahovat jen pár obrazovek a žádnou backendovou infrastrukturu. Může ale být i složitá až hyper-složitá, kdy už v sobě spojuje prvky sociální sítě se strojovým učením nebo rozšířenou realitou.
Během úvodní analýzy zjišťujeme, jak důležité jsou pro klienta funkce v následujícím seznamu. Dáváme mu je do souvislosti s našimi zkušenostmi, s produkční náročností a s cenou, aby se sám mohl rozhodnout, jestli jsou to pro něj „must have“, nebo jen „nice to have“.
Jak jsme řekli v článku o fázích vývoje, ne vždy zbývá klientovi místo v budgetu na hloubkové, automatizované testy. Patří ale mezi naše nejvýraznější doporučení, aby se tato metoda testování aplikace využila, protože dokáže mnohem rychleji než člověk otestovat všechny možné průchody aplikací, jejichž počet s přidáváním funkcí exponenciálně roste.
Automatické testy projdou nejdůležitější scénáře použití (login, platba, úprava profilu…) a zjistí, jestli u nich s novou aktualizací nenastala regrese – tedy situace, kdy nově přidaný kód rozbije starší, již otestovaný kód v jiné části aplikace.
Po tom, co společně s klientem provedeme analýzu jeho potřeb, potvrdíme si sadu funkcí a design, si vezmeme 14 dní na to, abychom připravili klikací prototyp. Na jeho základě se dá udělat první hrubý odhad celkové ceny vývoje.
1. Hrubší odhad po odsouhlasení UX prototypu, a to na základě podobnosti s jiným projektem.
2. Přesnější odhad při naceňování jednotlivých sprintů, kdy klientovi komunikujeme částku, jakou ho bude stát dalších 14 dní vývoje.
Postupně jak se agilní metodou posouváme vpřed a odškrtáváme seznam požadavků, je obrys konečné ceny čím dál zřetelnější. Tímto stylem práce za 4–6 měsíců dorazíme k MVP, kdy klient dostane do ruky první funkční verzi aplikace. V tuto chvíli si může vyhodnotit, kolik z původně naplánovaných funkcí skutečně chce dotáhnout, v jakém pořadí po sobě a v jakém časovém horizontu. Touto dobou je spolupráce zpravidla už běží jako na drátkách a pro klienta není těžké se rozhodnout, kolik ještě chce do aplikace investovat času a prostředků, aby byla tip ťop a podle jeho představ.
Pojďme ho probrat.
</07> PŘÍBĚHY KLIENTŮ I TECHNOLOGIE
Udělejte první krok k realizaci Vašeho nápadu. Rezervujte si schůzku s Honzou Jelínkem.