Utrzymanie i rozwój aplikacji po wdrożeniu
Wdrożenie jest początkiem kosztu, nie jego końcem. Aplikacja bez utrzymania przestaje działać sama, nawet gdy nikt jej nie zmienia.
Zgłoszenia w jednym miejscu
Rejestr zamiast wiadomości do wykonawcy. Bez niego nie wiadomo, co jest zgłoszone, co zrobione i co czeka.
Po stronie firmy powinna być jedna osoba zbierająca zgłoszenia od zespołu. Kiedy każdy pisze do wykonawcy sam, powstają zgłoszenia sprzeczne, a kolejność prac ustala się przypadkiem.
Podział zgłoszeń
- usterka — działa inaczej niż powinno,
- zmiana — ma działać inaczej niż ustalono,
- nowa funkcja — czegoś brakuje.
Mieszanie tych trzech rodzajów uniemożliwia jakiekolwiek planowanie.
Podział ma też skutek handlowy. Usterka mieści się w naprawie tego, co zamówiono. Zmiana i nowa funkcja to osobny zakres, rozliczany stawką godzinową albo wyceną, zależnie od wielkości.
Aktualizacje zależności
Biblioteki i środowisko starzeją się niezależnie od aplikacji. Odkładanie aktualizacji przez dwa lata zamienia je w projekt przepisywania.
Aktualizacje robi się drobnymi krokami, na osobnym środowisku, ze sprawdzeniem przed przełączeniem. Skok przez kilka wersji naraz jest zawsze trudniejszy niż suma małych kroków, które można było zrobić po drodze.
Kopie zapasowe
Wykonywane i sprawdzane pod kątem odtworzenia. Kopia, której nigdy nie przywrócono, jest założeniem, nie zabezpieczeniem.
Trzeba ustalić dwie rzeczy: ile danych możemy stracić i jak długo firma wytrzyma bez aplikacji. Od tych odpowiedzi zależy częstotliwość kopii i sposób ich przechowywania. Warto też trzymać kopię poza tym samym serwerem, na którym stoi aplikacja.
Rytm zmian
Zmiany wprowadzane partiami w ustalonych terminach zamiast pojedynczo w miarę zgłoszeń. Użytkownicy wiedzą, czego się spodziewać, a każda partia jest sprawdzana w całości.
Do rytmu warto dopisać czynności okresowe: przegląd kont i uprawnień oraz sprawdzenie, czy czasy odpowiedzi nie rosną wraz z ilością danych. Jedno i drugie zgłasza się samo dopiero wtedy, gdy jest już problemem.
Zależność od wykonawcy
Kod, dostępy i dokumentacja muszą być po stronie firmy. To warunek, żeby zmiana wykonawcy była decyzją, a nie katastrofą.
Do tego kompletu należą także dane logowania do serwera i domeny oraz krótki opis, jak uruchomić aplikację od zera. Ten opis powstaje przy wdrożeniu w kilkanaście minut, a odtwarzany po latach bywa niemożliwy. Warto sprawdzić, czy komplet jest pełny, zanim pojawi się taka potrzeba — najprościej próbując uruchomić aplikację na czystym serwerze wyłącznie z tego, co firma ma u siebie.
Kiedy nie warto rozwijać
Nie każde zgłoszenie musi trafić do realizacji. Funkcja potrzebna raz w roku jednej osobie zwykle taniej wychodzi jako czynność ręczna. Warto trzymać listę odłożonych zgłoszeń i wracać do niej co jakiś czas — część z nich przestaje być potrzebna sama, wraz ze zmianą procesu opisaną przy wdrożeniu.
