Podcast
2026-10-15
Építs IT-t, ami túléli a vezetőjét
40 000 láb magasan nincs hová félreállni
Amit egy bank Tribe Tech Leadje tanult a repülőgépipartól, az államtól és a banki rendszerektől is.
Röviden, ha csak fél perced van rá:
- Egy átlagos senior fejlesztő heti munkaidejének 30 százalékát tölti azzal, hogy korábbi hibákat javít vagy legacy kódot foltoz.
- Egy tesztcsapatban a belsős és külsős szakértők kb. 50-50 százalékos aránya adja a leginkább fenntartható működést.
- Egy hibás banki alkalmazás közvetlen pénzügyi kárnál sokkal nagyobb veszteséget okozhat azzal, hogy az ügyfelek végleg elpártolnak.
A legtöbb szoftvercsapat számára egy hiba kellemetlen, drága, de javítható. Van viszont néhány iparág, ahol ez a mondat egyszerűen nem igaz.
A Nálunk működött legújabb epizódjában Kuti Róberttel, az Erste Magyarország Tribe Tech Leadjével beszélgettünk arról, mit tanult a repülőgépipartól, az államigazgatástól és a banki rendszerektől a kockázatról, a tesztelés valódi értékéről és arról, hogyan érdemes felépíteni egy tesztcsapatot.
Amikor a hiba nem opció
Kuti Róbert pályája során a GE Aerospace hajtómű-szerviz szoftverein is dolgozott. Ott a tesztelés egészen más tétet kapott, mint egy hagyományos üzleti alkalmazásnál: egy repülőgép 40 000 láb magasan nem tud félreállni, ha valami elromlik.
Ez a fajta gondolkodás nem azt jelenti, hogy minden szoftvercsapatnak ugyanolyan szigorral kell dolgoznia, mint a repülőgépiparnak. Azt viszont igen, hogy érdemes tudatosan végiggondolni, mely pontokon olyan nagy egy hiba ára, hogy ott nem engedhető meg egyetlen felületes teszt sem.
A kockázatvállalás nem a technológiától függ
Kuti Róbert dolgozott már állami projekten (az IDOMSoftnál, a digitális állampolgárság fejlesztésén) és piaci vállalkozásoknál is. Elmondása szerint a kockázatvállalási hajlandóságát nem az befolyásolta, hogy éppen kinek dolgozott technológiailag, hanem az, hogy egy hiba kire hat ki.
Egy induló cég egy rosszul sikerült funkciót viszonylag gyorsan tud korrigálni. Egy állami rendszernél, ahol több millió állampolgár napi digitális élményéről van szó, egyetlen probléma is jóval nagyobb társadalmi kockázatot jelent. Ez az igazi választóvonal az állami és a piaci szféra kockázatvállalása között, nem a bürokrácia vagy a technológia színvonala.
A rejtett számla, amit a legtöbb cég nem lát
Az adásban elhangzott egy adat, amit minden vezetőnek érdemes megjegyeznie: egy átlagos senior fejlesztő heti munkaidejének 30 százalékát tölti azzal, hogy korábbi hibákat javít vagy legacy kódot foltoz.
Ez majdnem fél munkahét, ami gyakorlatilag csak a múlt takarítására megy el, minden egyes héten. A tesztelés hiányának ez a fajta költsége nem jelenik meg egyetlen sorban sem a projekt eredeti költségvetésében, mégis folyamatosan ott van a háttérben.
A reputációs kár tovább kamatozik, mint a pénzügyi veszteség
Egy hibás kiadás vagy egy nem megfelelően működő banki alkalmazás közvetlen pénzügyi kára viszonylag jól mérhető. A valódi veszteség inkább ott kezdődik, amikor az ügyfelek egy része ezután csendben tovább áll, és nem tér vissza.
Ez a fajta veszteség nem egyszeri tétel, hanem folyamatosan kamatozik, és sokszor jóval nagyobb, mint amennyibe az eredeti hiba javítása került volna.
Miért nem olcsóbb egy automatizálási mérnök egy fejlesztőnél?
A beszélgetés egyik pontja arról szólt, miért él még mindig az a tévhit, hogy a tesztelői bér automatikusan alacsonyabb, mint egy fejlesztőé. Kuti Róbert szerint egy automatizálási mérnök valójában szoftverfejlesztő, aki teszt-frameworköket épít és automatizálja a tesztelési folyamatokat. A piacon logikusan ugyanazt a bérezést kellene kapnia, mint egy funkciófejlesztő kollégának.
A legjobb tesztelő-jelöltek szerinte azok, akik manuális tesztelőként kezdenek, de nyitottak arra, hogy elmozduljanak az automatizálás felé. Ez a nyitottság hosszú távon a bérezésben is meglátszik.
Hogyan épül fel egy jó onboarding?
Kuti Róbert egy konkrét gyakorlatot is megosztott: egyik csapatánál az új tesztelő kollégák első másfél hónapja kizárólag tudásépítés volt. Rögzített oktatási anyagok, központi wiki, kötelező TDD- és BDD-képzés, a végén pedig egy vizsga, mielőtt bárki élesben dolgozhatott volna.
Az Ericssonnál korábban egy teljes karriermodellt épített fel ugyanerre az elvre, ahol a jelölt bizottság előtt vizsgázott, a menedzsere pedig coachként kísérte végig a folyamatot.
A helyes arány belsős és külsős csapat között
Kuti Róbert nagyjából 50-50 százalékos belsős-külsős arányt tart egészségesnek egy tesztcsapatban. A külsős szakértő gyorsan indul és azonnal hozza a tudást, a belsős csapat a hosszú távú domain-tudást és stabilitást adja.
A kettő kombinálása nem kompromisszum, hanem tudatos stratégia, amit érdemes már a csapat felépítésekor eldönteni, nem utólag korrigálni.
Kíváncsi vagy a teljes beszélgetésre?
Ha érdekel, hogyan látja a kockázatot, a tesztelés értékét és egy jól működő csapat felépítését valaki, aki a repülőgépipartól a banki szektorig sok különböző környezetben dolgozott már, hallgasd meg a Nálunk működött legújabb epizódját Kuti Róberttel, az Erste Magyarország Tribe Tech Leadjével.
🎙️ Nézd meg vagy hallgasd meg a teljes epizódot!
