Blog

A DORA rendelet szerint a felelősséget nem lehet kiszervezni. Megmutatom, mit jelent a gyakorlatban a nyilvántartás, az előzetes kockázatelemzés, a kötelező szerződési pontok és a tesztelt kilépési terv, mit kérj az IT-beszállítóidtól, és hol csúszik el leggyakrabban a felkészülés.

IT contractor vagy saját fejlesztő? Szerintem mindkettő kell. Erős belső csapat nélkül nincs, aki a tudást megtartsa, külső szakértők nélkül pedig a csapat beszűkül. Kutatásokkal, KSH-adatokkal, költség-összehasonlítással, döntési fával és a DORA elvárásaival mutatom meg, hogyan használd a külső tudást úgy, hogy ne válj kiszolgáltatottá.

Összefoglaló: A digitális transzformáció leggyakrabban absztrakt fogalomként kerül elő , de a jelentéskészítés automatizálása a legkonkrétabb, legkevésbé kockázatos belépési pont: a pénzügyi csapatok fele még mindig manuálisan dolgozik, miközben az automatizálás akár 40%-os időmegtakarítást és 90%-kal kevesebb hibát hozhat. A cikk megmutatja miért éppen ez az ideális első lépés, hogyan segít ebben a felhő, és miért itt kezdődik ,- nem a projekt végén -, a szervezet kulturális elfogadása a digitalizáció iránt.

GitHub Copilot, Cursor, Claude Code, Windsurf, Kiro, Tabnine és Cline 2026 őszén: mire a legalkalmasabbak, milyen árazási modellel működnek, milyen kész integrációik vannak, és mire kell figyelni költség, biztonság és megfelelőség szempontjából. Plusz: három valós feladat, amelyben a FrontX AI-eszközöket használt.

Egy pénzügyi mobilalkalmazásnál a bejelentkezés jogi és architekturális döntés: a PSD2 erős ügyfél-hitelesítést (SCA) ír elő, konkrét szabályokkal (max. 5 hibás próbálkozás, 5 perc inaktivitás, összeghez kötött kód). Mutatjuk, mit kell a fejlesztés előtt tisztázni, és hogyan oldottuk meg Keycloak-alapú kétfaktoros azonosítással egy valós projektben.

A scope creep nem egy nagy katasztrófa, hanem lassú szivárgás: apró, önmagukban ártalmatlan kérések összeadódó hatása. Agilis projekteknél azért veszélyesebb, mert a „rugalmasság” álcázza. Ki felel a kezeléséért, melyek a korai jelei, hogyan kezeld a szabályozói változásokat a pénzügyi szektorban, és milyen eszközökkel védheted a scope-ot már projektindításkor.

A legacy rendszer nem szitkozódás -értéket hordoz. 4 helyzet amikor nem érdemes modernizálni: ha nem tudod pontosan mit csinál, ha IT divat hajtja a döntést, ha nincs meg a belső tudás az átálláshoz, és ha a határidő sürgeti. És 4 egyértelmű jel amikor mégis muszáj - döntési keretrendszerrel.

A fejlesztő nem azért nem találja meg a saját kódja hibáit, mert nem elég jó, hanem mert ugyanazzal a gondolkodásmóddal tesztel, amellyel a kódot írta. Négy valós eseten (Oracle-számlázórendszer, biztosítói mobilalkalmazás, lízingcéges workflow, IVR-rendszer), a tesztpiramison és a TDD-kutatáson keresztül mutatjuk meg, mikor elég a fejlesztői tesztelés, mit változtat az AI által írt kód, és mikor nem opcionális a független tesztelés.

Kanban vagy Scrum? A Scrum iterációkban, a Kanban folyamatos áramlásban szállít, és pénzügyi szektorbeli szervezeteknél ritkán kell választani: a fejlesztés Scrummal, az üzemeltetés és a BA/SA csapat Kanbannal működik a legjobban. Összehasonlító táblázat, a Scrum valós időigénye, és négy kérdéses ellenőrzőlista a döntéshez.

A Scrum formális alkalmazása pénzügyi szektorbeli nagyvállalatoknál sokszor nem hozza a várt eredményt: lassú döntéshozatal, nem autonóm csapatok, compliance által diktált backlog. Mit ír elő a Scrum Guide a Scrum Masternek, mi történik a gyakorlatban, mi működik helyette, és hogyan ellenőrizd, készen áll-e a szervezeted a Scrumra.

A digitalizációs projektek többsége azért bukik el, mert IT-projektként kezeli, holott valójában szervezeti változásról van szó. Három szereplő hiánya okozza a legtöbb kudarcot: az üzleti folyamat gazdája, az üzleti elemző aki fordít az IT és az üzlet között, és a változásmenedzsment felelős. Amíg az üzlet passzív befogadó marad, a legjobb technológia sem hoz valódi változást.

Egy pénzügyi nagyvállalatnál 50-200 digitalizálható folyamat van. Mindenki a saját területét tartja a legfontosabbnak. A sorrend döntés stratégiai — mert ha az első projekt megbukik, a következőhöz már sokkal nehezebb belső támogatást kapni. Ez a cikk egy egyszerű döntési keretrendszert ad: négy tényező - fájdalomintenzitás, megvalósíthatóság, üzleti hatás és láthatóság - alapján meg lehet határozni mivel érdemes kezdeni. Három konkrét példán keresztül: biztosítótól, banktól és lízingcégtől.

A digitális transzformációs projektek többsége nem technológiai okból bukik el, hanem azért, mert hiányzik az üzleti szemlélet, a valódi folyamatértés és a változásmenedzsment. A cikkben 25 év pénzügyi szektorbeli tapasztalatomon keresztül mutatom be azt az 5 leggyakoribb mintát, amely miatt a vállalatok 70%-a nem éri el a kívánt üzleti eredményt. Valós biztosítói, banki és lízinges példákon keresztül látszik: a sikeres transzformáció nem az új rendszerekről, hanem a jól definiált üzleti célokról, a legacy rendszerek őszinte feltérképezéséről és az üzlet–IT együttműködésről szól.

A szoftvertesztelés kiszervezése nem mindig a legjobb megoldás, de négy helyzetben egyértelműen az. A cikk megmutatja, hogyan javítja a kiszervezett tesztelés a termék megbízhatóságát és milyen mutatók igazolják ezt, gyakorlati értékelőlapot ad a QA-partner kiválasztásához, összeveti az AI-alapú tesztelést a hagyományos kiszervezéssel, és bemutatja a DORA tesztelési és harmadik féllel kapcsolatos előírásait, azt is, mikor NEM érdemes kiszervezni.

Sok IT-projekt nem a technológia miatt csúszik meg, hanem mert nincs, aki gazdája legyen az üzleti igénynek. Kutatási adatokkal (PMI, IAG, McKinsey), átlátható számítással és valós projektpéldákkal mutatjuk meg, mikor térül meg egy üzleti elemző, mi marad ki leggyakrabban a specifikációból, hogyan működik a BA agilis környezetben, és mit változtat az AI.

A cikk bemutatja, miért nem működik sok követelmény specifikáció és funkcionális specifikáció a gyakorlatban, még akkor sem, ha szakmailag rendben vannak. Egy tapasztalt üzleti elemző nézőpontjából 5 tipikus jelet sorol fel, amikor a specifikációt nem olvassák vagy félreértik. Fő üzenet: a specifikáció nem csak dokumentum, hanem kommunikációs eszköz — minősége közvetlenül befolyásolja az IT projektek sikerét.

A nagyvállalatok 74 százaléka belekezdett, de nem fejezte be legacy modernizációs projektjét. Mi teszi nehézzé a legacy rendszereket (hiányzó dokumentáció, elfogyó szaktudás, kódba temetett szabályok), miért buknak el mégis főleg üzleti okokból a projektek, és mit változtat az AI a kódelemzésben, a dokumentálásban és az átírásban.

Business analyst vagy product owner amire szüksége van a projektnek? Mikor kell BA és mikor PO, és mikor mindkét pozíció? Miben különbözik a két szerepkör? Ezekre keressük a válaszokat a cikkünkben.

Meddig tart a Business Analyst munkája? Mikor mondhatja el, hogy kész van? Három viselkedési jel, ami megmutatja, hogy a BA valóban hatékonyan dolgozik

A COVI hatalmas változást hozott a szükséges proojektmenedzsment módszerekben. Változó csoportdinamika, új eszközrendszer, változó stakeholder kezelés, és egy kis jövőbe révéedés, hogy mi fog még vátozni. Ezeket a kérdseket járuk körbe....

Felháborodnánk, ha a hűtőszekrényünket naponta javítani kellene, a szoftvereinkhez viszont hetente jönnek a javítások. Tényleg ennyire gyenge a szoftverek minősége? Adatokkal mutatjuk meg, miért nem a frissítések száma a jó mérce, mit jelent a minőség az ISO/IEC 25010 és a DORA-kutatás szerint, mennyibe kerül a gyenge minőség, és mit változtat az AI és az EU kiberrezilienciáról szóló rendelete.