Mobilalkalmazások fejlesztése, amelyeket imádni fogsz!

Mobilalkalmazás fejlesztés magánügyfeleknek

A Mobilalkalmazás fejlesztés akkor jó választás, ha egy ötletből használható, kipróbálható és később bővíthető alkalmazást szeretne. Nem elég annyi, hogy legyen egy app. A feladatot pontosítani kell, mert a fejlesztő csak így tud reális árat, határidőt és munkamenetet adni. Én azt látom, hogy a legtöbb magánügyfél nem a programozás részén akad el, hanem az elején. Nem világos, kinek készül az alkalmazás, milyen képernyők kellenek, milyen adatokat kell kezelni, és mi számít kész eredménynek.

Online megbízásnál ez különösen fontos. A magánfejlesztő nem ül ott az ügyfél mellett, ezért minden döntést írásban, képernyőképekkel, mintákkal vagy rövid leírással érdemes rögzíteni. A Qjob.hu felületén olyan szakember kereshető, aki vállalhat kisebb alkalmazásjavítást, prototípus készítést, egyszerű ügyfélalkalmazást vagy meglévő rendszerhez kapcsolódó mobilos megoldást. Itt a lényeg nem a nagy cég, hanem az, hogy a kiválasztott szakember értse a feladatot, tudjon kérdezni, és ne ígérjen olyat, amit nem lehet tartani.

Mobilalkalmazás készítés előkészítése

A mobilalkalmazás készítés nem a kóddal kezdődik. Először azt kell leírni, mire való az alkalmazás. Egy rövid vázlat sok vitát megelőz. Legyen benne a cél, a fő felhasználó, a szükséges képernyők, a belépés módja, az adatok kezelése, és az is, hogy kell-e kapcsolat más rendszerrel. Ha ez nincs meg, a fejlesztő találgatni fog. És a találgatás később drága lesz.

Szerintem egy magánügyfélnek nem kell hosszú műszaki dokumentációval indulnia. Elég lehet egy átgondolt leírás, néhány rajzolt képernyő és egy lista a kötelező funkciókról. De a kötelező és a jó lenne funkciókat külön kell választani. Sokan ott hibáznak, hogy az első változatba mindent bele akarnak tenni. Időpontfoglalás, fizetés, üzenetküldés, értesítés, admin felület, statisztika, több nyelv, minden egyszerre. Ettől a munka nehezebb lesz, az ár nő, és a határidő is bizonytalanabbá válik.

Volt olyan eset, amikor egy ügyfél egyszerű bemutatkozó alkalmazást szeretett volna, majd a beszélgetés közben kiderült, hogy valójában rendeléskezelő, ügyféladatbázis és értesítési rendszer is kell neki. A fejlesztő először alacsony árat mondott, mert nem látta a teljes képet. Később mindkét fél elégedetlen lett volna, ha nincs újratervezés. Ezért jobb már az elején őszintén beszélni a valódi célról.

Applikáció fejlesztés ára

Az applikáció fejlesztés ára erősen függ attól, hogy csak terv, működő próba, teljes alkalmazás vagy meglévő app javítása a feladat. 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 tesztelésre, hibajavításra és tiszta átadásra. Tapasztalatom szerint az ügyfélnek nem csak a végösszeget kell néznie, hanem azt is, mit tartalmaz az ár.

Ezek az összegek tájékoztató jellegűek, de a nagyságrendet jól mutatják. Egy fejlesztő más árat adhat, ha sürgős a munka, ha több platformra kell elkészíteni az alkalmazást, vagy ha a megbízó sok módosítást kér menet közben. A korrekt ajánlatban szerepel a munka tartalma, a javítási körök száma, az átadás módja és a fizetési ütemezés. Ha csak egy rövid összeg szerepel benne minden részlet nélkül, az később félreértést okozhat.

Mobilalkalmazás fejlesztő választása

A mobilalkalmazás fejlesztő kiválasztásánál nem csak a portfólió számít. Fontos, hogy a szakember hogyan kérdez. Egy jó fejlesztő nem azonnal árat mond, hanem először tisztázza a célokat, a funkciókat és a korlátokat. Megkérdezi, milyen készülékeken kell működnie az appnak, van-e meglévő weboldal vagy adatbázis, kell-e belépés, fizetés, értesítés vagy admin felület. Ez nem akadékoskodás. Ez a pontos munka része.

Én azt tartom jó jelnek, ha a szakember érthetően beszél. Nem kell minden technikai részletet az ügyfélre zúdítani. De az fontos, hogy el tudja mondani, miért tart egy feladat két napig vagy két hétig. A magánügyfélnek érdemes korábbi munkát kérni, akár egyszerű képernyőképeket is. Nem mindig az a legjobb jel, ha valakinek nagyon sok referenciája van. Inkább az számít, hogy a hasonló méretű feladatokban van-e tapasztalata.

Az is lényeges, hogy a fejlesztő vállal-e utólagos javítást. Egy alkalmazásnál ritka, hogy minden elsőre tökéletes. Lesznek apró hibák, szövegjavítások, képernyőméretből adódó gondok, használati észrevételek. Ha ez nincs megbeszélve, a végén vita lesz arról, mi számít hibának és mi számít új kérésnek.

Online munka és átadás

Az online munka akkor működik jól, ha minden fontos anyag egy helyen van. A megbízó adja át a szövegeket, képeket, belépési adatokat, mintákat és minden külső rendszer elérését, amelyre a munkához szükség van. De ezeket nem érdemes rendezetlen üzenetekben küldözgetni. Jobb egy rövid lista, amelyben látható, mi érkezett meg és mi hiányzik még.

A fejlesztés általában több szakaszban halad. Először készül a feladatleírás vagy képernyőterv. Utána jön az alap működés. Ezt követi a tesztelés, a javítás, majd az átadás. Kisebb feladatnál ez néhány nap vagy egy-két hét lehet. Összetettebb alkalmazásnál több hét vagy hónap is reális. Sokan ott hibáznak, hogy csak a végső határidőt beszélik meg. Pedig köztes ellenőrzési pontok nélkül könnyen rossz irányba megy a munka.

A kommunikáció legyen rövid és pontos. Nem kell minden nap hosszú beszámoló. De kell rendszeres visszajelzés. Például hetente egyszer egy állapotjelzés, vagy minden fontosabb rész elkészülte után egy próbalink, képernyőkép vagy rövid videó. Ez segít az ügyfélnek megérteni, hol tart a munka, és segít a fejlesztőnek is, mert nem a végén derülnek ki az eltérések.

Alkalmazásfejlesztés javításokkal

Az alkalmazásfejlesztés természetes része a javítás. Az ügyfél sokszor csak akkor látja pontosan, mit szeretne, amikor már van mit kipróbálni. Ez nem baj. De a javításokat kezelni kell. Érdemes külön listát vezetni a hibákról, a módosításokról és az új ötletekről. A hiba az, amikor a megbeszélt funkció nem működik. A módosítás az, amikor működik, de máshogy lenne jobb. Az új ötlet pedig már új munka lehet.

Tapasztalatom szerint a legtöbb konfliktus ebből a különbségből jön. Az ügyfél azt gondolja, hogy minden javítás benne van az árban. A szakember pedig azt látja, hogy a megbeszélt feladat közben bővül. Ezért kell előre rögzíteni, hány javítási kör tartozik az árba, meddig lehet változtatni a képernyőkön, és mi történik, ha új funkció kerül a listába.

Szerintem egy kisebb mobilos projektben két javítási kör elég lehet, ha a leírás pontos. Az első körben a nagyobb észrevételek kerülnek elő. A másodikban a finomítások. Ha ennél több kör kell, akkor vagy nem volt elég pontos a brief, vagy az ügyfél menet közben új irányt választott. Mindkettő előfordul, csak az árat és a határidőt is hozzá kell igazítani.

Gyakori hibák mobilos projektnél

A leggyakoribb hiba az, hogy az ügyfél csak az ötletet írja le, de a használati helyzetet nem. Például azt mondja, hogy kell egy rendelős app. De nem derül ki, ki rendel, ki hagyja jóvá, hol jelenik meg a rendelés, kell-e értesítés, hogyan történik a fizetés, és mi legyen a hibás adatokkal. A fejlesztő ilyenkor nem tud pontos munkát végezni.

Másik gyakori hiba a túl korai spórolás. A túl olcsó ajánlat elsőre vonzó lehet, de ha nincs benne tesztelés, dokumentálás és átadás, akkor a későbbi javítás többe kerülhet. Egy félkész appot más szakembernek átvenni nehéz. Főleg akkor, ha nincs tiszta forrásanyag, nincs leírás, és a hozzáférések sincsenek rendben.

Az is gond, ha az ügyfél nem válaszol időben. Online fejlesztésnél a szakember sokszor egyetlen döntésre vár. Milyen szöveg legyen a gombon. Milyen adatmező kell. Melyik képernyő legyen előbb. Ha ezekre napokig nincs válasz, a határidő csúszik. Nem azért, mert a fejlesztő lassú, hanem mert nincs döntés.

Mobilos fejlesztés kész eredménye

A kész eredmény nem csak az, hogy az alkalmazás elindul. A magánügyfélnek át kell kapnia mindent, ami a későbbi használathoz vagy további munkához szükséges. Ide tartozhat a forráskód, a tervfájl, a belépési adatok, a rövid használati leírás, a telepítési információ és a hibajavítási lista. Nem minden projektben ugyanaz kell, de az átadás tartalmát előre meg kell beszélni.

Egy jó mobilos fejlesztés után az ügyfél tudja, mit kapott, hogyan használhatja, és milyen korlátai vannak az elkészült változatnak. Ez különösen fontos, ha az első verzió csak próba vagy alapváltozat. Ilyenkor nem baj, ha még nincs benne minden funkció. A baj az, ha az ügyfél azt hiszi, teljes rendszert kapott, miközben valójában csak egy induló változat készült.

Én azt látom, hogy a nyugodt projekt kulcsa a pontos feladat, az érthető ajánlat és a rendszeres online egyeztetés. A Mobilalkalmazás fejlesztés így nem vak bizalomra épül, hanem ellenőrizhető lépésekre. Ez magánügyfélként is biztonságosabb. A szakembernek is jobb, mert nem kell kitalálnia a kimondatlan elvárásokat. A végeredmény pedig használhatóbb lesz, és kevesebb lesz a felesleges javítás.