Przejęcie utrzymania aplikacji po innym wykonawcy

Na czym polega utrzymanie aplikacji

Utrzymanie aplikacji to stała opieka nad systemem, który już działa produkcyjnie. Standardowo obejmuje ono: monitoring dostępności rozwiązania, aktualizacje bezpieczeństwa, regularne kopie zapasowe (backupy) oraz reakcję na zgłoszenia klientów zgodnie z ustalonym SLA. Dodatkową praktyką jest także rozwój rozwiązania w ramach określonej miesięcznej puli godzin.

To coś innego niż rozwój aplikacji. Rozwój to budowa nowych funkcjonalności - najczęściej osobny projekt, osobny budżet i dedykowany harmonogram.

Granica między utrzymaniem a rozwojem bywa płynna. Niewielkie poprawki i usprawnienia, które można zrealizować w ramach dostępnej puli godzin, są częścią bieżącej opieki. Większe zmiany funkcjonalne lub techniczne najpierw analizujemy, a następnie ustalamy dla nich osobny zakres, budżet i harmonogram.

Mały zespół, który zna Twój kod

Zgłoszeniami zajmują się osoby, które znają architekturę i kontekst biznesowy Twojego systemu. Dzięki temu nie tracimy czasu na przekazywanie spraw między kolejnymi poziomami wsparcia ani każdorazowe wdrażanie nowej osoby w projekt.

Pracujemy w niewielkich, stałych zespołach, dlatego komunikacja jest krótsza, decyzje zapadają sprawniej, a problemy szybciej trafiają do specjalisty, który może realnie je rozwiązać.

Stały zespół nie oznacza jednak zamkniętego składu. Gdy projekt wymaga dodatkowych kompetencji albo czasowego zwiększenia zasobów, możemy włączyć do pracy odpowiednich specjalistów. Pozwala nam to zachować ciągłość wiedzy o systemie, a jednocześnie elastycznie reagować na zmieniające się potrzeby.

To ma znaczenie zwłaszcza po przejęciu systemu: ci sami ludzie, którzy przeprowadzali audyt, później faktycznie utrzymują aplikację. Nie tracisz wiedzy przy każdej zmianie osoby po stronie wykonawcy, bo takiej rotacji po prostu unikamy.

Przejęcie systemu po innym wykonawcy

Jak wygląda przejęcie systemu po innym wykonawcy

Przejęcie utrzymania aplikacji od innego software house'u, dostawcy IT lub freelancera realizujemy w czterech krokach. Z naszego doświadczenia, poprawnie przeprowadzone przejęcie systemu trwa od 2 do 6 tygodni i opiera się na czterech konkretnych krokach:

1. Audyt kodu, infrastruktury i dokumentacji. Sprawdzamy repozytorium, środowisko produkcyjne, konfigurację, zależności i to, jakie dostępy w ogóle istnieją.
2. Wykaz ryzyk i długów technicznych z rekomendacjami. Zamiast ogólnego "kod jest stary" - konkretna lista: co jest pilne, co może poczekać, co kosztuje najwięcej w utrzymaniu.
3. Opcjonalny okres równoległej pracy z poprzednim wykonawcą. Jeśli to możliwe, przez pewien czas oba zespoły działają obok siebie - to naturalny bufor bezpieczeństwa na wypadek pytań, których nie da się przewidzieć na starcie.
4. Start SLA z odpowiedzialnością. Od tego momentu zgłoszenia, monitoring i backupy są już po naszej stronie.

Standardowy czas przejęcia systemu wynosi od 2 do 6 tygodni - każdy projekt, system jest inny. Wpływa na niego kilka elementów: stan i jakość kodu, kompletność dokumentacji, dostęp do repozytoriów, infrastruktury i kont administracyjnych, a także możliwość współpracy z obecnym zespołem i sprawnego przekazania wiedzy.

Proces przebiega szybciej, gdy system ma uporządkowane środowisko, niezbędne dostępy są kompletne, a poprzedni wykonawca może wyjaśnić najważniejsze decyzje techniczne i biznesowe. Więcej czasu potrzeba wtedy, gdy dokumentacji brakuje, dostęp do części zasobów jest utrudniony, a wiedzę o systemie trzeba odtwarzać głównie na podstawie kodu, konfiguracji i logów.

Nie wiesz, czy Twój system kwalifikuje się do szybszej czy wolniejszej ścieżki? Najłatwiej to sprawdzić w krótkiej rozmowie - bez zobowiązań, wystarczy opisać nam, z czego zbudowana jest aplikacja.

Co sprawdzamy podczas audytu

Audyt nie polega wyłącznie na przejrzeniu kodu. Sprawdzamy również sposób wdrażania aplikacji, stan infrastruktury, bezpieczeństwo danych oraz to, jak zespół reaguje na błędy i awarie.

Najczęściej analizujemy między innymi:

• jakość i czytelność kodu,
• dostępność testów automatycznych,
• sposób budowania i wdrażania kolejnych wersji aplikacji,
• aktualność bibliotek, frameworków i pozostałych zależności,
• konfigurację środowisk oraz kompletność dostępów,
• sposób wykonywania backupów i możliwość ich skutecznego odtworzenia,
• monitoring działania systemu i dostępność logów,
• dokumentację techniczną oraz wiedzę o kluczowych procesach biznesowych.

Wynikiem audytu nie jest ogólna ocena, że system jest „dobry” albo „zły”. Przygotowujemy listę konkretnych ryzyk, określamy ich wpływ na stabilność i bezpieczeństwo aplikacji oraz wskazujemy, które działania są pilne, a które można zaplanować w dalszej kolejności.

W pracy korzystamy też z aktualnych narzędzi analitycznych, w tym rozwiązań wspieranych AI, które przyspieszają wstępne rozpoznanie kodu, zależności i potencjalnych podatności. Użycie takich narzędzi każdorazowo omawiamy i uzgadniamy ze zleceniodawcą. Ostateczną ocenę ryzyk oraz rekomendacje zawsze formułuje inżynier/expert prowadzący audyt, w oparciu o swoje doświadczenie.

Jak organizujemy pracę i dobieramy narzędzia

Po audycie porządkujemy sposób obsługi systemu: monitoring, zgłoszenia, wdrożenia, backupy i komunikację z zespołem klienta.

Do monitoringu i porządkowania obrazu systemu wykorzystujemy narzędzia klasy Grafana i Zabbix, zgłoszenia standardowo prowadzimy w Redmine, Jira, a wdrożenia automatyzujemy przez Bitbucket Pipelines. Nie traktujemy tego jako pakietu narzuconego każdemu klientowi - dobieramy zestaw do tego, co faktycznie pasuje do istniejącego środowiska. Jeśli w firmie funkcjonuje już własny system zgłoszeń - pracujemy w nim, żeby nie dokładać Ci kolejnego narzędzia do ogarniania.

Model opieki i SLA po audycie

Jak dopasowujemy model opieki po audycie

Punktem wyjścia do rozmowy są trzy orientacyjne pakiety - Basic, Standard i Premium - różniące się częstotliwością backupu, pulą godzin na drobny rozwój i czasem reakcji na zgłoszenia. To jednak właśnie punkt wyjścia, nie gotowy cennik z półki.

Realny zakres - liczba godzin, częstotliwość backupu, czasy reakcji, lista technologii objętych opieką - ustalamy po audycie, dopasowując go do faktycznego ryzyka i budżetu, z jakim pracujesz. Rozmawiamy o Twoim systemie, nie odpytujemy z gotowego formularza.

Jak działa SLA w praktyce

SLA (Service Level Agreement) określa gwarantowany czas reakcji na zgłoszenie w zależności od jego priorytetu:

Ważne zastrzeżenie, które warto znać niezależnie od dostawcy: czas reakcji to moment, w którym inżynier przejmuje zgłoszenie - nie czas naprawy. Ten drugi zależy od złożoności problemu i nie da się go uczciwie zagwarantować jedną liczbą dla wszystkich przypadków.

Dlaczego długofalowa opieka wychodzi taniej niż gaszenie pożarów

Firmy decydują się na stałe utrzymanie zamiast doraźnych napraw z pięciu powodów: przewidywalność kosztów (stała pula godzin zamiast wyceny w panice), krótszy czas naprawy (partner znający system działa szybciej niż ktoś nowy), bezpieczeństwo (aktualizacje i monitoring podatności zapobiegają lukom, zanim staną się incydentem), stabilna roadmapa (drobny rozwój bez uruchamiania nowego projektu przy każdej zmianie) oraz jeden właściciel tematu - bez szukania winnego w trakcie awarii.

Dobrym przykładem długofalowej opieki jest platforma Centrum Terapii Dialog, którą utrzymujemy i rozwijamy od 2019 roku. W tym czasie system obsłużył ponad 140 tysięcy pacjentów, prawie 900 tysięcy wizyt online. Wieloletnia współpraca pozwoliła zespołowi dobrze poznać architekturę systemu, jego procesy biznesowe oraz obszary szczególnie istotne dla stabilności działania. Dzięki zachowaniu ciągłości wiedzy możemy sprawniej reagować na problemy, bezpieczniej wdrażać zmiany i dostosowywać aplikację do rosnącego obciążenia.

[FAQ] - Najczęściej zadawane pytania o utrzymanie aplikacji

Czy możecie przejąć utrzymanie systemu po innym wykonawcy?

Tak. Proces obejmuje audyt kodu i infrastruktury, wykaz ryzyk i długów technicznych, opcjonalny okres pracy równoległej z poprzednim wykonawcą i start SLA z pełną odpowiedzialnością. Trwa zwykle 2-6 tygodni.

Czym różni się utrzymanie od rozwoju aplikacji?

Utrzymanie to ciągła opieka nad istniejącym systemem - monitoring, aktualizacje, naprawy, drobne korekty w ramach miesięcznej puli godzin. Rozwój to budowa nowych funkcjonalności jako osobny projekt z własnym budżetem i harmonogramem.

Ile trwa przejęcie systemu od innego software house'u?

Standardowo 2-6 tygodni. Czas zależy od jakości dokumentacji pozostawionej przez poprzedniego wykonawcę oraz od złożoności samej aplikacji.

Czy utrzymanie aplikacji to tylko usuwanie błędów?

Nie. Oprócz obsługi incydentów obejmuje proaktywny monitoring, aktualizacje bezpieczeństwa zanim pojawi się luka, regularne backupy, raportowanie oraz drobny rozwój w ramach ustalonej puli godzin.

Czy pakiet utrzymania można dopasować do wielkości naszej firmy?

Tak. Pakiety Basic, Standard i Premium są punktem wyjścia - pulę godzin, częstotliwość backupu, czasy reakcji i zakres technologii ustalamy indywidualnie po audycie systemu.

Czy musicie zmieniać nasze obecne narzędzia i procesy?

Nie. Jeśli korzystasz już z systemu zgłoszeń, monitoringu lub procesu CI/CD, możemy pracować w istniejącym środowisku. Podczas audytu sprawdzamy, czy obecne rozwiązania są wystarczające, a zmiany proponujemy tylko tam, gdzie mogą realnie poprawić bezpieczeństwo, stabilność albo szybkość obsługi.

Jeśli rozpoznajesz swoją sytuację w tym, co opisaliśmy powyżej - masz system po innym wykonawcy, brakuje dokumentacji albo po prostu chcesz mieć pewność, że ktoś odpowiada za jego stabilność - napisz do nas albo umów krótką rozmowę.

Nie musisz mieć gotowej listy pytań ani przygotowanego briefu - wystarczy, że opowiesz, jak wygląda Twój system dziś.