3 powszechne błędne przekonania założycieli fintechów na temat zespołów inżynieryjnych

Przez ostatnie 10 lat zarządzałem zespołami inżynieryjnymi dla projektów fintech i ciągle widzę te same schematy. Nietechniczni założyciele przychodzą z konkretnymi założeniami na temat funkcjonowania tworzenia oprogramowania – założeniami, które mają sens w innych branżach, ale tworzą poważne wyzwania w naszej.

Pozwól, że podzielę się trzema największymi błędnymi przekonaniami, z którymi się spotykam, dlaczego są ważne i co możesz z nimi zrobić.

Błędne przekonanie #1: Planowanie oprogramowania jest jak planowanie budowy

Kiedy budujesz dom, kładziesz fundamenty, następnie budujesz konstrukcję, a na końcu wykańczasz wnętrze. Tworzysz szczegółowy plan, ustalasz budżet i realizujesz. Cały proces trwa, powiedzmy, rok lub osiemnaście miesięcy. Ale inżynieria oprogramowania działa inaczej.

Podczas tworzenia produktów programistycznych istnieje znacznie wyższy poziom niepewności – szczegóły, których po prostu nie możesz zaplanować i zrozumieć, dopóki faktycznie nie rozpoczniesz realizacji. Na przykład, budowa MVP zwykle zajmuje sześć miesięcy. Ale w ciągu sześciu miesięcy twoje wymagania zmieniają się z powodu rozwoju klienta, nowych spostrzeżeń od pierwszych użytkowników, nieoczekiwanych wyzwań technicznych lub zmian rynkowych. Teraz początkowy plan nie jest już aktualny i musisz zmienić koncepcję produktu lub jego funkcjonalność. 

To właśnie dlatego w tworzeniu oprogramowania istnieją frameworki Agile – pozwalają dostosowywać plany po każdej iteracji.

Dlaczego to ważne: Ma to bezpośredni wpływ na budżety. Kiedy jesteś założycielem startupu z pomysłem i prezentacją, i pozyskałeś pierwszą rundę inwestycji, oszacowanie końcowego kosztu produktu jest niezwykle trudne. Dlatego zakres pierwszej wersji powinien być jak najbardziej minimalny zarówno pod względem budżetu, jak i czasu – aby osiągnąć szybki czas wprowadzenia na rynek i utrzymać przewidywalne liczby.

Błędne przekonanie #2: Budujesz produkt raz, a potem masz spokój

Wielu założycieli fintech myśli: zainwestujemy teraz X pieniędzy, aby zbudować produkt, i to wszystko – koniec z procesami rozwoju i kosztami. Ale to nie jest realna strategia.

Twój rynek nieustannie się zmienia, twoi klienci ewoluują, a konkurenci wprowadzają innowacje – dlatego musisz stale rozwijać produkt, aby pozostać konkurencyjnym. Co więcej, nie powinieneś zapominać o podstawowej konserwacji, aby rozwiązywać błędy i wprowadzać ulepszenia. 

Istnieje również inna ważna warstwa – bezpieczeństwo. Czasami dostawcy rozwiązań przestają wspierać i aktualizować swoje produkty lub określone wersje. Oznacza to, że firma nie monitoruje już potencjalnych luk w zabezpieczeniach i nie wprowadza nowych zmian, aby zachować zgodność z wymogami bezpieczeństwa. Jeśli nie zainwestujesz czasu w aktualizację tej technologii, twoja platforma ryzykuje stanie się krytycznie podatna na ataki hakerskie.

Rozwiązanie: Zawrzyj umowę, że zespół techniczny może poświęcić 30% swojego czasu w ciągu roku na prace techniczne. Ta umowa nie może być złamana. Jeśli ją złamiesz, musisz to zrekompensować. Jeśli to zignorujeszs, dramatycznie zwiększasz ryzyko bezpieczeństwa.

Błędne przekonanie #3: Koszty rozwoju powinny pozostać niezmienne

W miarę rozwoju produktu rośnie również złożoność jego funkcjonalności i liczba zależności między różnymi częściami systemu. Ma to bezpośredni wpływ na koszty rozwoju w czasie.

Na przykład, podczas budowania pierwszej wersji produktu, stworzenie prostej funkcji logowania może zająć tydzień i kosztować około 2000 dolarów. Dwa lata później, implementacja tej samej funkcji może zająć sześć tygodni i kosztować 12000 dolarów.

Powód jest prosty: teraz musisz uwzględnić znacznie większą liczbę istniejących zależności w systemie i upewnić się, że nie zepsujesz niczego, co już działa. W miarę jak system staje się bardziej połączony, koszt na funkcję naturalnie wzrasta.

Zalecałbym również wczesne inwestowanie w inżynierów QA, którzy piszą zautomatyzowane skrypty testowe. Gdy masz dobre pokrycie, możesz poruszać się bardzo szybko bez obaw, że wszystko się rozpadnie. Jedynym wyzwaniem jest to, że może to zwiększyć koszty rozwoju o 30%.

Prawdziwy czynnik jakości produktu

Najlepsza współpraca ma miejsce, gdy założyciele traktują zespoły inżynieryjne jako partnerów i inwestują w dobre relacje. Rozumieją, że ukrytym elementem doskonałej jakości produktu i sukcesu jest motywacja zespołu. Dlatego inwestują czas w wyjaśnianie problemu, który rozwiązują, odbiorców, którym pomagają, i są transparentni w kwestii sukcesów lub porażek. 

Doceniają wysiłek i, gdy to możliwe, budują relacje nie z zespołem ogólnie, ale z każdą osobą indywidualnie. Dwa lata temu jeden z naszych klientów zorganizował konferencję dla swoich klientów i zaprosił naszych inżynierów do bezpośredniego udziału w przygotowaniu prezentacji i prezentowaniu systemu AI, który zbudowaliśmy razem. Ten prosty gest poprawił współpracę i pomógł wzmocnić zaufanie, pogłębić poczucie własności i sprawić, że wszyscy poczuli się częścią misji.

Podsumowanie

Produkty fintech nigdy nie są "zbuduj raz i zapomnij". Są to żywe systemy – pełne niepewności, ewoluujących wymagań, rosnącej złożoności i ciągłych zagrożeń bezpieczeństwa. Założyciele, którzy akceptują tę rzeczywistość, planują ciągły rozwój i traktują inżynierów jako strategicznych partnerów, budują lepsze produkty, szybciej i z dużo mniejszą liczbą niespodzianek. \n \n

\