2021-re várhatóan 350 milliárd alkalmazás letöltés fog generálódni a különböző mobilos platformokon, ez közel 200 milliárd dollárnyi árbevételt jelent. Nem meglepő, hogy a mobilalkalmazás fejlesztés manapság nagy népszerűségnek örvend, exponenciális tempóban készülnek az új fejlesztések, senki nem akar kimaradni a lehetőségből.
Annak ellenére, hogy közel 2.8 millió mobil alkalmazás érhető el a Google Play áruházban és 2.2 millió alkalmazás az Apple által üzemeltetett App Store-ban, minden évben növekszik az új mobil alkalmazások száma.
Ráadásul ez a trend megállíthatatlannak látszik, a mobil eszközök átvettek a népszerűséget az „asztali” gépektől, különösen az üzleti és a technológiai körökben.
Nagyon sokan (egyre többen) szeretnének tehát saját mobilalkalmazást, legyen szó vállalati megoldásokról vagy startup fejlesztésről. A kérdés tehát:
Mennyi idő és munka egy mobilalkalmazás fejlesztés?
Megpróbálunk erre részletes választ adni néhány konkrét, valós példával alátámasztva mennyi idő és energiabefektetés kell ahhoz, hogy az ötlettől egészen egy kész, piacra vagy „munkába állítható” mobilalkalmazást készítsünk.
Az általános vélekedés szerint egy mobil alkalmazás fejlesztése 3-5 hónap
Annak ellenére, hogy minden évben 1 millió új alkalmazással bővülnek a különböző alkalmazást áruló platformok, nem áll rendelkezésre túl sok forrás, hogy valójában mennyi ideig is tart egy alkalmazás fejlesztés.
A legtöbb cég 3-4 hónapos fejlesztési időt állít ám ennek tényleges alátámasztására kevés valós, hiteles információ áll rendelkezésünkre. Azonban van mégis két, adatokkal alátámasztott kutatás a témával kapcsolatban amit érdemes megemlíteni.
Az első 2013-ban készült. A Kinvey nevű cég megkérdezett 100 mobilalkalmazás fejlesztéssel és tervezéssel foglalkozó szakembert, hogy szerintük mennyi ideig tartana egy mobilalkalmazás „1. verziójának„ (pl. MVP – Minimum Viable Product) elkészítése Android vagy iOS platformra.
A 100 visszajelzést átlagolva egy „első verziónak” (MVP) megfelelő minőségű alkalmazás fejlesztés körülbelül 18 hetet venne igénybe. Ezt az eredményt tovább bonthatjuk, 10 hét „backend” és 8 hét „frontend” fejlesztésre.
A Kinvey elkészített egy nagyszerű összefoglaló infografikát az alkalmazás fejlesztés teljes ciklusáról:
A fenti ábra elsőre kicsit zavarosnak tűnhet, a cikk későbbi részében még részletesebben bemutatjuk a backend és a frontend fejlesztés fontosabb elemeit.
Előtte nézzünk meg még egy másik tanulmányt, amit 2017-ben egy GoodFirm nevű cég készített. Az elkészült vizsgálatban kutatták a mobilalkalmazás fejlesztéshez kapcsolódó költségeket és időráfordítást. Ez a kutatás is hasonlóan folyt, mint az előbb említett Kinvey-féle, megkértek több fejlesztőt, hogy kalkulálják meg, hogy mennyi ideig tartana egy Instagramhoz, Tinderhez vagy Uber-hez hasonló alkalmazás kifejlesztése.
Az eredmények feldolgozása után a cég a következő eredményekre jutott:
- Összetett, sok funkcióval rendelkező alkalmazás (pl. Instagram, Uber) készítése nagyjából 4.5-5.5 hónap időt venne igénybe.
- Közepesen összetett mobilalkalmazás fejlesztése (pl. WhatsApp vagy QuizUp) esetében 4.6 hónapnyi idővel kell számolni.
- Kevésbé összetett, de azért felhasználóbarát alkalmazások (pl. Tinder, Periscope) pedig 3.8-41 hónapig tart.
Infografika:
Mindent összevetve tehát azt mondhatjuk, hogy egy alkalmazás elkészítése nagyjából 3-5 hónapnyi időbe telik. Vannak termesztésen kivételes esetek de az általános vélekedés szerint ez az idő tipikusan elég.
Nézzük meg a mobilalkalmazás fejlesztés alapvető állomásait, hogy képet kapjunk arról, hogy bizonyos tényezők és döntések milyen módon befolyásolják a fejlesztési folyamat hosszát.
Fontos pontok a mobil alkalmazás fejlesztés során
Habár tekinthetünk úgy a mobil alkalmazás fejlesztésére, mint egy „iteratív” folyamat, mégis hasznos, ha a teljes fejlesztést állomások sorozataként képzeljük el. A következő részben minden ilyen lépésen végig megyünk. Fontos azonban látni, hogy ezek a fázisok nem különülnek el teljesen egymástól.
1. Lépés: Kutatás és tervezés
Első lépésként két fontos kérdéscsoportra kell választ adnunk:
- Miért szeretnénk ezt az alkalmazást elkészíteni? Miért fontos? Mit és hogyan fogja azt előrébb vinni? Vajon az emberek valóban szeretnék használni ezt az alkalmazást? Kik és miért?
- Létezik már hasonló alkalmazás? Ha igen, lehet jobbat csinálni? Mi lesz az előny? Miben fog különbözni a meglévőtől?
A fent említett kérdések megválaszolása („Mit fog csinálni az alkalmazás?”, „Milyen haszna lesz?”, „Miben tud többet, mint a konkurens?”) azért kritikus, mert megköveteli, hogy pontosan megértsük mi és kik a célpiac, kik fogják használni az alkalmazást és ki az ideális felhasználó.
Fontos hogy végezzünk alapos kutatást a piaci igényekről és elvárásokról. Határozzunk meg egy üzleti tervet, árazást, a piac nagyságát és keressünk visszaigazolásokat az alkalmazás létjogosultságára.
Ezen kívül körül kell nézni a piacon, megnézni a konkurens cégeket, milyen alkalmazásokkal és megoldásokkal rendelkeznek, mi az üzleti stratégiájuk. Nehéz pontosan meghatározni ez a lépés mennyi időt vesz igénybe, de várhatóan több hét is rámehet egy intenzív piackutatásra.
2. Lépés: Funkciók
Miután megvan az elképzelésünk arról, hogy kik fogják használni az alkalmazásunkat és tudjuk, hogy van piaca, el kell döntenünk milyen funkciókra is van szükségünk.
Ezen a ponton nagyon sokan „elvesznek”.
Ez az a pillanat, ahol ki kell találni, milyen módon működjön az alkalmazásunk:
- Mit tudjon az alkalmazás?
- Milyen feladatokat, funkciókat fog ellátni? (Chat, Integráció másik alkalmazásokkal)
- Hogyan kezeli az adatot? Szeretnénk adatokat is gyűjteni vagy meglévő adatbázishoz csatlakoznánk?
Ebben a fázisban elkészítjük az úgynevezett „story board”-ot ami gyakorlatilag egy vizuális ábrázolása az alkalmazás felhasználói felületének: képernyők tervezése és egymáshoz való kapcsolódásuk.
A Storyboard segít felfedezni a hibákat, finomítani lehet a használhatóságon és a felhasználói élményen.
Tervezni kell továbbá „use case”-eket (használati eseteket) melyek arra szolgálnak, hogy illusztrálják a user – alkalmazás interakciót, azaz ideális esetben a felhasználók hogyan fogják az alkalmazást használni.
Általános szabályként elmondható, hogy minél több funkciót építünk bele a mobilalkalmazásba, annál komplexebb lesz, és annál tovább fog tartani a fejlesztés.
Az egyik legkritikusabb döntés, amit meg kell hozni ebben a fázisban, hogy az alkalmazás támogasson-e több platformot (iOS/Android) vagy elég csak az egyiket, esetleg mobilon és tableten is futnia kell.
Miért fontos tényezők ezek tehát a fejlesztési idő meghatározásánál?
- Ha több platformot, eszköztípust is támogatni szeretnénk, az biztosan mindig több időt fog igénybe venni.
- Habár a különbség egyre csökken, megállapítható, hogy az Androidos eszközökre való fejlesztés több időt vesz igénybe mint az Apple iOS. (Tapasztalatok szerintem 20-30% plusz idő.)
Ennek következtében gyakran javasolt, csak iOS támogatása első körben, azon elindítani az alkalmazást, kevesebb támogatott eszközzel és iOS verzióval. Lényegesen könnyebb megbizonyosodni arról, hogy a mobil alkalmazás hibátlanul és ideálisan működik, ha egyszerre csak egy platformra koncentrálunk.
Több, mint 12.000 féle Android eszköz van jelenleg a piacon, gyakorlatilag lehetetlen mindegyikre optimalizálni. Nem beszélve arról, hogy az Android alkalmazások tesztelése gyakran több időt is igénybe vesz.
Természetesen ezek csak ténybeli megállapítások, manapság mind a két platform támogatása ajánlott.
Szerencsére vannak nagyszerű lehetőségek, hogy ne duplázódon a fejlesztési idő két platform támogatása esetén. Hagyományosan az Android alkalmazás fejlesztés Javában és Kotlinban, az iOS fejlesztés pedig Swiftben és Objective-C-ben történik.
Elérhetőek olyan eszközök, melyek támogatják mind a két platformra történő „párhuzamos” fejlesztést minimális hátrányok mellett. Xamarin, React Native és az Ionic technológiák jó és népszerű példák erre.
Azt, hogy pontosan melyik módszert érdemes választani egyedileg, a megrendelővel közösen határozzuk meg.
Anélkül, hogy mélyebben belemennénk technikai részletekbe, mind a két (Android, iOS) platform támogatása esetén tehát két út áll előttünk:
- Két teljesen külön alkalmazás fejlesztés mind a két platformra, a saját programozási nyelvüket használva.
- Úgynevezett „cross-platform” megoldás használata (pl. a fentebb említett Xamarin, React Native, Ionic), melynek segítségével egy időben, egy technológiával tudunk több rendszert támogatni.
Ugyan lehetetlen pontosan meghatározni de általában érdemes 3-5 héttel számolni erre a fázisra, hogy meghatározzuk az alap funkciókat és az alkalmazás általános működését.
3. Lépés: Tervezés és fejlesztés
Miután meghatároztuk az alkalmazás működésének tervét, specifikáltuk a funkciókra vonatkozó elképzeléseket és kritériumokat, fontos hogy ezeket még egyszer megerősítsük, megbizonyosodjuk arról, hogy ezt szeretnénk az alkalmazásban látni.
Ez egy kritikus lépés, itt véglegesítjük a technikai csapat felé mit szeretnénk a fejlesztendő alkalmazásban. Fontos meghatározni az alkalmazás kinézetét is, az interakciókat és ellenőrizni, hogy a backend és a frontend rendszer képesek együtt működve megvalósítani az elvárásokat.
Ehhez a lepéséhez mindenképpen be kell már vonni egy fejlesztőket, programozókat akik technikai oldalról tudják biztosítani a megvalósíthatóságot.
Frontend: Vizuális megjelenése a szoftvernek, alkalmazásnak vagy weboldalnak, lényegében ezt látja a felhasználó, ezzel van kapcsolatban.
Backend: A rendszer logikáját tartalmazza, amit közvetlenül a felhasználó nem ér el, „indirekten” kerül vele kapcsolatba a frontend-en keresztül.)
Kritikus pontja a fejlesztésnek a kommunikáció a két „oldal” között.
„Ha olyan mobilalkalmazást fejlesztünk, melyhez backend, háttér infrastruktúra is kapcsolódik, fontos prioritást felállítani a készülő funkciók között. A backend fejlesztőknek némileg előrébb kell járnia, hogy a frontend fejlesztők már funkcionálisan jól működő kódot tudjanak írni. Amennyiben a backend, a háttérrendszer nincs jól meghatározva és funkcionálisan nem jól működik ez a frontend fejlesztők számára gátolja a hatékony munkavégzést. ”
Egy lényeges pont a mobilalkalmazás fejlesztés során, hogy legyen hozzáférésünk az alap adatokhoz amit a rendszer használni fog.
Fogunk publikus API-t használni? Az API az Application Programming Interface jelentése, röviden megfogalmazva egy kapcsolódási pont, amivel az alkalmazások kommunikálni tudnak egymással (vagy a fejlesztőkkel).
A legnagyobb alkalmazásoknak (pl. DropBox, Facebook, Instagram, Skype, Twitter, Uber) vannak nyílt API-uk, melyeket a fejlesztők felhasználhatnak a mobil alkalmazás fejlesztése során.
Egy példa: A Tinder (népszerű ismerkedős alkalmazás) a Facebook API-t használja. A Tinder felhasználók a Facebook profiljuk segítségével tudnak bejelentkezni, ami egy jó megközelítés, hiszen nem kellett saját felhasználói közösséget létrehozniuk teljesen az alapoktól. Támaszkodtak egy meglévőre.
Hogy meghatározzuk a frontend – backend kompatibilitását és ideális működését, megköveteli, hogy UX (user experience – felhasználói élmény) és UI (user interface – felhasználói felület) tervezést végezzünk, beleértve „wireframe” készítését is.
A UX (felhasználói élmény) tervezésének része a „wireframe” készítése. A Wireframe egy egyszerűsített ábrázolása a mobilalkalmazás felhasználói felületének, fókuszba helyezve az elemek elhelyezését, a tartalom és funkciókhoz kapcsolódó vizuális megjelenést és prioritást.
A wireframe-k általában fekete-fehérek és a következő célt szolgálják:
- Átmenetet biztosítanak az alkalmazás specifikációja és a végleges design között
- Információk és adatok megjelenítésének módja a felhasználói felületen
- Funkciók „ábrázolása” a felületen
- Tartalom fontosságának meghatározása, azaz mennyi helyet biztosítunk bizonyos elemeknek és hova helyezzük el őket
Egy példa arra, hogy nézne ki a Facebook wireframe:
A wireframe és a storyboard egy útmutatás a backend struktúrához amit a mobilalkalmazásnak támogatnia kell, legyen szó API-ról, adatdiagrammokról, adatintegárcióról, push notification szolgáltatásokról.
Miután a wireframek elkészültek, rátérhetünk az alkalmazás grafikai megjelenésének kidolgozásához. Itt már lényeges minden „design elem”, beleértve a betűtípust, színeket, ikonokat stb.
Ha a design elemek és megjelenés elkészült, az eredménynek egy vizuális utasításnak kell lennie ami a fejlesztőket instruálja abban, hogyan képzeljük el a végső alkalmazást, milyen interakcióban lesz vele a felhasználó, mit fog látni, érezni, hogyan közlekedik benne.
Sok további technológiai szempontból vizsgálhatnánk még a mobilalkalmazás fejlesztést de ez tovább mutat jelen cikk tartalmán.
Figyelembe véve a fent bemutatottakat, beleértve a wireframe és design tervezést, a technológiai kihívásokat, fejlesztést, kódolást stb. nagyjából 1.5-2.5 hónapnyi idővel számolhatunk.
4. Lépés: Tesztelés és finomítás
A legutolsó fázis a mobilalkalmazás fejlesztés során (leszámítva az alkalmazás indítását és az ezzel járó marketing tevékenységeket) a tesztelés és a finomhangolás.
A tesztelés bizonyos értelemben termesztésen a fejlesztés része is, hiszen a fejlesztők és programozók mint „alpha tesztelők” folyamatosan próbáljak a hibákat előhozni, a problémás kódokat javítani.
Az előzetes tesztelés még akkor történik (ezt végezheti a megrendelő, hivatásos felbérelt tesztelők, alkalmazottak stb) mielőtt a felhasználókhoz bármilyen szinten is eljutna.
A következő lépés a „béta-teszt”, amit már valós felhasználók végeznek.
A béta teszt célja, hogy a valóságban, igazi felhasználóktól is jöjjenek visszajelzések. Vajon tényleg annyira jó az alkalmazás mint gondoljuk? Esetleg további finomításokat kell végezni?
Ezen a ponton már a tervezett specifikációnak megfelelő működést várunk el, a cél, hogy olyan felhasználásnak is alávessük amivel esetleg nem számoltunk a fejlesztés és tervezés során. Viszont fontos azért, hogy ebben a fázisban már nagy és komoly hibák ne jöjjenek elő, azokat az alpha tesztben ki kell szűrni.
A béta tesztelők keresésére tudunk javaslatokat adni, akár célcsoportra megfelelő szűréssel.
Több körös tesztelés és finomítás nagyjából 3-4 hetet vesz igénybe, ennél több csak akkor fordulhat elő, ha az alpha tesztelést nem jól végeztük illetve a tervezés során komolyabb hiányosságok merülnek fel.
Végszó
Összeadva a fentieket, a főbb lépések időtartamát nagyjából 4-5 hónappal számolhatunk ha mobil alkalmazást szeretnénk fejleszteni. Láthatjuk, hogy a mobil alkalmazás fejlesztés egy komplex és összetett folyamat ami gyakorlatot, türelmet és elszántságot kíván.
A végére két tanács azoknak akik mobilalkalmazás fejlesztés előtt állnak:
- Számolni kell csúszásokkal és próbáljunk némileg flexibilisek maradni fejlesztési idő kalkulálása során: Előre nem látható események következhetnek be pl. új operációs rendszer, harmadik fél által készített megoldás integrálásával felmerülő problémák. Hagyjunk egy kis rugalmasságot a tesztelési időszak meghatározásánál is, hiszen szembe jöhet egy-két váratlan kihívás. Amit fontos elkerülni, hogy olyan alkalmazást engedjünk ki a kezeink közül ami hibásan működik, rossz felhasználói élménnyel. Mindenkinek egy lehetősége van és az első benyomás kritikus.
- Győződjük meg róla, hogy a fejlesztőcsapat publikálás után is rendelkezésünkre áll. Fontos, hogy a későbbiekben ha tovább fejlesztenénk alkalmazásunkat vagy karban kell tartani mindig elérhető legyen egy mobil fejlesztő csapat akire tudunk támaszkodni.