Jak pomogliśmy platformie proptech zatrzymać największego klienta

Firma proptech z Bliskiego Wschodu stała w obliczu poważnego kryzysu. Z organizacji właśnie odchodził CTO, a jej produkt – platforma obsługująca czynsze, rozliczenia i opłaty eksploatacyjne w setkach budynków – borykał się z ciągłymi przerwami w działaniu. Dodatkowo, audyty finansowe, które należało zamykać w lutym, przeciągały się aż do września, grożąc firmie karami ze strony organów nadzoru. W efekcie tych narastających problemów, jej największy klient (duża firma zarządzająca nieruchomościami dla dziesiątek tysięcy najemców) tracił cierpliwość i groził odejściem.

Na pierwszy rzut oka problemy wydawały się niezwiązane: odchodzący CTO, regularne przerwy w działaniu systemu, niedotrzymane terminy, zespół bez procesów. Były to jednak objawy jednego błędu systemowego. Cały dział inżynierii opierał się wyłącznie na jednej osobie. Nikt nie zbudował procesów, standardów ani struktury, które pozwoliłyby zespołowi funkcjonować po odejściu CTO. To nie była wina jednego człowieka. Zawiodła cała kultura zarządzania, oparta na unikaniu trudnych decyzji i wymuszaniu wyników presją.

Nasz były klient, Kitopi, polecił CEO tej firmy usługi Pragmatic Coders. Rozmawialiśmy w środę. W sobotę byliśmy już w samolocie na Bliski Wschód, aby poprowadzić warsztaty na miejscu. To, co zastaliśmy, okazało się poważniejsze, niż zakładaliśmy.

Wyzwania

Po stronie klienta

Odejście CTO nie było przyczyną tych problemów. Ujawniło ono lata dysfunkcji systemowych, które jego obecność maskowała. Firma funkcjonowała w modelu, w którym jedna osoba brała na siebie każdą decyzję techniczną. Kiedy jej zabrakło, braki stały się widoczne:

• Brak procesów. Brak systemu zarządzania zadaniami, brak dokumentacji wymagań, brak ustrukturyzowanej komunikacji między działem technicznym a biznesem. Zadania były dosłownie przypisywane jako komentarze w kodzie źródłowym. Rok po odejściu CTO nadal znajdowaliśmy w bazie kodu jego adnotacje mówiące programistom, co i gdzie mają zrobić.
• Chaos w wymaganiach. Brakowało procesu analizy i zbierania wymagań. Funkcjonalności powstawały arbitralnie, w oderwaniu od rzeczywistych potrzeb użytkowników. Klienci nie korzystali z dużych części aplikacji, ponieważ jej obsługa była zbyt skomplikowana. Aplikacja stawała się coraz trudniejsza w użyciu, podczas gdy potrzebowała radykalnego uproszczenia.
• Niestabilność systemu. Regularnie dochodziło do przerw w działaniu aplikacji. Cały system stawał się niedostępny, co paraliżowało zarządzanie wieloma nieruchomościami i odcinało dostęp tysiącom użytkowników końcowych.
• Presja ze strony inwestorów i regulatorów. Opóźnienia w audytach finansowych groziły karami, a połączone z niedostępnością systemu i nagłym odejściem CTO stworzyły sytuację kryzysową. Inwestorzy firmy domagali się natychmiastowego ustabilizowania platformy i powrotu do terminowego raportowania.
• Utrata wiedzy o projekcie. Wysoka rotacja w poprzednich latach sprawiła, że duża część kodu źródłowego została napisana przez programistów, których już nie było w firmie. Większość obecnego zespołu pracowała w niej zaledwie od roku do dwóch lat. Kluczowa wiedza o działaniu systemu odeszła razem z byłymi pracownikami.

Po naszej stronie

Sytuacja na miejscu okazała się gorsza, niż wynikało ze wstępnych ustaleń. Spędziliśmy tydzień na warsztatach z dwoma programistami i odchodzącym CTO. System miał znacznie więcej funkcji, niż ktokolwiek wcześniej komunikował. Nawet programiści klienta spierali się między sobą o to, jak konkretne funkcje powinny działać.

• Brak testów automatycznych. Zespół klienta podjął w przeszłości próbę ich wprowadzenia, ale zrobiono to nieumiejętnie i ostatecznie testy nie weszły do użycia.
• Brak dokumentacji. Ktoś próbował wygenerować dokumentację za pomocą wczesnych narzędzi AI, tworząc 70-stronicowy plik PDF, który okazał się całkowicie bezużyteczny.
• Nieczytelny kod źródłowy. Był to efekt wspomnianej wcześniej rotacji pracowników. Nie dało się z niego wywnioskować, dlaczego w przeszłości podejmowano takie, a nie inne decyzje techniczne.
• Niedoświadczony zespół. Większość programistów miała zaledwie trzy lub cztery lata ogólnego doświadczenia w branży. Najbardziej doświadczeni członkowie zespołu znali domenę biznesową, ale brakowało im warsztatu inżynieryjnego.
• Zderzenie kultur. Zespół był przyzwyczajony do mikrozarządzania – CTO mówił im dokładnie, co i jak mają robić. Zmiana tego modelu na taki, w którym programiści sami biorą odpowiedzialność za zadania, wywołała naturalny opór. Dla nich byliśmy ludźmi z zewnątrz, którzy narzucają rygorystyczne i nieznane im wcześniej procesy. Z naszej perspektywy zespół musiał po prostu nauczyć się podstawowej dyscypliny pracy. Przełamanie tej bariery wymagało czasu i wypracowania kompromisu, na który ostatecznie obie strony musiały się otworzyć.
• Opór przed zmianami technicznymi. Część programistów uważała, że system ma dobre fundamenty, a problemem są jedynie zaległe błędy. Jak to ujął jeden z nich: “Mamy dobry samochód. Po prostu w tej chwili nie jeździ”. Byliśmy zupełnie innego zdania, ale żeby zmienić ich podejście, musieliśmy najpierw zdobyć zaufanie.

Nasze podejście

Działaliśmy na dwóch frontach jednocześnie: stabilizując platformę i gruntownie zmieniając sposób pracy zespołu. Wdrożyliśmy proces zbliżony do naszego standardowego, przepracowaliśmy początkowe tarcia z zespołem i nowe podejście przyjęło się stosunkowo szybko.

• Pierwsze kilka miesięcy: Wyeliminowaliśmy przerwy w działaniu systemu i przywróciliśmy terminowość audytów. Programiści przeszli od wykonywania zadań zlecanych przez CTO do aktywnego angażowania się we współpracę z biznesem w zakresie wymagań i decyzji technicznych.
• Po trzech, czterech miesiącach: Poznaliśmy system na tyle dobrze, by zarekomendować gruntowny refaktoring kodu. Klient nie był jeszcze gotowy na taką inwestycję, więc skupiliśmy się na tym, co mogliśmy kontrolować. Od teraz cały nowy kod powstawał zgodnie z dobrymi praktykami programistycznymi. Uporządkowaliśmy również jeden kluczowy moduł systemu i uczyniliśmy go punktem odniesienia dla reszty aplikacji. Napisaliśmy dla niego testy automatyczne i wykorzystaliśmy go do weryfikacji logiki biznesowej. Stary kod pozostał bez zmian, ale zatrzymaliśmy lawinowe narastanie nowych problemów.
• Po około roku: Jeden z naszych ekspertów zaczął nieformalnie pełnić rolę lidera technicznego w zespole klienta. Z czasem przerodziło się to w oficjalne stanowisko Dyrektora ds. Technicznych (Head of Engineering).
• Po dwóch latach: Pomogliśmy firmie zatrudnić nowego Dyrektora ds. Technicznych, który przejął stery nad zespołem po naszym ekspercie. Pierwotnie celem było znalezienie nowego CTO, ale z czasem stało się jasne, że to właśnie lider skupiony na procesach i zarządzaniu zespołem technicznym był tym, czego firma faktycznie potrzebowała.

Rezultaty

Dla klienta

Platforma ustabilizowała się w ciągu kilku miesięcy. Głębsza transformacja trwała dwa lata. Oto, co się zmieniło:

• Koniec przerw w działaniu systemu. System, który wcześniej był regularnie niedostępny, teraz działał niezawodnie, zapewniając płynne zarządzanie setkami nieruchomości.
• Skrócenie czasu trwania audytów finansowych. Audyty, które w poprzednich latach ciągnęły się aż do września, udało się zamknąć już w kwietniu. Dzięki temu firma w dużej mierze uniknęła kar finansowych ze strony organów nadzoru.
• Od widma upadku do dynamicznego wzrostu. Gdy zaczynaliśmy, główny klient firmy groził odejściem, co wiązałoby się z utratą około 80% przychodów. Ustabilizowanie platformy zażegnało ten kryzys. W trakcie naszej współpracy biznes urósł o około 40% pod względem liczby zarządzanych budynków.
• Stałe kierownictwo techniczne i samodzielny zespół. Firma zyskała dedykowanego Dyrektora ds. Technicznych. Programiści, którzy kiedyś czekali na instrukcje, przejęli odpowiedzialność za decyzje techniczne i tworzyli kod zgodnie ze spójnymi standardami.

Czego się nauczyliśmy

Dwa lata pracy przy ratowaniu projektu nauczyły nas kilku rzeczy, których nie moglibyśmy się dowiedzieć w żaden inny sposób.

• Elastyczność w podejściu, bezkompromisowość w fundamentach. Nie mogliśmy wdrożyć naszego procesu 1:1 w organizacji, która wcześniej nie miała żadnych standardów pracy. Dopasowaliśmy go do panującej tam kultury, ale nie zrezygnowaliśmy z dobrych praktyk programistycznych. Konsekwentne przełamywanie początkowego oporu zespołu okazało się właściwą decyzją.
• Brak wiedzy to nie zawsze brak kompetencji. Rozpoczynając współpracę, założyliśmy, że zespół zna ogólnopojęte “standardy tworzenia oprogramowania”. Szybko okazało się, że z większością z nich programiści klienta nigdy nie mieli styczności. Zrozumienie, że wynika to z braku odpowiedniego wdrożenia w przeszłości, a nie z braku umiejętności, całkowicie zmieniło nasz sposób komunikacji i pozytywnie wpłynęło na tempo pracy zespołu.
• Zatrzymaj krwotok, zanim zaczniesz operować. W każdym ratowanym projekcie kusi, aby zaorać stary kod i zbudować wszystko od nowa. Zamiast tego, w pierwszej kolejności zgasiliśmy pożary – ustabilizowaliśmy platformę i uporządkowaliśmy procesy pracy zespołu. Dopiero na tych fundamentach mogliśmy planować głębsze zmiany architektoniczne.
• Zdobywaj zaufanie przez transparentność i namacalne efekty. Klient dopiero co rozstał się ze swoim CTO po miesiącach trudnych negocjacji. Konsekwentne prezentowanie działających rozwiązań dawało mu znacznie większe poczucie bezpieczeństwa niż jakiekolwiek zapewnienia słowne.
• Zacznij od jednego, pewnego punktu odniesienia. Nawet po dwóch latach naszej pracy 70% kodu źródłowego nadal stanowił stary kod (legacy). Zamiast próbować naprawić wszystko naraz, najpierw uporządkowaliśmy jeden kluczowy moduł i uczyniliśmy go wzorem dla reszty systemu. Oskryptowaliśmy go testami automatycznymi i wykorzystaliśmy do weryfikacji logiki biznesowej. Dało nam to dwie rzeczy: po pierwsze, namacalny przykład tego, jak powinien wyglądać dobry kod; po drugie, solidny fundament, który przyspieszył wszystkie późniejsze prace programistyczne. Pełny refaktoring odbywa się teraz, w ramach nowego etapu współpracy zbudowanego właśnie na tych podstawach.

Podsumowanie

Firma proptech była o krok od utraty swojego największego klienta. Platforma po prostu nie radziła sobie z obsługą kluczowych procesów biznesowych. Dzięki rekomendacji klient trafił do Pragmatic Coders, a my spędziliśmy kolejne dwa lata, przebudowując jego dział techniczny od wewnątrz.

Ustabilizowaliśmy platformę, a biznes zanotował solidny wzrost. Zespół przestał być biernym wykonawcą poleceń i – pod nowym, kompetentnym przywództwem – zaczął samodzielnie brać odpowiedzialność za decyzje techniczne. Na tym właśnie polega skuteczne ratowanie projektów IT.