IT outsourcing, szoftverfejlesztés kiszervezése

IT Outsourcing illusztráció: futurisztikus fejlesztő csapat

Ismerős a helyzet? A felvétel lassú, a munka viszont nem áll meg

Van egy projekted, aminek van határideje, és van egy csapatod, aminek nincs elég szabad kapacitása rá. Vagy megvan a kapacitás, de hiányzik egy konkrét kompetencia: egy senior mobilos, aki érti az iOS release-folyamatot, egy Java-fejlesztő a meglévő backendhez, egy tesztelő a kiadás előtti hetekre.

A kézenfekvő válasz a felvétel, csakhogy a felvétel lassú. Egy senior fejlesztő megtalálása a kiírástól az önálló szállításig könnyen négy-hat hónap: kiválasztás, felmondási idő, onboarding. A most futó projektedre ez nem megoldás.

És ott vannak a láthatatlan költségek: a toborzás elviszi a saját csapatvezetőd idejét, egy elhibázott felvétel ára a szakma szerint az éves fizetés egynegyede vagy egyharmada, egy állandó fejlesztőre pedig egész évben tervezned kell a bérrel, akkor is, ha a rá tartozó munka szezonális. A szoftverfejlesztés kiszervezése (IT outsourcing) éppen erre ad választ: gyors hozzáférést biztosít az elérhető szaktudáshoz.

Mikor jobb a szoftverfejlesztés kiszervezése, és mikor érdemes a belső csapatot építeni?

Mielőtt döntenél, érdemes feltenni három kérdést: mennyire kötődik a feladat a céged fő tevékenységéhez, mekkora az időkeret, és mekkora a költségkeret? A válaszokból általában kirajzolódik, melyik irány való neked.

Ha a fejlesztés maga a terméked, a versenyelőnyöd, amit napi szinten csiszolsz, akkor a jó válasz gyakran a saját csapat. Egy SaaS-cég motorja vagy egy fintech tranzakciós rendszere olyan tudás, amit érdemes házon belül tartani. Ez őszinte tanács egy olyan cégtől, amelyik többek között a kiszervezésből él: ha a rendszer a te műved, építsd magadnak.

A legtöbb fejlesztési igény azonban nem ilyen. Egy jól körülírható, időre leszállítandó projektnél, egy speciális terület lefedésénél vagy egy csúcsidőszaki felskálázásnál a felvétel lassú és drága válasz egy gyors kérdésre. A kiszervezés a teljes gépezetet adja készen, adott esetben akár kész csapatként is: fejlesztőket, üzleti elemzőt, projektmenedzsert és tesztelőt.

A freelancer egy szűk, jól definiált feladatra gyors és költséghatékony lehet. A buktató, hogy a freelancer maga írja, maga ellenőrzi és maga is adja ki a kódját, code review és külön tesztelés nélkül, és ha eltűnik, a tudás vele megy. Egy fejlesztőcég egy embernél többet ad: folyamatot, több szemet a kódon, helyettesíthetőséget, dokumentált átadást.

Három kiszervezési modell (ábra): egy-egy fejlesztő, dedikált fejlesztői csapat, end-to-end projekt

A három IT outsourcing modell

A kiszervezésnek nincs egyetlen helyes formája: azon múlik, mennyi kontrollt akarsz megtartani, és mennyi felelősséget adnál át. Három tiszta modell van, és a gyakorlatban ezek keverednek is.

1. Egy-egy fejlesztő a hiányzó kompetenciára
Beemelsz egy vagy néhány mérnököt a saját csapatodba, és te irányítod őket, ahogy a többi kollégádat: egy Java-fejlesztőt a meglévő backendhez, egy UX-tervezőt egy szakaszra, egy iOS-fejlesztőt a mobilappod kiadásához. Akkor jó, ha megvan a saját projektmenedzsmented, és csak a kapacitás vagy egy pontszerű szaktudás hiányzik. A kontroll végig a te kezedben marad, és a napi menedzsment is a te dolgod.

2. Dedikált fejlesztői csapat a te iránymutatásod mellett
Egy komplett, összeszokott csapatot állítunk össze (backend- és frontend-fejlesztők, UX/UI-tervező, tesztelő, üzleti elemző, projektmenedzser), amely a te iránymutatásod mellett, de saját belső koordinációval dolgozik, gyakorlatilag mintha a saját fejlesztőrészleged lenne. A hosszabb, komplexebb munkákra való, ahol a folytonosság számít. A stratégiai irány nálad marad, és az a te döntésed, hogy a napi koordinációt magad vállalod (a gyakorlatban ez sokszor hatékonyabb), vagy ezt a terhet is levesszük a válladról.

3. End-to-end: a teljes projekt, ötlettől a karbantartásig
Egy jól körülírt projektet a maga egészében átveszünk: az ötleteléstől és a specifikációtól a fejlesztésen át a bevezetésig és a karbantartásig. Fix scope, fix költségvetés, tervezett ütemterv. Akkor a legerősebb, ha a feladat világos és stabil, és csak egy leszállított, működő eredményt szeretnél. Az ára a merevség: ha menet közben jelentősen változik, hogy mit kell építeni az a scope pontosítását igényli. Ezért kezdünk minden ilyen projektet feltárással és specifikációval.

Dedikált team: illusztráció futurisztikus fejlesztőkkel

Hogyan válassz a három között?

A választás három tényezőn múlik: a projekt méretén és időtávján, azon, hogy mennyi napi kontrollt akarsz megtartani, és a scope stabilitásán.

Rövid, jól körülhatárolt kapacitáshiányra az egy-egy fejlesztő a leggyorsabb az egy-egy fejlesztő a leggyorsabb.
Hosszú, folyamatosan fejlődő rendszerhez a dedikált fejlesztői csapat ad folytonosságot.
Jól definiált, önálló projekthez, ahol a leszállított eredmény a fontos, az end-to-end modell adja a legjobb kiszámíthatóságot.

A gyakorlatban a három ritkán tiszta: sok együttműködés úgy indul, hogy beemelünk egy-két fejlesztőt, aztán ahogy nő a bizalom és a scope, dedikált csapattá bővül. Így a modell mindig a te helyzetedhez igazodik.

Az erőforrás kiszervezés minőségét befolyásoló tényezők (ábra)

Miből lesz jó minőségű a kiszervezett munka?

A kiszervezés minősége nagyban függ attól, milyen együttműködési modellt választasz. A nyílt freelancer-piacon a teljesítmény egyetlen szakember tapasztalatán és munkamódszerén múlik, ezért nagyobb lehet az eltérés az egyes fejlesztők között.

Nálunk a kihelyezett mérnök is a mi technológiai standardjaink szerint dolgozik, így egy fejlesztőcég belső mércéje, és szükség esetén kontrollja is tükröződik a munkájában.A gyakorlatban ez azt jelenti, hogy a kódra több szem néz: van code review, van tesztelés, vannak rövid fejlesztési körök és rendszeres demók. Ez akkor is igaz, ha csak egyetlen fejlesztőt kérsz, akit te irányítasz: mögötte ott áll a cég folyamata, a code review és a helyettesíthetőség.

A folytonosság szintén adott: ha valaki kiesik, a tudás dokumentált és a csapaton belül megosztott, nem tűnik el vele együtt.

IT outsourcing kompetenciák: backed, frontend, mobil tech stack

Milyen kompetenciákat tudunk kihelyezni?

A kiszervezés akkor működik, ha a partner egy egész projekt kompetencia-igényét le tudja fedni, nem csak egy szeletét. Sokszor egyetlen fejlesztőt kérsz, akit a saját csapatod irányít (ez a klasszikus IT contracting, staff augmentation eset), máskor egy komplett gárdát.

Backend oldalon PHP/Laravel és Java/Symfony a két legerősebb vonalunk, mellette Node.js, Go és Python/Django; a magyar piacon az egyik legnagyobb PHP-fejlesztő csapatot tartjuk fent, és vezető szakembereink az ELTE-n tanítják a Laravelt. Frontenden Vue, React és Angular; mobilon natív iOS (Swift), Android (Kotlin) és Flutter. A fejlesztés mellé szoftvertesztelőt, UX/UI-tervezőt, üzleti elemzőt, projektmenedzsert és IT-tanácsadót is biztosítunk, így a kódoláson túl a teljes fejlesztési folyamatot lefedjük.

Ezek erős kompetenciáink, de a kép ma már nem teljes az AI nélkül, amely egyre inkább beleszól abba, hogyan fejlesztünk hatékonyan. A jó fejlesztő nem áll meg a kódolásnál: érti a problémát is, és tudja, hol gyorsít rajta az AI, és hol nem. A kihelyezett IT-szakembereink pontosan így dolgoznak, full-stack, tanácsadói szemlélettel.

Így segítettük ügyfeleink fejlesztéseit

A kihelyezett fejlesztés nálunk nem új dolog, és nem is elméleti.

A Vodafone-nál éveken át dolgoztunk kihelyezett fejlesztői csapattal, agilis együttműködésben: backend- és frontend-fejlesztőkkel, üzleti elemzővel és UX-tervezőkkel. Ennek egyik látványos eredménye a korábbi Vodafone New Portal volt, közel egy éves fejlesztés után.

Máskor egy ügyfél saját fejlesztőcsapatát egészítettük ki külső szakemberekkel egy adott területen, hogy ne akadjon meg a szállítás. Ez a klasszikus staff augmentation eset.

A LogiNet magyar tulajdonú fejlesztőcég, 100+ IT-szakemberrel, 19 év folyamatos piaci jelenléttel és 120+ megvalósult projekttel. Fix költségvetést és betartott határidőket vállalunk, kompromisszum és túlígérés nélkül, és a kihelyezett IT-szakembereink ugyanazok, akikkel a saját projektjeinket is visszük.

Gyakran ismételt kérdések a szoftverfejlesztés kiszervezéséről (IT outsourcing)

❓ Mi a különbség a fejlesztés átvétel és a rendszer audit között?
A rendszer audit önálló, független értékelés a meglévő szoftvered állapotáról, ami a megrendelőé marad, és bármilyen döntéshez használható (folytatás a meglévő csapattal, beszállítóváltás, újraírás). Részleteket a [[loginet/szolgaltatasok/rendszer-audit|rendszer audit]] szolgáltatás oldalán találsz. A fejlesztés átvétel ezzel szemben átvállalja a teljes utat: a felmérés, az új környezetre telepítés, a hibajavítás és a hosszú távú support egyetlen szerződésben fut. A két szolgáltatás kombinálható: érdemes először auditot kérni, és ennek eredménye alapján dönteni az átvételről.

⚡ Mennyi időt vesz igénybe egy átvétel?
A komplexitástól függ. Egy közepes méretű rendszer kódbázisának értékelése 1-1,5 hét, az új környezetre telepítés és deployment 1-3 hét, az első hibajavítási hullám 5-6 hét. A teljes átvételi projekt (értékelés + átállás + hibajavítás első hullám) tipikusan 2-3 hónap. Az opcionális stabilizációs csomag plusz 1-2 hónap, az opcionális frontend modernizáció ennél is nagyobb mértékben függ a mérettartománytól. Az értékelési szakasz után indikatív ütemtervet adunk a scope pontosítást követően.

♾️ Mi van, ha a meglévő kódbázis menthetetlen, és az újraírás a jobb út?
Az értékelési szakasz egyik fontos kimenete pont ez. Ha a vizsgálat azt mutatja, hogy az architektúra rugalmatlan, a függőségek deprecated szintűek, és a karbantartási sebesség drámaian romlik, az újraírást reális számsorral kalkulálható meg, és összevethető a folytatás várható kumulált költségével. A döntés a megrendelőé. Itt is őszinték vagyunk: az egyedi fejlesztő cégnek a folytatás üzletileg jobban jön, ezért is fontos, hogy a válasz ne ezt szolgálja. A leggyakoribb harmadik út a stabilizációs csomag, ami sok esetben elegendő ahhoz, hogy az újraírás elhalasztható vagy elkerülhető legyen.

⚠️ Vállalsz garanciát a meglévő kódra is, vagy csak az új fejlesztésekre?
Az alapcsomagban a saját új fejlesztéseinkre vállalunk 90 napos funkcionális garanciát, a korábban elkészített funkciók hibáira nem. Ennek oka egyszerű: nem tudjuk minden esetben kizárni, hogy az átadott kódbázisban rejtett hibák ne maradjanak. A megoldás a stabilizációs csomag: AI-támogatott refaktorálás, automatizált tesztek és code quality eszközök integrálása, 1 hónapos hypercare az élesedés után. Ezzel teljes funkcionális garanciát vállalunk az egész rendszerre, és lényegesen csökkennek az „egymásra mutogatós" helyzetek. Az ügyfél a kockázattűrése és a büdzséje alapján választ a két szint között.

☎️ Mobilalkalmazás átvétele iOS és Android oldalon hogyan zajlik?
A mobilalkalmazás átvétele sajátos technikai feladat. Az onboarding flow fix időkeretű (jellemzően 20-30 óra az első hónapban): a kódbázis elérése (Swift, Kotlin), backend-API megismerése, kiadói fiókok (App Store, Google Play) átállítása, a build és release folyamat újrafelépítése az új csapat eszközein. A korábbi fejlesztővel néhány technikai egyeztetés tisztázza a release folyamat egyedi lépéseit (signing, store metaadatok, jailbreak detektálás). Az ismerkedési fázisban próbajellegű hibajavítások és első support feladatok futnak. Az élesedés után SLA-val fedett support megy tovább, ahol a kritikus hibára 2 órán belüli első válasz és 2 munkanapon belüli végső megoldás a vállalási tartomány. Flutter és React Native átvételére hasonló folyamat érvényes, a stackre jellemző eltérésekkel.

⚙️ A meglévő ERP-mmel és a külső integrációkkal mi történik?
Maradnak. Az átvétel az alkalmazás rétegére fókuszál, az integrációk működése folyamatosan biztosított, és a régi és az új környezet párhuzamos futtatása a fizetési, ERP-szinkron és partner integrációk minimális kockázati szinten történő átállását célozza. A meglévő integrációk az értékelési szakasz egyik kifejezett vizsgálati pontja, és a kockázati jelentés külön szakaszt szentel nekik. Ha új integrációs réteg vagy [[loginet/megoldasok/middleware|middleware]]-fejlesztés is szükségessé válik, az a fejlesztési hullámba beilleszthető.

⚖️ Milyen árazási modellben dolgoztok?
A komplexitástól függ. A kódbázis értékelésének szakasza fix óraszámon megy (jellemzően 24 óra körül), az átvétel és az első hibajavítási hullám fix scope-on és időkereten alapul, time & material elszámolással a 15 százalék feletti túllépésre. A hosszú távú support több modellben fut: havi lekötési modell (előre fizetett órakeret kedvezményesebb óradíjjal, fel nem használt órák egy hónapig átvihetők, dedikált support manager) vagy használatalapú (best effort SLA-val). Az értékelési szakasz lezárása után fix scope-ú ajánlatot adunk a továbbvitelre, és a megrendelő világosan látja, miért fizet.

☠️ Mi van, ha a régi fejlesztő nem hajlandó vagy nem tud együttműködni az átvételben?
Az átvétel első hetében jellemzően szükség van a korábbi fejlesztői- és üzemeltetési csapat támogatására (forráskód biztosítása, hozzáférések biztosítása, felmerülő technikai kérdés esetén egyeztetés). Ha ez nem áll rendelkezésre, az átvétel attól még megvalósítható, de a kockázat magasabb, és az értékelési szakasz kifejezett figyelmet fordít a hiányzó tudás kompenzálására. Az AI-támogatott statikus elemzés ilyenkor különösen értékes, mert a kódbázis felépítését és a függőségi gráfot szisztematikusan tudjuk feltárni. A scope ilyen esetben rugalmasabb és nagyobb bufferrel kalkulált, a kockázattűrés és a büdzsé függvényében.

▶️ A projekt után ki üzemelteti a rendszert?
Választható. Vagy a [[loginet/szolgaltatasok/uzemeltetes|LogiNet üzemeltetés]] és [[loginet/szolgaltatasok/support|support]] szolgáltatása fut tovább transzparens SLA-val (több rendszerünket 8-10-15+ éve támogatjuk, az átvettek között is), vagy a saját csapatod veszi át a dokumentáció átadásával és tudásátadási folyamattal. Az átvétel során épített dokumentáció pontosan ezt a kettősséget szolgálja: bárhonnan folytatható.