Przejęcie projektu IT
Przejmujemy aplikacje po innym software house albo freelancerze: przegląd kodu, stabilizacja, dokumentacja i dalszy rozwój — bez przepisywania wszystkiego od zera.
Poprzedni wykonawca zniknął, nie dowozi albo projekt po prostu przerósł jednego freelancera. Aplikacja działa, ale nikt nie wie do końca jak, każda zmiana coś psuje, a dokumentacji brak. To częsta sytuacja i da się z niej wyjść bez przepisywania wszystkiego od zera.
Jak przejmujemy projekt
1. Dostępy i inwentaryzacja
Zbieramy dostępy do repozytorium, serwerów, domen, baz danych i usług zewnętrznych. Sprawdzamy, czy wszystko, co jest potrzebne do działania aplikacji, faktycznie należy do Ciebie. Jeśli coś jest zarejestrowane na poprzedniego wykonawcę, pomagamy to przenieść.
2. Audyt kodu i infrastruktury
Przeglądamy architekturę, jakość kodu, wersje frameworka i bibliotek, bezpieczeństwo, wydajność i sposób wdrażania. Na koniec dostajesz raport: co jest w porządku, co jest ryzykowne i co trzeba naprawić najpierw. Szczegóły na stronie audytu aplikacji.
3. Stabilizacja
Zaczynamy od rzeczy, które zagrażają działaniu aplikacji: luk bezpieczeństwa, braku kopii zapasowych, ręcznych wdrożeń, braku monitoringu. Ustawiamy automatyczne wdrożenia i testy przy każdej zmianie, żeby kolejne poprawki nie psuły tego, co działa.
4. Dokumentacja i przekazanie wiedzy
Opisujemy architekturę, sposób uruchomienia i wdrożenia oraz najważniejsze procesy biznesowe w kodzie. Ta wiedza zostaje u Ciebie, a nie w głowie jednego programisty.
5. Rozwój i utrzymanie
Dopiero na ustabilizowanym projekcie wracamy do nowych funkcji. Dalszą opiekę prowadzimy w ramach utrzymania i rozwoju aplikacji.
Przepisać czy naprawiać?
Przepisanie aplikacji od zera kusi, ale rzadko jest najlepszym wyjściem: trwa długo, a w tym czasie stara wersja i tak musi działać. Zwykle rekomendujemy stopniową naprawę — najpierw stabilizacja, potem wymiana najgorszych fragmentów jeden po drugim. Przepisanie proponujemy tylko wtedy, gdy audyt pokazuje, że naprawa będzie droższa. Jeśli aplikacja działa na starej wersji Laravela albo PHP, zwykle zaczynamy od aktualizacji do wspieranej wersji.
Jakie projekty przejmujemy
Najlepiej znamy aplikacje w Laravelu i PHP, frontendy w React, aplikacje mobilne w React Native oraz infrastrukturę na Dockerze. W tym stacku przejmujemy zarówno systemy wewnętrzne firm, jak i produkty dla klientów: platformy, portale i aplikacje mobilne.
Najczęściej zadawane pytania
Poprzedni wykonawca nie chce oddać kodu. Co robić?
Najpierw sprawdź umowę: kto ma prawa autorskie i dostęp do repozytorium. Jeśli aplikacja działa na Twoim serwerze, kod zwykle da się z niego odzyskać. Pomagamy ustalić, co jest potrzebne do przejęcia i co można odtworzyć.
Ile trwa przejęcie projektu?
Zależy od wielkości aplikacji i stanu dokumentacji. Pierwszy etap, czyli dostępy i audyt, planujemy tak, żeby jak najszybciej wiedzieć, czy są pilne ryzyka. Harmonogram stabilizacji ustalamy na podstawie raportu z audytu.
Czy będziecie chcieli przepisać wszystko od nowa?
Nie domyślnie. Przepisanie proponujemy tylko wtedy, gdy audyt pokazuje, że naprawa będzie droższa. Zwykle stabilizujemy aplikację i wymieniamy najgorsze fragmenty stopniowo.
Czy aplikacja przestanie działać w trakcie przejęcia?
Nie powinna. Przejęcie zaczynamy od kopii zapasowych i uruchomienia aplikacji w osobnym środowisku, a zmiany na produkcji wprowadzamy małymi porcjami, które łatwo wycofać.
Co dostanę po pierwszym etapie przejęcia?
Listę dostępów z informacją, co należy do Ciebie, a co trzeba przenieść, raport z audytu z ryzykami uszeregowanymi według ważności oraz plan stabilizacji z kolejnością prac. Na tej podstawie decydujesz, jak idziemy dalej.
Czy przejmujecie też aplikacje mobilne?
Tak, szczególnie w React Native. Sprawdzamy wtedy także dostęp do kont deweloperskich w App Store i Google Play, certyfikaty podpisywania i konfigurację powiadomień push, bo bez nich nie da się opublikować kolejnej wersji.