Kod źródłowy jest ważną częścią aplikacji, ale sam folder z plikami nie daje jeszcze kontroli nad systemem. Firma potrzebuje wiedzieć, gdzie działa produkt, kto opłaca usługi i jak uruchomić nowe wydanie. Jeśli odpowiedzi są wyłącznie w głowie jednej osoby, przekazanie nie zostało zakończone. Nawet gdy ta osoba jest bardzo pomocna. Urlop nadal potrafi być skuteczniejszym testem dokumentacji niż najbardziej uroczyste podpisanie protokołu.
Dlatego zasady przekazania warto ustalić już wtedy, gdy zamawiasz aplikację dla firmy. Obejmują zakres kodu, dokumentację, konta oraz uzgodnienia dotyczące praw do korzystania i dalszych zmian. Warunki umowy powinny odpowiadać temu, jak firma chce rozwijać produkt. Nie zakładaj, że dostęp do panelu administracyjnego automatycznie oznacza dostęp do wszystkich elementów potrzebnych innemu zespołowi.
Repozytorium powinno pozwalać odtworzyć wydanie
Poproś o pokazanie, który zapis w repozytorium odpowiada wersji uruchomionej dla użytkowników. Ważna jest także instrukcja przygotowania środowiska oraz lista wymaganych ustawień. Wartości poufne, takie jak klucze dostępu, przekazuje się uzgodnioną bezpieczną drogą, nie dopisuje do publicznego pliku. Nowy zespół powinien móc zrozumieć, czego potrzebuje aplikacja, bez odkrywania infrastruktury metodą kolejnych komunikatów błędu.
Dobrą próbą jest odtworzenie środowiska przez osobę, która wcześniej go nie konfigurowała. Autor może obserwować, ale nie powinien wykonywać całej pracy za nią. Takie zadanie uzupełnia odbiór funkcjonalny aplikacji. Wykrywa brakujące kroki, zależności oraz nieaktualne instrukcje. Nie potrzeba przy tym dokumentu opisującego każdą linijkę kodu. Potrzebne są informacje, które pozwalają bezpiecznie uruchomić i zmienić system.
Konta i dane potrzebują wskazanego gospodarza
Hosting, domena, poczta transakcyjna i połączenia z innymi usługami powinny mieć ustalonego właściciela. Sprawdź, kto ma dostęp administracyjny, kto otrzymuje informację o płatności i do kogo trafi ostrzeżenie o problemie. W małej firmie nie musi to oznaczać rozbudowanej administracji. Wystarczy odpowiedzialność przypisana konkretnej roli oraz sposób zastępstwa. Skrzynka dawnego współpracownika nie jest dobrym miejscem na jedyny kontakt do infrastruktury.
Przy połączeniach z zewnętrznymi programami potrzebna jest również mapa zależności. Wskażcie, co aplikacja pobiera, co wysyła i jakie prawa otrzymało dane konto techniczne. Zagadnienia opisane w tekście o integracji i własności danych wracają tu bardzo praktycznie: jeśli zmienicie wykonawcę albo dostawcę usługi, trzeba wiedzieć, które połączenia odtworzyć i które dostępy odebrać. Inaczej porządki mogą przypadkiem zatrzymać działający proces.
Kopia zapasowa ma znaczenie po udanej próbie odtworzenia
Informacja o wykonywaniu kopii nie mówi jeszcze, jak firma wróci do pracy po błędzie. Ustalcie, co jest kopiowane, jak długo pozostaje dostępne i kto może rozpocząć odtwarzanie. Osobno potraktujcie pliki użytkowników, bazę danych oraz ustawienia usług. Przydatnym elementem przekazania jest próba na uzgodnionym środowisku, z zapisem jej wyniku. W ten sposób sprawdzacie procedurę, zamiast kupować sobie uspokajające zdanie w dokumentacji.
Nie każda zmiana wymaga awarii, żeby stała się problemem. Może zostać usunięty dokument, błędnie zaimportowana lista albo nadpisana konfiguracja. Warto wiedzieć, które z tych zdarzeń da się odwrócić i co wymaga osobnego działania. Zakres takich zabezpieczeń powinien znaleźć się w rozmowie o koszcie wykonania i utrzymania aplikacji, bo wpływa na pracę zespołu oraz sposób prowadzenia infrastruktury.
Utrzymanie opisuje pracę, nie magiczną opiekę
Dla osoby przejmującej system przygotujcie też mapę zwykłego dnia: gdzie sprawdza nowe zgłoszenia, jak rozpoznaje błędy i komu przekazuje problem wykraczający poza jej rolę. Dokumentacja techniczna oraz instrukcja operatora odpowiadają na różne pytania. Obie można sprawdzić podczas jednej próby. Jeśli chcesz uporządkować takie przekazanie, opisz obecny sposób obsługi aplikacji i wskaż czynności, które nadal zależą od pomocy poprzedniego wykonawcy.
Umowa wsparcia powinna wyjaśniać, jak zgłasza się usterkę, kto ustala jej pilność i co oznacza czas reakcji. Reakcja na zgłoszenie nie musi być równoznaczna z zakończeniem naprawy. Warto nazwać również planowane aktualizacje, kontrolę błędów i sposób publikowania poprawek. Dzięki temu firma odróżnia zwykły rozwój produktu od usuwania awarii, a wykonawca wie, jak organizować pracę przy kilku równoległych potrzebach. O podziale odpowiedzialności, sposobie zgłaszania problemów i znaczeniu czasu reakcji piszemy szerzej w artykule o umowie o utrzymanie aplikacji.
Jeśli przejmujesz istniejący system, zacznij od sprawdzenia aktualnego stanu zamiast od natychmiastowej przebudowy. W artykule o modernizacji aplikacji pokazujemy, jak ustalić bezpieczny zakres pierwszych zmian. Archifutura może pomóc w uporządkowaniu kodu i przekazaniu narzędzia tak, aby własne oprogramowanie pozostawało zasobem firmy, a nie zagadką odziedziczoną po poprzednim etapie projektu.
