iOS-alkalmazás fejlesztése szolgáltatások katalógusával és megrendelési lehetőséggel

iOS fejlesztés magánügyfeleknek

Az iOS fejlesztés akkor jó választás, ha valaki iPhone-ra vagy iPadre szeretne működő, áttekinthető és később is bővíthető alkalmazást készíttetni. A legtöbb magánügyfél nem teljes fejlesztőcsapatot keres, hanem egy olyan magánszakembert, aki érti az ötletet, kérdez, lefordítja a kéréseket technikai feladatokra, majd kézzel fogható eredményt ad át. Én azt látom, hogy az első döntés nem az ár, hanem a feladat tisztasága. Ha a cél nincs jól megfogalmazva, a munka drágább lesz, a határidő csúszik, és a végén az ügyfél sem biztos abban, hogy azt kapta, amit szeretett volna.

Az iPhone alkalmazás fejlesztése lehet egyszerű ügyféloldali megoldás, belső használatra szánt kis eszköz, foglalási felület, adatbekérő rendszer, fizetési funkcióval kiegészített alkalmazás vagy egy meglévő szolgáltatás mobilos változata. A privát megrendelőnek általában nem az a legfontosabb, hogy milyen keretrendszer kerül a háttérbe. Sokkal fontosabb, hogy az alkalmazás gyorsan induljon, érthető legyen, ne omoljon össze, és a felhasználó ne akadjon el az első percben. Szerintem ez különösen igaz akkor, ha az alkalmazást nem szakmai közönség használja, hanem mindennapi ügyfelek.

A Qjob.hu oldalán a magánügyfél olyan fejlesztőt kereshet, aki nem ügynökségként dolgozik, hanem közvetlenül vállal online munkát. Ez egyszerűbb kommunikációt adhat. De csak akkor, ha a megbízó leírja, milyen képernyőkre, funkciókra és eredményre van szüksége. Az iOS fejlesztés nem egyetlen gombnyomás. Rövid egyeztetés, terv, fejlesztés, tesztelés, javítás és átadás követi egymást. Minél kevesebb a találgatás, annál jobb a végeredmény.

iOS alkalmazás készítés feladatleírás alapján

Az iOS alkalmazás készítés első lépése a jó feladatleírás. Nem kell szakmai nyelven megírni, de legyen benne a cél, a felhasználói folyamat, a kötelező funkciók és az, hogy mi számít kész állapotnak. Tapasztalatom szerint a legtöbb félreértés abból jön, hogy az ügyfél csak az ötletet mondja el, a működést nem. Például azt kéri, hogy legyen foglalási lehetőség. De nem derül ki, kell-e naptár, e-mail értesítés, fizetés, adminfelület, lemondás vagy automatikus visszaigazolás.

Egy magánfejlesztő akkor tud pontos árat és határidőt adni, ha látja a képernyők számát és az adatok útját. Ez nem bonyolult dokumentumot jelent. Elég lehet egy egyszerű lista is. Ki használja az alkalmazást. Mit lát először. Milyen adatot ad meg. Mi történik mentés után. Kell-e belépés. Kell-e kapcsolat külső rendszerrel. Ezek a kérdések unalmasnak tűnnek, de pénzt takarítanak meg. A túl rövid leírás sokszor drága lesz, mert a fejlesztő menet közben próbálja kitalálni a hiányzó részeket.

Volt olyan eset, amikor egy ügyfél egy egyszerű árkalkulátort szeretett volna iPhone-ra. A beszélgetés közben kiderült, hogy a kalkulátor mellett PDF mentés, ügyféladatok tárolása, e-mail küldés és későbbi árlista frissítés is kellett. A munka így már nem kis kiegészítő volt, hanem önálló mobilalkalmazás. Ez nem baj. Csak előre kell látni, mert ettől változik a költség és a határidő.

iOS fejlesztés árak és munkadíjak

Az iOS fejlesztés ára főként a funkciók számától, az adatkezeléstől, a külső kapcsolatoktól, a megjelenés kidolgozottságától és a tesztelés mélységétől függ. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem mindig azért, mert a szakember rossz. Inkább azért, mert kevés idő marad tervezésre, hibakeresésre és rendes átadásra. Egy működő alkalmazásnál a látható képernyők csak a munka egyik részét adják. A háttérben adatmentés, jogosultság, hibaüzenet, frissítés és eszközkompatibilitás is van.

Ezek az összegek nem minden helyzetre érvényesek, de segítenek reálisabban gondolkodni. Egy iPhone app fejlesztő óradíja és projektára nagyon eltérő lehet. A kezdő szakember olcsóbb, de több magyarázatot és ellenőrzést igényelhet. A tapasztaltabb fejlesztő drágább, viszont sok hibát már előre felismer. Szerintem magánügyfélként az a jó megoldás, ha nem a legalacsonyabb ár alapján döntünk, hanem megnézzük, mit tartalmaz az ár. Benne van-e a tesztelés. Van-e átadás. Jár-e rövid javítási időszak. Egy olcsón elkezdett, de félbehagyott munka többe kerülhet, mint egy elsőre pontosabb megállapodás.

Megfelelő iOS fejlesztő kiválasztása

A megfelelő iOS fejlesztő kiválasztásánál nem elég azt nézni, hogy valaki tud-e programozni. A magánügyfélnek olyan embert érdemes keresnie, aki érthetően kommunikál, kérdez a részletekről, és nem ígér mindent azonnal. A túl gyors igen néha figyelmeztető jel. Egy jó szakember előbb tisztázza a funkciókat, a meglévő anyagokat, a felhasználói folyamatot és a határidőt. Csak utána mond árat.

Fontos a portfólió, de nem kell, hogy minden korábbi munka pontosan ugyanolyan legyen. Hasznosabb azt látni, hogy a fejlesztő készített már adatbekérő felületet, foglalási rendszert, külső kapcsolattal működő alkalmazást vagy tiszta felhasználói útvonalat. A privát megbízónak érdemes rákérdeznie arra is, hogy a kód átadható-e, ki kezeli a fejlesztői fiókot, hogyan történik a tesztverzió megosztása, és mennyi javítás fér bele az árba.

Sokan ott hibáznak, hogy csak képernyőképet mutatnak, és azt várják, hogy ebből teljes alkalmazás készüljön. A képernyők fontosak, de a működés még fontosabb. Mi történik, ha a felhasználó rossz adatot ír be. Mi legyen, ha nincs internetkapcsolat. Kell-e értesítés. Ki módosíthatja az adatokat. Ezek nem apró részletek, hanem a használhatóság alapjai. Egy fejlesztő akkor tud jó munkát végezni, ha ezeket időben megkapja.

Online munka és fejlesztési folyamat

Az online iOS fejlesztés teljesen működőképes forma, ha a kommunikáció rendezett. A munka általában rövid egyeztetéssel kezdődik, majd jön a feladat pontosítása, a képernyők vagy vázlatok ellenőrzése, a fejlesztés, a tesztverzió, a javítás és a végső átadás. Nem szükséges személyes találkozó. A leírás, a képernyővázlat, a hozzáférések és a visszajelzések mind átadhatók online.

A határidőt nem csak a fejlesztő sebessége határozza meg. Az is számít, hogy az ügyfél mikor ad választ. Ha egy kérdésre napokig nincs válasz, a munka megállhat. És ha később új igény kerül be, az nem mindig fér bele az eredeti árba. Tapasztalatom szerint a legjobb folyamat az, amikor a megrendelő hetente legalább egyszer ránéz a készülő változatra, és rövid, konkrét visszajelzést ad. Nem hosszú magyarázat kell, hanem döntés. Maradjon így. Legyen más szöveg. A gomb menjen más helyre. Ez gyorsítja a munkát.

Az eredmény átadásánál legyen egyértelmű, mit kap a megrendelő. Forráskód, telepíthető tesztverzió, rövid használati leírás, hozzáférési adatok, képernyőképek vagy publikáláshoz szükséges anyagok. Az iOS fejlesztés akkor tekinthető lezártnak, ha nem csak a fejlesztő gépén működik, hanem a megbeszélt eszközökön is ellenőrizhető.

Minőség, tesztelés és gyakori hibák

A minőség nem csak szép felületet jelent. Egy iOS alkalmazás akkor jó, ha stabil, érthető és nem kér felesleges lépéseket a felhasználótól. A tesztelés ezért nem mellékes rész. Érdemes ellenőrizni több képernyőméreten, különböző adatbevitelekkel, lassabb kapcsolat mellett és hibás felhasználói lépésekkel is. A hibák egy része csak akkor derül ki, amikor valaki nem úgy használja az alkalmazást, ahogy a megrendelő elképzelte.

A leggyakoribb ügyfélhiba a túl sok funkció egyszerre. Egy első verzióba nem mindig kell minden. Jobb lehet egy kisebb, jól működő alkalmazással indulni, majd később bővíteni. De ez csak akkor működik, ha az alapok jól vannak felépítve. Ha az első verzió kapkodva készül, a későbbi bővítés nehéz lesz. Szerintem a jó iPhone alkalmazás fejlesztése nem attól lesz sikeres, hogy az első változat mindent tud. Attól lesz sikeres, hogy a fő feladatot megbízhatóan oldja meg.

Probléma lehet az is, ha a megrendelő nem ad valódi tartalmat. Helyettesítő szöveggel és hiányzó képekkel lehet fejleszteni, de a végső ellenőrzéshez igazi adatok kellenek. Egy foglalási felület, egy adatlap vagy egy árkalkulátor csak akkor mérhető jól, ha valós példákkal próbálják ki. Röviden mondva, a tesztelés nem csak a fejlesztő dolga. Az ügyfél ismeri a saját felhasználóit, ezért az ő visszajelzése is fontos.

Átadás, javítások és későbbi bővítés

Az átadás előtt érdemes rögzíteni, mi számít javításnak és mi számít új funkciónak. Ha egy gomb nem működik, az hiba. Ha a megrendelő új fizetési módot kér, az már bővítés. Ez egyszerű különbségnek tűnik, mégis sok vitát előz meg. A magánszakemberrel végzett online munka akkor nyugodt, ha ezek a keretek már az elején látszanak.

A későbbi bővítéshez fontos a rendezett kód és a tiszta átadás. Nem minden ügyfél akar másik fejlesztőhöz fordulni, de jó, ha van rá lehetőség. Ezért hasznos, ha a fejlesztő röviden leírja, milyen eszközökkel dolgozott, hol vannak a fő részek, milyen külső szolgáltatások kapcsolódnak az alkalmazáshoz, és milyen hozzáférések szükségesek a folytatáshoz. Ez nem nagy dokumentáció, de sokat ér.

Az iOS fejlesztés hosszabb távon frissítéseket is igényelhet. Változhat az operációs rendszer, módosulhat egy külső adatkapcsolat, új képernyőméret jelenhet meg, vagy az ügyfél új igényt kap a saját felhasználóitól. Ezért nem érdemes úgy gondolni az alkalmazásra, mint egyszer lezárt tárgyra. Inkább egy működő digitális eszköz, amelyet időnként ellenőrizni és javítani kell. Aki ezt előre elfogadja, reálisabb költséggel és kevesebb csalódással számol.