Hogyan Építs Szoftverfejlesztő Csapatot

A döntés, hogy szoftverfejlesztő csapatot építesz, általában költségvetési sorként érkezik, nem tervként. Valaki jóváhagyott két fejlesztői álláshelyet, egy igazgatósági előterjesztés azzal érvelt, hogy a kód birtoklása olcsóbb, mint a bérlése, és a keresés még azelőtt elindul, hogy bárki leírta volna, mire való a csapat. A felvétel ezután úgy siklik félre, hogy az nagyjából kilenc hónapig láthatatlan marad.

Aki ezt a kérdést felteszi, többnyire még nem kellene, hogy felvegyen bárkit is, és a válasz őszinte változata innen indul. Az állandó csapat fix költség egy olyan igénnyel szemben, amely rendszerint ingadozik. Akkor működik, ha a munka folyamatos, ha a szoftver az, amiért az ügyfelek fizetnek, és ha a cégen belül valaki meg tudja mondani, mit kell építeni a jövő héten. Vedd ki bármelyiket, és évre vetted meg azt, amit napra is megvehettél volna.

Ami következik, az a számtan és a sorrend: mennyibe kerül valójában egy fejlesztő, ha a National Insurance, a nyugdíj, a szabadság, az eszközök és a toborzás is benne van a számban, melyik szerepet töltsd be először, mit szállít egy, három, öt és tíz fős csapat, és hogyan vezess műszaki interjút, ha a házban senki sem műszaki.

Hány ember kell egy szoftverfejlesztő csapat felépítéséhez? Kevesebb, mint gondolnád, és később, mint gondolnád. Egy tapasztalt generalista, aki a szállítást elejétől a végéig viszi, több területet fed le, mint három junior, mert kis léptékben az ítélőképesség a szűk keresztmetszet, nem a gépelés. Az első valóban stabil forma három fő, évi nagyjából 250 000 GBP teljes költséggel. Szakadozott ütemterv mellett általában az ügynökség a jobb eszköz.

A legtöbb cégnek még nem kell szoftverfejlesztő csapatot építenie

A felvétel a legdrágább módja annak, hogy megválaszolj egy rosszul feltett kérdést. A munkaszerződés addig köt egy fizetéshez, amíg az illető ott van, plusz a felmondási idő, plusz az alább leírt törvényi költségek, és mindezt azelőtt, hogy tudnád, létezik-e még a munka tizennyolc hónap múlva.

A kudarc ritkán látványos. Egy cég felvesz két fejlesztőt, megépítik, ami a listán van, és a lista elfogy. Senki nem akar elbocsátani, így a csapat munkát talál ki magának: egy újraírást, egy keretrendszer-frissítést, egy belső eszközt, amit senki sem kért. Tizenkét hónappal később a bérköltség valós, az eredmény nem, és az alapító arra jut, hogy a fejlesztők improduktívak. Nem voltak azok. Alulspecifikáltak voltak.

Az ellenérv erős: az ügynökségek naponta többe kerülnek és kevésbé értik az üzletedet. Mindkettő igaz. Az marad ki belőle, hogy az ügynökség változó költség, amit ki tudsz kapcsolni, tehát egy rossz hónap egy hónapba kerül, nem egy évbe. Ha az ütemterv valóban folyamatos, a számítás megfordul, és a házon belüli megoldás nyer költségben és sebességben is. A hiba az, ha túl korán fordítod meg. A rögzített, lezárható munka ügynökségi megbízás, nem felvételi terv, ezért érkezik a szoftverfejlesztési szolgáltatásunkhoz annyi cég, amely létszámról kérdez, de valójában projektje van, nem programja.

A teszt, amely megmutatja, kell-e csapat

Három feltétel, és mind a hármat akarod. Háromnál kevesebb azt jelenti, hogy még nem tartasz ott.

A szoftver a termék, vagy a terméket támogatja? Ha az ügyfelek szoftverért fizetnek neked, vagy ha emiatt választanak téged a versenytárs helyett, a kód stratégiai eszköz, és a teljes kiszervezése előbb-utóbb irányítási problémává válik. Ha a szoftver a számlázást viszi, akkor az vízvezeték, a vízvezetéket pedig veszik.

Folyamatos az ütemterv? Írd le, mit építenél a negyediktől a tizenkettedik hónapig. Nem olyan funkciókat, amelyek tetszenének, hanem munkát, amit üzletileg meg tudsz védeni. Ha a lista vékony, projekted van egy uszállyal, nem egy évnyi munkád.

Van a cégben valaki, aki képes specifikálni a munkát? Ezt a pontot szokás átugrani. A fejlesztőnek tudnia kell, milyen problémát oldjon meg, és miből fogod látni, hogy megoldotta. Ha csak az ügyvezető tud erre válaszolni, és neki heti negyven perce van, a csapat az idejét várakozással vagy találgatással tölti. A product owner nélküli csapat mozgást termel, nem haladást.

Egy negyedik kérdés az időzítést dönti el, nem a választ. Tudsz tizennyolc hónapot finanszírozni úgy, hogy a szoftver nem termel bevételt? Ha a pénzügyi helyzet miatt a csapatnak a hatodik hónapra nyereségesnek kell lennie, ne vegyél fel senkit, és vedd meg a munkát napra.

Mennyibe kerül valójában egy alkalmazott 2026-ban

A fizetés a szám nagyjából hetven százaléka. A többi törvényi, működési és egyszeri, és az utolsó kategória az, amely tönkreteszi az első év költségvetését.

A törvényi költségek, amikről nem lehet alkudni

A munkáltatói National Insurance a legnagyobb tétel. A 2026 és 2027 közötti adóévben a munkáltató 15 százalékot fizet az évi 5 000 GBP másodlagos küszöb feletti kereset után, a GOV.UK munkáltatói kulcsok és küszöbök szerint. Egy 60 000 GBP fizetésnél ez 55 000 GBP 15 százaléka, vagyis 8 250 GBP. A jogosult munkáltatók az Employment Allowance révén évi legfeljebb 10 500 GBP-t számíthatnak be a másodlagos 1. osztályú kötelezettségükbe, egy olyan cég azonban, amelynek egyetlen ügyvezetője van és nincs másodlagos járulékra kötelezett további alkalmazottja, ezt nem igényelheti.

A nyugdíj automatikus beléptetése legalább 3 százalékos munkáltatói hozzájárulást ad, egy összesen legalább 8 százalékos kereten belül, évi 6 240 GBP és 50 270 GBP közötti figyelembe vehető keresetre számolva, a GOV.UK munkahelyi nyugdíjjárulékokról szóló útmutatója szerint. A sáv tetején ez alkalmazottanként nagyjából 1 321 GBP. Sok munkáltató ehelyett a teljes fizetés egy százalékát fizeti, ami nagyvonalúbb és könnyebben elmagyarázható egy jelöltnek.

A szabadság kapacitásköltség, nem pénzköltség. A törvényi jogosultság 5,6 hét, ami heti öt munkanap esetén 28 nap, és a munkaszüneti napokat nem kötelező ezen felül adni. Nagyjából 260 munkanaphoz mérve ez az év közel tizenegy százaléka, még mielőtt bárki megbetegedne.

A költségek, amik kimaradnak a táblázatból

Az eszköz kicsi, de valós: egy fejlesztői laptop 1 500 és 2 500 GBP között, egy monitor, egy asztal. Az eszközkészlet többe kerül, mint gondolnád, ha összeszámolod a verziókövetést, az IDE-licencet, a folyamatos integráció perceit, a felhőkörnyezeteket, a hibakövetést és a naplók megőrzését. Fejlesztőnként és évente 1 200 és 3 000 GBP közötti összeg védhető tervezési szám, házon belüli becslés és nem közölt statisztika.

A toborzás a csúcs. Az Egyesült Királyságban a sikerdíjas ügynökség jellemzően az első éves fizetés egy százalékát kéri, a tizes évek végétől a húszas évek közepéig terjedő sávban, tehát 60 000 GBP-s álláshoz tervezz 9 000 és 15 000 GBP közötti összeget, hacsak nem közvetlenül veszel fel. Ez is házon belüli becslés.

Az a sor, amit senki nem számol, a vezetés. Az a tapasztalt fejlesztő, aki két másikat felügyel, saját szállítási kapacitásának húsz-negyven százalékát veszíti el, tehát három felvétel nem hoz három ember teljesítményét.

Ezt olvasd úgy, hogy az első évben a fizetés nagyjából 1,4-szerese, utána 1,2-szerese, a vezetési ráfordítás nélkül. A fizetésre, eszközökre, szoftverekre és toborzásra vonatkozó számok házon belüli tervezési becslések; csak a National Insurance, a nyugdíj és a szabadság sora származik közölt kulcsokból.

A vállalkozói út és hogy valójában mit vásárolsz

A napidíjas vállalkozó leveszi a törvényi költségeket és a felmondási időt, és hozzáad egy felárat meg egy irányítási kötelezettséget. Az Egyesült Királyságban a saját korlátolt felelősségű cégén keresztül dolgozó tapasztalt fejlesztő jellemzően napi 400 és 600 GBP közötti sávban van, a ritka tudás és a rövid megbízások pedig efölött. Ez házon belüli becslés, összhangban azokkal a sávokkal, amelyeket az oldal más pontjain közlünk.

Napi 500 GBP-vel és 220 számlázható nappal ez évi 110 000 GBP, szemben a 60 000 GBP fizetésű alkalmazott 72 000 GBP-s teljes költségével. A felár három dolgot vesz meg: le tudsz állni, gyorsan tudsz indulni, és olyasvalakit kapsz, aki ezt a problémát máshol már megoldotta. Cserébe elveszíted a folytonosságot és azt a tudást, amely a szerződéssel együtt kisétál.

A vállalkozók jól működnek körülhatárolt tudáshiányra, távollét pótlására, és egy építés első hat hónapjára, amikor tapasztalt ítélőképességet akarsz létszám lekötése nélkül. Rosszul működnek a csapat állandó helyettesítőjeként, mert az ösztönzők csendben a hosszt jutalmazzák a befejezés helyett, és mert tizennyolc hónappal később senki sem felel a kódért. Az ésszerű változat vegyes: vállalkozók a csúcsokra és a szakterületekre, alkalmazottak a rendszer azon részeire, amelyek távozását nem engedheted meg. Ez a minta áll a legtöbb webfejlesztő felvételére irányuló megbízásunk mögött.

A bérszámfejtésen kívüli munka és amit a szabályok elvárnak

Ez a szakasz egy kötelezettséget ír le. Nem adótanácsadás, és bármilyen méretű vállalkozói megállapodást indulás előtt könyvelővel vagy foglalkoztatási adószakértővel érdemes átnézetni.

A bérszámfejtésen kívüli munkára vonatkozó szabályok, közismert nevükön az IR35, akkor érvényesek, ha valaki saját közvetítőjén keresztül nyújt szolgáltatást, és alkalmazott lett volna, ha közvetlenül veled szerződik. A GOV.UK útmutatója a bérszámfejtésen kívüli munkáról rögzíti, ki dönt. A közepes vagy nagy magánszektorbeli megrendelő állapítja meg a munkavégző adózási foglalkoztatási státuszát, és Status Determination Statementet kell kiadnia az indokokkal. Kis, közszférán kívüli megrendelő esetén ez a felelősség a munkavégző közvetítőjénél marad.

Azt, hogy kicsinek számítasz-e, a Companies Act mérettesztje dönti el. A HMRC Employment Status Manual rögzíti, hogy 2025. április 6-tól a küszöbök 15 millió GBP feletti árbevételre és 7,5 millió GBP feletti mérlegfőösszegre emelkedtek, az 50 fős korlát változatlanul maradt. Egy cég közepes vagy nagy, ha két egymást követő üzleti évben a három feltételből legalább kettőt teljesít.

A HMRC magához a megállapításhoz eszközt tesz közzé. Az adózási foglalkoztatási státusz ellenőrzésére szolgáló eszközt megrendelők, munkavégzők és ügynökségek is használhatják, és a HMRC kijelenti, hogy tartja magát az eredményhez, feltéve hogy a megadott adatok pontosak és összhangban vannak az útmutatóval. Ez a kikötés a lényeg: az az eredmény, amely a vágyott szerződésen alapul, semmit sem ér.

A gyakorlati következmény egyszerű. A vállalkozó adminisztratív szempontból csak addig olcsóbb az alkalmazottnál, amíg kicsi vagy. Ha átléped a mérettesztet, minden megbízás hoz magával egy megállapítást, egy nyilatkozatot és egy nyilvántartást.

Mennyibe kerül egy ügynökség és miről mondasz le

Az Egyesült Királyságban a tapasztalt fejlesztőre vonatkozó ügynökségi napidíjak gyakran 600 és 1 200 GBP között mozognak, a tapasztalattól, az ágazattól és a beépített szállításirányítás mennyiségétől függően. Ez nagyjából egy vállalkozó duplája és egy teljes költségű alkalmazotti nap háromszorosa, és az összevetés mindkét irányban félrevezet.

A felár azt veszi meg, hogy a kapacitás már össze van rakva. Egy háromfős ügynökségi csapat már dolgozott együtt, van kiadási folyamata, ügyeleti rendje és valakije, aki tapasztaltan átnézi a kódot. Ezt házon belül felállítani hat-kilenc hónap és két felvételi kör. Rögzített terjedelmű építéshez vagy egy első verzióhoz, ahol még tanulod, mi legyen a termék, ez az előny általában legyőzi a díjkülönbséget.

Amiről lemondasz, az a közelség és az állandóság. Az ügynökség üzleti megértése addig tart, ameddig elmondtad neki, és vele együtt távozik. Az ellenszer a dokumentáció és egy átadási kikötés, amit az elején írsz meg, nem a végén.

A megtérülési pontot könnyebb hónapokban végiggondolni, mint díjakban. Nagyjából kilenc hónapnyi folyamatos munka alatt az ügynökség olcsóbb, ha beárazod a toborzást, a felfutást és a rossz felvétel kockázatát. Tizennyolc hónapon túl a házon belüli megoldás egyértelműen nyer. Az útmutatónk arról, hogyan válassz és bízz meg szoftverfejlesztő ügynökséget, a választásról szól, az egyedi szoftver költségvetési útmutatója pedig a számokról.

Az első fejlesztői felvétel dönt el mindent utána

Minden, ami az első fejlesztői felvételed után jön, ennek az embernek az ítélőképességéből következik. Ő választja meg a nyelvet, a hosztolást, a kiadás módját és az adatmodellt, és minden későbbi jelöltet egy általa meghatározott technológiai készlethez mérnek. Az a cég, amely itt téved, egy évig nem veszi észre, aztán egyszerre veszi észre az egészet.

Vegyél fel tapasztalt generalistát, aki a szállítást elejétől a végéig viszi. Ne annak a technológiának a szakértőjét, amelyre szerinted szükséged van, és ne vezetőt. Olyat, aki tud beszélni egy ügyféllel, el tudja dönteni, mit építsen, meg is építi, élesbe teszi, és kedd este támogatja is. Ez a profil drága, Londonon kívül házon belüli becsléssel nagyjából 70 000 és 95 000 GBP között, és ez a legolcsóbb dolog, amit abban az évben megveszel.

Az interjún nem az a próba, ismeri-e a keretrendszeredet. Az, hogy le tud-e írni egy projektet, amelyet rosszul mért fel, és meg tudja-e mondani, mit csinálna másképp, illetve hogy az ügyfeleidről kérdez-e előbb, nem a technológiádról. Aki csak a technológiáról kérdez, valami műszakilag kiválót és üzletileg jelentéktelent fog építeni.

Adj ennek az embernek hatáskört is, ne csak titulust. Ha nem tud nemet mondani egy funkciókérésre, egy nagyon drága kézpárt vettél fel. A bejegyzésünk arról, hogyan vegyél fel szoftverfejlesztőt az Egyesült Királyságban, mélyebben foglalkozik a szűréssel.

Miért bukik meg, ha először juniort veszel fel

A logika mindig ugyanaz és mindig hibás. A junior 28 000 GBP-be kerül 80 000 GBP helyett, tehát vehetsz kettőt, és majd belenőnek a szerepbe. Valójában az történik, hogy nincs ott senki, aki felnevelje őket.

A junior fejlesztő három-kilenc hónapig nettó mínusz a szállításban. Ez nem bírálat, így működik a szakma: kódátnézés kell neki, architekturális iránymutatás, és valaki, aki megállítja, mielőtt olyan döntést rögzít, amit drága visszabontani. Tapasztalt ember nélkül az átnézés soha nem történik meg, és a junior ellenőrizetlen munkát tol egyenesen abba a rendszerbe, amely az üzletedet viszi.

A számla később érkezik, műszaki adósság formájában. Tizennyolc hónapnyi át nem nézett kód újraírása jellemzően többe kerül, mint a megspórolt fizetés, és akkor kerül ennyibe, amikor a szoftver már teherhordó.

A juniorok jó befektetés a helyes sorrendben. Ha már van egy tapasztalt embered, akinek van kapacitása mentorálni, és van tesztekkel meg átnézési folyamattal ellátott kódbázisod, a junior olcsó kapacitás lesz, amely kamatozik. Elsőként felvéve fedezetlen kötelezettség, bérszámmal ellátva.

Csapatformák: mit szállít egy, három, öt és tíz ember

A szervezeti ábra megmondja, ki kinek jelent. A vevőnek viszont az kell, hogy melyik méret mit tud ténylegesen élesbe tenni, és mit nem tud szerkezetileg.

Egy fejlesztő

Egy tapasztalt generalista meg tud építeni és el tud üzemeltetni egyetlen, szerény felületű alkalmazást. Hetente tud kiadni, saját maga javítja az éles hibáit, és a fejében tartja az egész rendszert, ettől gyors. Amit nem tud: megbetegedni, szabadságra menni vagy felmondani. Az egyfős csapatnak nincs semmilyen tartaléka, és minden cég, amely egyetlen fejlesztőn fut, beáratlan kockázatot visel. Fedezd le a távollétekre szóló ügynökségi keretszerződéssel, vagy vállald kimondva, ne csak sodródva.

Három fejlesztő

A három az első forma, amely túléli egy ember távozását. Jellemzően egy technikai vezető és két fejlesztő, ahol a vezető a hete felét szállítással, a másik felét átnézéssel, tervezéssel és akadályelhárítással tölti. Három ember két munkaszálat tud vinni, kiadási ütemet tud tartani és ügyeleti rendet tud fedezni. Nem tudnak szakosodni, tehát minden mélyebb szaktudást igénylő feladatot, például egy fizetési integrációt vagy egy teljesítménycélú újraírást, kívülről vesznek meg. Teljes költséggel ez évi nagyjából 250 000 GBP.

Öt fejlesztő

Ötnél kezd megtérülni a szerkezet. Már megengedhetsz magadnak egy szakembert a generalisták mellé, és a technikai vezető a hét nagy részében már nem ír kódot. Öt ember el tud vinni egy valódi felhasználói bázissal rendelkező terméket, munkaidőben tud reagálni az incidensekre, és közben is halad az ütemtervvel. Ez az a méret is, ahol a product owner hiánya elviselhetetlenné válik, mert a koordináció költsége már meghaladja azt, amit egy alapító a szabad perceiben elnyel.

Tíz fejlesztő

A tíz már két csapat, akár meghúztad a vonalat, akár nem. A kommunikációs utak gyorsabban nőnek, mint a létszám, tehát az informális működés eltörik, és kimondott felelősség kell: ki birtokol melyik szolgáltatást, ki van ügyeletben, ki dönt. Itt lesz a mérnöki vezetés önálló szerep és nem egy másodkalap, és itt lesz a platformmunka (kiadás, környezetek, megfigyelhetőség) valakinek a feladata mindenki estéje helyett.

A szerepek nem műszaki olvasónak elmagyarázva

A szoftveres munkakörök megnevezése cégenként eltér, ezért nehéz megvásárolni őket. Íme, mit csinál a hetével az egyes szerepek.

Product owner

Eldönti, mi épül meg és milyen sorrendben, leírja, mit jelent a “kész”, és tud nemet mondani. A hetét azzal tölti, hogy beszél az ügyfelekkel és a csapattal, és az egyiket olyan munkára fordítja, amellyel a másik dolgozni tud. E szerep nélkül valaki más csinálja rosszul, rendszerint a technikai vezető, a saját szállítási idejének rovására. Nagyjából öt fejlesztőig el lehet lenni dedikált product owner nélkül, ha egy alapítónak tényleg van rá heti egy napja.

Technikai vezető

Ő birtokolja, ahogyan a rendszer felépül. Átnézi a kódot, meghozza az architekturális döntéseket, és ő felel, ha a terv rossznak bizonyul. Háromfős csapatban még szinte naponta kódol, tízfősben nagyon keveset. Ezt a szerepet egy fő fölött semmilyen méretben nem hagyhatod ki, mert innen jön a következetesség.

Full-stack fejlesztő

A teljes útvonalon épít funkciókat, a felhasználó által látott képernyőtől a mögötte lévő adatbázisig. Minden kis csapat gerince, mert a generalista fel tudja venni azt, ami éppen akadályozza a kiadást. Kis léptékben szinte kizárólag erre a profilra vegyél fel embert.

Specialista

Mély egy területen: mobil, adatmérnökség, biztonság, egy adott keretrendszer. Rendkívül értékes, ha a munka valóban megköveteli, és tétlen, ha nem. Napra vedd meg a specialistákat, amíg az igény legalább hat hónapig nem folyamatos.

QA mérnök

Szándékosan teszteli a rendszert, nem véletlenszerűen, automatizált tesztkészleteket épít, és ő birtokolja annak meghatározását, mikor biztonságos egy kiadás. A fejlesztők tesztelik a saját munkájukat, de azt tesztelik, amire számítottak. A tesztelő azt teszteli, amit a felhasználó valóban tenni fog.

Platformmérnök

Ő birtokolja a talajt, amelyen a szoftver fut: környezetek, kiadási folyamatok, felügyelet, mentések, költségek. Néha DevOpsnak hívják, ami valójában gyakorlat és nem munkakör. A munka minden méretben létezik; a kérdés csak az, hogy valakinek a feladata-e, vagy mindenki túlórája.

Mikor válik szükségessé tesztelő, tervező és platformmérnök

Mindegyiknek van őszinte jelzése, és az tünet, nem létszámadat.

Vegyél fel dedikált tesztelőt, ha negyedévente többször jut ki hiba az ügyfelekhez, vagy ha a kiadások lassulnak, mert senki sem elég magabiztos ahhoz, hogy megnyomja a gombot. Mindkettő azt jelenti, hogy a kézi ellenőrzés meghaladta azt, amit a fejlesztők elnyelnek. Ötfős csapatban ez rendszerint a tizenkettedik és a huszonnegyedik hónap között érkezik el.

Vegyél fel vagy szerződtess tervezőt, ha a fejlesztők a pull requestben hozzák meg a felületi döntéseket. Ez sorrendi hiba és nem képességbeli: egyszerre kell tervezniük és építeniük, és a tervezési félnek marad, ami az időből marad. Egy részmunkaidős tervező tíz fejlesztőn jóval túl is elég.

Vegyél fel platformmérnököt, ha a kiadás eseménnyé válik a rutin helyett, vagy ha a legjobb fejlesztőd hetét a környezetek és a folyamatok eszik meg. Ha az élesítéshez egy megnevezett ember és egy nyugodt délután kell, a talaj lett a szűk keresztmetszet. A bejegyzésünk a CI/CD folyamatok bevált gyakorlatairól leírja, milyen a jó, még mielőtt embert vennél fel rá.

Mérnöki vezetőt nagyjából nyolc-tíz főnél vegyél fel, előbb ne. Az alatt a hatáskörrel bíró technikai vezető jobb, mint a műszaki hitelesség nélküli menedzser, mert kis léptékben a fontos döntések műszakiak.

Olyan álláshirdetés, amely szűr

Az álláshirdetésnek egyetlen dolga van: csökkenteni az elolvasandó jelentkezések számát, és közben növelni a relevánsak arányát. A legtöbb az ellenkezőjét teszi, mert technológiákat sorol problémák helyett.

Kezdd a problémával. “Te fogod vinni egy foglalási rendszer újraírását, amely évi 4 millió GBP-t kezel, és jelenleg hetente körülbelül egy rendelést veszít el” többet mond egy jó fejlesztőnek, mint egy bekezdésnyi jelző, és azokat választja ki, akiket ez érdekel. A technológiai készletet egy sorban nevezd meg, jelenlegi állapotként és nem elvárásként: az erős fejlesztő két hét alatt megtanulja a keretrendszeredet, a gyengét pedig nem menti meg, hogy már ismeri.

Tedd közzé a fizetési sávot. A sáv nélküli állások olyanokat vonzanak, akik mennyiségre optimalizálnak, és egy teljes interjúkört pazarolnak el annak felfedezésére, amit egy szám tíz másodperc alatt megmutatott volna. Ha a sávot kényelmetlen nyilvánosságra hozni, valószínűleg rossz.

Mondd ki világosan, milyen a csapat, azt is, hogy kicsi. A “te leszel az első fejlesztőnk, az alapítónak jelentve” egyeseknek valódi vonzerő, másoknak valódi elrettentés, és mindkét hatást akarod. A homályosság itt olyan jelölteket termel, akik elfogadják, majd a negyedik hónapban távoznak.

Aztán vágd vissza az elvárások listáját arra, ami tényleg elvárás. Tizennégy felsorolás olyan preferencialista, amely specifikációnak adja ki magát, és elnyomja azok jelentkezését, akik jól végezték volna a munkát.

Műszaki felmérés, amit magad nem tudsz levezetni

Műszaki alapító nélkül a kísértés az, hogy a magabiztosságot méred, ami semmivel sem korrelál. Építsd úgy a folyamatot, hogy a műszaki ítélet ott szülessen, ahol megbízhatsz benne.

Használj rövid, fizetett otthoni feladatot. Két-három óra, ésszerű díjazással, írásos kiírással, amely rögzíti a korlátokat és az értékelési szempontokat. A fizetetlen, több napos feladatok a szabadidőt szűrik és nem a tudást, és épp azokat a tapasztalt jelölteket veszítik el, akiket akarsz. Tartsd közel a valódi munkához: egy kis funkció egy élethű kódbázison jobban jelzi előre a munkakört, mint egy algoritmusrejtvény.

Hozz be külső műszaki értékelőt az átnézésre és a követő beszélgetésre. Egy tapasztalt fejlesztő egy órája, aki elolvassa a beadott anyagot és végigvezeti a jelöltet a döntésein, többet mond, mint bármennyi kompetenciakérdés. Számolj napidíjjal, és tekintsd olcsó biztosításnak egy olyan felvétel ellen, amely egy évbe kerül.

Kérd meg a jelöltet, hogy magyarázza el neked, a nem műszaki embernek, a kódját. Ha nem tudja olyan szavakkal leírni, amit követni tudsz, hogy mit épített és miért, az információ: a munka nagy része azzal telik, hogy nem fejlesztő emberekkel kommunikál.

Kérj referenciát rendesen, és tegyél fel egy konkrét kérdést: mit tett ez az ember, amikor nem értett egyet egy döntéssel. A válasz elkülöníti azokat a fejlesztőket, akik korán szólnak, azoktól, akik elhallgatnak és helyesen építik meg a rossz dolgot.

A munkavállalási jog ellenőrzése nem opcionális

Minden munkáltatónak ellenőriznie kell, hogy a jelöltnek van-e joga az Egyesült Királyságban dolgozni, és az ellenőrzést a munkaviszony kezdete előtt le kell zárni. A GOV.UK útmutatója a jelentkező munkavállalási jogának ellenőrzéséről három elfogadható módot ismertet: online ellenőrzés megosztási kóddal, az eredeti dokumentumok kézi ellenőrzése a jelentkező jelenlétében, vagy ellenőrzés tanúsított személyazonosító szolgáltatón keresztül, dokumentumhitelesítő technológiával. A brit és ír állampolgárok nem tudnak megosztási kódot szerezni, így az ő ellenőrzésük dokumentumokkal vagy szolgáltatón keresztül zajlik.

A másolatokat a munkaviszony teljes idejére és utána két évig őrizd meg, és tűzz ki ismételt ellenőrzést mindenkinek, akinek a munkavállalási engedélye határozott idejű. A nyilvántartás az, ami megalapozza a törvényi mentesülést, ha később kiderül valami hiba.

A kitettség nem csekély. A GOV.UK szerint a munkáltatót munkavállalónként legfeljebb 60 000 GBP polgári jogi bírság sújthatja minden illegálisan foglalkoztatott után, ha a helyes ellenőrzés elmaradt. Egy első két felvételénél tartó cégnek ez több, mint a teljes toborzási keret. Az ellenőrzést az ajánlati folyamatba építsd be és ne az első napra, hogy soha ne érkezzen el kezdési dátum rendezetlen papírokkal.

Felvétel az Egyesült Királyságon kívülről

Ha a kívánt jelöltnek nincs már meg az engedélye, hogy itt dolgozzon, szponzori engedélyre van szükséged, mielőtt alkalmazhatnád, és az projekt, nem űrlap.

A Worker engedély igénylése 611 GBP kis vagy jótékonysági szponzornak és 1 682 GBP közepesnek vagy nagynak, a GOV.UK szponzorálási útmutatója szerint. A döntések többsége nyolc héten belül megszületik, és van 750 GBP-s elsőbbségi szolgáltatás, amely tíz munkanap alatt ad döntést, ha van szabad hely. Tervezz a szokásos határidővel, mert az a sor érkezési sorrendben halad.

Magának a munkakörnek is át kell lépnie egy fizetési küszöböt. A Skilled Worker vízum engedéllyel rendelkező szponzort és szponzorálási igazolást kíván, a GOV.UK pedig az általános fizetési követelményt évi 41 700 GBP-ben vagy a foglalkozásra irányadó díjazásban határozza meg, amelyik magasabb. A legtöbb szoftveres munkakörnél az irányadó díjazás a kötő korlát, nem az általános küszöb.

Aztán ott az Immigration Skills Charge, amelyet a munkáltató fizet a szponzorálási igazolás kiadásakor. A GOV.UK ezt az első tizenkét hónapra kis vagy jótékonysági szponzornál 480 GBP-ben, közepesnél vagy nagynál 1 320 GBP-ben állapítja meg, minden további fél évre pedig 240 vagy 660 GBP-ben. Hároméves szponzorálásnál egy közepes munkáltatónál ez 3 960 GBP, és a szponzor nem háríthatja át a munkavállalóra.

Tervezz 6 000 és 9 000 GBP közötti összeget és három-négy hónapot az első szponzorált felvételre. Ritka tudásnál ez gyakran helyes, egy olyan első felvételnél viszont, akire hat héten belül szükséged van, szinte soha.

A beillesztés és az első kilencven nap

Tűzz ki egy mérhető célt: az új fejlesztő az első héten kitesz valamit élesbe. Nem nagy funkciót, hanem egy kicsi, valódi változtatást, amit az ügyfelek látnak. Ez a leggyorsabb próbája annak, hogy a környezeted valóban működőképes-e, és az új ember lélektanát megfigyelőből tulajdonossá alakítja.

Ehhez több dolognak igaznak kell lennie. Dokumentált helyi beállítás, amely tiszta gépen is működik. Fiókok és jogosultságok, amelyeket az első nap előtt intéztek el, nem aznap igényeltek. Kiadási útvonal, amelyhez nem kell egy konkrét ember áldása. Megnevezett segítő, akinek a naptára azon a héten tényleg szabad. Ha bármelyik hiányzik, az új fejlesztő elsőként azt tanulja meg, hogy a rendszereitek nem működnek.

A harmincadik napra már kiadott egy értelmes funkciót, és az üzletet is le tudja írni, nem csak a kódbázist. A hatvanadik napra mások kódját nézi át és döntéseket kérdőjelez meg. A kilencvenedik napra munkát azonosít, nem pedig kap.

Ezek a mérföldkövek egyben a korai figyelmeztető rendszered is. Aki a hatvanadik napig semmit sem kérdőjelez meg, az vagy nem passzol, vagy túl szorosan van fogva, és mindkettő orvosolható a harmadik hónapban a kilencedik havi költség töredékéért. A bejegyzésünk a fejlesztői beillesztésről, amely az első héten szállít, leírja a gyakorlatot.

A megtartás, kiszámolva, nem elmesélve

Egy fejlesztő pótlása a toborzási díjba, a felfutásba és abba a teljesítménybe kerül, amelyet a távozó a felmondása után már nem nyújtott. Egy 60 000 GBP-s munkakörnél 12 000 GBP díj plusz három hónapnyi csökkent teljesítmény a valós számot 25 000 GBP fölé viszi. Ez házon belüli becslés, méghozzá óvatos, mert nem tartalmazza a vele távozó tudást.

A fejlesztők ritkán mennek el pusztán a pénz miatt, még ha a pénzt mondják is indoknak. Azért mennek el, mert nem tudnak szállítani. Egy kiadás, amely három napig tart, egy átnézési sor, amit senki nem ürít ki, egy ütemterv, amely kéthetente változik, hat hónap munka, amit kiadás előtt lefújnak. Mindegyik azt üzeni egy hozzáértő embernek, hogy az erőfeszítése nem alakul eredménnyé, a hozzáértő embereknek pedig van választásuk.

Az üzletileg ésszerű megtartási költés tehát nem a juttatás. Hanem a kiadás automatizálása, egy működő átnézési folyamat, egy stabil ütemterv, és elég mozgástér ahhoz, hogy a karbantartás megtörténjen, mielőtt vészhelyzetté válik. Ugyanezek a beruházások növelik a szállítási sebességet is.

A fizetési sávok továbbra is számítanak, egy meghatározott módon. A fizetések elcsúsznak, ha a piac mozdul és a belső felülvizsgálat nem, és az veszi észre először, aki máshol interjúzik. Évente vesd össze a sávokat nyilvános adatokkal, például az ONS brit munkavállalói keresetekről szóló jelentésével, amely szerint a teljes munkaidős alkalmazottak medián bruttó éves keresete 2025 áprilisában 39 039 GBP volt. Ez sokkal kevesebbe kerül, mint egy felmondás.

A hibrid modell, ahol a legtöbb cég kiköt

Tizennyolc hónap után a legtöbb cég, amely házon belüli csapat építésére indult, valahol félúton köt ki: kicsi állandó mag birtokolja a terméket, mellette ügynökség vagy vállalkozók a szakterületekre és a csúcsokra. Ez nem a terv kudarca. Ez az az elrendezés, amely túléli a találkozást egy valódi ütemtervvel.

Akkor működik, ha három dolog igaz. A házon belüli csapat birtokolja az architektúrát és az éles környezetet, így a külső fél olyan szerkezeten belül járul hozzá, amelyet te felügyelsz, nem pedig ő határoz meg egyet. A kódátnézés mindkét irányban működik, tehát a külső munkát a te csapatod nézi át, a te csapatod munkáját pedig ők. És a külső fél feladatköre eredményekben van megírva, nem órákban.

Akkor bukik meg, ha az ügynökség fekete dobozzá válik. Az árulkodó jel az, hogy házon belül senki nem tudja elmagyarázni, hogyan működik egy összetevő. Szerkezetileg akadályozd meg: a külső munka a te tárolódba kerül, a te folyamatodon át megy élesbe, és a dokumentáció a fizetés feltétele, nem a végén tett szívesség. Tarts a szerződésben rögzített ütemű tudásátadó alkalmat, havonta általában elég. Az összehasonlításunk a szoftverfejlesztés kiszervezéséről, Egyesült Királyság kontra offshore, érdemes elolvasásra, mielőtt eldöntöd, hol legyen a külső fél, mert az időzónák átfedése érezhetően megváltoztatja, mennyire működik ez a modell.

Szakaszos terv az első tizennyolc hónapra

Első-harmadik hónap: ne vegyél fel senkit. Írd meg a negyediktől a tizennyolcadik hónapig szóló ütemtervet, és nézesd át valakivel, aki műszaki és nem akar neked eladni semmit. Az azonnali munkát vedd meg ügynökségtől vagy vállalkozótól. Ennek a szakasznak az eredménye egy védhető válasz arra, folyamatos-e a munka.

Negyedik-kilencedik hónap: vedd fel a tapasztalt generalistát. Egy ember, jól megfizetve, a műszaki döntések feletti hatáskörrel. Az első két hónapban futtasd mellette a külső kapacitást is, hogy a szállítás ne álljon meg, amíg tájékozódik. Döntési pont a kilencedik hónapban: még mindig tele van az ütemterv, és tud-e ez az ember munkát specifikálni másoknak.

Tizedik-tizenötödik hónap: ha mindkét válasz igen, tedd hozzá a két fejlesztőt a stabil hármas formáig, és nevezz ki product ownert, még ha egy alapító is az, aki formálisan heti egy napot szán rá. Ha bármelyik válasz nem, maradj egy embernél plusz külső kapacitásnál, ami tökéletesen jó állandó állapot egy olyan cégnek, ahol a szoftver a terméket támogatja, nem pedig a termék.

Tizenhatodik-tizennyolcadik hónap: a második döntési pont. A negyedik és ötödik embert csak akkor tedd hozzá, ha a szűk keresztmetszet tényleg a kapacitás és nem az irány. A csapatok gyakrabban nőnek rossz okból, mint jóból, és a tünet egy hosszú, de nem rangsorolt teendőlista. Minden döntési ponton kérdezd meg, hogy a következő felvétel gyorsabb-e a következő ügynökségi napnál.

Hol kezdd

Először írd meg a tizennyolc hónapos ütemtervet, válaszold meg őszintén a háromrészes tesztet, aztán árazd be mindkét utat a valós számokkal, ne csak a fizetéssel. A legtöbb cég azt fedezi fel, hogy az első felvétel egy tapasztalt ember legyen két középszintű helyett, és hogy az azt megelőző hat hónapot jobb napra megvenni.

A Mecanik mindkét oldalon dolgozik. Szoftverfejlesztési megbízásokat viszünk olyan cégeknek, amelyek még nem állnak készen a felvételre, és tapasztalt kapacitást adunk webfejlesztő felvételén keresztül azoknak a csapatoknak, amelyek magot építenek, és közben fedezni akarják a csúcsokat. Ha a kettő között mérlegelsz, a hasznos beszélgetés az ütemtervről szól, mert az dönt.

Gyakran ismételt kérdések

Mennyibe kerül egy szoftverfejlesztő felvétele az Egyesült Királyságban? Számolj az első évben a fizetés nagyjából 1,4-szeresével, utána 1,2-szeresével. Egy 60 000 GBP-s fizetésnél ez az első évben körülbelül 85 600 GBP, amely a fizetésből, a 2026 és 2027 közötti adóévre vonatkozó 5 000 GBP-s másodlagos küszöb feletti 15 százalékos munkáltatói National Insurance-ból, a figyelembe vehető keresetre számolt legalább 3 százalékos nyugdíjhozzájárulásból, az eszközökből, a szoftverekből és a toborzási díjból áll össze. A fizetésre, eszközökre, szoftverekre és toborzásra vonatkozó számok házon belüli tervezési becslések.

Az első fejlesztői felvételem tapasztalt vagy junior legyen? Tapasztalt, méghozzá generalista és nem specialista. A junior fejlesztő három-kilenc hónapig nettó mínusz a szállításban, és tapasztalt emberre van szüksége, aki átnézi a munkáját, tehát ha őt veszed fel elsőként, ellenőrizetlen kód kerül abba a rendszerbe, amelytől az üzleted függ. Az újraírás rendszerint többe kerül, mint a megspórolt fizetés. A juniorok akkor jó befektetés, ha már van mentorálásra képes tapasztalt ember és átnézési folyamat.

Hány fejlesztő kell egy szoftverfejlesztő csapat felépítéséhez? A három a legkisebb forma, amely túléli valakinek a távozását: egy technikai vezető és két fejlesztő, évi nagyjából 250 000 GBP teljes költséggel. Egy tapasztalt generalista el tud vinni egyetlen alkalmazást, de nincs tartaléka betegségre, szabadságra vagy felmondásra. Ötnél kezd megtérülni egy szakember és egy dedikált product owner, a tíz pedig gyakorlatilag két csapat, amelyhez kimondott szolgáltatásfelelősség kell.

Mikor jobb egy ügynökség a házon belüli fejlesztőknél? Ha a munkának meghatározott vége van, ha nagyjából kilenc hónapnál kevesebb folyamatos ütemterved van, vagy ha hamarabb kell kapacitás, mint amennyi idő alatt egy felvételi kör hozná. Az ügynökség változó költség, amit le tudsz állítani, tehát egy rossz hónap egy hónapba kerül, nem egy évbe. Tizennyolc hónapnyi folyamatos munkán túl a házon belüli csapat egyértelműen nyer költségben és sebességben is.

Mit kell ellenőriznem, mielőtt fejlesztőt alkalmazok az Egyesült Királyságban? A munkaviszony kezdete előtt zárd le a munkavállalási jog ellenőrzését online megosztási kóddal, az eredeti dokumentumokkal a jelentkező jelenlétében, vagy tanúsított személyazonosító szolgáltatóval. A GOV.UK szerint a polgári jogi bírság minden illegálisan foglalkoztatott után elérheti a 60 000 GBP-t, ha a helyes ellenőrzés elmaradt. Ha az Egyesült Királyságon kívülről szponzorálsz valakit, szponzori engedély, szponzorálási igazolás és Immigration Skills Charge is kell.