Esettanulmány
Mobilbank: natív fejlesztők egy bank szabályozott release-folyamatában
Több mint egy éven át egy közép-európai lakossági bank mobilcsapatában dolgozott a HyperCode iOS- és Android-fejlesztőiből álló csapat. Onboarding-, fizetési, kártya- és bejelentkezési funkciókat szállítottunk a bank saját biztonsági és kiadási szabályai szerint. Az ügyfelet az NDA miatt nem nevezzük meg, minden más úgy történt, ahogy itt leírjuk.
Röviden
- —Egy lakossági banknak több natív mobilfejlesztői kapacitásra volt szüksége, egyszerre mindkét platformon.
- —A HyperCode legalább három Swift- és Kotlin-fejlesztőt ültetett be a bank mobilcsapatába, több mint egy évre.
- —A csapat négy területen szállított funkciókat: digitális onboarding és KYC, fizetések és átutalások, kártyakezelés, valamint bejelentkezés és biztonság.
- —A biztonsági munka nem feature volt, hanem az alap: certificate pinning, root- és jailbreak-detektálás, Keychain- és Keystore-alapú biztonságos tárolás.
- —Minden változtatás többlépcsős QA-n, üzleti UAT-n és biztonsági sign-offon ment át, és feature flag mögött, kikapcsolva került a release-be, amíg a bank be nem kapcsolta.
Miért nincs logó ezen az esettanulmányon
A csapatbővítéses munkáink nagy része más cégek termékeiben zajlik, titoktartási megállapodás alatt. Ez a projekt is ilyen. Nem nevezhetjük meg sem a bankot, sem az appot, és nem publikálunk felhasználószámot, tranzakciós volument és release-dátumokat.
Mégis megírjuk, mert aki azon gondolkodik, hogy külső fejlesztőket vonjon be, annak a munka jellege számít: mit vár egy bank a beágyazott mérnököktől, hogyan alakítják a biztonsági és kiadási szabályok a mindennapi fejlesztést, és mi került végül élesbe. Minden, ami alább olvasható, valóban megtörtént – csak az azonosításra alkalmas részleteket vettük ki.
A feladat: natív kapacitás két platformon, toborzás nélkül
A banknak már voltak natív iOS- és Android-mobilbanki appjai, körülöttük saját termék-, biztonsági és QA-szervezettel. Amire szüksége volt, az több natív fejlesztői kapacitás – senior Swift- és Kotlin-fejlesztőket felvenni pedig egy szabályozott környezetben lassú folyamat.
A HyperCode válasza egy legalább három natív fejlesztőből álló beágyazott csapat volt, iOS és Android között megosztva, amely a bank backlogjából, a bank folyamatai szerint dolgozott, egy-két éven át. Nem külön projekt volt ez, amelyet a végén átadunk, hanem a mobilcsapat további tagjai.
Mit épített a csapat
A munka a banki app azon részeit érintette, amelyeket az ügyfelek a legtöbbet használnak, és amelyeket a szabályozók a legszigorúbban néznek:
- —Digitális onboarding és KYC – ügyfél-onboarding és személyazonosság-ellenőrzési folyamatok a natív appokban
- —Fizetések és átutalások – a képernyők és a logika, amelyekkel az ügyfelek pénzt mozgatnak
- —Kártyakezelés – a bankkártyákhoz tartozó ügyféloldali beállítások és műveletek
- —Bejelentkezés és biztonság – autentikációs folyamatok és az alattuk lévő védelmi rétegek
A biztonság nem feature, hanem az alap
Egy banki appban a biztonsági követelmények nem backlog-elemek, amelyeket beütemezel; hanem azok a feltételek, amelyek mellett egy funkció egyáltalán létezhet. A csapat azokat a védelmi rétegeket építette és tartotta karban, amelyekre minden fölöttük lévő funkció támaszkodik.
Certificate pinning az iOS- és az Android-app hálózati rétegében, hogy az appok csak a bank saját végpontjaival beszéljenek. Root- és jailbreak-detektálás, hogy az appok tudják, ha kompromittált eszközön futnak. És a platform Keychainjére és Keystore-jára épülő biztonságos tárolás azoknak a titkoknak, amelyek soha nem kerülhetnek az app normál tárolójába. Ha jól csinálják, ez a munka láthatatlan az ügyfélnek – és pontosan ez a cél.
Munka egy szabályozott release-folyamatban
Egy bank nem úgy ad ki szoftvert, mint egy startup. A csapat minden változtatása több kapun ment át, mielőtt a store-okba került: a mobilcsapat saját QA-ján, az üzleti oldal felhasználói átvételi tesztjén (UAT) és egy biztonsági sign-offon. Semmit nem adtunk be pusztán egy fejlesztő szavára.
Ami ezt működőképessé tette, az a feature flag volt. A csapat kikapcsolt funkciókat szállított: a kód merge-elve, a rendes buildekben kiadva ott volt, csak nem volt bekapcsolva. A bank mindegyiket csak azután kapcsolta be, hogy a saját jóváhagyásai lezárultak. A fejlesztés a csapat tempójában haladt, az aktiválás a bankéban, így egyiknek sem kellett a másikra várnia.
Hogyan néz ki a csapatbővítés egy bankban
A felelősségmegosztás ugyanaz volt, mint minden más projektünkben: az ügyfélé a „mit”, a miénk a „hogyan” – az ő szabályaik keretein belül. A bank határozta meg a prioritásokat, a megfelelőségi követelményeket és a release-kapukat. A HyperCode fejlesztői feleltek az egyes funkciók mérnöki tartalmáért, és azért a fegyelemért, hogy mindez olyan formában készüljön el, amely átmegy ezeken a kapukon.
Ez utóbbin dől el, hogy egy beágyazott mérnök kiérdemli-e a helyét egy szabályozott cégnél. Egy funkció, amely elbukik a biztonsági sign-offon, nem egy délutánba kerül, hanem egy teljes release-ciklusba. A csapat dolga az volt, hogy elég jól ismerje a bank szabályait ahhoz, hogy a kódja átvizsgálásra készen érkezzen.
Az eredmény
A csapat által épített funkciók élesben futnak a bank natív iOS- és Android-appjaiban. A megállapodásunk szerint számokat nem publikálunk, ezért a lényeg röviden: egy lakossági bank több mint egy évre HyperCode-fejlesztőkkel bővítette a mobilcsapatát, négy alapvető területen szállított ügyfeleknek szóló funkciókat, és mindezt a bank saját biztonsági és kiadási folyamatán belül tette.
Ha olyan mobilterméket viszel, ahol a folyamat legalább annyira szigorú, mint a kód, ezt a tapasztalatot hozzuk.
Mit bizonyít ez az együttműködés
- ✓A beágyazott fejlesztők akkor válnak be egy szabályozott cégnél, ha átveszik az ügyfél folyamatát, nem pedig kerülgetik.
- ✓A biztonsági kontrollok – pinning, integritásellenőrzés, biztonságos tárolás – minden funkció előfeltételei, ezért mérnöki munkaként tervezd be őket, ne checklistként.
- ✓A feature flag lehetővé teszi, hogy a fejlesztés a fejlesztők tempójában haladjon, az aktiválás pedig a szervezetében.
- ✓A többlépcsős QA, az UAT és a biztonsági sign-off egy bankban nem overhead; egy visszadobott release sokkal többe kerül.
- ✓A csapatbővítéssel egy bank két platformon jut natív kapacitáshoz anélkül, hogy mindkettőre külön toborzási kört indítana.
Senior natív fejlesztőket keresel egy szigorú folyamatba?
Swift- és Kotlin-fejlesztőket ültetünk be olyan termékcsapatokba, ahol szigorúak a biztonsági és kiadási szabályok – és olyan kódot szállítunk, amelyet arra építünk, hogy átmenjen rajtuk.
Kérj ingyenes becslést