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

Szoftverfejlesztő mérnök Kecskeméten

A szoftverfejlesztő mérnök akkor jó választás, ha egyedi programra, javításra vagy régi rendszer rendbetételére van szükség Kecskeméten. Magánügyfélként sokan nem teljes terméket akarnak, hanem egy pontosan körülhatárolt megoldást. Ilyen lehet egy időpontfoglaló felület, egy családi vállalkozás belső nyilvántartása, egy egyszerű ügyfélkapcsolati rendszer vagy egy meglévő program hibáinak javítása. És néha csak annyi a cél, hogy valami végre működjön, ne kelljen táblázatok és üzenetek között keresgélni az adatokat.

Az ilyen munka nem ugyanaz, mint egy kész dobozos program megvétele. Itt a fejlesztő a megrendelő élethelyzetéhez igazodik. Először felméri, hogy mit használ most, hol akad el a folyamat, és melyik ponton csúszik szét a napi rutin. Szerintem ez többet számít, mint a hangzatos technikai lista. Egy jó szakember nem rögtön kódot ír, hanem megpróbálja megérteni, hogy a program kinek és mire kell. Sok félreértés abból indul, hogy az ügyfél eszközt kér, pedig valójában megoldást szeretne.

A Qjob.hu oldalon ezért érdemes olyan profilt keresni, ahol a leírásból látszik a gyakorlati szemlélet. Nekem az a benyomásom, hogy a túl általános bemutatkozás kevés. Jobb, ha a fejlesztő konkrét példákat ír arról, milyen rendszerekkel dolgozott, hogyan egyeztet, és mit vállal önállóan. A szoftverfejlesztő mérnök munkája akkor ad valódi értéket, ha a végeredmény egyszerűbbé teszi a használatot, nem pedig újabb terhet rak a megrendelőre.

Milyen feladatokra kérnek fejlesztőt

A magánügyfelek igénye sokkal változatosabb, mint elsőre látszik. Van, aki egy régi asztali program mellé kér webes felületet. Más egy kézi adminisztrációt szeretne kiváltani. Gyakori az is, hogy valaki már megvett egy rendszert, de az utolsó tíz százalék hiányzik belőle, és emiatt minden nap kerülőúton dolgozik. Ilyenkor egy programozó feladata nem feltétlenül egy teljes új rendszer elkészítése, hanem a szűk keresztmetszet megszüntetése.

Sok kérés érkezik kisebb automatizálásra. Például számlaadatok átvitele, űrlapok összekötése, rendelési adatok rendezése vagy ügyfélértesítések küldése. Ezek kívülről egyszerűnek tűnnek, de a háttérben sok apró részletet kell tisztázni. Hol vannak most az adatok. Ki kezeli őket. Milyen gyakran kell frissíteni. Mi történik hiba esetén. Én személy szerint jobban szeretem az olyan megoldásokat, ahol előbb egy kicsi, működő változat készül el. Ebből hamar kiderül, hogy jó irányba megy-e a munka.

Volt olyan eset, amikor egy ügyfél csak egy gyors javítást kért, mert egy régi nyilvántartás nem számolt helyesen. A beszélgetés közben derült ki, hogy nem a számítás volt a fő gond, hanem az, hogy ugyanazt az adatot három helyen írták át kézzel. A javítás végül nem a képletnél kezdődött, hanem az adatbevitel egyszerűsítésénél. Ez tipikus helyzet. Sok megrendelő a látható hibát akarja megszüntetni, miközben a valódi probléma mélyebben van.

Szakember választása

A szakember kiválasztásánál én nem a leghosszabb technológiai listát nézem. Inkább azt, hogyan kérdez, mennyire világosan fogalmaz, és tud-e egyszerűen beszélni a kockázatokról. Ha valaki már az első üzenetben mindent biztosra ígér, az nekem gyanús. A jó fejlesztő általában visszakérdez. Tisztázza a határidőt, a meglévő rendszert, a hozzáféréseket és azt is, hogy ki fogja használni a programot a mindennapokban.

Sokan ott hibáznak, hogy csak az óradíj alapján döntenek. Pedig egy olcsóbb ajánlat is lehet drága, ha közben nincs dokumentáció, nincs rendes átadás, és később senki nem nyúl hozzá. Szerintem jobb olyan informatikust választani, aki röviden leírja a munkamenetet. Legyen benne felmérés, egy kezdeti javaslat, részfeladatokra bontás, tesztelés és átadás. Nem kell ezeket túlbonyolítani, de a keret sok vitát megelőz.

Érdemes megnézni, hogy a kiválasztott szakember vállal-e utólagos hibajavítást, módosítást és rövid támogatást. A szoftverfejlesztő mérnök munkája ritkán zárul le abban a pillanatban, amikor átadja az első működő verziót. Használat közben derül ki, mi kényelmetlen, hol kell pontosítani a logikát, és milyen adat hiányzik. Aki erre előre felkészül, általában nyugodtabban fut végig a teljes folyamaton.

Közös munka menete

A megrendelés legtöbbször egy rövid egyeztetéssel indul. Ekkor nem kell kész műszaki leírás. De fontos, hogy az ügyfél tudjon példát mondani arra, mit szeretne gyorsabban vagy pontosabban csinálni. Jó, ha vannak képernyőképek, mintafájlok vagy rövid leírások a jelenlegi folyamatról. És jó, ha valaki megmutatja, hol fáj a rendszer használata. Nekem az a tapasztalatom, hogy öt konkrét példa többet ér, mint egy hosszú elméleti magyarázat.

Ezután jöhet egy egyszerű terv. Mi készül el először. Mi az, ami ráér később. Milyen adatokat kell átvenni. Kell-e jogosultságkezelés. Hol lesz a mentés. Sok megrendelő ezt unalmas résznek érzi, pedig itt dől el, mennyire lesz stabil az eredmény. Sok fejlesztés azért csúszik meg, mert a kezdeti határok nincsenek kimondva. A fejlesztő dolgozik, közben új ötletek kerülnek be, és egyszer csak már nem ugyanarról a feladatról beszél a két fél.

És van még egy kényes pont. Kié lesz a forráskód, a hozzáférés és a dokumentáció. Ezt szerintem már az elején tisztázni kell. Magánügyfélnél különösen fontos, mert gyakran egyetlen ember viszi az egész projektet. Ha minden jelszó és fájl egy helyen marad a kivitelezőnél, abból később kellemetlen helyzet lehet. Sokkal nyugodtabb a közös munka, ha az ügyfél is hozzáfér a saját rendszeréhez, és az átadás nem csak szóban történik.

Kecskemét környéki munkavégzés

Kecskemét esetében a helyi jelenlét néha előny, de nem mindig feltétel. Egy szoftveres feladat jelentős része távolról is megoldható. Mégis van, amikor jobb személyesen találkozni. Például ha a megrendelő több régi gépet használ, vegyes rendszerben dolgozik, vagy nehezen tudja összefoglalni a folyamatot. Ilyenkor egy helyszíni egyeztetés sok időt spórolhat. Kecskemét belső része mellett gyakran felmerülnek a külső városrészek és a közeli települések is.

Gyakori kérdés, hogy vállal-e valaki munkát Hetényegyháza, Kadafalva, Katonatelep, Méntelek vagy Ballószög felé. A válasz általában igen, de ezt érdemes előre tisztázni. Nem csak a kiszállás miatt, hanem azért is, mert egy helyi találkozó sokszor lerövidíti a felmérést. Ha a feladat inkább online végezhető, akkor elég lehet egy videós egyeztetés és néhány közösen átnézett fájl. De ha több eszköz, nyomtató, belső hálózat vagy régi adatbázis kapcsolódik a munkához, a személyes jelenlét hasznos lehet.

Kecskemét környékén a legtöbb ügyfélnek nem az a fontos, hogy a szakember pontosan melyik utcából indul, hanem hogy elérhető legyen, normálisan kommunikáljon, és vállalható időn belül reagáljon. Szerintem a földrajzi közelség önmagában kevés. De ha a feladat bonyolultabb, a közeli jelenlét mégis ad egyfajta biztonságot. Különösen akkor, ha később kisebb módosításokra is szükség lehet.

Szoftverfejlesztő mérnök árak

Az árakat nehéz egyetlen számmal leírni, mert nagyon más egy gyors javítás, egy új modul vagy egy teljesen egyedi rendszer. Mégis vannak kapaszkodók. A kisebb felmérés és konzultáció általában külön tétel. A rövid hibajavítás, az adatkapcsolatok rendbetétele vagy egy egyszerű automatizálás már külön munkadíjjal számolható. A komolyabb, több lépésből álló fejlesztésnél pedig szinte mindig jobb részfeladatokra bontani a költséget. Olcsóbban dolgozó embert persze lehet találni, de a túl alacsony ár nálam óvatosságot jelent. Őszintén szólva 12.000 alatt ritkán látok olyan munkát, amelynél az egyeztetés, a tesztelés és az átadás is rendben van.

Ezek az összegek tájékoztató jellegűek, de a nagyságrendet jól mutatják. Az árat főleg az befolyásolja, hogy mennyire tiszta a kiinduló helyzet. Van-e dokumentáció. Hozzáférhető-e a jelenlegi rendszer. Mennyi az ismeretlen tényező. Aki csak annyit ír, hogy kellene egy program, annál a bizonytalanság is nagyobb. Aki pontos példákat hoz, annál az ajánlat is használhatóbb lesz.

Szerintem nem a legolcsóbb ajánlat a legjobb kiindulás. A túl olcsó munka sokszor azért olcsó, mert hiányzik mögüle a tervezés vagy az utókövetés. És ezt a megrendelő fizeti meg később plusz körökkel. A szoftverfejlesztő mérnök árak akkor értelmezhetők jól, ha az ügyfél azt is látja, mit kap cserébe. Nem csak kódot, hanem érthető egyeztetést, próbát, javítást és átadható eredményt.

Mire figyeljen a megrendelő

Sok ügyfél túl későn szól arról, hogy a programot más is használni fogja. Ez nem apróság. Ha több felhasználó van, már más lehet a jogosultság, a belépés, a mentés és a hibakezelés. Másik gyakori hiba, hogy a megrendelő fejben késznek érzi a feladatot, de papíron nem tudja megmutatni a folyamatot. Ilyenkor a szakember kénytelen találgatni. És a találgatás általában időbe és pénzbe kerül.

Én azt javaslom, hogy a munka elején legyen egy rövid lista a kötelező és a ráérő elemekről. Mi az, aminek mindenképp működnie kell. Mi az, ami csak kényelmi funkció. És mi az, ami jó lenne, de nem sürgős. Ez leveszi a nyomást a projektről. A fejlesztő is tisztábban tud haladni, az ügyfél pedig nem érzi azt, hogy a munka szétesik. A programozó és a megrendelő közti legnagyobb vita ritkán technikai kérdés. Inkább abból születik, hogy ki mit gondolt magától értetődőnek.

Végül azt látom, hogy a jó együttműködés alapja az őszinte állapotfelmérés. Nem baj, ha a jelenlegi rendszer kusza. Nem baj, ha egy részét már többen próbálták javítani. De ezt jobb kimondani. Volt olyan ügyfél, aki az első körben csak egy kis módosításról beszélt, majd később derült ki, hogy három külön adatforrás között kellene egyezést teremteni. A munka végül elkészült, de sokkal simábban ment volna, ha a teljes helyzet már az elején látszik. Itt ezen az oldalon akkor érdemes választani, ha a profil és a kommunikáció alapján úgy tűnik, hogy a kiválasztott ember nem csak fejleszt, hanem gondolkodik is a feladatról.