Autosave - jak nie wpaść w pułapki rozwoju aplikacji i ocalić dane

Z pewnością wielu z was kojarzy, czym jest KYC. Dla tych, którzy nie wiedzą lub chcieliby odświeżyć swoją wiedzę, wyjaśnię, o co chodzi. KYC to skrót od Know Your Customer. W bankowości jest to proces identyfikacji oraz weryfikacji klienta. Wykonywany jest na etapie nawiązywania relacji oraz odnawiany w określonych interwałach czasowych. W praktyce oznacza rozpoznanie klienta i jego identyfikację. Jest to podstawa do rozpoczęcia biznesowej relacji z danym podmiotem. 

W Raiffeisen proces ten odbywa się za pomocą kilku narzędzi. W przypadku klientów istnieje aplikacja eKYC, która stanowi część platformy MyRaiffeisen.com. Jest to punkt styku z klientem, w którym reprezentanci innych instytucji finan¬sowych i korporacji udzielają nam odpowiedzi na predefiniowane pytania. Dotyczą one obecnej działalności biznesowej, struktury organizacyjnej, procesów wewnętrznych i środków ostrożności stosowanych przez ich pracodawców. Informacje zebrane w eKYC budują wiedzę niezbędną do rozpoczęcia dalszej współpracy z poszczególnymi klientami. 

Nasz RTechowy zespół Eagle wraz z wiedeńskim zespołem DaVinci nieustannie zbierają feedback dotyczący eKYC. Jesteśmy w stałym kontakcie z użytkownikami wewnętrznymi. Istnieje np. ankieta skierowana do klientów, akcje klienta są logowa¬ne w countly. Zebrane dane analizujemy, omawia¬my i priorytetyzujemy na regularnie odbywają¬cych się spotkaniach. Niemal w każdym releasie coś się zmienia, wprowadzane są ulepszenia do istniejących funkcjonalności. 

• odświeżenie predefiniowanych wzorów formularzy elektronicznych. Od teraz jest ich więcej, ale każdy z nich jest lepiej dopasowany do poszczególnych grup klientów, dzięki czemu oczekujemy ułatwienia oraz skrócenia czasu trwania procesu;
• stworzenie edytowalnych plików pdf na bazie powyższych formularzy elektronicznych. Zarówno z myślą o klientach, którzy rezygnu¬ją z dostępu do platformy, jak i pracownikach przygotowujących dla nich formularze KYC. Do tej pory alternatywą dla platformy były oddziel¬nie utrzymywane pliki w formacie kompatybil¬nym z MS Word. Były one utrzymywane osobno w stosunku do wersji elektronicznych. Obecnie zaimplemen¬towany został proces generujący edytowalne pliki pdf przy każdym wdrożeniu na bazie wzorów formularzy elektronicznych;
• część danych pochodzących z eKYC, które mają znaczenie z punktu widzenia Business Com¬pliance Framework, są przekazywane do sys¬temu Neuron, gdzie na ich bazie wyliczane są predefiniowane wskaźniki. Te ostatnie trafiają ostatecznie do Copernicusa. Stanowi to element auto¬matyzacji analizy danych dotyczących klientów.
  

Poza wymienionymi usprawnieniami zamierza¬liśmy zająć się również rozwiązaniem jedne¬go z najczęściej pojawiających się problemów podczas wypełniania przez klientów formularzy. Wiele zgłoszeń produkcyjnych, ale również ko¬mentarzy podczas sesji UAT czy innych testów, dotyczy sytuacji utraty uzupełnionych danych. Nietrudno sobie wyobrazić emocje użytkownika, który udziela odpowiedzi na kilkanaście, nawet kilkadziesiąt pytań, po czym w nieoczekiwanych okolicznościach traci wszystkie postępy pra¬cy. Każdy z czytelników tego tekstu na pewno przynajmniej raz w życiu miał do czynienia z podobną sytuacją! 

Naturalnym krokiem wycho¬dzącym naprzeciw wymaganiom użytkowników wydało się nam zaimplementowanie rozwiązania, które już teraz sprawdza się w innych aplikacjach w świecie MyRaiffeisen, takich jak ePIC (Payment Information Center) czy eGAO (Group Account Opening). W związku z tym zaczęliśmy nasze dyskusje, aby wspólnie ustalić, jak dobrze zaadaptować autozapis w eKYC. 

Z początku wydawało się nam, że dyskusja powinna zająć dwa, trzy spotkania. Omawianie problemu rozpoczęliśmy w setupie składają¬cym się z reprezentantów kilku zespołów: Eagle (odpowiedzialni za implementację ePIC), Forgot¬ten Heroes (odpowiedzialni za dotychczasową implementację eKYC), A Team (odpowiedzialni za implementację eGAO). Dodatkowym wspar¬ciem był Solution Architect platformy. Pierwszym krokiem było określenie stojących przed nami wyzwań. Pośród nich wyodrębniono kwestie tech¬niczne i regulacyjne.

• zagrożenie spowolnienia aplikacji poprzez dużą liczbę zapisów dużych struktur json;•
• zagrożenie obciążenia bazy danych dużą liczbą zapisów – obecnie każdy obraz danych pocho¬dzący z zapisu manualnego jest utrzymywany w bazie;
• długość trwania zapisu wynikająca z operacji powiązanych z zapisem. Nadmierna długość tej akcji może zagrozić prawidłowemu wykonywa¬niu się zapisów;
• zagrożenie działania dwóch różnych użyt¬kowników operujących w tym samym czasie na tym samym formularzu (obecnie, kiedy zostaje aktywowany manualny zapis przez jednego z użytkowników, pozostali dostają informację o zmianie wersji formularza i są zmuszani do jego odświeżenia).
  

Zanim przejdziemy do kwestii regulacyjnych, warto zwrócić uwagę na obecne przechowywanie przez aplikację obrazów danych z poszczególnych zapisów manualnych. Ku naszemu zaskoczeniu okazało się, że każda taka akcja wiąże się z po¬wstaniem tak zwanego snapshotu. Wyjaśniliśmy z zespołem Forgotten Heroes (DaVinci), który do tej pory zajmował się rozwojem i utrzymaniem aplikacji, że snapshoty i konieczność ich utrzy¬mania wynikała z celów audytowych. Jednocze¬śnie przyczyniała się do trudności wprowadzenia równoczesnego autozapisu. 

W związku z tym głównym celem zagadnień regulacyjnych było uzyskanie opinii i rekomendacji poszczególnych departamentów po to, by określić, czy logika istniejących snapshotów jest czymś, co powinno zostać utrzymane i czy idea autozapisu jest do¬puszczalna z różnych punktów widzenia.

• IT Security
• GDPR
• Compliance (teams responsible for institutional and corporate customers)
• Legal

Logicznym początkiem było uzyskanie opinii reprezentantów wymienionych zespołów na temat potencjalnej zmiany istniejącego rozwiązania i wprowadzenia autozapisu w eKYC. W mniejszej grupie osób rozpoczęliśmy więc maraton spotkań. Wytrwale opisując różnym osobom propozycję zmian, udało nam się wspólnie dojść do pozytyw¬nych rezultatów. 

W trakcie prowadzonych rozmów okazało się, że utrzymywanie obrazów danych formularzy, wykonanych na podstawie manualnych zapisów  (snapshotów) nie jest czymś przynoszącym korzyści żadnej ze stron. Nie ma też obowiązku prawnego nakazującego nam zachowanie zapisów do celów audytowych. Okazało się też, że z perspektywy RODO utrzymywanie dodatkowych źródeł danych wrażli¬wych, bez regulacyjnego wymagania, jest sprzecz¬ne z zasadą minimalizacji danych. Dzięki potwier¬dzeniom rozmówców, które zbieraliśmy w formie e-maili, mogliśmy przejść do następnego etapu. 

Wróciliśmy do dyskusji na poziomie zespołów deweloperskich na temat technicznej implementacji rozwiązania. Podstawowym argumentem był duży koszt tech¬niczny zmiany rozwiązania funkcjonującego od lat w eKYC. Koledzy z zespołu Forgotten Heroes wyrazili wątpliwość co do utrzymania spójności dotychczasowych danych spraw, w których utrzy¬mujemy system snapshotów oraz nowych for¬mularzy, w których wykorzystalibyśmy autozapis działający w interwałach. W ramach omawiania rezultatów dyskusji technicznych postanowiliśmy przewartościować problem od nowa. 

Skoro implementacja rozwiązania typu autosave stanowi ryzyko dla stabilności aplikacji i niesie ze sobą duży koszt, należy ponownie zrewidować założenia dotyczące dyskusji. Zadaliśmy sobie następujące pytania:

PYTANIE 1 
Jaki problem próbujemy rozwiązać? 
Odpowiedź: Chcielibyśmy zabezpieczyć klienta przed przypadkową utratą udzielanych odpo¬wiedzi (wprowadzonych od ostatniego zapisu manualnego). 

PYTANIE 2 
Co jest przyczyną utraty dotychczasowych odpowiedzi?
Odpowiedź: Wspólnymi siłami udało nam się wyod¬rębnić wiele sytuacji, które mogą spowodować ten problem. Mianowicie:

• Użytkownik (klient) opuszcza formularz, używając standardowego przycisku „X” nieświadomy, że poskutkuje to opuszczeniem formularza bez zapisu zmian.
• Użytkownik (klient) zamyka przeglądarkę, w której ma otwarty formularz eKYC.
• Użytkownik (klient) zamka okno przeglądarki, w którym ma otwarty formularz eKYC.
• Użytkownik (klient) wylogowuje się z platformy.
• Użytkownik (klient) zostaje wylogowany z platformy z powodu braku aktywności (po 15 minutach mamy soft logout, po na¬stępnych 15 – całkowite wylogowanie).
• Użytkownik (klient) traci połączenie internetowe przed zapisaniem zmiany.
• Użytkownik (klient) odświeża stronę. 
• Użytkownik (klient) przypadkowo używa przycisku backspace w przeglądarce lub na klawiaturze.
• Przeglądarka użytkownika (klienta) lub system operacyjny ulega permanentnemu zawieszeniu.
• Następuje nagły restart systemu użytkownika (klienta).
• Dwóch użytkowników (reprezentantów tego samego klienta) wzajemnie nadpisuje zmiany w formularzu.

Na bazie zdefiniowanych sytuacji zastanowi¬liśmy się, czy jako alternatywę dla autozapisu możemy zastosować inne rozwiązania, które pomogą zapobiec utracie danych. Przechodząc przez każdy przypadek z osobna, okazało się, że w niektórych nie da się nic zrobić. W większości udało nam się jednak znaleźć alternatywne sposoby na za¬pobieżenie utracie danych. Rezultatem dyskusji było wyodrębnienie sytuacji, w których możemy zredukować liczbę incydentów bez implemen¬tacji autozapisu. 

Nasze rozwiązanie było proste: zamiast zapisywać zmiany w interwałach czasowych, postano¬wiliśmy, że tam, gdzie to możliwe, będziemy prezentować okienka przypominające użytkow¬nikom o tym, że jeśli opuszczą stronę, utracą dane. Jednocześnie alerty będą zawierać opcje powrotu do strony w celu zapisania odpowiedzi. Alternatywne rozwiązanie jest zdecydowanie łatwiejsze w implementacji oraz nie niesie ze sobą niemal żadnego ryzyka dla aplikacji. 

Wyjątkiem jest sytuacja, w której klient zostaje wylogowany ze względu na brak aktywności. Wówczas ze względu na to, że użytkownik prawdopodobnie przeoczy każdy potencjalny komunikat uznaliśmy, że w ramach wywołania tak zwanego soft logoutu dokonamy automa¬tycznego zapisu. Będzie to jednak przypadek odosobniony i występujący z reguły rzadziej. W porównaniu do autozapisu odbywającego się w interwałach będzie więc wywoływany spora¬dycznie, co nie zagrozi obciążeniem aplikacji. 

Podsumowując, warto pamiętać, że nie zawsze rozwiązania, które natychmiast przychodzą nam do głowy, są najlepsze, mimo że intuicyjnie wydają się odpowiednie ze względu na to, że sprawdziły się w innych aplikacjach. Po drugie, w takich przypadkach, aby wybrnąć z patowej sytuacji, warto wrócić do analizy problemu i próby jego rozbicia na mniejsze kwestie do zaadresowania. Po trzecie, rozwój aplikacji wy¬maga czasem poznania opinii i ekspertyzy wielu osób, więc warto planować zmiany z odpowied¬nim wyprzedzeniem.

W tym zespole jest niemal od początku, wcześniej w roli Analityka Biznesowego. Obecnie zarządza product backlogiem zespołu, łącząc w nim potrzeby wielu interesariuszy. Kształtuje zakres poszczególnych faz projektów, wspiera zespół w sprawnej realizacji zadań. Poza pracą lubi czytać powieści i reportaże. Ogląda i grywa w snookera, regularnie jeździ na rowerze, docenia również dobre filmy, które najchętniej ogląda w kinie.