Plan modernizacji gotowy, budżet wstępnie zaakceptowany. Wykonawca zadaje pierwsze pytanie: „Gdzie jest dokumentacja systemu?". Okazuje się, że jest wiki aktualizowana ostatnio pięć lat temu, kilka schematów „gdzieś na dysku sieciowym" i kod, który sam sobie robi za dokumentację. Wycena rośnie o jedną trzecią. Bo wykonawca nie wycenia pracy, tylko niepewność.
Ten tekst opisuje praktykę, która tę niepewność zdejmuje ze stołu: zanim ktokolwiek dotknie kodu starej aplikacji, odtwarza się wiedzę o niej. Jeszcze niedawno taki etap oznaczał tygodnie pracy analityka i mało kto się na niego decydował. Dziś AI wykonuje większość tej analizy w dni robocze. I to zmienia kolejność całego projektu.
Najpierw mapa, potem kod
Modernizacja systemu bez aktualnej dokumentacji przypomina remont budynku bez planu instalacji. Da się, ale każde skucie ściany to loteria: może za nią nic nie ma, a może rura, od której zależy pół piętra. W aplikacjach tą rurą bywa integracja z hurtownią, o której pamiętał tylko autor kodu, albo nocny eksport, z którego po cichu korzysta księgowość.
Dlatego rozsądna kolejność jest odwrotna do intuicyjnej. Nie zaczyna się od pisania nowego kodu ani nawet od wyceny. Zaczyna się od mapy.
Co AI wyciąga z kodu, bazy i logów
Nowoczesne narzędzia analizy potrafią przeczytać trzy źródła prawdy o systemie: kod źródłowy, strukturę bazy danych i logi z działania produkcyjnego. Z ich skrzyżowania powstaje mapa systemu, która obejmuje cztery warstwy.
Pierwsza to moduły: z czego system się składa i za co każdy fragment odpowiada, opisane językiem zrozumiałym również dla osób spoza IT. Druga to przepływy danych: skąd dane wchodzą, co się z nimi dzieje po drodze, gdzie lądują. Trzecia to integracje, czyli wszystkie miejsca, w których aplikacja rozmawia z innymi systemami: księgowością, magazynem, sklepem, partnerami. To one najczęściej pękają przy zmianach.
Czwarta warstwa jest najmniej oczywista: martwy kod. Analiza logów pokazuje, które funkcje nie zostały wywołane od lat i do których tabel nikt nie pisze od 2019 roku. W starszych systemach taki balast to często spora część całości. Każda linia, której nie trzeba przenosić, to realna oszczędność w projekcie.
Co mapa zmienia w decyzji „przepisać czy zmodernizować"
O samej decyzji pisaliśmy osobno, w tekście o czterech kryteriach: framework decyzyjny. Mapa systemu daje tym kryteriom twarde dane. Bez niej dług technologiczny ocenia się na wyczucie, a ryzyko na podstawie anegdot. Z nią widać czarno na białym: które moduły niosą wartość biznesową, które są martwe, gdzie siedzą integracje podnoszące ryzyko każdej zmiany.
Efekty bywają zaskakujące w obie strony. Czasem system, który „trzeba przepisać od zera", okazuje się w trzech czwartych zdrowy i wystarczy wymienić dwa moduły. Czasem odwrotnie: aplikacja wygląda niewinnie, a mapa ujawnia kilkanaście nieudokumentowanych połączeń, które czynią częściową modernizację droższą od przepisania. W obu przypadkach decyzja zapada na danych, nie na emocjach. A wykonawca, który dostaje mapę zamiast zagadki, wycenia pracę zamiast ryzyka.
Naszym zdaniem odtworzenie mapy powinno być osobnym, pierwszym etapem umowy modernizacyjnej, z własnym odbiorem. Nawet jeśli po tym etapie zdecydujesz, że modernizację robi kto inny albo nie robisz jej wcale, dokumentacja zostaje w firmie i pracuje dalej.
Jak zweryfikować to, co wygenerowała AI
Dokumentacja wygenerowana automatycznie nie jest wyrocznią. Trzeba ją sprawdzić. Najskuteczniejsza metoda jest prosta: przegląd z osobą, która system zna najlepiej, często jedyną taką w firmie. Różnica względem klasycznego podejścia polega na roli tej osoby. Nie prosisz jej o spisanie wiedzy, czego nikt nie lubi i co ciągnie się miesiącami. Prosisz o recenzję gotowego opisu, a wskazanie „tu się zgadza, tu nie" idzie wielokrotnie szybciej niż pisanie od zera.
Dobrą praktyką jest przejście przez kilka najważniejszych procesów od początku do końca: zamówienie, faktura, reklamacja. Jeśli mapa poprawnie opisuje przepływy krytyczne i wyrywkowo sprawdzone szczegóły, można jej zaufać w pozostałych obszarach. To się da zrobić w dzień.
Czego AI nie odtworzy
Tu uczciwe zastrzeżenie: kod mówi, co system robi, ale nie mówi, po co. Dziwny wyjątek w naliczaniu rabatu może być błędem, a może ustaleniem handlowym z 2016 roku, które nadal obowiązuje jednego dużego klienta. Tego żadna analiza kodu nie rozstrzygnie. Intencje biznesowe sprzed dekady odtwarza się wywiadami: krótkimi rozmowami z ludźmi od sprzedaży, księgowości i operacji, prowadzonymi już z mapą w ręku. Mapa podpowiada, o co pytać, ale odpowiedzi ma człowiek.
Osobnym tematem jest też otoczenie aplikacji: serwery, sieć, kopie zapasowe. O dokumentowaniu tej warstwy pisaliśmy w tekście o audycie dokumentacji infrastruktury.
W ESKOM AI etap mapowania prowadzimy zespołem wyspecjalizowanych agentów AI pod nadzorem doświadczonych inżynierów: analiza typowego systemu firmowego zajmuje dni robocze, a wynikiem jest dokumentacja czytelna dla zarządu i zespołu technicznego. Jeśli po niej zapada decyzja o modernizacji, dalsze prace przebiegają w zautomatyzowanym procesie wytwarzania oprogramowania z pełnym zakresem testów — jednostkowych, integracyjnych, E2E, UI, bezpieczeństwa i wydajnościowych.
Od czego zacząć u siebie
Wybierz jeden system: ten, którego modernizację odkładasz najdłużej albo którego najbardziej boisz się dotknąć. Zleć odtworzenie jego mapy jako samodzielny, niewielki etap, zanim poprosisz kogokolwiek o wycenę przebudowy. Na bezpłatnej konsultacji podpowiemy, jak taki etap zaplanować i czego się po nim spodziewać.
Umów bezpłatną konsultację przez formularz kontaktowy →