Szoftverfejlesztők Kecskeméten: Vélemények és kedvező árak

Szoftverfejlesztő Kecskemét

A szoftverfejlesztő akkor kell, amikor egy kész program már nem elég, és a feladatot saját működésre kell szabni. Kecskemét környékén ez magánügyfeleknél is gyakori. Van, aki időpontfoglalót akar, más egy egyszerű ügyfélkezelőt, megint más egy régi táblázat helyett használható rendszert. A jó fejlesztés nem attól jó, hogy bonyolult, hanem attól, hogy a végén tényleg könnyebb vele dolgozni. Személy szerint én azt tartom jó indulásnak, ha az első beszélgetésben már világos, mi az a feladat, amit most kézzel oldanak meg, és miért lett belőle teher.

Sokan túl későn keresnek szoftverfejlesztőt. Addig halogatják a döntést, amíg a hibák, a duplázott adatok és a felesleges kézi munka már mindennap pénzt vagy időt visz el. Mások meg túl korán kérnek nagy rendszert, pedig előbb egy kisebb megoldás is elég lenne. A Qjob.hu felületén ezért sokan nem céget, hanem önálló szakembert keresnek. Olyat, aki felméri a helyzetet, visszakérdez, és nem akar rögtön mindent újraépíteni.

Milyen feladatokra jó a fejlesztő

Egy fejlesztő magánügyfélnek is sokféle munkát vállalhat. Gyakori kérés az egyedi űrlap, a foglalási felület, a számlázáshoz vagy készlethez kapcsolódó kis rendszer, a meglévő weboldal mögötti admin felület, vagy két külön program összekötése. De idetartozik egy hibásan működő belső folyamat javítása is. A legtöbb ügyfél nem technológiát keres. Hanem azt akarja, hogy valami végre rendesen működjön.

És itt szokott félremenni a gondolkodás. Sok megrendelő úgy indul neki, hogy felsorolja, milyen gombot hová képzel. Közben nem mondja el, mi a valódi cél. Pedig a programozó akkor tud jól dolgozni, ha látja az okot. Volt olyan eset, amikor egy ügyfél új rendszert akart rendeléskezelésre. Pár kérdés után kiderült, hogy nem új rendszer hiányzott, csak a meglévő folyamatból három felesleges lépést kellett kivenni. Olcsóbb lett, gyorsabb lett, és nem kellett hónapokig várni az indulásra.

Tapasztalatom szerint a rövid, tiszta projekt gyakran jobb, mint a túl nagyra tervezett indulás. Előbb legyen egy működő alap. Utána lehet bővíteni. Ez különösen igaz akkor, ha az ügyfél még nem látja pontosan, mekkora forgalmat vagy terhelést kell majd kezelni.

Projektindítás és pontos igény

A jó közös munka nem a kóddal kezdődik. Hanem azzal, hogy a szakember végigveszi a célt, a jelenlegi helyzetet és a korlátokat. Milyen adat van most. Ki fogja használni a rendszert. Telefonon vagy gépen kell inkább működnie. Kell-e belépés, értesítés, export, jogosultság, vagy csak egy egyszerű felület. Ezek alap kérdések, de sok pénzt spórolnak.

Sokan hibáznak, amikor túl általános leírással kérnek ajánlatot. Azt írják, kell egy egyedi program vagy egy saját rendszer. Ez kevés. A szoftverfejlesztő ebből még nem látja a terhelést, a funkciók számát, a várható módosításokat és azt sem, hogy mi az, ami valóban kötelező az első verzióban. Ilyenkor az olcsó ajánlat sokszor csak azért olcsó, mert nincs benne minden.

Én jobban bízom abban a szakemberben, aki már az elején kényelmetlen kérdéseket tesz fel. Például mi történik, ha egyszerre többen használják a rendszert. Ki javítja az adatot, ha hibásan kerül be. Mi van akkor, ha fél év múlva új funkció kell. Ezek nem akadékoskodó kérdések. Ezek védik a megrendelőt attól, hogy kétszer fizessen ugyanazért.

Szoftverfejlesztő árak

A szoftverfejlesztő árak azért szórnak erősen, mert nem ugyanaz egy kisebb javítás, egy új modul, vagy egy teljes egyedi rendszer. Magyar piaci példák szerint a fejlesztési óradíjak gyakran 16.000 és 24.000 forint között mozognak, de egyes szolgáltatóknál ettől lejjebb és jóval feljebb is lehet menni. Külföldi összehasonlításban a szabadúszó fejlesztők díja széles sávban mozog, és a bonyolultabb munkáknál az óradíj gyorsan emelkedik. Ez nekem azt erősíti meg, hogy az ár önmagában nem mond sokat a végeredményről.

Szerintem 12.000 alatt ritkán lesz igazán jó a munka, ha a feladat már tervezést, tesztelést és utólagos javítást is igényel. A nagyon alacsony díj mögött gyakran az áll, hogy nincs dokumentálás, nincs normális átadás, vagy a fejlesztő csak a legszűkebb részt vállalja el. Kecskemét térségében is jobb úgy nézni az árat, hogy mit fed le. Benne van-e az egyeztetés. Benne van-e a hibajavítás. Kap-e az ügyfél használható átadási anyagot.

Az is fontos, hogy fix összeg vagy óradíj alapján dolgozik-e a programozó. A fix díj kényelmesebb lehet, ha a feladat pontos. Az óradíj tisztább, ha még sok a nyitott kérdés. Sok vita abból jön, hogy a két fél nem ugyanazt érti a kész állapoton. Ezért az árnál fontosabb a leírt tartalom.

Hogyan válassz szoftverfejlesztőt

A választásnál nem a leghangosabb ajánlat számít. Inkább az, hogy a jelentkező mennyire érti meg a problémát, és mennyire tud egyszerűen fogalmazni. Egy jó szoftverfejlesztő nem beszél végig csak eszközökről. Elmondja, hogyan bontaná részekre a munkát, mi a kockázat, és milyen sorrendben haladna. Már ebből sok minden látszik.

Szerintem érdemes elkérni rövid példát hasonló feladatról, megkérdezni, hogyan kezeli a módosításokat, és ki fogja később javítani a hibát, ha valami előjön. Az is árulkodó, hogy a szakember le meri-e írni, mi nincs benne az ajánlatban. Sokan ott követik el a hibát, hogy csak a végösszeget nézik. Pedig a rosszul tisztázott munka a végén szinte mindig drágább.

Volt már olyan ügyfél, aki azért cserélt fejlesztőt, mert az első ember gyorsan dolgozott, de semmit nem magyarázott el. Amikor később bővíteni kellett volna a rendszert, senki nem értette, hogyan épül fel. Ez tipikus gond. A kód önmagában nem elég. Kell hozzá olyan átadás is, amit a megrendelő később elő tud venni.

Régi rendszerek és bővítések

Sok munka nem nulláról indul. Hanem egy félig működő oldalból, egy elavult adatbázisból vagy egy olyan megoldásból, amit évekkel ezelőtt valaki gyorsan összerakott. Ilyenkor a fejlesztő első feladata nem az új funkció, hanem az állapot felmérése. Mi menthető. Mi veszélyes. Mi az, amit jobb nem toldozni tovább.

És itt sok megrendelő csalódik. Azt várja, hogy egy kis bővítés majd gyors lesz. Közben kiderül, hogy a régi alap miatt minden módosítás kockázatos. Ezt nem jó hallani, de jobb előre tudni. Saját tapasztalatom szerint néha olcsóbb újraépíteni a kritikus részt, mint hónapokig javítgatni egy rossz alapot. Nem mindig. De gyakrabban, mint sokan gondolják.

Az is fontos kérdés, hogy kell-e hosszabb távú karbantartás. Egy egyszerű belső rendszer lehet, hogy fél évig gond nélkül megy. De ha sokan használják, vagy külső szolgáltatásokhoz kapcsolódik, előbb utóbb kell frissítés, ellenőrzés, javítás. Ezt már az indulásnál érdemes tisztázni.

Kecskemét és a környező városrészek

Kecskemét esetén a helyi jelenlét még mindig sokat számít, főleg az első egyeztetésnél. Nem minden ügyfél szeretne csak üzenetben vagy hívásban dönteni. A személyes találkozó hasznos lehet a belvárosban, de gyakran ugyanúgy megoldható Kadafalva, Katonatelep, Hetényegyháza, Méntelek vagy a közeli kisebb települések felől érkező megrendelőknek is. A helyszín inkább kényelmi kérdés. A pontos kommunikáció fontosabb.

Kecskeméten és környékén sokan vegyesen működnek. Van egy meglévő weboldal, mellette táblázat, külön levelezés, külön nyilvántartás. Ebből lesz a legtöbb kézi hiba. Ilyen helyzetben nem látványos fejlesztés kell elsőre, hanem rend. Egy tapasztalt informatikus vagy programozó ezt hamar felismeri, és nem ígér olyat, amit később nem lehet tartani.

A helyi keresésnél érdemes rákérdezni a kiszállásra, az elérhetőségre és arra is, hogy mennyi egyeztetéssel dolgozik a szakember. Van, akinek ez nem lényeg. Másnak igen. Én személy szerint szeretem, ha legalább a kezdeti felmérés egyértelmű és gyors. Már ebből látszik, mennyire lesz kiszámítható a közös munka.

Gyakori hibák megrendelés előtt

Az egyik leggyakoribb hiba, hogy valaki túl sok mindent akar az első verzióba belerakni. A másik, hogy nincs felelős a tartalomra, az adatra vagy a tesztelésre. Pedig a fejlesztő nem tudja egyedül kitalálni, melyik mező kötelező, melyik folyamat kivételes, és mi számít valós használatnak. Ezeket az ügyfélnek is végig kell gondolnia.

Sokan azt is elrontják, hogy csak szóban egyeztetnek. Aztán amikor elkészül a rendszer, kiderül, hogy mindenki másra emlékezett. Ezért kell rövid, de tiszta leírás. Nem regény. Csak annyi, hogy mi a cél, mi a kötelező funkció, mi számít késznek, és mi történik utána. Ettől lesz kezelhető a projekt.

És van még egy visszatérő probléma. Az ügyfél azt hiszi, hogy a fejlesztés befejezése egyben az egész történet vége. Pedig a valóságban ez inkább egy új szakasz eleje. Használat közben derülnek ki az apró kényelmi igények, a furcsa esetek, a lassú részek. Ez nem feltétlen hiba. Ez a normális működés része. A jó szakember erre előre felkészíti a megrendelőt, és nem csinál úgy, mintha minden elsőre végleges lenne.