Synetech

Zadáváte vývoj mobilní aplikace poprvé? Poradíme vám

Významná chvíle nadešla! Konečně jste se pevně rozhodli, že svůj projekt potřebujete dostat na mobilní platformy a přemýšlíte, komu vývoj mobilní aplikace zadat… A tápete. A my to chápeme — koneckonců, to, jak probíhá tvorba aplikací není úplně všeobecnou znalostí a faktorů, které ovlivňují cenu je množství nemalé. A tak jsme se rozhodli připravit pro vás souhrn toho, jak takový vývoj aplikací pro Android a iOS vlastně probíhá a pro vás následně bylo jednodušší určit, komu jej zadat nebo jaké financování zvolit, aby vaše prostředky nepřišly nazmar.

Dozvíte se:

  • Rozdíly mezi typem dodavatele
  • Že vývoj mobilní aplikace je proces, ne dílo
  • Proč je vývoj mobilní aplikace tak drahý

first

Rozdíl mezi typem dodavatele

1. Samostatný vývojář (freelancer)

Jak už název napovídá, jedná se o samostatný subjekt, který se vám postará o celý vývoj mobilní aplikace a její distribuci — tedy o jediného člověka, který je vám schopen za pár týdnu celou appku dodat. Stará se o definici produktu a komunikaci se zadavatelem a sám potom je schopen si po sobě aplikaci otestovat a vydat.

Výhodou tohoto přístupu je, že programátor si organizuje práci samostatně a má jasný přehled o tom, co se v aplikaci děje. Nedochází ke komunikačnímu šumu v rámci týmu a lépe se tak s daným člověkem pracuje… Teoreticky. Nevýhodou totiž často bývá, že většina samostatných vývojářů má se srozumitelnou komunikací navenek a reportingem poměrně velké problémy. Může tak jednoduše dojít k chybnému pochopení zadání a tím pádem k celkem zásadním komplikacím v průběhu vývoje mobilní aplikace.

Další nevýhodou je neexistující prioritizace. Se samostatným freelancerem je problematické urychlit vývoj a pokud se stane (a není to nepravděpodobné), že takový dodavatel onemocní, bude zavalen další prací, nebo odjede na dovolenou, budete muset posunout deadline.

V neposlední řadě je nutné mít na paměti, že programátor, který již delší dobu pracuje na jednom projektu, bude mít také velmi omezený pohled na logické chyby v aplikaci a zároveň může přehlížet přehmaty, které v aplikaci sám nevědomky udělá.

Jakkoliv pesimisticky mohou předchozí řádky znít, vězte, že pokud se vám podaří najít freelancera, který je spolehlivý a komunikativní, tak je to pro vývoj mobilní aplikace nejlepší volba. Těchto lidí, u kterých se vyhnete výše popsaným problémům, je však velmi málo (a obvykle tomu pak také odpovídá jejich vytíženost). Je to vlastně takový modrý Mauricius na trhu práce.

Cena: Nízká

Míra rizika: Vysoká

Výhoda: Přímá komunikace s vývojářem

2. Menší studio (ve velikosti zhruba 20 lidí)

Agenturní přístup poskytuje vyšší spolehlivost díky zastupitelnosti vývojářů. Studio vám je schopno dodat celý tým, tím ovšem logicky roste cena projektu proti samostatnému freelancerovi. V porovnání s jednotlivcem je ve vývojářské sestavě kromě programátora ještě druhý programátor, projektový manažera tester. Jedná se tak o 4 lidi namísto jednoho, kteří vám však zajistí, že budou zadání a specifikace správně vykomunikovány a práce korektně zadána s pravidelnými výstupy ve formě nové verze aplikace (to zajišťuje role projektového manažera). Druhý programátor garantuje zastupitelnost a zároveň provádí vzájemnou kontrolu kódu aplikace, což je poměrně zásadní — nezávislý pohled druhého člověka odhalí velké množství problémů již v počátku a na všechno navíc ještě dohlíží tester, který má za úkol snažit se aplikaci rozbít. Simuluje různé situace, které v telefonu mohou nastat, a zajišťuje, aby se aplikace nedostala do špatného stavu.

Tým lze následně velmi jednoduše škálovat, tak aby byla i větší aplikace dodána ve správném čase, což je proti jednotlivci samozřejmě zásadní plus. Nevýhodou menší agentury proti freelancerovi je logicky vyšší cena tvorby projektu. Zakázka musí zaplatit provoz firmy a k tomu ještě 4 lidi, místo jednoho samostatného vývojáře.

I zde pak může hrozit nebezpečí, že pokud tým nefunguje správně, může docházet ještě k většímu komunikačnímu šumu a prodlevám než u samostatného vývojáře. Je třeba proto vybírat studia osvědčená s prokazatelnými referencemi. Menší agenturu oproti té větší upřednostníte, pokud je vám bližší osobní a lidštější přístup před zavedenými a neměnnými korporátními procesy.

Cena: Vyšší

Míra rizika: Nízká

Výhoda: Zastupitelnost vývojáře, snížení rizika dodání špatné aplikace

3. Větší agentura (nad 20 lidí)

Větší agentura budí větší důvěru, vzhledem k množství zkušeností a zastupitelnosti lidí. Je stabilní finančně, takže pravděpodobně nezkrachuje během vývoje vaší aplikace, což přece jen potěší vědět.

Větší agentury ale již vyžadují hierarchické struktury, tak aby byly distribuovány informace a celkově byl provoz udržitelný. Zároveň taková firma řeší mnoho zakázek najednou, takže vedení váš projekt pravděpodobně nebude řešit osobně, pokud se nejedná o něco zásadního.

Cena menší a větší agentury se zásadně lišit nebude, a pravděpodobně nenaleznete ani příliš velké rozdíly v kvalitě. Obě agentury mohou poskytnout dobrou i špatnou práci v závislosti na motivaci agentury poskytovat kvalitní řešení. Platí tedy, že pro bezproblémovou tvorbu aplikací jsou zásadní reference studia, ať už menšího či většího, a pak je vše v dobrých rukou.

Cena: Vyšší

Míra rizika: Nízká

Výhoda: Větší důvěra, stabilita na trhu

Vývoj mobilní aplikace je proces, ne dílo

Vybrali jste si, komu svěříte programování aplikací? Pak jste na dobré cestě, ale tady vaše dilemata zdaleka neskončí. Další zásadní položkou, o které se musíte fundovaně rozhodnout, je nacenění prací. Většina appek se v průběhu vzniku mění — vývoj mobilní aplikace totiž často narazí na původně nedomyšlené detaily, či se v průběhu programování aplikací změní trh nebo trendy v oboru.

Tvorba aplikací za fixní cenu

Zkrátka změny jsou naprosto přirozené a je dobré s nimi počítat. V případě smlouvy fixed price — fixed time se úpravy řeší pomocí změnových požadavků od původního zadání.

Zde ale nastává problém — jak se změní původní cena? Chceme-li nyní odchylky od zadání, tak přeženeme-li to — neměla by se dohodnutá odměna spíše snižovat v závislosti na tom, kolik kódu se vlastně nenapsalo? V tuto chvíli začne být celá situace poměrně složitou a místo vývoje mobilní aplikace spíše řešíte byrokracii a neustále přepočítávání.

K tomu si navíc ještě připočtěte fixní datum dodání, které nelze posunout, a praktický výsledek je takový, že pouhých 15 % projektů dopadne zdárně bez zdražení, s udržením kvality a plné funkcionality. (Převzato z Agilní metody řízení projektů od Zuzany Sochové, Eduarda Kunce)

Vývoj aplikací a agilní smlouva

Jak z toho ven? Jako ideální řešení se jeví agilní smlouva se studiem, která je založena na předplacení týmu na sprint a před každým dalším sprintem se zákazník rozhodne, zda mu dané funkcionality již stačí nebo v základu vyžaduje více funkcionalit. Tento přístup zahrnuje velmi aktivní začlenění klienta do týmové práce — pravidelně jsou mu reportovány pokroky, a tím pádem zákazník přesně ví, za co zrovna platí. Vyžaduje to ale kompletní transparentnost a součinnost všech členů procesu. Klient pak kormidluje celý proces vývoje k výsledku, který přesně v daný okamžik vyžaduje a neutrácí tak své peníze zbytečně, vývoj aplikací pro Android nebo iOS totiž není levná záležitost. Proč tomu tak je?

Proč je vývoj mobilní aplikace tak drahý?

Výpočet ceny aplikace se přímo odvíjí od práce, kterou musí strávit jednotlivec nebo tým nad jejím vývojem. Množství práce, které je třeba odvést, je závislé na výběru technologie i velikosti aplikace a většinou jde o spoustu činností, které na první pohled nejsou vidět, avšak v konečném důsledku hrají zásadní roli. Abychom vám více přiblížili, o čem je řeč, rozhodli jsme se vám ukázat na změně pozice tlačítka v aplikaci, jak náročný je na první pohled jednoduchý úkon.

Příklad: Změna pozice tlačítka v aplikaci

Zadání od klienta: Přesunutí tlačítka z horní části obrazovky na spodek

Na první pohled jednoduchá úprava, která vypadá, že zabere 15 minut, v praxi jde ale o proces, který zabere mnohem delší dobu. Jak se to může stát?

Po 5 minutách

Vývojář dostane zadání, které definuje přesun tlačítka níže. Posune jej podle svého nejlepšího vědomí a svědomí na spodní okraj obrazovky, což mu zabere zhruba 7 minut. Výborně, zvládli jsme to o dost rychleji! Avšak v rámci udržení kvality kódu musí každou vyrobenou funkci zkontrolovat jiný vývojář, aby se ujistil, že je kód napsaný správně. Kontrola a ověření, že je vše v pořádku, zabere kolegovi zhruba 5 minut. Jsme tedy na 12 minutách a stále jsme v rámci odhadu!

V tuto chvíli máme neotestovanou verzi aplikace, která je k dispozici v repozitáři a na telefonu vývojáře. Takovouto neotestovanou aplikaci ale nemůžeme předat klientovi na akceptaci funkcionality, v tuto chvíli ji proto dostane tester.

Po 27 minutách

Ten si nastuduje, co bylo přesným zadáním klienta a funkcionalitu začne testovat na více různě velkých telefonech s různou kvalitou displejů. Na jednom ze zařízení zjistí, že se text zobrazuje chybně a přesahuje velikost tlačítka, což je třeba opravit. Reportuje tak chybu zpět vývojáři, a kromě tohoto problému potvrzuje, že je změna naimplementována. Otestování i s reportem chyby mu zabralo 15 minut a jsme tedy aktuálně na 27 minutách.

Po 67 minutách

Programátor, který chybu způsobil, si přebírá znovu aplikaci a začíná řešit opravu pro dané konkrétní zařízení. Bohužel často zjistí, že tato úprava není úplně triviální, protože se jedná o specifickou změnu pouze pro toto jedno zařízení. Za 30 minut se mu podaří nalézt správné řešení, avšak vzhledem k tomu, že se jedná o další zásah do kódu, si jej musí opět nechat zkontrolovat jiným vývojářem. Dohromady jim zabralo 40 minut, aby opravili problém se špatným textem na jednom specifickém zařízení a jsme aktuálně na 67 minutách celkem.

Tester otestuje, že funkcionalita je správně implementovaná a změna již funguje na všech testovacích zařízeních. Připravuje verzi pro projektového manažera, který jde představit novou funkcionalitu klientovi. Otestování funkčnosti a příprava demonstrační verze, včetně komunikace, zabere testerovi 10 minut. Celkově jsme tedy za celou implementaci spotřebovali 77 minut. Pak již projektový manažer předává verzi klientovi a seznamuje ho s implementovanou funkcionalitou.

Po 107 minutách

Klient si ale představoval, že tlačítko ve spodní částí obrazovky bude vypadat lépe. Nyní ale zvláštním způsobem překrývá spodní část obrazovky, což se mu ve výsledku nelíbí a prý by pomohlo, kdyby tlačítko mělo pod sebou poloprůhledné pozadí. Klient tedy reklamuje dodanou funkci.

Projektový manažer si na základě schůzky připraví nové zadání pro programátory a celkově mu demonstrace a příprava nové změny zabraly 30 minut a jsme aktuálně na 107 minutách práce.

Po 147 minutách

Po implementaci pozadí, otestování a následné další prezentaci u klienta, jsme na aktuálním čase 2 hodiny 27 minut. Klient už je takto spokojený a chce mít aplikaci s úpravou co nejdříve nahranou na App Store, ale tak jednoduché to není.

Jednalo sice se o jedinou funkci, která je v tomto updatu aplikace, nicméně v rámci udržení kvality je potřeba provést celkové testy aplikace, jestli nemohla nastat při vývoji nějaká chyba, která by způsobila nefunkčnosti některé části. Tester musí provést tzv. systémové testy, kdy projde všechny funkce appky a zjistí, jestli všechny stále fungují, jak mají.

Po 207 minutách… Je hotovo

Následně připraví pro projektového manažera release verzi, která je již vhodná k umístění na App Store. Celkově testování zabralo dalších 40 minut a jsme tedy na 3 hodinách a 7 minutách.

Příprava záznamu na App Store a distribuce releasu vyžaduje zhruba dalších 20 minut a celkově jsme se tedy dostali z původních 15 minut na 3 hod a 27 minut. A co teprve, když je třeba provést úpravu mnohem složitější?!

Závěrem

Jak tedy vše shrnout? Vývoj aplikací pro Android a iOS je daleko časově náročnější, než se zdá. Je proto na zvážení, zda by studia a agentury neměly místo fixed price — fixed time smluv, které se po několika netrefených odhadech stejně začnou přeceňovat, aby zahrnovaly i možná rizika, rovnou nepodepsat agilní smlouvu, která rozděluje celý vývoj mobilní aplikace na jednotlivé sprinty. Ideální je také mít přesnou přípravu aplikace, včetně technické specifikace, neboť čím víc času se stráví před zahájením vývoje, tím víc peněz a nervů se ušetří následně.

Hodně štěstí, aplikacím zdar :)

Vráťa Zima, CEO