Przejęcie istniejącego projektu IT bywa trudniejsze niż zbudowanie produktu od zera.
W przypadku IKZMED problem był jeszcze bardziej złożony. Projekt przeszedł przez kilku wykonawców, powstały dwie różne wersje aplikacji, zbliżał się termin zakończenia projektu, a produkt nadal wymagał doprowadzenia do stanu, który można było zaprezentować i obronić.
Kiedy dołączyłem do projektu, pierwszą decyzją nie było napisanie kolejnej wersji.
Najpierw trzeba było odpowiedzieć na znacznie ważniejsze pytanie:
Dwie aplikacje, dwa różne problemy
Pierwsza wersja produktu była rozbudowana funkcjonalnie. W trakcie developmentu dodawano jednak kolejne elementy bez wystarczającej kontroli nad spójnością całego rozwiązania.
Efektem był produkt posiadający wiele funkcji, ale również problemy architektoniczne, techniczne i produktowe.
Kolejny wykonawca podjął inną decyzję: zamiast rozwijać istniejący system, rozpoczął budowę produktu od początku.
Teoretycznie mogło to rozwiązać problem długu technologicznego.
W praktyce pojawił się inny problem. Rozwiązanie było wielokrotnie rozwijane i zmieniane, ale przy ograniczonych zasobach nie udało się osiągnąć odpowiedniej dojrzałości produktu. Z rozbudowanej, choć problematycznej aplikacji doszliśmy do znacznie prostszego MVP.
A termin zakończenia projektu był coraz bliżej.
Trzecia wersja nie była potrzebna
Kiedy przejąłem technologiczną stronę projektu, miałem przed sobą dwa rozwiązania.
Mogłem zrobić dokładnie to samo, co wcześniej: uznać, że oba są złe i rozpocząć budowę trzeciej aplikacji od zera.
Nie zrobiłem tego.
Przeanalizowałem obie wersje i oceniłem nie tylko jakość kodu, ale również istniejące funkcjonalności, architekturę, możliwości dalszego rozwoju oraz czas potrzebny do osiągnięcia celu.
Ostatecznie zdecydowałem się wrócić do pierwszego produktu. Miał problemy, ale posiadał też znacznie więcej gotowych elementów, które można było wykorzystać.
Najpierw zrozumieć, potem przepisywać
Rozpocząłem od dokładnej analizy istniejącego rozwiązania. Uporządkowałem projekt i przygotowałem dokumentację pozwalającą zrozumieć jego strukturę oraz zależności.
Dopiero wtedy rozpoczęły się właściwe zmiany. Kod został poprawiony tam, gdzie było to potrzebne. Brakujące funkcjonalności zostały uzupełnione. Poszczególne elementy produktu zaczęły tworzyć bardziej spójną całość.
Równolegle powstała strona produktu i elementy potrzebne do jego prezentacji.
To ważne rozróżnienie. W projekcie z ograniczonym czasem i budżetem CTO nie zawsze powinien wybierać rozwiązanie najbardziej eleganckie technologicznie. Powinien wybrać rozwiązanie, które daje biznesowi największą szansę osiągnięcia celu.
W tym samym czasie powstawał IKZ OCR
Równolegle do prac nad IKZMED rozwijaliśmy dodatkowy moduł przeznaczony do automatycznego przetwarzania dokumentacji medycznej. Celem IKZ OCR było wykorzystanie OCR do odczytywania dokumentów medycznych i przekształcania ich w ustrukturyzowane dane możliwe do wykorzystania przez system placówki.
Tutaj pojawił się kolejny problem charakterystyczny dla projektów technologicznych. Na późnym etapie developmentu pojawiła się propozycja zmiany wykorzystywanego silnika OCR na rozwiązanie, które technicznie mogło być lepsze.
Tyle że do zakończenia projektu pozostawał około miesiąc. Produkt był już przygotowywany do oddania i prezentacji podczas finału programu akceleracyjnego.
W takim momencie pytanie nie brzmi: „Czy znaleźliśmy lepszą technologię?"
Tylko: „Czy korzyść ze zmiany jest większa niż ryzyko, które wprowadzimy miesiąc przed terminem?"
W tym przypadku priorytetem stało się dowiezienie działającego rozwiązania. Więcej o tej decyzji piszę w osobnym artykule: Miesiąc do oddania produktu. Czy to dobry moment na zmianę technologii? →
Od technologii do prezentacji produktu
Dokończyłem brakujące elementy produktu, dobudowałem frontend potrzebny do jego obsługi i przygotowaliśmy rozwiązanie do finału akceleracji.
Ostatnim etapem było zaprezentowanie i obrona projektu podczas Carpathian Startup Fest, gdzie pojechałem reprezentować projekt przed organizatorami programu akceleracyjnego.
W ciągu kilku miesięcy równolegle doprowadziliśmy więc do końca dwa technologiczne strumienie: naprawę i rozwój istniejącego IKZMED oraz budowę rozwiązania OCR dla dokumentacji medycznej.
Czego nauczył mnie IKZMED?
Najważniejszą lekcją z tego projektu nie była konkretna technologia.
A na końcu pamiętać, że technologia istnieje po to, żeby dowieźć cel produktu — nie odwrotnie.
W przypadku IKZMED oznaczało to świadomą decyzję o powrocie do wcześniejszej wersji aplikacji zamiast budowania trzeciej od początku. W przypadku IKZ OCR oznaczało to niedokonywanie fundamentalnej zmiany technologicznej tuż przed zakończeniem projektu.
W obu przypadkach zasada była ta sama: najlepsza decyzja technologiczna nie zawsze oznacza wybór najnowszej albo najbardziej eleganckiej technologii. Czasami najlepszą decyzją jest zatrzymanie zmian i dowiezienie produktu.