Dwie aplikacje, dwa różne problemy
Pierwsza wersja produktu była już mocno rozbudowana funkcjonalnie.
Problem polegał na tym, że w trakcie developmentu dodawano kolejne elementy bez wystarczającej kontroli nad spójnością całego rozwiązania.
Produkt miał więc dużo funkcji, ale jednocześnie posiadał problemy architektoniczne, techniczne i produktowe.
Kolejny wykonawca podjął inną decyzję.
Zamiast rozwijać istniejący system, rozpoczął budowę produktu praktycznie od początku.
Na papierze wyglądało to rozsądnie.
Jeżeli istniejący system ma duży dług technologiczny, przepisanie go może wydawać się najprostszym sposobem na rozpoczęcie pracy z czystą architekturą.
Problem pojawił się później.
Przy ograniczonych zasobach nie udało się doprowadzić nowej wersji do odpowiedniej dojrzałości. Z rozbudowanej, choć problematycznej aplikacji powstało znacznie prostsze MVP.
I właśnie wtedy pojawił się najważniejszy problem:
Termin zakończenia projektu był coraz bliżej.
Trzecia wersja aplikacji nie była rozwiązaniem
Kiedy przejąłem technologiczną stronę projektu, miałem przed sobą dwie możliwości.
Mogłem zrobić dokładnie to samo, co wcześniej.
Uznać, że obie wersje są złe i rozpocząć budowę trzeciej aplikacji od zera.
Nie zrobiłem tego.
Zamiast tego przeanalizowałem obie istniejące wersje.
Nie patrzyłem wyłącznie na jakość kodu. Trzeba było ocenić cały projekt z perspektywy celu, który miał zostać osiągnięty.
Analizowałem między innymi:
- jakie funkcjonalności już istnieją,
- które z nich rzeczywiście działają,
- jak wygląda architektura,
- jakie są największe problemy techniczne,
- co można dalej rozwijać,
- czego brakuje,
- ile czasu zajmie doprowadzenie każdej wersji do odpowiedniego stanu,
- która droga daje największą szansę na ukończenie projektu.
Ostatecznie zdecydowałem się wrócić do pierwszego produktu.
Nie dlatego, że był dobry.
Był problematyczny.
Miał jednak jedną ogromną przewagę: posiadał znacznie więcej gotowych elementów, które można było wykorzystać.
I w tym momencie zmieniła się cała strategia projektu.
Najpierw zrozumieć, potem przepisywać
Jednym z największych błędów przy przejmowaniu projektu IT jest założenie, że skoro poprzedni wykonawca zrobił coś źle, trzeba wszystko napisać od nowa.
Czasami tak jest.
Ale często nie.
Przepisanie systemu może być technicznie kuszące, ponieważ daje poczucie rozpoczęcia od czystej kartki. Problem w tym, że razem z kodem przepisujesz również czas potrzebny na odtworzenie funkcjonalności, testy, integracje, błędy i wszystkie rzeczy, o których dowiadujesz się dopiero w trakcie developmentu.
Dlatego po przejęciu projektu rozpocząłem od analizy istniejącego rozwiązania.
Trzeba było zrozumieć:
- jak zbudowany jest system,
- jakie ma zależności,
- które elementy są ze sobą powiązane,
- co rzeczywiście działa,
- co wymaga poprawy,
- czego brakuje całkowicie.
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 zaczęły tworzyć bardziej spójną całość.
Równolegle powstała strona produktu i elementy potrzebne do jego prezentacji.
Celem nie było stworzenie technicznie idealnego systemu.
Celem było doprowadzenie istniejącego produktu do stanu, w którym realizuje swoje zadanie, może zostać pokazany i pozwala prawidłowo zakończyć projekt.
To bardzo ważne rozróżnienie.
CTO nie zawsze powinien wybrać najlepszą technologię
W projektach IT łatwo wpaść w pułapkę myślenia, że zadaniem CTO jest zawsze wybór najbardziej nowoczesnego albo najbardziej eleganckiego rozwiązania.
Nie zawsze.
Jeżeli masz nieograniczony czas i budżet, możesz optymalizować architekturę przez wiele miesięcy.
Jeżeli jednak projekt ma konkretny termin, budżet i zakres, priorytety wyglądają inaczej.
Wtedy CTO powinien odpowiedzieć sobie na pytanie:
Która decyzja technologiczna daje największą szansę na osiągnięcie celu biznesowego?
Nie:
„Która technologia jest najlepsza?”
Tylko:
„Która decyzja pozwoli nam dowieźć produkt?”
To czasami oznacza pozostawienie części starszego kodu.
Czasami oznacza ograniczenie zakresu.
Czasami oznacza rezygnację z kolejnego rewrite'u.
A czasami oznacza powiedzenie zespołowi:
Nie zmieniamy teraz technologii, bo ryzyko jest większe niż potencjalna korzyść.
W tym samym czasie powstawał IKZ OCR
Projekt miał jeszcze drugi technologiczny strumień.
Równolegle rozwijany był moduł przeznaczony do automatycznego przetwarzania dokumentacji medycznej.
Celem IKZ OCR było wykorzystanie technologii OCR do odczytywania dokumentów medycznych i przekształcania ich w ustrukturyzowane dane, które mogły być później wykorzystane przez system placówki.
I tutaj pojawił się kolejny problem.
Na późnym etapie developmentu pojawiła się możliwość wykorzystania innego silnika OCR, który technicznie mógł oferować lepsze rezultaty.
Brzmi dobrze.
Problem polegał na tym, ż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ę?”
Powinno brzmieć:
„Czy korzyść ze zmiany jest większa niż ryzyko, które wprowadzimy miesiąc przed terminem?”
W tym przypadku priorytetem było dowiezienie działającego rozwiązania.
Więcej o tej konkretnej decyzji technologicznej opisałem w osobnym artykule:
Miesiąc do oddania produktu. Czy to dobry moment na zmianę technologii?
Od technologii do gotowego produktu
Naprawienie kodu było tylko częścią zadania.
Produkt trzeba było również przygotować do rzeczywistego użycia i prezentacji.
Dokończyłem brakujące elementy, dobudowałem frontend potrzebny do obsługi rozwiązania i przygotowaliśmy projekt do finału akceleracji.
Ostatnim etapem było zaprezentowanie i obrona projektu podczas Carpathian Startup Fest, gdzie reprezentowałem 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,
- budowę rozwiązania OCR dla dokumentacji medycznej.
Najważniejsze było jednak to, że przestaliśmy traktować projekt jak problem polegający na napisaniu „jeszcze jednej wersji”.
Zaczęliśmy traktować go jak problem biznesowo-technologiczny, który trzeba po prostu rozwiązać.
Co robi Fractional CTO, kiedy przejmuje trudny projekt?
Tego typu sytuacja dobrze pokazuje, gdzie w praktyce pojawia się wartość Fractional CTO.
Nie chodzi wyłącznie o pisanie kodu.
Nie chodzi również o przychodzenie do firmy i mówienie zespołowi, że wszystko, co zrobił poprzedni wykonawca, było błędem.
Pierwszym zadaniem jest odzyskanie kontroli nad projektem.
W praktyce oznacza to między innymi:
- zrozumienie obecnej architektury,
- ocenę stanu produktu,
- analizę wcześniejszych decyzji technologicznych,
- sprawdzenie, co rzeczywiście działa,
- określenie braków,
- ocenę ryzyka,
- ustalenie priorytetów,
- przygotowanie planu prowadzącego do konkretnego celu.
Dopiero później przychodzi czas na development.
To szczególnie ważne, kiedy projekt przeszedł przez kilku wykonawców.
Każdy kolejny zespół może mieć własną wizję tego, co powinno zostać zrobione. Jeżeli nie ma osoby, która patrzy na projekt z góry i bierze odpowiedzialność za całość, bardzo łatwo wejść w cykl:
nowy wykonawca → nowa diagnoza → nowa architektura → nowy rewrite → kolejny termin.
I nagle po kilku latach projekt nadal nie jest gotowy.
Kiedy nie warto zaczynać od zera?
Nie ma jednej reguły, która mówi, że istniejący system zawsze należy ratować.
Są sytuacje, w których rewrite jest właściwą decyzją.
Na przykład wtedy, gdy:
- architektura uniemożliwia dalszy rozwój,
- koszty utrzymania są nieproporcjonalnie wysokie,
- kluczowe elementy systemu są nie do odzyskania,
- technologia nie pozwala spełnić wymagań produktu,
- dalsze rozwijanie istniejącego rozwiązania będzie droższe i bardziej ryzykowne niż budowa nowego.
Problem polega na tym, że decyzja o przepisaniu systemu powinna wynikać z analizy, a nie z frustracji.
„Ten kod jest brzydki” nie jest jeszcze argumentem za rewrite'em.
Tak samo jak:
„Poprzedni wykonawca zrobił to źle” nie oznacza, że wszystko trzeba wyrzucić.
Dobry CTO powinien umieć oddzielić problemy, które rzeczywiście wymagają przebudowy, od tych, które można rozwiązać przez uporządkowanie istniejącego systemu.
Największy błąd przy przejmowaniu projektu IT
Moim zdaniem jest nim rozpoczęcie pracy od kodowania.
Jeżeli przejmujesz projekt po kilku wykonawcach i pierwszego dnia otwierasz IDE, istnieje duża szansa, że zaczniesz naprawiać objawy zamiast przyczyny.
Najpierw trzeba zrozumieć:
co mamy, czego potrzebujemy i ile czasu mamy.
Dopiero później należy decydować, co budować.
W przypadku IKZMED najważniejszą decyzją nie było napisanie nowego rozwiązania.
Najważniejszą decyzją było niepisanie trzeciej wersji aplikacji.
To może wydawać się paradoksalne, szczególnie w branży, w której nowe technologie i nowe architektury pojawiają się praktycznie cały czas.
Ale czasami najlepszą decyzją technologiczną jest właśnie powstrzymanie się od kolejnej zmiany.
Czego nauczył mnie ten projekt?
Najważniejszą lekcją z IKZMED nie była konkretna technologia.
Było nią to, że przejęcie trudnego projektu IT nie powinno zaczynać się od pisania kodu.
Najpierw trzeba zrozumieć, co już istnieje.
Potem oddzielić rzeczy, które rzeczywiście wymagają przebudowy, od tych, które po prostu wymagają uporządkowania.
Następnie trzeba określić, jaki jest rzeczywisty cel projektu.
I dopiero wtedy podejmować decyzje technologiczne.
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 taka sama:
Technologia ma pomagać dowieźć cel produktu, a nie stawać się celem sama w sobie.
Kiedy warto zaangażować Fractional CTO?
Nie musisz zatrudniać CTO na pełen etat, żeby odzyskać kontrolę nad projektem.
Model Fractional CTO może mieć sens szczególnie wtedy, gdy firma:
- ma produkt technologiczny, ale nie ma osoby odpowiedzialnej za całość technologii,
- przejęła projekt po poprzednim software house,
- ma kilka wersji tego samego systemu,
- nie wie, co właściwie zostało wykonane,
- stoi przed decyzją o rewrite'cie,
- ma problem z terminem lub budżetem,
- potrzebuje uporządkować architekturę,
- potrzebuje doświadczonej osoby, która połączy technologię z celem biznesowym.
Nie zawsze potrzebny jest pełnoetatowy CTO.
Czasami potrzebujesz kogoś, kto wejdzie do projektu, uporządkuje sytuację, podejmie trudne decyzje i doprowadzi zespół do konkretnego punktu.
To właśnie jeden z przypadków, w których model Fractional CTO może być szczególnie użyteczny.
Najczęstsze pytania
Czy da się uratować projekt po kilku software house'ach?
Tak, ale nie zawsze.
Pierwszym krokiem powinna być analiza istniejącego rozwiązania. Dopiero po niej można ocenić, czy bardziej opłaca się rozwijać obecny system, przebudować jego część czy rozpocząć projekt od nowa.
Czy każdy stary system trzeba przepisać?
Nie.
Wiek technologii sam w sobie nie jest powodem do rewrite'u. Kluczowe jest to, czy obecna architektura pozwala osiągnąć cele produktu, rozwijać system i utrzymywać go przy akceptowalnym poziomie kosztów oraz ryzyka.
Co zrobić, jeśli poprzedni wykonawca zostawił słabą dokumentację?
Nie należy od razu zakładać, że projekt jest nie do uratowania.
Dokumentację można częściowo odtworzyć na podstawie kodu, infrastruktury, baz danych, konfiguracji, istniejących funkcjonalności i rozmów z osobami, które pracowały przy projekcie.
Najpierw trzeba zbudować obraz tego, co faktycznie istnieje.
Czy Fractional CTO musi sam programować?
Nie.
W zależności od projektu może pracować bezpośrednio z kodem, ale jego główną rolą jest podejmowanie decyzji technologicznych, zarządzanie ryzykiem, architekturą, zespołem i delivery.
W trudnym projekcie ważniejsze od napisania kolejnych kilkuset linii kodu może być podjęcie właściwej decyzji o tym, czego nie należy teraz budować.
Kiedy rewrite ma sens?
Wtedy, gdy analiza pokazuje, że dalsze rozwijanie istniejącego systemu jest bardziej ryzykowne lub kosztowne niż budowa nowego rozwiązania.
Nie powinno się jednak podejmować tej decyzji wyłącznie dlatego, że obecny kod jest trudny do zrozumienia.
Czy Fractional CTO może przejąć projekt w trakcie jego realizacji?
Tak.
Co więcej, właśnie wtedy taka rola może być szczególnie potrzebna — gdy projekt już trwa, pojawiły się problemy, termin się zbliża, a firma potrzebuje niezależnej oceny sytuacji i konkretnego planu działania.
Podsumowanie
Najtrudniejsze projekty IT rzadko potrzebują po prostu większej liczby programistów.
Często potrzebują jednej osoby, która spojrzy na projekt z góry i podejmie odpowiedzialność za decyzje technologiczne.
W IKZMED problemem nie było to, że nie można było napisać kolejnej aplikacji.
Problemem było to, że kolejna aplikacja nie rozwiązywała rzeczywistego problemu.
Dlatego zamiast zaczynać od zera, przeanalizowałem to, co już istniało, wybrałem wersję dającą największą szansę na dowiezienie projektu i doprowadziłem ją do stanu, w którym można było zakończyć pracę.
Czasami ratowanie projektu IT nie polega na napisaniu lepszego systemu.
Polega na podjęciu właściwej decyzji, co jeszcze warto budować — a czego już nie.
O autorze
Sebastian Magnes — Fractional CTO · MedTech · SaaS · AI
Pomagam firmom przejmować, porządkować i rozwijać produkty technologiczne — szczególnie tam, gdzie projekt utknął, technologia przestała nadążać za biznesem albo potrzebna jest osoba, która weźmie odpowiedzialność za stronę technologiczną bez zatrudniania CTO na pełen etat.
Pracuję przy projektach IT, SaaS i MedTech, w tym przy projektach finansowanych ze środków publicznych.
Łączę architekturę, development, cloud, DevOps i zarządzanie produktem z jednym celem: doprowadzić projekt do końca.
