Category: Vývoj

5 faktorů, které ovlivní cenu vaší aplikace

Podle webu Bankmycell se počet uživatelů smartphonu s internetem v roce 2021 vyšplhal na 6,37 miliard. Není tedy divu, že poptávka po mobilních aplikacích jde s tímto trendem ruku v ruce. Zvažujete v rámci svého byznys záměru aplikaci taky, ale nevíte, na kolik vás přijde peněz a hlavně proč? Pak je tento článek pro vás. 

Jen v samotných Čechách 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 toho pro ně nejlepšího. Ale pokud nejdou vyloženě na doporučení a váhají, často sklouznou k tomu, že se rozhodují podle ceny za vývoj. 

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.

1. Kompatibilita aplikace

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 vyměňovat obsah a grafické prvky. Než jsme se nadáli, už vyvíjíme 5 aplikací.

Nová aplikace

Co doporučujeme?

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í.

2. Technologie zvolené pro vývoj

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.

Scénář 1

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.

Scénář 2

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.

3. Sofistikovanost vizuálního stylu

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.

Pokud se budeme držet Apple nebo Google guidelines, aplikace bude i po změnách vypadat jako „každá jiná od Applu nebo Googlu“. Je to sice levnější řešení, ale Váš brand určitě neposílí.

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é.

4. Rozsah funkcí aplikace

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“.

5. Automatizované testy (?)

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.

Postup odhadu ceny pro klienta

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.

Fáze odhadu

  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.

Řekněte nám, o jaké aplikaci přemýšlíte,
a my se vám rádi ozveme s nezávazným návrhem.

Pokud byste si rádi přečetli více o naší práci, doporučujeme rozkliknout náš BLOG, na kterém shromažďujeme například rozhovory s našimi klienty nebo různé tipy a triky z oblasti technologií a podnikání.

Dozvědět se více

Průběh vývoje aplikace v KOALA42 krok za krokem

Na začátku každé spolupráce se nás klient logicky ptá, co může od vývoje aplikace čekat – v jakých krocích se celý proces odehrává, jak spolu budeme komunikovat a na kolik ho celá záležitost vyjde peněz. V tomto článku se podíváme zblízka na první dvě otázky a ceně aplikace a faktorům, které ji ovlivňují, se budeme věnovat v samostatném článku.

Není pro nás úplně železným pravidlem, že začínáme aplikaci vyvíjet vždy od nuly – stává se nám taky, že dostaneme do ruky rozdělaný projekt a máme za úkol ho dotáhnout. Máme pochopení pro to, že klient potřebuje dokončit aplikaci za použití technologií, ve kterých vznikla, a nemůže si dovolit dosud investované peníze vyhodit oknem. Dává nám to smysl z hlediska dlouhodobého vztahu s klientem – rádi mu ušetříme peníze. Pro potřeby článku se ale podíváme na vývoj aplikace od A do Z a zmíníme následující témata:

  • Řízení projektu metodou waterfall
  • Proč stále častěji dostává přednost agilní vývoj
  • Design v pojetí Koaly
  • Postupné iterování aplikace
  • Dbáme na zastupitelnost
  • Komunikace mezi vývojářem a klientem
  • Testování, opomíjená část vývoje
  • Vydáním příběh nekončí

Řízení projektu metodou waterfall

Někteří klienti (vlastně jich je stále většina) otevírají spolupráci tak, že za softwarovou firmou přijdou s balíkem práce, balíkem peněz a otázkou „Kdy můžeme aplikaci očekávat?“ Mají často velký zájem o to, aby cenu za vývoj mohli zafixovat. 

Co se ale snažíme vždy vysvětlit, je, že s metodou vývoje zvanou waterfall není možné klientovi dát přesnou představu, jak bude vypadat produkt, který vypadne na druhé straně.Postupuje se při ní tak, že se aplikace designuje a programuje v celé svojí šíři a ke každému dalšímu kroku se přistoupí, až když je ten předchozí považovaný za hotový. 

Vývoj aplikace – ať už webové, nebo mobilní – se občas přirovnává k výrobě auta. Vodopádový model v této metafoře od začátku chystá závodní Ferrari, které klient dlouho vidí jenom na papíře a projet se v něm může až ke konci projektu.

Agilní vývoj

Proč stále častěji dostává přednost agilní vývoj

Agilní vývoj si naproti tomu klade praktické cíle v kratších úsecích – sprintech. Na začátku každého sprintu, který trvá 14 dní, se definují jednotlivé dílčí úkoly (tasky) a programátoři je potom postupně z projektu ukrajují. U agilní metody se nedá závazně říct, jestli bude celý projekt trvat tři měsíce, nebo šest, ale klient může vývoj daleko více ovlivňovat. Na konci každého sprintu dostává report, ve kterém vidí, o jaký kousek vývoj zase pokročil kupředu, a může podle potřeby upřesnit zadání. 

Pokud se vrátíme k metafoře s automobilem – nedodáváme klientovi po částech precizně sestrojený volant, nápravu, karoserii a tak dále. Dostane od nás rovnou koloběžku, která ho dopraví z bodu A do bodu B. V tu chvíli může aplikaci vzít a ověřit si její základní funkce v praxi se zákazníky.

Agilní vývoj počítá s tím, že se během projektu budou dít změny, takže když se s klienty bavíme o ceně a jejím zafixování, docházíme k tomu, že je pro obě strany lepší mít flexibilní budget. Vývojář pak nemá svázané ruce, když ze strany klienta přijdou v průběhu vývoje nové požadavky, a kromě toho dokáže pružně zakomponovat novinky z technologického pokroku.

Waterfall vs Agile

Design v pojetí Koaly

Na začátku spolupráce si nejdřív ze všeho s klientem potvrdíme koncept aplikace a zjistíme od něj maximum informací o tom, jaké funkce od ní potřebuje. Během analýzy se snažíme co nejlépe pochopit, jak funguje klientův produkt (nebo procesy, pokud jde o interní aplikaci), na co klade největší důraz a jak může aplikace podpořit jeho „edge“, tedy konkurenční výhodu oproti ostatním v oboru.

Už při vývoji koloběžky dbáme na to, aby design byl na dobré úrovni a aby byl funkční. V této fázi má hlavní slovo UX designér, který má za úkol nastavit logiku aplikace z pohledu uživatele– aby orientace v jejím rozhraní byla snadná a průchod jejími částmi logický. 

Domluvenou představu o aplikaci co nejdříve převádíme do podoby UX prototypu, který si klient může proklikat a prohlédnout do posledního detailu. Je lepší si aplikaci co maximálně odladit dřív, než se začne programovat. Později během samotného vývoje už jsou větší zásahy do produktu náročnější a zbytečně dražší. 

Postupné iterování aplikace

Od chvíle, kdy si s klientem odsouhlasíme UX prototyp a shodneme se, které funkce by zásadně měly být součástí aplikace, se rozjíždí samotný agilní vývoj. Na začátku 14denního sprintu si s klientem vždy řekneme, co je reálné stihnout, a na konci sprintu mu odevzdáváme funkční demo v takzvané dev verzi na testovacím serveru.

Jak už bylo řečeno, naším úkolem je klientovi co nejdříve dodat pojízdný model – koloběžku, které se říká MVP (minimal viable product). Po MVP následuje kolo, které toho umí o něco víc, pak motorka a nakonec ono Ferrari, které dost možná bylo v plánu od samého začátku, ale mohlo se k němu taky dospět až cestou.

Někdy se může stát, že po kole přijde loď, protože si klient během vývoje aplikace uvědomil, že jeho podnikání je o něčem trochu jiném. Díky tomu, jakou flexibilitu agilní vývoj umožňuje, to ale nemusí být takový problém.

Dbáme na zastupitelnost

Podle náročnosti aplikace na programování případně jeden až tři z celkového týmu 13 zkušených vývojářů. Máme v týmu lidi s širokým záběrem v technologiích a programovacích jazycích, ale zároveň držíme kolektivní know-how projektu, abychom zaručili zastupitelnost a aby se sprinty v případě nemoci nebo náhlého výpadku lidí nezadrhávaly. Píšeme kód i dokumentaci tak, aby mohl kdokoli do projektu naskočit, rychle se zorientovat a navázat na kolegovu práci.

Komunikace mezi vývojářem a klientem

Je pro nás úplně běžné se s klientem synchronizovat denně nebo párkrát do týdne. Jsme dostupní na telefonu, na e-mailu, nebo chatovacích nástrojích. Všechny požadavky sepisujeme do backlogu, který v každém daném okamžiku přesně odráží současný stav aplikace. Máme potom pečlivý záznam o tom, kde zrovna ve vývoji jsme a na čem jsme se s klientem domluvili.

Každý projekt postupně roste. Koloběžka na sebe nabaluje další a další funkce a zakomponovat je bývá těžší než na začátku, protože už se jedná o změny v mnohem komplexnějším celku. I přesun tlačítka na jiné místo může trvat půl dne, protože k tomu nestačí Ctrl+X a Ctrl+V.

Zastupitelnost týmu

Vývojář musí nejdřív zjistit, co všechno změna ovlivní, musí ji naplánovat, provést a otestovat. Na backendu se může snadno stát, že se i menší změna nečekaným způsobem projeví v úplně jiné části aplikace.

O časové náročnosti ale s klientem otevřeně mluvíme a na konci sprintu ukazujeme, kolik hodin se strávilo na kterém úkolu, abychom případně mohli upravit priority.

Testování, opomíjená část vývoje

Pokud je na testování vyčleněná jenom malá část rozpočtu, nedají se naskriptovat a provést opravdu hloubkové, automatizované testy. Manuální testy jdou bohužel vždy jen po povrchu a nepokryjí každou představitelnou kombinaci kroků, kterou může později uživatel v reálu provést. 

Testování

Může se potom stát, že aplikace se zasekne a spadne zrovna ve chvíli, kdy si ji prohlíží CEO – kdy jindy, že? – a problém je na světě. Automatizace je v testování vždy výhodná. Je důležitá kvůli zachycení případné regrese – tedy toho, že po nové změně přestane fungovat kód v dříve napsaných (a otestovaných) částech aplikace. Automatizace tedy šetří obrovské množství času vývojářům i testerům a my ji rozhodně považujeme za důležitý krok směrem ke špičkové výsledné kvalitě.

Vydáním příběh nekončí

Když je vše v pořádku otestováno a schváleno, můžeme provést release – aplikaci vydat. Vydání znamená přesun kódu aplikace na produkční server a publikaci na webu, případně v App Store (iOS) a/nebo Google Play (Android). Ať už je to koloběžka, kolo, nebo motorka, není to tak, že bychom si oprášili ruce, vystavili fakturu a šli od toho. Opravujeme bugy, které se mohou projevit až po nějaké době, a optimalizujeme v návaznosti na aktualizace operačních systémů.

Přeci jen jsme postavili funkční nástroj a je na nás, abychom ho udrželi při životě. 

Kromě samozřejmých oprav klienta rádi upozorníme, když se objeví nová technologie, která by pro jeho projekt mohla mít nějakou zajímavou přidanou hodnotu, takže se potom spolupráce může rozvíjet roky. Záleží nám na dlouhodobých vztazích a kvalita u nás pokaždé zvítězí nad kvantitou. A proto máme projektů čím dál víc.


Pokud byste si rádi přečetli více o naší práci, doporučujeme rozkliknout náš BLOG, na kterém shromažďujeme například rozhovory s našimi klienty nebo různé tipy a triky z oblasti technologií a podnikání.

Dozvědět se více