Naprawiać, modernizować czy przepisać system legacy? Kryteria decyzji
Kluczowy system firmy może nadal działać, a jednocześnie coraz mocniej ograniczać jej rozwój. Gdy każda kolejna zmiana trwa dłużej, kosztuje więcej i zwiększa ryzyko awarii, zarząd staje przed wyborem: dalej naprawiać obecne rozwiązanie, wymienić problematyczne moduły czy przepisać cały system.
Każda z tych ścieżek ma sens w innych warunkach. W tym artykule pokazujemy, kiedy warto wybrać każdą z nich oraz jak oprzeć decyzję na stanie systemu, ekonomice rozbudowy systemu (przed i po przepisaniu), ryzyku migracji i sytuacji biznesowej firmy.
W skrócie
|
Oddziel problemy starego systemu od problemów organizacji
Te same opóźnienia mogą wynikać z kodu, sposobu pracy albo obu obszarów jednocześnie. Zacznij więc od pytania: czego firma nie może dziś zrobić przez ten system? Odpowiedź powinna wskazywać konkretną barierę, na przykład zablokowaną integrację lub zbyt długi czas wprowadzenia nowej usługi.
Prześledź też, jak zgłoszenie nowej funkcji przechodzi od pomysłu do decyzji o realizacji. Częste zmiany priorytetów, niejasne ustalenia i powolne decyzje potrafią zablokować nawet zdrowy technicznie system.
Zanim zdecydujesz, czy system naprawiać, modernizować częściowo czy przepisać, przeanalizuj:
- czas od pomysłu do wdrożenia typowej funkcji;
- rzeczywisty koszt dostarczenia pojedynczej funkcji przez cały zespół;
- udział kosztów utrzymania, awarii i poprawek w budżecie IT;
- liczbę regresji oraz wpływ incydentów na klientów i przychody;
- obejścia stosowane przez użytkowników poza systemem;
- stan testów, dokumentacji, integracji oraz liczbę osób posiadających kluczową wiedzę.
Tydzień lub dwa oczekiwania na prostą funkcję to wyraźny sygnał ostrzegawczy, choć próg zależy od branży i złożoności rozwiązania. Ważniejszy jest trend: czy porównywalne zmiany trwają coraz dłużej?
Dopasuj zakres modernizacji do źródła problemu
Wybierz najmniejszy zakres zmiany, który usuwa ograniczenie biznesowe i trwale poprawia ekonomię rozwoju. Przepisanie całości ma największy zakres oraz ryzyko, więc potrzebuje też najmocniejszego uzasadnienia.
Dalsze naprawy, gdy fundament systemu pozostaje zdrowy
Dalsze poprawki mają sens, gdy architektura pozwala bezpiecznie rozwijać system. Zespół rozumie zależności, ma użyteczną dokumentację, ufa testom i sprawnie wdraża zmiany. Koszt utrzymania pozostaje rozsądny wobec wartości obsługiwanych procesów.
Wiek technologii i niechęć deweloperów do trudnego kodu o niczym nie przesądzają. O wyborze powinien przesądzać wpływ na firmę. Jeśli kolejne funkcje nadal powstają w przewidywalnym czasie, dalszy rozwój może być najrozsądniejszą opcją.
Wymiana modułów, gdy problemy da się odizolować
Częściowa modernizacja sprawdzi się dla systemu, w którym słabe punkty są skupione w pojedynczych obszarach. Zleć sprawdzenie, gdzie trafia większość zmian i które funkcje użytkownicy świadomie obchodzą. Arkusz w Excelu używany zamiast aplikacji zwykle oznacza, że dany moduł przestał wspierać rzeczywisty proces.
Możesz zlecić wydzielenie tego modułu, jego przepisanie i połączenie z resztą systemu. W większym systemie kolejne takie fragmenty lepiej wymieniać etapami. Ograniczysz w ten sposób początkową inwestycję i szybko sprawdzisz efekty.
Przepisanie całości, gdy ograniczenie obejmuje cały system
Pełne przepisanie ma uzasadnienie, gdy trudność wdrażania zmian obejmuje cały system. Drobne poprawki trwają tygodniami, modyfikacja jednego obszaru psuje inne, testy nie dają wiarygodnych informacji, a architektura nie pozwala na wydzielenie stabilnych elementów. Dodatkowe ryzyko tworzą szczątkowa dokumentacja i niski bus factor (kluczowa wiedza skupiona w głowach kilku osób).
Pełne przepisanie ma sens, gdy firma już wie, jakie procesy i reguły system ma obsługiwać oraz jak produkt ma działać. Gdy te wymagania wciąż mocno się zmieniają, lepsza będzie modernizacja etapami albo sprawdzenie nowego kierunku na małym zakresie, bez ingerencji w obecny system.
Zanim porównasz koszty naprawy, wymiany modułów i przepisania całości, możesz przejść przez sześciostopniową autodiagnozę stanu projektu IT. Dzięki niej uporządkujesz sygnały z biznesu, produktu i technologii.
Porównaj pełny koszt utrzymania, modernizacji i przepisania systemu
Porównaj koszt dalszego utrzymania, refaktoryzacji, wymiany modułów i przepisania całego systemu za ten sam okres (na przykład 2 kwartałów). Dopiero długoterminowe zestawienie kosztów pokazuje, która opcja naprawdę wychodzi taniej.
W rachunku uwzględnij:
- koszty pracy zespołu, infrastruktury, licencji i wsparcia specjalistów;
- koszt tworzenia funkcji, testowania regresji i usuwania awarii;
- koszt godzin, które pracownicy poświęcają na ręczne czynności i obejścia poza systemem;
- koszt migracji danych, podłączenia pozostałych systemów, przeszkolenia ludzi oraz utrzymania starej i nowej wersji w tym samym czasie;
- koszt utraconych przychodów (oferty, integracje i umowy, których obecny system nie pozwala uruchomić).
Przygotuj scenariusz optymistyczny, bazowy i pesymistyczny.
Przykład: przepisanie Pragmatic Meet
Przepisanie od zera Pragmatic Meet (naszego własnego produktu do organizacji wydarzeń w społecznościach technologicznych) pokazuje zmianę ekonomiki projektu, jakiej możesz oczekiwać. Koszt porównywalnej historyjki użytkownika spadł z około 60 roboczogodzin zespołu do około 18 godzin na starcie, a później ustabilizował się na poziomie 15–16 godzin. Ten wynik przełożył się na około trzykrotnie niższy koszt historyjki. Więcej dowiesz się z webinaru o przepisaniu Pragmatic Meet.
Był to system średniej wielkości, znany zespołowi z około półtora roku pracy. Czterech programistów i Product Owner osiągnęli gotowość produkcyjną po około 7,5 tygodnia, a dodatkowy tydzień przeznaczyli na poprawki.
Oceń, czy w ogóle ruszać system, i sprawdź to na krótkim teście
Rachunek kosztów pokaże, która droga wychodzi taniej, ale koszty to tylko część decyzji. Przed uruchomieniem projektu trzeba potwierdzić, że obecny system rzeczywiście ogranicza firmę, i ustalić źródło problemu. Trzeba też sprawdzić, czy organizacja może bezpiecznie przeprowadzić zmianę. Taki przegląd systemu i gotowości organizacji możesz przeprowadzić wewnętrznie albo zlecić go na zewnątrz, na przykład Pragmatic Coders.
Ustal źródło problemu i uzasadniony zakres zmiany
Najpierw nazwij konkretny skutek biznesowy obecnego systemu: wolniejsze wprowadzanie nowych usług, rosnący koszt zmian, utracone przychody albo ryzyko awarii. Następnie ustal, czy jego główną przyczyną jest architektura całego systemu, pojedyncze moduły czy sposób, w jaki firma zbiera wymagania, ustala priorytety i wdraża zmiany.
Przegląd powinien też objąć dane, integracje, bezpieczeństwo, ryzyko migracji oraz dostęp do kodu, dokumentacji i osób znających procesy biznesowe. Dzięki temu wiadomo, czy proponowaną zmianę da się przeprowadzić bezpiecznie i bez nieplanowanego zatrzymania działalności.
Na tej podstawie osoby prowadzące przegląd powinny przedstawić rekomendację wraz z uzasadnieniem: zostawić system, uprościć go, refaktoryzować, wydzielić lub zastąpić wybrane moduły, przepisać całość albo zmienić sposób pracy. Rekomendacja może również wskazać, że pełne przepisanie nie ma wystarczającego uzasadnienia biznesowego.
Okres próbny w Pragmatic Coders pozwala zastąpić hipotezy danymi
Po wyborze kierunku najważniejsze założenia można sprawdzić na reprezentatywnym fragmencie systemu. Reprezentatywny fragment to część systemu o takim samym charakterze jak jego większość: z tymi samymi rodzajami reguł biznesowych, danych i połączeń z innymi systemami. Wynik pracy nad prostym, odizolowanym modułem nie pokaże, jak będzie wyglądała praca nad całością systemu.
Przed rozpoczęciem próby ustal mierzalne kryteria kontynuacji: działający zakres, tempo dostarczania, koszt funkcji, jakość testów, ryzyka migracyjne i gotowość do uruchomienia rozwiązania.
Pragmatic Coders oferuje sześciotygodniowy okres próbny. W tym czasie zespół przepisuje reprezentatywny fragment obecnego systemu i mierzy rzeczywiste tempo, koszt oraz jakość pracy. Dzięki tym pomiarom możemy określić dla klienta przewidywany czas i koszt dalszych prac o wiele dokładniej niż na podstawie samych szacunków albo wcześniejszego audytu. W okresie próbnym piszemy kod produkcyjny, tak jak w zwykłym projekcie przepisania. Jeśli współpraca trwa dalej, wykorzystujemy ten kod w ostatecznym rozwiązaniu i od niego prowadzimy dalsze przepisywanie.
Audyt i okres próbny są częścią podejścia Pragmatic Coders do przepisywania systemów legacy bez ryzyka. Jeśli potrzebujesz wsparcia przy wyborze właściwej drogi, możesz skontaktować się z nami lub umówić bezpłatną konsultację.
Użycie AI obniża koszt przepisania, ale to zespół nadal odpowiada za wymagania i jakość
Wykorzystanie AI skraca drogę od specyfikacji do działającego kodu, co przyspiesza przepisywanie systemu i obniża koszt implementacji. Samo tempo nie przesądza jednak o jakości rezultatu: wykorzystanie AI pozwala szybciej zakodować zarówno dobrze przemyślane rozwiązanie, jak i takie, które opiera się na niepełnych wymaganiach lub błędnych założeniach. Dlatego większe tempo tworzenia kodu wymaga precyzyjnych wymagań i skutecznej kontroli jakości.
W podejściu Spec-Driven Development zespół pracuje na podstawie uzgodnionej specyfikacji. Opisuje w niej oczekiwane zachowanie systemu, scenariusze i kryteria akceptacji, z których korzystają zarówno inżynierowie, jak i agent AI. Przed rozpoczęciem implementacji trzeba więc odtworzyć reguły biznesowe, doprecyzować wymagania i ustalić, jak zweryfikować rezultat. W jednym z naszych zespołów ten etap zajmował około 30% sprintu.
Nawet dobra specyfikacja nie zwalnia inżynierów z odpowiedzialności za architekturę, bezpieczeństwo, jakość i ostateczne zatwierdzenie zmian. Potrzebne są przeglądy kodu, testy automatyczne, testy architektury i regularne testy eksploracyjne. W ten sposób zespół sprawdza, czy powstający system działa zgodnie z wymaganiami i przyjętymi zasadami architektury.
Uwzględniaj migrację od początku projektu
Plan projektu powinien od daty startu obejmować przeniesienie danych, odtworzenie połączeń z systemami i usługami, z którymi obecne rozwiązanie wymienia dane, oraz sposób przełączenia. Prace te są taką samą częścią przedsięwzięcia jak budowa nowego systemu, dlatego powinny znaleźć się w zakresie i harmonogramie.
Niezależnie od tego, czy przepisanie prowadzi własny zespół, czy zewnętrzny wykonawca, osoby realizujące projekt powinny rozmawiać z użytkownikami i obserwować ich codzienną pracę. Pozwoli im to odkryć operacje, wyjątki i obejścia, których nie ma w dokumentacji. Na tej podstawie trzeba uzgodnić, które zachowania systemu zachować, poprawić, uprościć lub usunąć. Zmiana interfejsu albo sposobu pracy użytkowników powinna trafić do zakresu tylko wtedy, gdy ma wyraźne uzasadnienie.
Zanim wybierzesz sposób migracji, poproś osoby prowadzące projekt o porównanie kosztów i ryzyka poszczególnych wariantów oraz wskazanie najlepiej dopasowanego do tego projektu. Nową wersję Pragmatic Meet uruchomiliśmy jednorazowo po wcześniejszych testach. W rozbudowanym systemie z wyraźnymi granicami modułów bezpieczniejsze może być przełączanie etapami. Równoległa obsługa tych samych procesów przez starą i nową wersję ma sens tylko wtedy, gdy ograniczenie ryzyka uzasadnia koszt synchronizacji danych i utrzymywania obu wersji.
Zanim nowy system przejmie obsługę rzeczywistych procesów firmy, powinieneś otrzymać wyniki próbnego przeniesienia danych oraz testów integracji i kluczowych procesów. Plan migracji powinien też określać, w jakich sytuacjach należy wrócić do starej wersji i jak przeprowadzić taki powrót. Na tej podstawie możesz ocenić, czy można bezpiecznie rozpocząć przełączanie.
Podsumowanie
Proces decyzyjny zacznij od ustalenia, gdzie leży źródło problemu: w całym systemie, w pojedynczych modułach czy w sposobie pracy. Następnie porównaj całkowity koszt każdej opcji, zweryfikuj najważniejsze założenia na reprezentatywnym fragmencie systemu i od początku zaplanuj migrację.
Po wdrożeniu oceń efekty na podstawie tych samych wskaźników, które uzasadniały inwestycję. Sprawdź, czy skrócił się czas dostarczania funkcji, spadły koszty zmian i liczba awarii oraz czy firma może już realizować cele, które wcześniej blokował system. Te wyniki pokażą, czy wybrana droga była właściwa.
