Działająca aplikacja ma użytkowników, generuje przychody, a zespół regularnie ją rozwija. Programiści korzystają już ze sztucznej inteligencji, która powinna przyspieszać codzienną pracę. W takiej sytuacji nie myśli się o przepisaniu aplikacji. Mimo to prosta zmiana może zajmować wiele czasu, a większe funkcje czekają często na wdrożenie miesiącami.
Wtedy warto zatanowić się, ile będzie kosztować utrzymywanie obecnego systemu przez kolejne lata? Dopiero takie porównanie pozwala ocenić, kiedy przepisanie działającej aplikacji ma sens.
Dlaczego stary system wydłuża wdrażanie zmian?
Wyobraźmy sobie aplikację, która od lat obsługuje użytkowników. Product owner chce dodać nowe pole do formularza, prostą ankietę przed wydarzeniem albo zmienić sposób prezentowania cennika. Funkcja nie wygląda na skomplikowaną. W nowym produkcie jej wdrożenie mogłoby zająć kilka dni.
W istniejącym systemie trzeba jednak sprawdzić zależności, ustalić, co zmiana może popsuć, znaleźć miejsce odpowiedzialne za dane zachowanie i przeprowadzić dodatkowe testy. Pozornie niewielka funkcja zajmuje więc nawet kilka sprintów.
Podobny problem pojawił się w przypadku Pragmatic Meet, gdzie wdrożenie ankiety przed wydarzeniem przeciągało się przez kilka sprintów. Takie sytuacje wynikają z tego, że z rozwojem produktu kolejne funkcje są coraz bardziej uzależnione od wcześniejszych decyzji. O tym, co można szybko wdrożyć, zaczyna decydować konstrukcja starego systemu. Zespół może mieć kompetencje i korzystać z AI, a mimo to koszt zmiany w aplikacji pozostaje wysoki.
Różne działanie AI w projektach
Wpływ AI na pracę zespołu zależy od rodzaju zadań. Warto rozdzielić trzy sytuacje: budowę nowego produktu, rozwój istniejącego systemu i przepisanie działającej aplikacji z zachowaniem potrzebnych funkcji.
Przy tworzeniu nowego produktu zespół nie musi uwzględniać historycznych decyzji. Od podstaw planuje sposób działania aplikacji pod aktualne wymagania. AI może wspierać tworzenie kolejnych elementów, testów czy dokumentacji.
Rozwój starego systemu wygląda inaczej. Zanim powstanie nowy fragment, trzeba zrozumieć, jak obecna aplikacja działa i z czym jest powiązana. AI w starym systemie może pomóc szybciej znaleźć informacje, przygotować część kodu czy uporządkować dokumentację. Nie usuwa jednak ograniczeń wynikających z konstrukcji systemu.
Trzecia sytuacja to przepisanie istniejącej aplikacji. Zespół zna potrzeby użytkowników i może zachować funkcje, które są potrzebne. Jednocześnie ma możliwość zbudowania systemu lepiej dopasowanego do obecnego produktu. Samo korzystanie z AI nie jest więc argumentem ani za pozostaniem przy starej aplikacji, ani za jej przepisaniem. Należy się zastanowić, gdzie AI przyspiesza tworzenie oprogramowania, a gdzie jego możliwości są ograniczone.
Kiedy kolejne poprawki kosztują za dużo
Wiek systemu nie jest jeszcze powodem do rozpoczynania nowego wielomiesięcznego projektu. Ważniejsze jest to, jak konstrukcja wpływa na codzienną pracę zespołu. Trzeba sprawdzić, czy przepisanie systemu ma sens biznesowy.
Jednym z sygnałów ostrzegawczych jest sytuacja, gdy niewiele osób naprawdę rozumie, jak działa aplikacja. Jeśli odejście jednej osoby oznacza utratę wiedzy potrzebnej do bezpiecznego rozwijania produktu, każda kolejna zmiana staje się ryzykowna. Kolejny problem to nieprzewidywalne skutki zmian. Funkcja modyfikowana w jednym miejscu powoduje problemy w innym, pozornie niezwiązanym obszarze. Zespół poświęca czas nie na wykonanie zadania, lecz sprawdzenie, czego jeszcze może ono dotknąć.
Jeśli aplikacja opiera się na starej technologii, znalezienie specjalisty, który zna ją wystarczająco dobrze, może być trudniejsze i droższe. Do tego dochodzą funkcje, które od dawna czekają na wdrożenie, ponieważ zespół stale wybiera pilniejsze poprawki. Sytuacja wygląda inaczej, gdy problem jest ograniczony do jednego modułu. Jeżeli zespół dobrze zna kod, a większość aplikacji rozwija się bez większych przeszkód, nie trzeba przepisywać całości. Rozsądniejszym rozwiązaniem może być stopniowa wymiana problematycznego fragmentu.
Zanim zdecydujemy o przepisaniu systemu
Działająca aplikacja przez lata gromadzi funkcje, które nie zawsze są nadal potrzebne. Przepisanie systemu nie musi oznaczać odtworzenia każdego przycisku, formularza i procesu. Warto podzielić funkcje na trzy grupy:
- konieczne do zachowania,
- te, które można zmienić,
- do usunięcia.
Pozwala to uniknąć sytuacji, w której nowy system staje się kopią starego i pozbyć się niepotrzebnych elementów.
Druga kwestia to sposób przejścia między wersjami. Trzeba sprawdzić, czy możliwe jest przepisanie działającego produktu bez zatrzymywania jego działania. Jeśli tak, można to potraktować jak kontrolowany proces, a nie jednorazowe wyłączenie dotychczasowego produktu.
Należy też policzyć koszt pracy na konkretnych przykładach. Zamiast opierać się wyłącznie na spekulacjach można sprawdzić, ile czasu rzeczywiście zajmuje wdrożenie określonej funkcji. Jeśli dodanie nowego pola, zmiana cennika czy przygotowanie ankiety wymaga więcej pracy niż podobne zadanie w nowej wersji, otrzymujemy konkretny punkt odniesienia.
Oszczędność w perspektywie lat
Największym błędem przy ocenie przepisywania aplikacji jest porównanie wyłącznie kosztu obu projektów. Nowy system może być droższy na początku, ale jego wartość trzeba oceniać przez pryzmat przyszłości. Jeżeli obecna aplikacja wymaga coraz więcej czasu przy każdej zmianie, jej utrzymanie generuje koszt nie tylko w postaci pracy programistów. Opóźniają się funkcje, które mogłyby wspierać sprzedaż lub poprawiać doświadczenie użytkowników. Zespół mniej czasu poświęca na rozwój produktu, a więcej na obchodzenie ograniczeń istniejącego rozwiązania.
Dlatego porównanie powinno obejmować kilka kolejnych lat. Po jednej stronie znajduje się koszt utrzymania obecnego systemu, kolejnych poprawek, opóźnionych funkcji i trudności z jego rozwijaniem. Po drugiej – koszt kontrolowanego przepisania oraz późniejszego utrzymania nowej wersji.
Jeśli niewielkie zmiany regularnie zajmują tygodnie, a zespół coraz częściej dostosowuje pomysły do ograniczeń aplikacji zamiast odwrotnie, warto policzyć alternatywę. Pytanie nie brzmi wtedy, czy przepisanie systemu jest drogie ale, ile będzie kosztować pozostawienie go bez zmian.
