Kodėl mobiliųjų aplikacijų keitimas yra rizikingas
Aplikacijos migracija nėra toks paprastas procesas, kaip gali pasirodyti iš pirmo žvilgsnio. Nors dažnai tai atrodo kaip įprastas atnaujinimas, iš tiesų jis susijęs su įvairiomis rizikomis. Dauguma tų rizikų yra trumpalaikės, bet jas būtina atidžiai valdyti. Todėl svarbu koncentruotis ne tik į naujas funkcijas, bet ir į stabilų bei kontroliuojamą perėjimą.
Kaip rodo DevOps praktika pagrįsti tyrimai, nepriklausomai nuo industrijos ar projekto apimties, migracijos metu dažniausiai pasikartoja tos pačios rizikos. Tai – duomenų praradimas, sistemos prastovos, biudžeto viršijimas, saugumo pažeidžiamumai ir atitikties reguliaciniams reikalavimams problemos.
Pavyzdžiui, migracijos metu dalis duomenų gali būti sugadinta arba netikti naujai sistemai. Tokiu atveju nukenčia vartotojų paskyros, jų istorija ar kiti svarbūs duomenys.
Tuo pačiu metu gali kilti ir techninių problemų kaip nestabiliai veikiančios API ar „backend“ sistemų sutrikimai gali laikinai sustabdyti paslaugų veikimą. Jei prie to dar prisideda sudėtingos ar pasenusios vidinės sistemos, migracija dažnai užtrunka ilgiau nei planuota ir kainuoja daugiau.
Papildomą rizikos sluoksnį sukuria saugumas ir atitiktis. Migracijos metu sistemos tampa labiau pažeidžiamos, todėl bet kokie trūkumai duomenų valdyme, sutikimų sekime ar auditavime gali turėti rimtų pasekmių, ypač griežtai reguliuojamose srityse.
Kaip užtikrinti atitiktį keičiant mobiliąją aplikaciją
Atitiktis reguliaciniams reikalavimams nėra dalykas, kurį galima palikti projekto pabaigai. Ji turi būti integruota į migracijos procesą nuo pat pradžių.
Keičiant mobiliąją aplikaciją, kartu perkeliami ir vartotojų duomenys, jų suteiktos teisės bei prieigos logika. Todėl labai svarbu aiškiai suprasti, kaip viso proceso metu tvarkomi asmens duomenys. Reikia kontroliuoti kaip duomenys yra apdorojami, saugomi ir pasiekiami, ypač laikantis tokių reikalavimų kaip GDPR. Kaip pažymi mūsų CTO:
„Saugumo standartai laikui bėgant keičiasi. Tai, kas anksčiau buvo laikoma saugu, gali tapti nebetinkama, todėl reikia taikyti naujus šifravimo ar atitikties sprendimus.“
Tai reiškia, kad migracija yra ne tik perkėlimas, bet ir galimybė pasitikrinti esamą situaciją. Autentifikavimo procesai, sesijų valdymas ir šifravimo standartai turi būti peržiūrėti ir atnaujinti pagal šiandieninius reikalavimus, o ne tiesiog perkelti iš senos sistemos.
Pavyzdžiui, dirbant su tarptautine žiniasklaidos organizacija „Internews“, Baltic Amadeus atliko saugumo vertinimus Baltijos šalių medijų organizacijose. Jų metu buvo nustatyti infrastruktūros, duomenų valdymo ir pažeidžiamumų trūkumai bei pateikti aiškūs žingsniai, kaip sustiprinti atsparumą.
Tai parodo jog realios rizikos išryškėja tik tada, kai sistemos yra tinkamai įvertinamos.
Dar vienas svarbus aspektas – atsekamumas. Migracijos metu komandos turi aiškiai žinoti, kas buvo pakeista, kada ir kodėl. Tam reikalingi tinkamos sekimo sistemos i ir auditavimo mechanizmai, kurie dažnai yra privalomi reguliuojamose srityse.
Svarbu nepamiršti ir aplikacijų parduotuvių reikalavimų. „Apple“ kasmet atnaujina privatumo ir duomenų naudojimo taisykles, o „Google“ – net kelis kartus per metus. Jei aplikacija jų neatitinka, atnaujinimai gali būti atmesti arba aplikacija apskritai pašalinta.
Kaip sklandžiai perkelti mobiliąją programėlę
Mobiliųjų aplikacijų keitimas nėra vien tik „frontend“ atnaujinimas. Didžioji dalis sudėtingumo slypi sistemose, kurios veikia už jos ribų. Todėl migracijos negalima vertinti kaip vienkartinio paleidimo. Praktikoje saugiausias ir efektyviausias būdas yra migracija etapais, kai tam tikrą laiką kartu veikia ir sena, ir nauja versija.
Toks požiūris mažina riziką, leidžia testuoti realiomis sąlygomis ir suteikia vartotojams laiko priprasti prie pokyčių.
Kaip sako Vitalis Kavaliauskas:
„Pradėjus keisti aplikaciją, dažnai paaiškėja, kad reikia platesnio sistemų modernizavimo.“
2024 m. „Red Hat“ tyrimas parodė, kad dauguma organizacijų modernizaciją vertina kaip kelių etapų procesą – nuo mažesnių eksperimentų iki plataus masto ir nuolatinio atnaujinimo. Dažniausiai pasirenkamas laipsniškas perplatforminimas ar refaktoringas, o ne vienkartinis visos sistemos perrašymas.
Vietoje to, kad visi vartotojai būtų perkelti vienu metu, nauja aplikacija įvedama palaipsniui, išlaikant ir senąją versiją. Tai sukuria saugumą nenumatytiems atvejams ir padeda užtikrinti nenutrūkstamą paslaugų veikimą.
Ne mažiau svarbus yra duomenų tęstinumas. Vartotojai neturi jaustis lyg pradėtų viską iš naujo – jų paskyros, istorija, nustatymai ir pasirinkimai turi būti perkelti sklandžiai. Priverstinis registravimasis iš naujo ar prarasti duomenys yra vienas greičiausių būdų prarasti pasitikėjimą.
Didelę reikšmę turi ir komunikacija. Vartotojai turi suprasti, kas keičiasi ir kodėl. Aiškūs pranešimai aplikacijoje, el. laiškai ir informacija padeda išvengti painiavos. Net ir techniškai gera aplikacija gali nepasiteisinti, jei vartotojai pasimeta pokyčių metu.
Taip pat, kaip minėta anksčiau, atitiktis turi būti integruota į migracijos procesą nuo pat pradžių. Tai apima vartotojų sutikimų išsaugojimą, saugų duomenų perdavimą ir auditavimo užtikrinimą. Reguliuojamose srityse migracija nėra tik funkcionalumo klausimas – tai ir nuolatinis atitikimas teisiniams bei saugumo reikalavimams.
Šis požiūris galioja ne tik mobiliosioms aplikacijoms. Pavyzdžiui, dirbant su viena didžiausių Lietuvos energetikos įmonių, Baltic Amadeus pakeitė pasenusią savitarnos platformą, kuri nebeatitiko nei vartotojų, nei saugumo lūkesčių. Vietoje senos sistemos taisymo buvo sukurta nauja, tuo pačiu užtikrinant, kad pagrindinės paslaugos, tokios kaip mokėjimai, sutartys ar komunikacija, veiktų be sutrikimų.
Vartotojo patirtis: lemiamas veiksnys
Kaip jau buvo galima suprasti, net ir padarius viską techniškai teisingai, rezultatas vis tiek gali būti nesėkmingas jei nukenčia vartotojo patirtis.
Kai vartotojai po atnaujinimo ar migracijos atsidaro aplikaciją, jie negalvoja apie architektūrą, API ar atitiktį. Jie tiesiog tikisi, kad viskas veiks taip, kaip įprasta arba dar geriau.
Viena dažniausių klaidų – per daug pakeitimų vienu metu. Nors visiškai naujas dizainas gali atrodyti patraukliai, esamiems vartotojams tai dažnai sukelia jausmą, kad jie atsidūrė visai kitoje aplikacijoje.
Migracijos metu tikslas turėtų būti ne staigus pokytis, o nuoseklus tobulinimas. Svarbiausi naudojimo scenarijai turėtų išlikti atpažįstami. Vartotojai turi galėti atlikti tuos pačius veiksmus panašiu būdu, net jei sistema iš esmės pasikeitė.
Praktiniai pavyzdžiai rodo, kad etapais ir nuosekliai gerinant registracijos procesą ir navigaciją galima padidinti vartotojų išlaikymą net iki 30–40 % per 30 dienų ir apie 25 % sumažinti riziką, kad jie pereis kitur. Tai gali būti net efektyviau negu perkuriant visą aplikaciją nuo nulio.
Laipsniškas pokyčių įvedimas per mažus atnaujinimus, aiškias žinutes ir subtilų vartotojų supažindinimą leidžia daug lengviau pereiti prie naujos versijos. Jei vartotojai supranta, kas pasikeitė ir kodėl, jie kur kas lengviau tai priima.
Greita atmintinė: 6 dažniausios klaidos
Dauguma aplikacijos keitimo projektų žlunga ne dėl technologijų, o dėl sprendimų, susijusių su laiku, planavimu ir vartotojų valdymu.
Štai dažniausiai pasitaikiančios klaidos:
- Per anksti pašalinama sena aplikacija. Visiškas perėjimas vienu metu gali atrodyti efektyvus, tačiau taip prarandamas saugumas. Jei kas nors neveikia, vartotojai neturi kur grįžti.
- Tikimasi, kad vartotojai „susigaudys patys“. Net ir nedideli UX pokyčiai gali sukelti painiavą. Jei įprasti veiksmai staiga atrodo kitaip, vartotojai greitai nusivilia.
- Vartotojai priverčiami pradėti viską iš naujo. Prarasti duomenys, istorija ar būtinybė registruotis iš naujo – vienas greičiausių būdų prarasti pasitikėjimą.
- Migracija laikoma tik techniniu procesu. Be aiškios komunikacijos net ir gerai sukurta aplikacija gali atrodyti sudėtinga. Vartotojai turi suprasti, kas keičiasi ir kodėl.
- Atitiktis paliekama paskutinei minutei. Prarasti sutikimai, nepakankamas auditavimas ar pasenę saugumo sprendimai gali sukelti rimtų teisinių problemų.
- Neįvertinama, kas slypi už aplikacijos ribų. „Backend“ sistemos ir integracijos dažnai nulemia, ar migracija bus sklandi, ar sudėtinga.
Daugumos šių klaidų galima išvengti. Esminis skirtumas dažniausiai slypi tame, ar aplikacijos keitimas traktuojamas kaip vienkartinis projektas, ar kaip valdomas pereinamasis procesas.
Išvada: svarbu pasirinkti tinkamą požiūrį ir partnerį
Skirtumas tarp sėkmingos ir nesėkmingos migracijos dažniausiai slypi ne tame, kaip greitai paleidžiama nauja aplikacija, o kaip sklandžiai vartotojai pereina prie jos.
Baltic Amadeus, kaip viena iš lyderiaujančių mobiliųjų aplikacijų kūrimo įmonių, į aplikacijos keitimą žiūri kaip į nuoseklų evoliucinį procesą, o ne vienkartinį projektą. Mūsų tikslas – ne tik sukurti naują sprendimą, bet užtikrinti, kad jis veiktų realiomis sąlygomis, su realiais vartotojais, nuo pirmos dienos. Būtent tai ir apibrėžia tvarią, ateičiai paruoštą mobiliąją aplikaciją.
Jei planuojate atnaujinti ar keisti savo mobiliąją aplikaciją, verta skirti laiko tinkamam perėjimo planui. Susisiekite su mūsų komanda ir mes padėsime įvertinti esamą situaciją bei parinkti migracijos sprendimą.
