Onshore, nearshore, offshore: mit jelentenek a fogalmak
A fogalmak azt írják le, hol található a partner Önökhöz képest. Az onshore saját országbeli partnert jelent. A nearshore közeli országban működő partnert, általában azonos vagy szomszédos időzónában. Egy magyar cég számára ez például szlovéniai, ausztriai vagy más közép-európai partner lehet. Az offshore nagy időeltolódású, távoli országot jelent.
A helyszín csak a döntés egyik fele. A másik fele az együttműködési modell, vagyis hogy ki irányítja a munkát, és ki felel az eredményért:
| Modell | Ki irányítja a munkát | Ki felel az eredményért | Jellemző felhasználás |
|---|---|---|---|
| Saját csapat | Önök | Önök | Hosszú távú kulcstermék |
| Dedikált fejlesztőcsapat | A partner vezetője az Önök termékgazdájával | Megosztott, a szerződés szerint | Hosszabb projektek, amelyekhez stabil, bővíthető csapat kell |
| Csapatbővítés (staff augmentation) | Önök | Önök | Hiányzó szaktudás pótlása vagy gyors kapacitásnövelés |
| Projektalapú kiszervezés | A partner | A partner, az egyeztetett terjedelemre | Jól specifikált, időben korlátozott munka |
Bármely együttműködési modell lehet onshore, nearshore vagy offshore. Egy dedikált nearshore csapat és egy offshore csapatbővítési szerződés teljesen eltérő konstrukció, még ha mindkettőt „kiszervezésnek” nevezik is.
Mikor melyik modell működik
- A saját csapat akkor a legjobb, ha a szoftver a fő versenyelőnyük, a munka folyamatos, és mély szakterületi tudást igényel. Az ár a lassabb toborzás és a kisebb rugalmasság.
- A dedikált nearshore csapat hosszabb projektekhez illik, ahol rendszeres, gyakran napi együttműködés kell, és a csapatnak a munkával együtt kell bővülnie vagy szűkülnie. Az átfedő munkaidőnek köszönhetően a közös tervezés, az áttekintések és a gyors kérdések a normál munkanap részei.
- A csapatbővítés a leggyorsabb módja egy szakember bevonásának, például adatmérnöké vagy mobilfejlesztőé, de csak akkor, ha már erős technikai vezetésük van. Enélkül órákat vásárolnak, nem eredményt.
- A projektalapú kiszervezés integrációhoz, migrációhoz vagy világos követelményű különálló modulhoz illik. Nehézzé válik, ha a követelmények folyamatosan változnak.
- Az offshore egyértelműen specifikált, kevés szakterületi tudást igénylő munkánál működhet, amelyhez nem kell valós idejű egyeztetés.
A gyakorlatban gyakoriak a kombinációk: a termékgazdai szerep és az architektúra házon belül, a fejlesztés nagyobb részére dedikált csapat, egy-egy speciális tudásra pedig külső szakember.
A partnert a minőség, ne az óradíj alapján értékelje
Az óradíj a legkönnyebben összehasonlítható, de a legkevésbé hasznos szám. Az eredményt az dönti el, hogy a partner egyenletes tempóban működő, karbantartható szoftvert szállít-e. Az ajánlatok összevetésekor a teljes birtoklási költséget nézze: a betanítás idejét, az Önök oldalán jelentkező irányítási ráfordítást, a javításokat, a csúszásokat és egy későbbi partnerváltás költségét.
Az értékelést bizonyítékokra építse:
- referenciák hasonló projektekből, felhívható kapcsolattartókkal,
- a tényleges csapat, nem az értékesítők tapasztaltsága és stabilitása,
- fejlesztési gyakorlat: kódellenőrzés, automatizált tesztelés, CI/CD és dokumentáció,
- biztonsági gyakorlat és adott esetben tanúsítványok, például ISO/IEC 27001,
- kommunikáció: kijelölt kapcsolattartó, rendszeres jelentés és a munkanyelvük magabiztos ismerete, legyen az angol vagy német.
Irányítás és kommunikáció
A kiszervezési problémák többsége valójában irányítási probléma. Már az elején rögzítsék, ki dönt a prioritásokról (az Önök termékgazdája), ki hagyja jóvá az architektúrát, mit jelent a „kész”, és hogyan számolnak be a haladásról. A közös eszközök segítenek: az Önök repozitóriuma, feladatkezelője és CI-folyamata, hogy a munka látható legyen és Önöknél maradjon.
A munkaidő átfedése fontosabb, mint amilyennek látszik. Az a csapat, amely a munkanapjuk nagy részén elérhető, részt vehet a napi egyeztetéseken, percek alatt válaszol a kérdésekre, és együtt dolgozhat a fejlesztőikkel. Nagy időeltolódásnál minden tisztázatlan követelmény egy napba kerül.
GDPR, NIS2 és ágazati szabályok
Ha a partner hozzáférhet személyes adatokhoz, például tesztadatokon, naplókon vagy az éles környezet támogatásán keresztül, adatfeldolgozóként jár el, és a GDPR 28. cikke szerinti adatfeldolgozási szerződésre van szükség. A GDPR harmadik országba történő továbbításra vonatkozó szabályai (V. fejezet) akkor alkalmazandók, ha a személyes adatok elhagyják az EU-t/EGT-t. Az EU-ban/EGT-ben székhellyel rendelkező és ott adatot kezelő partner elkerüli ezt a kérdést, feltéve, hogy további adatfeldolgozói és eszközei is ott vannak, ezért kérje el a listát.
Ha szervezetük a NIS2-irányelv (EU) 2022/2555 hatálya alá tartozik, amelyet Magyarországon a 2024. évi LXIX. törvény Magyarország kiberbiztonságáról ültetett át, az ellátási lánc biztonsága a kötelező kockázatkezelési intézkedések egyike. Az irányelv elvárja, hogy figyelembe vegyék a közvetlen beszállítók sérülékenységeit és kiberbiztonsági gyakorlatuk minőségét, beleértve a biztonságos fejlesztési eljárásokat. A fejlesztőpartner éppen ilyen beszállító, ezért a szerződésben rögzítsék a biztonsági követelményeket, az incidensek bejelentését és az auditjogot.
A pénzügyi szektorban a DORA-rendelet (EU) 2022/2554 külön követelményeket ír elő a harmadik fél IKT-szolgáltatókra. Az egészségügynek és a közszférának saját szabályai vannak. Ezeket aláírás előtt ellenőrizze, ne utána.
Szerződés, szellemi tulajdon és kilépés
Az uniós jog a munkáltatónak biztosítja a vagyoni jogokat azon szoftverek felett, amelyeket a munkavállalók munkaköri feladataik ellátása során hoznak létre. Külső cég munkájánál ne hagyatkozzon feltételezésekre: a szerződésnek egyértelműen át kell ruháznia Önökre, vagy kizárólagosan Önöknek kell engednie a forráskódot, a dokumentációt és a többi eredményt. Gyakorlati biztosítékok:
- a forráskód az első naptól az Önök repozitóriumában, a fiókok a cég nevén,
- a nyílt forráskódú komponensek és licencük egyértelmű listája,
- titoktartás, amely kiterjed az adataikra és az üzleti logikára,
- felmondási idők és egyeztetett határidők a csapat bővítésére vagy szűkítésére,
- kilépési terv: a kód, a dokumentáció, a hozzáférések és a tudás átadása, valamint a partner kötelezettsége az átállás támogatására.
Ellenőrizze a partnert 30 napos pilottal
Az ajánlat azt mutatja meg, hogyan értékesít a partner. A pilot azt, hogyan dolgozik. Bízzon a szűkített listán szereplő partnerre egy kicsi, de valódi feladatot, előre egyeztessék a siker szempontjait, és saját környezetükben hajtsák végre: először betanítás és egy egyszerű feladat, aztán szállítás kódellenőrzéssel és tesztekkel, majd egy feladat, amely érinti a szakterületüket vagy egy integrációt, végül visszatekintés a fejlesztőikkel. A fenti eszköz pilottervet és a helyzetükhöz súlyozott ellenőrzőlistát készít.
Figyeljen a figyelmeztető jelekre: nem ismerheti meg azokat, akik a munkát végzik, a partner meg akarja tartani a kódot vagy a szellemi tulajdont, a referenciák nem elérhetők, alacsony árat ígérnek, mielőtt bárki megértené a követelményeiket, vagy homályosak maradnak a biztonságra és az alvállalkozókra vonatkozó válaszok.
Ha a projekt ERP-integrációkat is tartalmaz, nézze meg az ERP-rendszer kiválasztásának ellenőrzőlistáját is. Ha szeretné megbeszélni szoftverprojektjét és a hozzá illő megvalósítási modellt, beszéljen velünk.
