Wstęp
Założyciele startupów fintechowych początkowo koncentrują się na rozwoju aplikacji na namacalnych, widocznych elementach: produkcie koncepcyjnym, ekranach powitalnych, przepływach płatności, planach działania i terminach uruchomienia. Projekty te mają niewątpliwie ogromne znaczenie dla ogólnego sukcesu firmy fintech. Jednak w rzeczywistości najtrudniejsze do rozwiązania problemy napotykane podczas rozwoju aplikacji wynikają głównie z czynników, które nie są widoczne od razu, takich jak reguły, które nigdy nie są formalnie zdefiniowane, założenia, że integracje można łatwo przeprowadzić, oraz rzeczy, które są “odkładane” na później, ponieważ lista zadań stale się powiększa, aż do momentu wystąpienia znaczących negatywnych skutków dla harmonogramów, problemów z uzgadnianiem, zgłoszeń serwisowych i stresu związanego z audytami.
Oznacza to, że wysoka jakość dostarczania produktów fintech wymaga raczej szybkości niż zapewnienia ustrukturyzowanego procesu pozwalającego uniknąć typowych pułapek.
W Appricotsoft wierzymy, że dostarczanie oprogramowania powinno dawać poczucie przejrzystości, odpowiedzialności i spokoju, a nie chaosu. Realizujemy tę filozofię, wdrażając wspólny zestaw oczekiwań, które konsekwentnie realizujemy w trakcie wszystkich projektów rozwojowych dla naszych klientów: widoczny postęp, wczesna identyfikacja i rozwiązywanie zagrożeń, wspólne decyzje oraz zaangażowanie w jakość w całym procesie, a nie ograniczanie jej do produktu końcowego. Wszystkie narzędzia, które zalecamy w ramach naszego, zorientowanego na sztuczną inteligencję, Unison Framework (pierwotnie zaprojektowanego, aby wspierać realizację projektów za pomocą sztucznej inteligencji, jednocześnie pociągając ludzi do odpowiedzialności za rezultaty), zostały wdrożone, aby zapobiec przekształcaniu się drobnych nieporozumień (które czasami mogą prowadzić do kosztownych poprawek) w poważne rozproszenia. Na przykład: cotygodniowe dema; dzienniki decyzyjne; śledzenie ryzyka; zdyscyplinowane plany wydań.
W projektach firm zajmujących się tworzeniem oprogramowania fintech, pułapki pojawiają się regularnie. Są powszechne, ponieważ na początku często wydają się niegroźne. Zespół może nadal dostarczać interfejs użytkownika, łączyć się z platformą testową dostawcy i prezentować postępy w wersjach demonstracyjnych. Jednak fundamenty pozostają kruche.
Poniżej znajdziesz pięć najczęstszych i kosztownych błędów w rozwoju aplikacji fintech, dlaczego są ważne i co zrobić zamiast nich.
1. Niejasne zasady księgi głównej
Jednym z najgroźniejszych błędów jest brak jasnych reguł księgi głównej, ponieważ często maskują się one za dobrą funkcjonalnością.
Na przykład aplikacja fintech może wydawać się działać poprawnie na zewnątrz (prawa strona obrazka), ale w jej logice finansowej może być ogromna luka (lewa strona obrazka). Zespół mógł zdefiniować dostępne salda, ale mógł nie zdefiniować statusów rozliczeń. Zespół może być w stanie dokonać zwrotów, ale mógł nie określić, co się stanie, gdy transakcja zostanie tylko częściowo cofnięta. Interfejs użytkownika może wyświetlać środki w portfelu, opłaty transakcyjne, wstrzymane transakcje, transakcje oczekujące i obciążenia zwrotne; jednak może nie istnieć ustalona reguła dotycząca ich wpływu na księgę rachunkową w czasie.
Po wprowadzeniu produktu na rynek wynik jest przewidywalny: problemy z uzgadnianiem, raportowanie niezgodności, zdezorientowani klienci korzystający z pomocy technicznej, sfrustrowany zespół finansowy i konieczność przeprowadzenia szeroko zakrojonych działań porządkowych po wprowadzeniu produktu na rynek.
W większości przypadków problem ten nie jest spowodowany brakiem umiejętności inżynieryjnych, ale raczej brakiem zdefiniowania niezbędnych reguł przed rozpoczęciem opracowywania przepływów przez zespół.
Poniższe pytania często zadawane są zbyt późno:
- Kiedy transakcja staje się sfinalizowana?
- Jakie jest źródło prawdy dla salda dostępnego i salda zaksięgowanego?
- W jaki sposób rozliczacie się Państwo w przypadku nieudanych wypłat?
- Jak sobie poradzić z sytuacją, gdy webhook dostawcy dociera z opóźnieniem lub dwukrotnie?
- Jak rejestrować opłaty, zwroty i korekty?
- Które zdarzenia należy przechowywać w ramach historii audytu, a które są jedynie wyświetlane?
Jak temu zapobiec
Rozpocznij od warsztatów dotyczących zasad księgi głównej przed opracowaniem funkcji. Nie traktuj tego jako dokumentu wyłącznie finansowego ani zadania wyłącznie back-endowego. Interesariusze odpowiedzialni za produkt, inżynierię, zapewnienie jakości i zgodność z przepisami powinni rozumieć ten model.
Dokument:
- typy kont
- stany transakcji
- zasady publikowania
- logika opłat
- zachowanie oczekujące a ustalone
- odwrócenia i spory
- pojednanie własności
- raportowanie wyników
- przypadki brzegowe
Następnie przekształć te decyzje we wspólne artefakty: elementy backlogu, kryteria akceptacji, przykłady i dziennik decyzji. To właśnie ten rodzaj dyscypliny w dostarczaniu, stawiającej na jasność i precyzję, zapobiega dryfowaniu zakresu i chroni harmonogramy.
Przydatną wewnętrzną lekturą dla zespołów planujących tę fazę jest: Przewodnik Appricotsoft po odkrywaniu technologii finansowych, co wyjaśnia, dlaczego wczesna praca definicyjna oszczędza czas później.
2. Słabe zarządzanie webhookami
Firmy fintech regularnie potrzebują informacji z systemów zewnętrznych, takich jak bramki płatnicze, dostawcy KYC, wystawcy kart, bankowe API, narzędzia do wykrywania oszustw i inne usługi powiadomień. W związku z tym zespoły często zdają sobie sprawę, że webhooki są częścią ich rozwiązania; jednak często popełniają błąd, myśląc, że webhook to po prostu “punkt końcowy odbierający aktualizacje”.”
W rzeczywistości webhooki są jednym z głównych obszarów niepowodzeń systemów płatniczych i technologii finansowych.
Biorąc pod uwagę charakter webhooków produkcyjnych, wprowadzają one znaczną złożoność w obsłudze ruchu webhooków produkcyjnych, na przykład:
- Mogą one zostać dostarczone dopiero po przetworzeniu ich działań.
- Mogą przybyć wielokrotnie.
- Mogą one zostać dostarczone w innej kolejności niż ta, w której zostały wygenerowane.
- Dostawcy mogą wysyłać je wielokrotnie.
- Należy dokonać weryfikacji podpisu wydarzenia.
- Systemy downstream mogą być tymczasowo niedostępne.
- Środowiska piaskownicy mogą zachowywać się/działać inaczej niż środowiska produkcyjne.
Słabości w projektowaniu webhooków mogą prowadzić do duplikowania działań, zmian stanów w trakcie procesu, niespójnych sald, błędów powiadomień i trudnych problemów z rozwiązywaniem problemów podczas transakcji na żywo.
Oficjalna dokumentacja firmy Stripe dotycząca webhooków kładzie nacisk na prawidłową obsługę webhooków pod kątem bezpieczeństwa w punkcie końcowym, testowania lokalnego, oczekiwanego zachowania zdarzeń w procesie dostarczania i najlepszych praktyk przetwarzania w rzeczywistym środowisku produkcyjnym.
Jak zatem uniknąć wyżej wymienionych problemów?
Postrzegaj obsługę webhooków jako cechę niezawodności, a nie tylko kwestię hydrauliki.
Ustal dobrze zaprojektowaną metodę obsługi webhooków, upewniając się, że wykonujesz następujące czynności:
- Weryfikacja podpisu zdarzenia.
- Tworzenie elementów sterujących zapewniających idempotentność procesów.
- Przechowywanie zdarzeń w celach audytowych.
- Przetwarzanie zdarzeń w sposób umożliwiający uwzględnienie ponownych prób.
- Wdrażanie procesów biznesowych służących do przeglądania zdarzeń przepadniętych lub odrzuconych.
- Konfigurowanie monitorowania i powiadamiania.
- Jasne określenie, kto jest odpowiedzialny za transformację państwa.
- Opracowywanie przypadków testowych w celu sprawdzenia, czy duplikaty, opóźnienia i niezgodność z kolejnością nie spowodują awarii w środowisku produkcyjnym.
W fintechu, złe UX dotyczące zgody to nie tylko problem UX. Stwarza ryzyko biznesowe i operacyjne. Użytkownicy mogą zrezygnować z onboardingu, ponieważ prośba wydaje się podejrzana. Wsparcie otrzymuje zgłoszenia z pytaniem “po co to jest potrzebne?”. Zespoły ds. zgodności obawiają się, że dane użytkownika nie dowodzą wystarczająco jasno świadomej zgody. Zespoły produktowe próbują później naprawić problem, dodając dodatkowy tekst, dodatkowe pola wyboru lub wprowadzając niefortunne zmiany.
W takiej sytuacji zespoły często korzystają z pisania testów opartych na scenariuszach uwzględniających zachowania dostawców, a nie tylko z testów integracyjnych dotyczących szczęśliwego przebiegu prac. Najnowsza strategia Appricotsoft w zakresie zapewniania jakości i wydawania wersji W poście podkreślono również, dlaczego produkty fintech wymagające intensywnej integracji wymagają rygorystycznej walidacji przed udostępnieniem.
3. Słabe UX dotyczące zgody
Istnieją trzy rodzaje zgody: słabe UX dla założycieli firm, z którymi się angażują. Zgodność jest bardzo ważna. Wiele organizacji nie dostrzega, jak słabe projektowanie zgody może wpłynąć na ich zaufanie i konwersję, a także na ilość wsparcia, jakie otrzymają.
Oto kilka przykładów słabej zgody UX:
- Niejasna kopia pozwolenia
- Kopia prawna nie jest związana z żądaniem
- Łączenie uprawnień, które powinny być oddzielne
- Niejasne wyjaśnienia dotyczące udostępniania danych
- Zgoda wyrażona, ale nie objęta kontrolą wersji
- Różne doświadczenia w Internecie i na urządzeniach mobilnych
- Trudno znaleźć lub uzyskać dostęp do opcji wycofywania preferencji
Nieprawidłowe UX w zakresie zgody to nie tylko problem branży FinTech. Stanowi on ryzyko zarówno biznesowe, jak i operacyjne. Użytkownicy mogą zrezygnować z procesu rejestracji, jeśli uznają prośbę za podejrzaną. Wsparcie otrzymuje zgłoszenia typu “Po co to jest potrzebne?”. Zespoły ds. zgodności obawiają się, że w rekordzie użytkownika nie ma wystarczającego dowodu na świadomą zgodę. W takiej sytuacji zespoły produktowe zazwyczaj próbują rozwiązać problem później, dodając więcej tekstu, tworząc dodatkowe pola wyboru lub powtarzając produkt w nieudolny sposób.
Aby rozwinąć silne doświadczenie użytkownika FinTech i zbudować zaufanie użytkowników, UX wyrażania zgody musi być jasny i dostosowany do potrzeb konsumenta.
Co można zrobić, aby uniknąć negatywnych skutków zgód użytkowników?
- Uwzględniaj zgodę jako część całego procesu i doświadczenia klienta, a nie tylko część dokumentów prawnych.
- Napisz proste i łatwe do zrozumienia opisy zgód, które mają zostać udzielone użytkownikom.
- Połącz cel zgody z wartością, jaką przedstawia ona dla klientów.
- Podziel uprawnienia na kilka celów, dla których wyrażasz zgodę.
- Przechowuj wyświetlane rekordy zgód, aby zapewnić kontrolę wersji.
Dobrym standardem jest to, że rozsądny użytkownik mógłby wyjaśnić prostym językiem, na co się zgodził i dlaczego? Jeśli nie, projekt nie jest gotowy.
Jest to szczególnie ważne w przypadku tworzenia aplikacji mobilnych dla produktów finansowych, gdzie mniejsze ekrany potęgują niejednoznaczność. Solidne wzorce UX budują zaufanie, redukują tarcia i pomagają założycielom uniknąć niepotrzebnych strat związanych z wdrażaniem.
4. Brak logów i słaba możliwość audytu
Niektóre zespoły uważają, że rejestrowanie danych nie staje się problemem aż do późniejszego etapu, gdy ich produkt osiągnie odpowiednią skalę. Jednak w branży fintech, dobre rejestrowanie danych będzie kluczowe dla przetrwania od samego początku.
Nieprawidłowe rejestrowanie zdarzeń może być frustrujące, gdy występują problemy w aplikacji skierowanej do konsumenta. Jednak prawdopodobieństwo wystąpienia problemu operacyjnego lub związanego z zgodnością z przepisami jest znacznie większe w przypadku produktu fintech, w którym trzeba wiedzieć, czy została wywołana nieudana płatność, zmiana zgody, ponowne żądanie webhooka lub reguła ryzyka, a także mieć pewność, co się stało, kiedy się stało, kto (lub co) to spowodowało i co system zrobił w wyniku tego zdarzenia.
W przypadku braku odpowiednich dzienników zespoły będą musiały wrócić i ręcznie spróbować odtworzyć zdarzenia z wielu stron pulpitu nawigacyjnego, konsol dostawców lub niekompletnych śladów.
Arkusz informacyjny OWASP dotyczący rejestrowania jest przydatnym źródłem informacji, ponieważ podkreśla praktyczną kwestię pomijaną przez wiele zespołów: same logi infrastruktury nie wystarczą. Rejestrowanie zdarzeń na poziomie aplikacji jest niezbędne do zrozumienia działań wrażliwych pod względem bezpieczeństwa i krytycznych dla firmy.
Aby tego uniknąć, konieczne jest zdefiniowanie struktury rejestrowania i audytu przed uruchomieniem, a już na pewno przed wystąpieniem jakiegokolwiek poważniejszego incydentu.
Minimalna struktura rejestrowania powinna szczegółowo opisywać następujące zdarzenia:
- Wydarzenia uwierzytelniania i autoryzacji
- Rejestrowanie i aktualizowanie zgód
- Zmiany w cyklu życia transakcji
- Odbiory i wyniki przetwarzania webhooków
- Działania administracyjne
- Zmiany statusu wypłaty
- Szczegóły dotyczące żądania i odpowiedzi dostawcy, w stosownych przypadkach
- Stany błędów powiązane z widocznymi dla użytkownika wynikami
Ważne jest również ustalenie następujących kwestii:
- Identyfikatory korelacji
- Okresy przechowywania dostępnych dzienników
- Kontrola dostępu do logów
- Zasady maskowania dotyczące danych wrażliwych
- Proces przeglądu incydentów
Powinieneś zadać sobie następujące pytania: “Czy prowadzimy logi?”, a nie: “Czy jesteśmy w stanie szybko opisać sekwencję zdarzeń, jakie miały miejsce w związku z incydentem?”
To jeden z powodów, dla których Appricotsoft preferuje przejrzysty model dostarczania, obejmujący współdzielone artefakty, dyscyplinę w zakresie wydań i jasne kryteria gotowości. Dobre dostarczanie rozwiązań fintech to nie tylko kompletność kodu. To gotowość operacyjna.
5. Niedotrzymywanie terminów dostaw od dostawców
Zarówno start-upy, jak i ugruntowane przedsiębiorstwa cierpią, gdy błędnie oceniają terminy dostaw swoich dostawców.
Startup tworzy plan projektu, który zakłada, że integracja płatności, KYC, linkowania i wydawania kart może z łatwością mieścić się w ramach idealnego planu sprintu, a zespół programistów buduje następnie swoją “piaskownicę” wokół tych założeń. Jednak gdy po raz pierwszy napotkasz cykl weryfikacji dostawców, wymogi prawne, zatwierdzenie dostępu do produkcji, zmiany w wymaganiach API, brak dokumentacji oraz ograniczenia regionalne, zależności związane z onboardingiem lub odpowiedzi na pytania dotyczące zgodności, które wykraczały poza budżet, data wydania zostanie przekroczona, mimo że zespół “wykonał pracę”.”
Szczerze mówiąc, to się zdarza non stop – taka jest natura prowadzenia biznesu w branży technologii finansowych. Ponieważ harmonogramy dostawców często pozostają poza Twoją bezpośrednią kontrolą, szczególnie ważne jest uwzględnienie tego na etapie planowania.
The Appricotsoft Plan działania Fintech / Oś czasu Posty odzwierciedlają powyższe realia; czas potrzebny na dostarczenie zależy od zakresu kodowania, ale także od integracji, głębokości zapewnienia jakości, ilości pracy związanej z zapewnieniem zgodności i konieczności uzyskania zatwierdzeń od zewnętrznych dostawców.
Jak uniknąć tego błędu
Już od pierwszego dnia planu projektu uwzględnij niepewność związaną z dostawą usług przez dostawców.
Aby wprowadzić to w życie, możesz wprowadzić kilka usprawnień:
- Weryfikacja wymagań dotyczących wdrażania dostawców w trakcie procesu odkrywania.
- Już na wczesnym etapie należy zidentyfikować różnice między środowiskiem testowym a produkcyjnym.
- Udokumentuj zależności dla każdego dostawcy.
- Przygotuj rozwiązania awaryjne.
- Pracuj nad zadaniami rozwojowymi w określonej kolejności, aby mieć pewność, że żadne zadanie nie zatrzyma postępu całego projektu.
- Prowadź rejestr ryzyka, w którym będziesz wymieniać wszystkie ryzyka związane z dostawcami zewnętrznymi.
- Przeglądaj status każdego dostawcy na cotygodniowych spotkaniach poświęconych aktualizacji statusu projektu.
W naszym Unison Framework ryzyka, decyzje, zmiany zakresu i cotygodniowe demonstracje istnieją właśnie po to, aby uczynić dostawę bardziej przewidywalną dla klientów. Zespoły nie powinny przypadkowo odkrywać blokad na późnym etapie. Powinny je dostrzegać na wczesnym etapie, rozumieć kompromisy i spokojnie dostosowywać się do zmian.
Prosta lista kontrolna działań zapobiegawczych dla założycieli firm fintech i liderów produktów
Krótka lista kontrolna dla założycieli i managerów produktów FinTech, którzy chcą zaoszczędzić pieniądze, popełniając mniej błędów w rozwoju oprogramowania FinTech.
Zanim przejdziesz do dalszych etapów budowy, zadaj sobie te proste pytania.
Produkt i proces:
- Czy udokumentowałem wystarczająco dużo zasad dotyczących transakcji i rejestru, aby móc przetestować scenariusze brzegowe?
- Czy moje zespoły ds. produktu, inżynierii i zapewnienia jakości mają taki sam przepływ środków pieniężnych?
Integracja:
- Czy mam mapę zależności moich dostawców i kroków ich wdrażania oraz wiem, które z tych kroków mogą wiązać się z ryzykiem zatwierdzenia produkcji?
- Czy projektując web-hooki, wziąłem pod uwagę scenariusze duplikacji, opóźnień, ponawiania prób i awarii?
Zaufanie i zgodność:
- Czy mój interfejs użytkownika dotyczący zgody będzie zrozumiały dla osoby, która nie ma z nami żadnego doświadczenia?
- Czy mogę udowodnić, na co użytkownik wyraził zgodę, kiedy i na podstawie jakiej wersji?
Operacje:
- Czy posiadam rejestry wszystkich najważniejszych działań finansowych i działań użytkowników?
- Czy mój zespół wsparcia i inżynierii może zbadać incydent bez zgadywania?
Dostawa:
- Czy wszystkie ryzyka są widoczne co tydzień?
- Czy zapisujemy decyzje, czy też wszystko pozostaje w wątku na czacie lub spotkaniu?
- Czy potwierdzamy postępy udostępniając działającą wersję demonstracyjną zamiast po prostu informować o stanie prac?
Możesz uznać, że niektóre z tych pytań są stosunkowo proste. Taki jest mój zamiar. Poważne błędy w FinTech wynikają z pomijania podstaw i nieujawniania ich.
W jaki sposób Appricotsoft to robi poza innowacjami
Dążymy do tego, by być wzorem dla świetnego rozwoju oprogramowania: uczciwego, odpowiedzialnego, wysokiej jakości i praktycznego. Z pasją tworzymy oprogramowanie, z którego jesteśmy dumni, co oznacza minimalizowanie ryzyka dla naszych klientów, bez chowania się za technicznym żargonem i zawiłościami.
W przypadku aplikacji fintech oznacza to styl realizacji, który pozwoli założycielom i kadrze zarządzającej na efektywną współpracę, zapewniając:
- Jasna definicja tego, co zostanie zbudowane, zanim rozpoczniemy budowę.
- Widoczne kompromisy przy podejmowaniu decyzji dotyczących funkcjonalności i użyteczności.
- Tygodniowe pokazy działającego oprogramowania w trakcie jego rozwoju.
- Kontrola zakresu bez dramatów; brak niespodzianek przy dostawie.
- Dokumentowanie wszystkich decyzji i ryzyka związanego z każdą decyzją.
- Standardy jakości są uwzględniane w naszej codziennej pracy, a nie odkładane na tydzień przed premierą.
Nasze unikalne podejście do realizacji projektów jest szczególnie przydatne w branży fintech, gdzie koszty niejasności mogą być bardzo wysokie. Skutki niedopełnienia obowiązku regulacyjnego, niewystarczających założeń integracyjnych lub niewłaściwie obsłużonych przypadków brzegowych mogą mieć konsekwencje wykraczające poza pojedynczy sprint.
Jeśli oceniasz potencjalnych partnerów, Blog Appricotsoft na temat wyboru odpowiedniego fintechu partner jest również dobrym źródłem informacji, ponieważ kładzie nacisk na jakość samej realizacji, a nie tylko na prezentacje sprzedażowe.
Wniosek
Podsumowując, aplikacje FinTech nie generują zbyt dużego wpływu finansowego wyłącznie ze względu na zawiłości regulacyjne lub nieustanne dążenie do terminów. Mają one jednak wpływ finansowy, gdy zespoły projektowe przez długi czas pozostają niejasne co do konkretnych aspektów.
Niewłaściwe zdefiniowanie źródła prawdy, nieudolne zarządzanie webhookami, słabe doświadczenie użytkownika w zakresie zarządzania zgodami, słabe procesy rejestrowania i nierealistyczne oczekiwania dostawców skutkują nieprzyjemnymi niespodziankami w projektach związanych z tworzeniem oprogramowania, ale można i należy ich unikać.
Zazwyczaj zespoły projektowe, które potrafią unikać tych i innych pułapek, to nie te, które zapewniają najbardziej efektowne demo, lecz te, które wdrożyły szczegółowe procesy definiowania, testują rzeczywiste zachowania użytkowników, dokładnie dokumentują procesy decyzyjne i identyfikują WSZYSTKIE ryzyka, zanim przekształcą się one w przeróbki.
Appricotsoft uznaje to za swoją podstawową filozofię. Tak, działaj szybko, ale w sposób, który zapewnia zaufanie interesariuszy, identyfikowalność oraz budżet, harmonogram i jakość (zgodnie z Twoją inwestycją finansową).
