Applikáció készítéshez szükséged van egy szabadúszóra?

Applikáció készítés

Az applikáció készítés akkor működik jól, ha a feladat elején világos, mire lesz jó a mobilalkalmazás, kik használják majd, és milyen gondot kell ténylegesen megoldania. Sokan ott hibáznak, hogy rögtön a látványról beszélnek, miközben a folyamat, a belépés, az adatkezelés és a későbbi javítás nincs végiggondolva. A Qjob.hu oldalon magán megbízók is találhatnak olyan fejlesztőt, aki kisebb vagy közepes munkát is elvállal. Ez sokszor jobb út, mint rögtön egy nagy csapatot keresni, főleg akkor, ha még csak az első változat készül.

A mobilalkalmazás készítés nem egyetlen nagy lépés. Először ki kell derülni, hogy elég-e egy egyszerű felhasználói felület kevés funkcióval, vagy rögtön szükség van belépésre, értesítésekre, fizetésre, térképre vagy külső rendszer kapcsolatra. Személy szerint én azt látom, hogy a legtöbb magán ügyfél túl sok ötlettel indul, és túl kevés valódi prioritással. Ilyenkor a jó szakember nem bólogat mindenre, hanem visszakérdez, szűkít, és megmondja, mi maradjon az első körben.

Mobilalkalmazás tervezés

Jó mobilalkalmazás fejlesztés nincs használható terv nélkül. Nem hosszú dokumentum kell, hanem tiszta szerkezet. Mi történik az első megnyitáskor. Hogyan regisztrál a felhasználó. Mit lát akkor, ha hibás az adat. Hogyan ment a rendszer. Ezek száraz kérdéseknek tűnnek, mégis itt dől el, hogy a végeredmény kényelmes lesz-e vagy állandó bosszúságforrás. Sok megbízó csak annyit mond, hogy legyen gyors és egyszerű. De ez nem brief, csak kívánság.

Volt olyan eset, amikor egy ügyfél eredetileg egy összetett közösségi megoldást akart, üzenetküldéssel, naptárral, értékeléssel és kuponnal. A fejlesztő leült vele, és két beszélgetés után kiderült, hogy a valódi gond valójában csak az időpontfoglalás és az emlékeztető. A munka így rövidebb lett, az ár kisebb lett, és a kész alkalmazást tényleg használni kezdték. Ezért fontos, hogy az applikáció készítés elején a funkciólista ne dísz legyen, hanem döntési eszköz.

Applikáció készítés árak

Az ár mindig a funkciókból, az összetettségből és a javítási igényből áll össze. Olcsóbb megoldás lehet egy egyszerűbb mobilalkalmazás, amely kevés képernyőből áll és nem kapcsolódik külső rendszerhez. Drágább lesz a feladat, ha több felhasználói szerep, admin felület, fizetés, helymeghatározás vagy folyamatos karbantartás is kell. Az is számít, hogy a szoftverfejlesztő egyedül dolgozik-e, vagy bevon tervezőt és tesztelőt is.

Saját tapasztalatom szerint a túl alacsony ár gyanús. Olcsóbban 120.000 alatt ritkán lesz olyan munka, amelyet később nyugodtan lehet bővíteni. A másik véglet sem jobb. Sokszor a megbízó túl sokat fizet azért, amit egy tapasztalt fejlesztő kisebb csomagban is jól megoldana. Érdemes tételes becslést kérni, és nem csak egy végösszeget elfogadni.

A táblázat csak irányt mutat. Egy megbízás végösszegét gyakran az viszi fel, hogy menet közben új ötletek kerülnek elő. Sok ügyfél azt hiszi, hogy egy apró módosítás pár kattintás. Néha tényleg az. Máskor viszont újra kell írni egy egész részt miatta.

Fejlesztő választása

Jó fejlesztőt nem a legszebb bemutatkozás alapján érdemes választani. Inkább azt nézd, hogyan kérdez vissza. Egy tapasztalt szakember rákérdez a célra, a határidőre, a várható felhasználói számra, a későbbi bővítésre és arra is, hogy van-e már kész vázlat. Ha valaki az első üzenet után pontos végárat ígér, az nálam intő jel. A szoftverfejlesztő munkája nem csak kódírásból áll. Meg kell értenie a használati helyzetet is.

Sokan azt a hibát követik el, hogy kizárólag referenciát néznek. A referencia fontos, de önmagában kevés. Egy kisebb magán megbízásnál sokszor többet ér a rendezett kommunikáció, a vállalható határidő és a tiszta átadás. Én jobban bízom abban a fejlesztőben, aki leírja, mi nincs benne az árban, mint abban, aki mindent megígér. Kérj rövid ütemtervet, kérj mérföldköveket, és kérdezz rá arra is, ki javítja majd a hibákat az átadás után.

Funkciók és gyakori hibák

Az applikáció készítés során a legtöbb csúszás nem a bonyolult technikai rész miatt jön, hanem a pontatlan elvárások miatt. A megbízó mást ért egyszerű keresés alatt, a fejlesztő pedig mást ért értesítés alatt. Ezért a funkciókat érdemes rövid példákkal leírni. Ki mit lát. Honnan hová jut. Mi történik hiba esetén. Ha ez kimarad, akkor a vita később jön elő, amikor már drága a javítás.

És van egy másik gond is. Sokan túl korán kérnek túl sokat. Chat, értékelés, kupon, hűségpont, többnyelvűség, statisztika. Ezek jól hangzanak, de nem mindig kellenek az induláshoz. A mobilalkalmazás fejlesztés első változata legyen használható. Nem kell, hogy mindent tudjon. Volt olyan ügyfél, aki hónapokig halogatta a rajtot egy plusz funkció miatt, amelyet végül senki nem használt. Ez tipikus veszteség. Pénzben is, időben is.

Átadás és karbantartás

Az átadás nem az a pillanat, amikor a munka véget ér. Inkább akkor kezd látszani, mennyire volt stabil a kivitelezés. Jó esetben a megbízó megkapja a forrásanyagot, a hozzáféréseket, a rövid kezelési leírást és azt is, hogyan lehet hibát jelezni. A mobilalkalmazás készítés után rendszerint jönnek kisebb finomítások. Gomb helye, szöveg hossza, adatellenőrzés, értesítés ideje. Ezek normális kérések.

De sok vita abból lesz, hogy ezt előre senki nem tisztázta. Benne van-e az árban egy hónap javítás. Mi számít hibának és mi új kérésnek. Ki tölti fel a frissítést. Aki ezt előre rendbe teszi, az sok kellemetlenséget spórol. Én azt tartom reálisnak, ha a megbízó legalább rövid utógondozással számol. A nagyon olcsó induló díj gyakran ott fordul drágába, hogy utána minden apróság külön tétel lesz.

Összességében az applikáció készítés akkor lesz nyugodtabb folyamat, ha a cél egyszerű, a funkciók sorrendbe vannak rakva, és a kiválasztott szakember nem csak vállal, hanem érvel is. Ez a munka nem attól lesz jó, hogy nagy szavak szerepelnek a leírásban. Hanem attól, hogy a kész alkalmazás valódi helyzetben is használható marad.