Przed startem ustalamy, kto obsługuje produkt.
Utrzymanie aplikacji to określony zakres pracy, a nie domyślny dodatek bez końca. Firma potrzebuje informacji, kto przyjmuje zgłoszenia, jakie środowisko obejmuje obsługa i jak wygląda kontakt w razie problemu. Godziny dostępności oraz czas reakcji wymagają osobnych ustaleń.
Oddzielamy usunięcie błędu w uzgodnionym działaniu od nowej funkcji. Rozbudowa o drugi oddział, kolejny system lub dodatkową rolę może wymagać projektu i wyceny. Jednocześnie uwaga użytkownika może ujawnić błąd, a nie nowy pomysł; oceniamy ją w kontekście zakresu.
Warto ustalić odpowiedzialność również za domenę, hosting, konta sklepów i zewnętrzne usługi. Brak dostępu do konta może utrudnić aktualizację nawet wtedy, gdy sam kod jest gotowy. Zapis właściciela i osób uprawnionych pomaga zachować ciągłość.
Sprawdzamy działanie ważnych zadań.
Monitorowanie powinno odpowiadać na pytania dotyczące produktu: czy można się zalogować, zapisać sprawę i otrzymać wynik. Sam fakt, że serwer odpowiada, nie dowodzi wykonania tych zadań. W integracji warto widzieć również operacje odrzucone oraz oczekujące na wyjaśnienie.
Google opisuje monitorowanie jako sposób obserwacji działania i rozpoznawania problemów w SRE Workbook. Dobieramy zakres do wielkości oraz ważnych procesów aplikacji, bez kopiowania rozbudowanej infrastruktury tam, gdzie nie jest potrzebna.
Alert ma sens, jeśli wiadomo, kto go odbiera i jakie działanie może wykonać. Duża liczba powiadomień bez odpowiedzialności nie zapewnia obsługi. Ustalamy potrzebne sygnały i granice dostępności zespołu, zamiast sugerować nieuzgodniony nadzór przez całą dobę.
Kopia i odtworzenie są różnymi zadaniami.
Dla produktu z zapisem danych trzeba określić, co obejmuje kopia, kiedy powstaje i kto może z niej skorzystać. Same pliki aplikacji nie zastępują danych użytkownika, a kopia danych może nie wystarczyć bez właściwej konfiguracji i wersji systemu.
Warto przygotować kontrolowaną próbę odtworzenia w odpowiednim środowisku. Pozwala sprawdzić, czy da się wrócić do działania i jakie informacje mogą być utracone pomiędzy kopiami. Częstotliwość oraz zakres zależą od potrzeb firmy i sposobu zapisu.
Nie deklarujemy uniwersalnego czasu odzyskania bez uzgodnienia i sprawdzenia. Dla prostego narzędzia i systemu obsługującego wiele aktywnych spraw wymagania mogą być inne. Nasza statyczna witryna ofertowa nie ma bazy klientów; produkcyjna aplikacja może jej potrzebować.
Zmiana obejmuje również współpracę elementów.
Przeglądarki, systemy telefonów i zewnętrzne usługi zmieniają się. Aktualizacja może dotyczyć biblioteki, integracji albo sposobu działania serwera. Przed wykonaniem sprawdzamy, jakie procesy od niej zależą i które scenariusze wymagają ponownej próby.
W aplikacjach mobilnych część użytkowników pozostaje przez pewien czas na wcześniejszym wydaniu. Serwer powinien obsługiwać uzgodniony okres współpracy wersji. W aplikacji webowej również trzeba uwzględnić otwarte sesje i dane, nad którymi użytkownik pracuje podczas zmiany.
Dla ważnego wdrożenia ustalamy plan powrotu i sposób poinformowania obsługi. Nie każdą zmianę można bezpiecznie cofnąć, zwłaszcza gdy zmienia strukturę danych. Taki przypadek powinien być rozpoznany podczas przygotowania, a nie dopiero po uruchomieniu.
Zgłoszenie użytkownika zachowuje kontekst.
Przydatne zgłoszenie zawiera zadanie, wybrane dane i otrzymany wynik. Użytkownik nie musi znać technologii, ale powinien móc wskazać sprawę lub krok. Ustalamy kanał, który pozwala przekazać potrzebne informacje bez publikowania danych klientów w przypadkowym miejscu.
Zgłoszenia porządkujemy według wpływu na pracę. Brak możliwości potwierdzenia rezerwacji wymaga innej oceny niż niejasna etykieta w pobocznym widoku. Priorytet powinien wynikać z rzeczywistego procesu oraz ustalonego zakresu obsługi, nie tylko z kolejności wiadomości.
Powtarzające się pytania mogą wskazywać problem z projektem, nie potrzebę kolejnej instrukcji. Warto obejrzeć zadanie, które użytkownik próbował wykonać. Projektowanie UX/UI pomaga rozpoznać, czy należy zmienić układ, tekst czy sam przebieg.
Kolejne funkcje wynikają z użycia.
Po starcie sprawdzamy, które zadania rzeczywiście są wykonywane i gdzie pozostaje praca ręczna. Następny etap może obejmować dodatkową integrację, rolę lub krótszy przebieg. Zmiana powinna mieć cel, a nie wynikać wyłącznie z chęci zwiększenia liczby ekranów.
Dla szkoły językowej po zapisach i obecności można rozważyć materiały oraz rozliczenia. Dla firmy sprzątającej po uzgodnieniu zakresu przydać się może harmonogram ekip. Podstrony branżowe pokazują rozdzielenie pierwszego procesu od dalszego wdrożenia.
Plan rozwoju pozostaje listą priorytetów do decyzji, z określeniem kosztu i sposobu oceny. Nie obiecujemy stałego wzrostu wyników biznesowych na podstawie samego dodania funkcji. Utrzymanie zapewnia uzgodnioną obsługę, a rozwój zmienia możliwości produktu.
Jaką decyzję podjąć dalej?
Aby zamieniać uwagi użytkowników w dalszą pracę, przeczytaj Zgłoszenia użytkowników i plan rozwoju aplikacji.
W budżecie po uruchomieniu uwzględnij Koszt utrzymania aplikacji po wdrożeniu.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Utrzymanie aplikacji.