IT contractor vagy saját fejlesztő? Szerintem rossz a kérdés. Erős belső csapat kell, és mellé külső szakértő is. A belső csapat nélkül nincs kinek átadni a tudást és nincs, aki gazdája legyen a rendszereknek. Külsősök nélkül viszont a csapat lassan bezárul, és elveszíti a kapcsolatot azzal, ami a piacon történik. A művészet az egyensúly: használd ki a külső tudást, de soha ne válj kiszolgáltatottá neki. Ebben a cikkben megmutatom, mit mond erről a kutatás, mennyibe kerül valójában egy saját ember és egy contractor, és hogyan döntsd el, mikor melyik kell.
Röviden
- Az IT contracting (csapatkiterjesztés, angolul staff augmentation) azt jelenti, hogy külső szakértő dolgozik a csapatodban, a te irányításod alatt.
- Erős belső csapat nélkül a külső tudást sem tudod hasznosítani: a kutatás szerint csak arra tudsz építeni, amihez van saját alapod.
- Külső szakértő nélkül a csapat beszűkül: egy klasszikus MIT-kutatásban a régóta együtt dolgozó fejlesztőcsapatok teljesítménye romlott, ahogy csökkent a külső szakmai kapcsolatuk.
- A legnagyobb hiba a kitettség: ha a kulcstudás csak a külsősök fejében van, nem te irányítod a rendszeredet.
- Pénzügyi szolgáltatóknál a DORA ezt szabályozói elvárássá is tette: kilépési stratégia és átállási időszak kell minden kritikus külső kapcsolathoz.
Rossz kérdés: contractor vagy saját ember?
Vezetőként és most szállítóként is újra meg újra ugyanazt a vitát hallom. Az egyik tábor szerint a saját ember a biztos, a contractor drága és elmegy. A másik szerint a saját csapat lassú és merev, a külsős gyorsan bevethető. Mindkettőnek igaza van, és mindkettő téved, mert az egyiket a másik helyett akarja.
Én úgy látom, hogy a kettő nem helyettesíti, hanem kiegészíti egymást. A belső csapat adja a folytonosságot, az üzleti tudást és a felelősséget. A külső szakértő hozza azt, amit a belső csapat egyszerűen nem láthat: hogyan oldották meg ugyanezt a problémát öt másik cégnél, mi működött és mi nem. Egy contractor néhány év alatt több rendszert, több csapatot és több hibát lát, mint egy belső fejlesztő egy évtized alatt egy helyen.
A kérdés nem az, hogy saját ember vagy contractor. Hanem az, hogy a kettő együtt hogyan erősíti egymást, és ki tartja a kezében a kulcsot.
Mit jelent az IT contracting, és miben más, mint a kiszervezés?
A fogalmak sokszor összecsúsznak, pedig a különbség lényeges, mert mást kapsz és máshol van a felelősség. A piacon ugyanarra több néven is hivatkoznak: IT contracting, csapatkiterjesztés, staff augmentation, erőforrás-biztosítás, régebben body leasing.
| Modell | Ki irányítja a munkát? | Ki felel az eredményért? | Mikor jó választás? |
|---|---|---|---|
| Saját alkalmazott | Te | Te | Tartós, kulcsfontosságú szerepeknél, ahol a tudásnak a cégen belül kell maradnia |
| IT contractor (csapatkiterjesztés) | Te, a saját folyamataidban | Te, a contractor a szakmai minőségért | Ha gyorsan kell kapacitás vagy olyan tudás, ami a csapatban nincs meg |
| Projektkiszervezés (fix áras szállítás) | A szállító | A szállító, a szerződés szerint | Jól körülhatárolt, önálló feladatoknál, ahol az eredmény pontosan leírható |
| Szolgáltatás (managed service) | A szállító | A szállító, szolgáltatási szint alapján | Üzemeltetési, támogatási feladatoknál, ahol a folyamatos működés a cél |
Ez a cikk az első kettőről szól: mikor építs saját csapatot, mikor hozz be contractort, és hogyan működjön a kettő együtt. A tesztelés kiszervezésének modelljeiről külön írtam: mikor érdemes kiszervezni a szoftvertesztelést.
Miért kell erős belső csapat?
Mert valakinek gazdája kell legyen a rendszereidnek. A belső csapat ismeri az üzletet, a történetet (miért készült valami úgy, ahogy), a döntések okait és a cég működését. Ők viszik tovább a tudást akkor is, amikor egy projekt véget ér és a külsősök továbbállnak.
Van egy kevésbé nyilvánvaló ok is. Cohen és Levinthal 1990-ben bevezette az abszorpciós képesség (absorptive capacity) fogalmát: egy szervezet csak akkor tudja felismerni, befogadni és hasznosítani a külső tudást, ha van hozzá saját, kapcsolódó tudásbázisa. A kutatás szerint ez a képesség halmozódik, folyamatos befektetéssel épül, és ha egy gyorsan változó területen leállsz vele, később nagyon nehéz visszaszerezni.
A gyakorlatban ez azt jelenti: a legjobb külső szakértő is csak annyit ér nálad, amennyit a belső csapatod meg tud érteni, el tud kérni és be tud építeni belőle. Ha nincs belső csapat, a contractor tudása vele együtt távozik.
Miért kell külső szakértő is? A beszűkülés csapdája
Ez a személyes meggyőződésem: ha egy csapatba évekig nem érkezik kívülről tudás, beszűkül. Ugyanazokat a megoldásokat ismétli, mert azok egyszer beváltak. Nem veszi észre, hogy a piac már máshogy csinálja. A „nálunk ez mindig így működött” mondat nem a stabilitás, hanem a bezárkózás jele.
Ezt a jelenséget a kutatás is leírta. Ralph Katz az MIT-n 50 kutatás-fejlesztési projektcsoportot vizsgált, amelyek tagjai néhány hónaptól közel 13 évig dolgoztak együtt. A legjobb teljesítményt azok a csapatok nyújtották, amelyek átlagosan 2-4 éve dolgoztak együtt. Az 5 évnél régebb óta változatlan csapatoknál a teljesítmény romlott, és ezzel párhuzamosan jelentősen csökkent a kapcsolatuk a külső szakmai közeggel. A szerző maga is jelzi, hogy egyetlen szervezet adatairól van szó, de az összefüggés azóta is sokat idézett.
A külső szakértő ezt a kört töri meg. Nem csak kapacitást hoz, hanem friss mintákat, más cégek tanulságait és egy kívülálló kérdéseit: „miért csináljátok ezt így?” Ez sokszor kényelmetlen, de pont ettől értékes.
A másik véglet: amikor kitetté válsz a külsősöknek
A másik irány legalább ilyen veszélyes. Egy rendszert évekig külsősök fejlesztenek, a belső csapat egyre kisebb, a dokumentáció egyre vékonyabb, és egy nap rájössz, hogy senki nincs a házban, aki el tudná magyarázni, hogyan működik a saját core rendszered. Ilyenkor már nem te irányítasz, hanem a szállítód. Az árazásban, az ütemezésben és minden döntésben.
A figyelmeztető jelek:
- egy kritikus rendszerről csak külsős tud érdemben nyilatkozni;
- a fejlesztési döntéseket a külsősök hozzák, a belső csapat csak jóváhagy;
- nincs naprakész dokumentáció, a tudás fejekben van;
- egy contractor távozása hetekre megbénítaná a fejlesztést;
- a belső csapatnak nincs ideje vagy lehetősége tanulni a külsősöktől.
Pénzügyi szolgáltatóknál ez már nem csak üzleti, hanem szabályozói kérdés. A DORA rendelet a külső IT-szolgáltatókkal kapcsolatban dokumentált kilépési stratégiát vár el, a kritikus vagy fontos funkciókat támogató szerződéseknél pedig kötelező, megfelelő átállási időszakot, amely alatt át lehet térni másik szolgáltatóra vagy saját megoldásra (DORA 28. és 30. cikk). A rendelet azt is előírja, hogy a szerződés rendezze a szolgáltató részvételét a pénzügyi intézmény IT-biztonsági tudatossági programjaiban. Vagyis a szabályozó is azt mondja: használhatsz külső tudást, de ne legyél kiszolgáltatott neki.
Mennyibe kerül valójában egy saját fejlesztő és egy contractor?
A leggyakoribb hiba, hogy a contractor napidíját a saját fejlesztő havi bruttó bérével vetik össze. Ez almát a körtével. A saját alkalmazott valódi költségébe beletartozik a munkáltatói teher (a szociális hozzájárulási adó 2026-ban is 13 százalék), a toborzás, a betanulás, az eszközök, a képzés, és az, hogy egy évben jóval kevesebb produktív nap van, mint ahány munkanap.
| Költségelem | Saját alkalmazott | IT contractor |
|---|---|---|
| Bér és munkáltatói terhek | Bruttó bér + 13% szociális hozzájárulási adó, juttatások | Napidíj, csak a ténylegesen ledolgozott napokra |
| Toborzás | Hirdetés, fejvadász, a vezetők interjúideje, hetek vagy hónapok | Jellemzően napok vagy néhány hét alatt elérhető |
| Betanulás | Hosszabb, a cég kultúráját is meg kell ismernie | Rövidebb, de a cég sajátosságait neki is meg kell tanulnia |
| Szabadság, betegség, képzés | A cég fizeti | Nem számlázható, nem fizeted |
| Kihasználatlan időszak | Akkor is fizeted, ha épp nincs rá feladat | A szerződés szerint csökkenthető vagy megszüntethető |
| Hosszú távú érték | A tudás a cégnél marad, ha jól megtartod | A tudás elmegy, ha nincs tudásátadás |
Egy egyszerű becslés: egy évben nagyjából 250 munkanap van. Ebből a saját alkalmazottnál le kell vonni a szabadságot (a Munka Törvénykönyve szerint 20 nap alapszabadság, ehhez életkor szerint pótszabadság jár), a betegszabadságot, a képzéseket és a belső adminisztrációt. Így reálisan 200-210 produktív nappal érdemes számolni. Ha a saját fejlesztő teljes éves költségét ennyivel osztod el, sokkal tisztességesebb összevetést kapsz a contractor napidíjával.
A másik szempont a rendelkezésre állás. A KSH adatai szerint 2024-ben a magyarországi vállalkozások 6,2 százaléka toborzott vagy próbált toborozni IT-szakembert, és 3,5 százalékuknak okozott nehézséget a betöltés. A két számból kiszámolható, hogy a toborzó cégek több mint felének gondot jelentett megtalálni a megfelelő embert. Ez az arány csökkent az elmúlt években, de a senior, szűk szakterületű szakemberek piaca ma is szűk.
A pénzügyi szempont tehát nem dönti el egyértelműen a kérdést. Ami eldönti: mennyi ideig, milyen tudásra van szükséged, és mennyire kritikus, hogy az a tudás nálad maradjon. Erről szól a hiányzó szerepek ára is: miért kerül többe egy hiányzó BA, mint a jelenléte.
Mikor melyiket válaszd?
| Helyzet | Javaslat |
|---|---|
| Hosszú távon, folyamatosan kell a szerep, és a rendszer kulcstudásáról van szó | Saját ember. Ha most nincs, contractorral indulj, de a tudásátadás legyen a feladat része. |
| Rövid távú csúcsterhelés, határidős projekt | Contractor csapatkiterjesztésként |
| Új technológia vagy módszertan bevezetése | Külső szakértő, aki betanítja a belső csapatot |
| Ritkán kellő, specialista tudás (például terheléses teszt, biztonsági audit) | Külső szakértő vagy kiszervezett szolgáltatás |
| Legacy rendszer, amelyhez már alig van belső tudás | Külső szakértő a tudás feltárására és dokumentálására, belső gazdával párban |
| A csapat évek óta változatlan, és kevés az új ötlet | Néhány külső szakember bevonása kifejezetten a friss szemlélet miatt |
A legacy rendszereknél a tudásvesztés különösen veszélyes, erről részletesen írtam itt: miért buknak el a legacy modernizációs projektek.
Így tartsd egyensúlyban
Univerzális arány nincs, és szerintem nem is a százalék a lényeg. Néhány szabály viszont minden esetben működik:
- Minden kritikus rendszernek legyen belső gazdája, aki szükség esetén át tudja venni a munkát.
- Az architektúra, a termékfelelős és a tech lead szerep maradjon bent. A külsős javasolhat, de a döntés a tiéd.
- A tudásátadás legyen a szerződés része, ne utólagos kérés: dokumentáció, közös munka, kódátnézés.
- Párosítsd a külsősöket belsősökkel. Így a tudás nem csak átadódik, hanem beépül.
- Használd ki a külső nézőpontot: kérdezd meg a contractort, máshol hogyan csinálják. Ez ingyen van, és sokat ér.
- Időnként frissíts: a tartósan bent lévő külsős idővel ugyanúgy „belsőssé” válik, a friss szemlélet lassan elfogy.
Ellenőrzőlista: egészséges-e a belső és külső csapatod aránya?
- Minden kritikus rendszeredhez van legalább egy belső ember, aki érdemben ismeri?
- Az architektúra- és termékdöntéseket belsős hozza meg?
- Van naprakész dokumentáció, amelyből egy új ember be tud tanulni?
- Túlélnéd egy kulcs contractor holnapi távozását komoly fennakadás nélkül?
- A szerződéseidben szerepel a tudásátadás és az átállási időszak?
- Kerül be rendszeresen külső szakértelem a csapatodba?
- Tanul a belső csapat a külsősöktől, vagy csak mellettük dolgozik?
- A saját fejlesztő és a contractor költségét a teljes éves költség és a produktív napok alapján hasonlítod össze?
Amit a FrontX-nél másképp csinálunk
- Csak senior szakembereket biztosítunk, akik az első héttől érdemben hozzá tudnak tenni a munkához.
- Csapatunk tagjai pénzügyi szolgáltatóknál és nagyvállalatoknál dolgoztak, így nem kell elmagyarázni nekik a kontextust.
- A tudásátadást és a dokumentációt a munka részének tekintjük, nem extra feladatnak. Az a célunk, hogy a belső csapatod erősebb legyen, ne függő.
- Fejlesztő, üzleti elemző, tesztelő és rendszerszervező szerepekben is dolgozunk, a belső csapatod mellett, a te folyamataid szerint.
- Részletek az IT csapatkiterjesztés és contracting szolgáltatásunk oldalán.
Ha szeretnéd átgondolni, hol erősítené a csapatodat egy külső szakértő, és hogyan maradjon nálad a tudás, szívesen segítünk: kérj ingyenes konzultációt.
Ha senior szakemberként dolgoznál olyan projekteken, ahol a tudásod számít és át is adhatod, nézd meg nyitott pozícióinkat.
Gyakran ismételt kérdések
Mi az IT contracting?
Az IT contracting (csapatkiterjesztés, staff augmentation) azt jelenti, hogy egy külső szakember a megrendelő csapatában, annak irányítása és folyamatai szerint dolgozik, jellemzően napidíjas elszámolással. A munka irányítása és az eredmény felelőssége a megrendelőnél marad, a contractor a szakmai minőségért felel.
Mi a különbség az IT contracting és a kiszervezés között?
Contractingnál te irányítod a munkát, a külső szakember a csapatod része. Kiszervezésnél egy szállító önállóan, a saját módszereivel szállít egy előre meghatározott eredményt, és ő felel érte. A contracting rugalmasabb, a kiszervezés jól körülhatárolt feladatoknál működik jobban.
Megéri contractort alkalmazni saját fejlesztő helyett?
Rövid távú, határidős vagy speciális tudást igénylő feladatnál gyakran igen, mert nem fizetsz toborzást, szabadságot és kihasználatlan időt. Tartós, kulcsfontosságú szerepekre viszont saját ember kell, mert a tudásnak a cégnél kell maradnia. A legjobb eredményt a kettő kombinációja adja.
Hogyan hasonlítsam össze egy contractor és egy saját alkalmazott költségét?
Ne a havi bruttó bért vesd össze a napidíjjal. Számold ki a saját alkalmazott teljes éves költségét (bér, 13 százalék szociális hozzájárulási adó, juttatások, toborzás, eszközök, képzés), és oszd el a produktív napok számával, ami jellemzően 200-210 nap körül van. Ezt az összeget érdemes a contractor napidíjával összevetni.
Hogyan kerülhető el, hogy függővé váljunk a külső csapattól?
Minden kritikus rendszernek legyen belső gazdája, az architektúra- és termékdöntések maradjanak bent, a tudásátadás és a dokumentáció legyen a szerződés része, és a külsősök belsősökkel párban dolgozzanak. Pénzügyi szolgáltatóknál a DORA kilépési stratégiát és átállási időszakot is elvár.
Mit ír elő a DORA a külső IT-szakértők bevonásáról?
A DORA a pénzügyi szolgáltatóktól elvárja, hogy kezeljék a külső IT-szolgáltatókhoz kapcsolódó kockázatokat, beleértve a koncentrációs kockázatot, és dokumentált kilépési stratégiájuk legyen. A kritikus vagy fontos funkciókat támogató szerződésekben kötelező egy megfelelő átállási időszak, amely alatt másik szolgáltatóra vagy saját megoldásra lehet váltani.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil
