Wstęp
Na czym polegają studia przypadku skutecznej firmy zajmującej się tworzeniem oprogramowania fintech?
Jeśli rozważasz zatrudnienie dostawcy usług rozwoju oprogramowania fintech, z pewnością natkniesz się na mnóstwo “studiów przypadku” od dostawców usług rozwoju oprogramowania fintech, którzy twierdzą, że wykonali następującą prośbę o zlecenie w oparciu o rzekomy szum informacyjny:
- “Opracowaliśmy aplikację bankowości mobilnej.”
- “Stworzyliśmy przyjazne dla użytkownika funkcje dzięki ulepszeniom UX.”
- “Spełniliśmy oczekiwania klienta.”
Wszystkie te pytania są dobre i piękne, ale nie pomagają założycielowi firmy ani dyrektorowi naczelnemu odpowiedzieć na najważniejsze pytania:
- Czy ten dostawca spełni kryteria narzucone przez surową kontrolę fintech?
- Czy jednak będzie to niezawodny, bezpieczny i zgodny z przepisami dostawca, który zapewni możliwość uzyskania obiektywnych informacji na temat skuteczności swoich aplikacji?
- I wreszcie, czy mierzą sukces na podstawie wyników, czy tylko na podstawie ukończenia zadania związanego z dostarczeniem funkcji?
Dlatego w obszarze usług rozwoju oprogramowania fintech skuteczne studium przypadku służy jako: dowody potwierdzające proces myślowy przyjęty przez zespół programistów, przykłady poziomu podejmowanego ryzyka podczas opracowywania aplikacji oraz to, czy zespół programistów jest w stanie osiągnąć poziom mierzalnego sukcesu, jednocześnie spełniając wszystkie ograniczenia narzucone przez ‘realny świat’ (kontrole bezpieczeństwa/zgodność/integracje/audyty/umowy o poziomie usług/czas).
W tym artykule przedstawimy przegląd tego, co powinno zawierać skuteczne studium przypadku usługi rozwoju oprogramowania fintech, a także ogólny zarys tego, co można przekazać potencjalnym dostawcom do wykorzystania jako szablon do ponownego wykorzystania (umożliwiający założycielowi – z ograniczoną wiedzą techniczną – w bardzo krótkim czasie ocenić, jak skuteczny jest dostawca usług rozwoju oprogramowania fintech).
Dlaczego studia przypadków fintech muszą spełniać wyższe standardy?
Produkty FinTech nie istnieją w środowisku, w którym “działamy szybko i psujemy rzeczy”. Produkty FinTech są oferowane zgodnie z następującym zestawem wymagań:
- Weryfikacja tożsamości i trudności z wdrożeniem (KYC/AML)
- Udogodnienia płatnicze i bardzo rygorystyczne umowy i porozumienia integracyjne
- Zagrożenia operacyjne i gotowość do zarządzania incydentami
- Wysoki poziom bezpiecznej kontroli dostępu (szczególnie w lokalizacjach regulowanych)
- Wysoki poziom potwierdzenia bezpieczeństwa, który może być powiązany ze standardami [OWASP ASVS].
Gdy usługodawca/dostawca przedstawia Ci “studium przypadku”, analiza, którą wykonujesz, obejmuje coś więcej niż tylko ocenę projektu produktu, ponieważ bada on zdolność firmy do dostarczania bezpiecznych, przewidywalnych i mierzalnych produktów w realiach technologii finansowych.
Skuteczne studium przypadku powinno odpowiadać na następujące trzy pytania ewaluacyjne:
- Czy stworzą odpowiedni produkt? (zrozumienie produktu/domeny)
- Czy zbudują produkt prawidłowo? (bezpieczeństwo/zgodność/jakość)
- Czy stworzą produkt o niezawodnych wynikach? (Metoda dostarczania wartości, rejestr zakupów wartości, wskaźniki wolumenu sprzedaży).
Co powinno zawierać wartościowe studium przypadku fintech
Oto kilka rzeczy, które warto sprawdzić, oceniając studium przypadku firmy zajmującej się tworzeniem aplikacji fintech. Brak wielu z tych elementów zazwyczaj jest sygnałem ostrzegawczym.
1. Jasno określ problem, a nie tylko rozwiązanie.
Dobre studium przypadku powinno zaczynać się od jasnego opisu problemu biznesowego:
- Kim jest klient? (bank, dostawca usług płatniczych, start-up fintech, rynek z płatnościami itp.)
- Które elementy ścieżki użytkownika zostały przerwane lub brakowało ich w trakcie realizacji?
- Jakie KPI lub problemy operacyjne były przyczyną tego projektu?
Mocne przykłady:
- “Podczas rejestracji klient odnotował spadek liczby danych 62% z powodu ręcznego procesu KYC, który wymagał od klientów wielokrotnego wprowadzania tych samych danych”.”
- “Klient odnotował wzrost obciążeń zwrotnych o 28% po rozszerzeniu działalności na nowy obszar”.”
- “Klient potrzebował 2–3 dni na uzgadnianie rozliczeń, korzystając w tym celu z arkuszy kalkulacyjnych programu Excel”.”
Słabe przykłady:
- “Klient potrzebował aplikacji.”
- “Klient potrzebował portfela cyfrowego”.”
Jeśli studium przypadku firmy fintec nie przedstawia jasno problemu, dostawca prawdopodobnie nie jest odpowiedzialny za problem lub nie dokonał jego pomiaru.
2. Kontekst i ograniczenia (część, którą większość dostawców ukrywa)
To obszar, w którym pojawia się “prawdziwy świat”. Prawdziwe studium przypadku zawiera informacje dotyczące ograniczeń działania fintechu; ograniczenia te zawierają następujące informacje:
- Regulacje/zgodność: Obejmuje to wymogi regulacyjne, w tym zalecane zmiany w przepisach PSD2 (takie jak przechowywanie danych i gotowość do audytu).
- Bezpieczeństwo: Ogólne wymagania bezpieczeństwa (model zagrożeń, podejście do uwierzytelniania, wymagania dotyczące szyfrowania, wymagania dotyczące weryfikacji, tj. standardy ASVS)
- Integracja: Środowisko integracyjne obejmuje podstawowe systemy bankowe, bramki płatnicze, przetwarzanie kart, dostawców usług KYB/KYC i narzędzia do wykrywania oszustw.
- Chronometraż: Harmonogram obejmuje ustalone daty uruchomienia, terminy dla inwestorów oraz terminy migracji.
- Problemy z dziedzictwem/dziedzictwem: Do problemów starszych systemów należą monolityczne rozwiązania, niestabilne interfejsy API i brak dokumentacji.
- Operacyjny: Wymagania operacyjne obejmują całodobową pomoc techniczną, umowy SLA, dyżury i podręczniki dotyczące incydentów.
W tym miejscu można sprawdzić, czy faktycznie wprowadzili na rynek produkt w obszarze technologii finansowych, gdyż w branży technologii finansowych dominują ograniczenia na nią nałożone.
3. Strategia (jak podjęto decyzje)
Podejmuj decyzje w oparciu o historię, a nie tylko pracę.
Dobre studium przypadku opisuje:
- W jaki sposób prowadzono prace odkrywcze (np. warsztaty, przepływy użytkowników, rejestry ryzyka, zaległości)
- Na czym się skupili i jakie było uzasadnienie tego wyboru.
- Kiedy widzisz, że pojawiają się kompromisy decyzyjne (zakres, czas, ryzyko).
Jeśli szukasz przykładu, jak powinien wyglądać dobry proces odkrywania, zamieściliśmy dwa wpisy w naszym hhistoryf, którymi często dzielą się wewnętrznie zarówno założyciele, jak i kierownicy ds. produktów. Należą do nich:
Sprzedawca, który nie potrafi przedstawić kompromisu, najprawdopodobniej po prostu zareaguje.
4. Architektura (nie jest szczegółowo opisana – ale wystarczająco szczegółowa, by jej nie pomijać)
W ogólnodostępnym studium przypadku nie potrzeba 30-stronicowego obrazu, ale musi ono zostać przedstawione w sposób pokazujący, że zespół rozumiał architekturę na poziomie technologii finansowych.
Do stworzenia solidnego studium przypadku potrzebujemy:
- schemat systemu wysokiego poziomu (nawet prosty)
- granice danych (dane osobowe, dane finansowe, logi)
- Kluczowe usługi/moduły (uwierzytelnianie, księga/portfel, płatności, powiadomienia, administracja, raportowanie)
- Punkty integracji i strategia niezawodności (ponowne próby, idempotentność, kolejki)
Punkty bonusowe jeśli to wyjaśnia:
- Jak podeszli do śladów audytu i raportowania
- Jak radzili sobie z obszarami wysokiego ryzyka (inicjowanie płatności, zwroty, obciążenia zwrotne)
- Co zrobili w celu zapewnienia możliwości obserwacji (logi, metryki, alerty)
Jeśli w studium przypadku pada słowo ‘mikrousługi’, nie podając jednak jego granic ani znaczenia, należy to uznać za architekturę-modne słowo.
5. Kwestie bezpieczeństwa i zgodności z przepisami, którymi kieruje się dostawca technologii finansowych, nie podlegają negocjacjom.
Studium przypadku szczegółowo przedstawiające, w jaki sposób dostawca wdraża podstawowe praktyki bezpiecznej dostawy, powinno obejmować:
- Modelowanie zagrożeń/przegląd ryzyka
- Przeglądy kodu i kontrole CI
- Skanowanie zależności/zarządzanie sekretami
- Strategia testowania (jednostkowa, integracyjna i regresyjna)
- Pętla gotowości/naprawy testów penetracyjnych
- Podstawowe procedury reagowania na incydenty
Aby zapewnić punkt odniesienia dla pojęcia „wystarczające bezpieczeństwo”, w branży powszechnie stosuje się cieszącą się uznaniem strukturę weryfikacji aplikacji i usług sieciowych o nazwie OWASP ASVS.
Aby organizacje mogły działać zgodnie z oczekiwaniami bezpieczeństwa PSD2 (obejmującymi uwierzytelnianie wieloskładnikowe) w zakresie transakcji płatniczych realizowanych w UE, muszą one spełniać te oczekiwania przy podejmowaniu decyzji biznesowych.
Aby uzyskać więcej informacji o tym, jak wdrażamy bezpieczne SDLC w obszarze Fintech Delivery, przeczytaj: Bezpieczeństwo w projektowaniu: Jak prawidłowo tworzyć aplikacje Fintech.
6. Wyniki mierzalne (liczby, nie terminy opisowe)
W tym miejscu większość opcji “Studium przypadku” okazuje się niewystarczająca.
Dobre studium przypadku ma jasno określony wynik przedstawiony w formacie „przed i po” oraz łączy go z pierwotnym problemem. Przykłady studiów przypadku obejmują:
Wyniki z produktów
- % Zakończenie wdrażania: 38% → 61%
- Czas do pierwszej transakcji: 2 dni → 20 minut
- % Aktywni użytkownicy miesięcznie przez wszystkie 3 miesiące: +24%
Wyniki operacyjne
- Czas ręcznego uzgadniania: 2 dni → 2 godziny
- Bilety pomocy technicznej co 1000 użytkowników: -35% (mniej niż 1/10)
- Średni czas naprawy (MTTR) dla wszystkich incydentów: 90 minut → 25 minut
Wyniki z Bezpieczeństwa/Ryzyka
- Wysokie lub krytyczne wyniki podatności po teście penetracyjnym: 17 → 3
- Współczynnik oszustw jako % wolumenu transakcji: -18%
- Współczynnik obciążeń zwrotnych jest niższy niż próg docelowy
Jeśli nie możesz zmierzyć swoich rezultatów, zapytaj, co zmierzyłeś podczas dostarczania zasobów. Jeśli jedyną odpowiedzią jest to, że zmierzyłeś prędkość, to nie jesteś jeszcze dojrzałym fintechem.
7. Czego można się nauczyć (dowód dojrzałości)
Najlepsze przykłady z nauki znajdują przykłady, które nie były idealne lub mogłyby być, i wprowadzają zmiany w wyniku tego, co poszło nie tak.
- np. “Nie przeprowadziliśmy wystarczającej ilości testów w środowisku testowym dostawcy, więc teraz przeprowadzamy testy kontraktowe i korzystamy ze środowiska przejściowego”.”
- np. “pierwsza wersja procesu KYC miała zbyt wiele etapów i zbyt duże tarcia, więc udoskonaliliśmy proces i dodaliśmy stopniowe ujawnianie informacji”.”
- np. dowiedzieliśmy się, że proces obsługi zwrotów miał przypadki skrajne; dlatego dodaliśmy do procesu klucze idempotentności i kontrole uzgadniania”.”
Dostawca, który udokumentował wyłącznie udane wdrożenia (zwycięstwa), albo nie jest szczery, opisując swoje rzeczywiste doświadczenia jako dostawca, albo po prostu nie ma wystarczającego doświadczenia w tej roli, aby udokumentować jakiekolwiek niepowodzenia.
Czerwone flagi: “studia przypadków”, które powinny obniżyć poziom Twojego zaufania
Jeśli przeglądając stronę internetową sprzedawcy zauważysz poniższe sygnały, potraktuj je jako sygnały ostrzegawcze:
- Brak ograniczeń (brak wzmianki o zgodności z przepisami, brak wzmianki o bezpieczeństwie, brak wzmianki o jakiejkolwiek integracji, brak wzmianki o audycie).
- Brak podanych numerów (tylko “ulepszyli”; “zoptymalizowali”; “usprawnili”).
- Brak wyjaśnień dotyczących rozróżnienia ról (czy wykonali pełną wersję od początku do końca, czy tylko dostarczyli oprogramowanie programistom?).
- Brak harmonogramu dla żadnego z elementów dostarczalnych – ile czasu zajęło wykonanie każdego z zadań i dlaczego?
- Zrzut ekranu stockowegoktóre nie mówią nic na temat głębi samego produktu
- Niejasny stos technologiczny, który nie ma uzasadnienia:jak będzie wykorzystywana architektura
Jak postrzegamy studia przypadków w Appricotsoft
Appricotsoft uważa studia przypadków za ważne elementy służące prezentacji oprogramowania, które stworzyliśmy, jednocześnie uczciwie opisując sposób jego powstawania.
Poddajemy bardzo szczegółowe badania temu, co uważamy za studium przypadku.
Studium przypadku to nie trofeum; to artefakt uczenia się i sposób na budowanie zaufania potencjalnych klientów. Zdając sobie z tego sprawę, preferujemy, aby nasze studia przypadku ukazywały następujące kluczowe obszary:
- Widoczny rytm dostaw (cotygodniowe pokazy pokazujące postęp prac i ich faktyczne ukończenie).
- Pojedyncze źródło prawdy umożliwiające komunikację wszystkich decyzji, ryzyk, zmian zakresu i list kontrolnych wydań.
- Wykorzystanie sztucznej inteligencji w połączeniu z odpowiedzialnością człowieka w celu realizacji zadań projektowych (wierzymy, że DKB będzie pomagać i wspierać pracę, ale że każdy z pracowników pozostaje odpowiedzialny za końcowy produkt pracy).
Ten trzeci punkt jest również kluczowym elementem naszego Unison Framework (sztuczna inteligencja pomaga w realizacji projektu, ale odpowiedzialność za wynik spoczywa na jednostce), szczególnie w odniesieniu do zakresu, projektu, bezpieczeństwa i zobowiązań umownych.
Dotyczy to również wartości wyznawanych przez Appricotsoft:
- Zachowaj realizm (bez dramatów, bez spekulacji, bez wygórowanych oczekiwań).
- Uczyń to niesamowitym (ocena jakości nie jest odkładana na czas po zakończeniu projektu.)
- Posiadaj to (osiąganie wyników powinno być przewidywalne i przejrzyste).
Jeśli jesteś założycielem i dokonujesz oceny dostawców, nie powinieneś oczekiwać perfekcji, ale raczej przejrzystości wyników ich pracy, tak jak to przedstawiono w studium przypadku.
Często zadawane pytania dotyczące wyboru dostawcy
Czy studia przypadków są konieczne przy wyborze dostawcy?
Zdecydowanie tak, jeśli chodzi o technologie finansowe, ponieważ stanowią one najlepszy sposób na sprawdzenie, czy dostawca rozumie wymagania stawiane mu w zakresie bezpieczeństwa, zgodności i integracji, a także w jaki sposób mierzy swój sukces (wyniki).
Co zrobić, jeśli dostawca nie może udostępnić mi studium przypadku lub szczegóły są objęte umową o poufności?
To nie jest niczym niezwykłym. Jeśli jednak nie są w stanie podać Ci szczegółów, rozważ poproszenie ich o utworzenie anonimowej wersji, która zawierałaby wszystkie z poniższych:;
- Ograniczenia, w ramach których działali (tj. bezpieczeństwo, zgodność);
- Ich platforma architektoniczna;
- Mierzalne wyniki, które osiągnęli (zakresy są w porządku);
- Lekcje, które wyciągnęli podczas skutecznego świadczenia usług.
Ile studiów przypadku poleciłbyś mi poprosić dostawcę?
Zazwyczaj dostawca powinien być w stanie przedstawić Ci PRZYNAJMNIEJ DWA studia przypadków. Jedno powinno dotyczyć innego dostawcy, który otrzymał produkt podobny do tego, który oceniasz, a drugie powinno być opracowane w podobnych warunkach, wykraczając poza te warunki i przechodząc do innej typologii dostawcy (np. bank kontra portfel).
Szybka wskazówka
Udane studium przypadku fintech to nie tylko atrakcyjny kawałek papieru; to dowód na to, że potrafisz skutecznie realizować projekty pomimo ograniczonych zasobów (czasu, budżetu itp.).
Jeśli chcesz zapamiętać jedną zasadę: Brak ograniczeń + brak metryk = brak wartości.
A jeśli ty‘'‘d tak jak aby dokonać porównania dostawców łatwy, wysłać na zewnątrz szablon powyżej z przejrzystość, wynik, i dojrzałości punktacja dołączony W twój ocena z ich odpowiedzi.
Jeśli obecnie jesteś na etapie wyboru partnera ds. rozwoju technologii finansowych (fintech) lub chcesz uzyskać informacje na temat bezpiecznego sposobu realizacji procesu ujawniania i dostarczania informacji, zapoznaj się z poniższymi dwoma linkami dotyczącymi naszych procesów:
