Jak wygląda życie po wdrożeniu aplikacji do użytku? To moment, kiedy deweloperzy przekazują pałeczkę zespołowi utrzymania. Jeśli chcesz dowiedzieć się, jak wygląda maintenance od kuchni, czym jest SLA, CR i incydent - zapraszamy do lektury najnowszego artykułu na blogu.
Naturalnym (i niezbędnym) krokiem tuż po starcie gotowej aplikacji jest przeformatowanie współpracy z jej autorami w kierunku tzw. maintenance, czyli utrzymania kodu i bieżącej nad nim opieki. Warto przy tym zauważyć, że “start” aplikacji nie oznacza, że zadziała ona perfekcyjnie i nie pojawi się ani jeden bug. Start produktywny poprzedza seria testów (o których szerzej pisaliśmy TUTAJ) wykonywanych przez specjalistów z software house’u, zaś ostateczną wersję aplikacji testują już końcowi użytkownicy.
Pomimo dokładania wszelkich starań, aby wyeliminować wszystkie możliwe niedociągnięcia, może się zdarzyć, że w toku korzystania z produktu ujawnią się pewne defekty. Z czego to wynika? Aplikacja, choć tworzona zgodnie z wymaganiami klienta i testowana z uwzględnieniem większości możliwych scenariuszy, może zaskoczyć nas w warunkach “bojowych”. Użytkownik może rozpocząć scenariusz nieprzewidziany w fazie testów i tym samym wygenerować konieczność naprawienia luki.
Te i inne niespodzianki towarzyszą startowi niemal każdej aplikacji. Warto podkreślić, że nie wynikają one z braku wiedzy czy zaniedbań popełnionych przez deweloperów. Każdy projekt IT to bardzo złożona realizacja, wielokrotnie zmieniana i udoskonalana w toku jej tworzenia; pewne błędy są zatem nieuniknione i niejako wpisane w cykl życia aplikacji. O profesjonalizmie software house’u świadczy sprawność w usuwaniu usterek i proaktywne podejście do tego ważnego i trudnego etapu współpracy.
Po zakończeniu etapu wszystkich testów możemy zadać sobie pytanie: “Po co płacić za utrzymanie nowej aplikacji, przecież wszystko jest nowe i działa?”. Jednak warto zwrócić uwagę na fakt, że aplikacja, przy całej swojej złożoności, wymaga stałego doglądania, aktualizowania i rozwijania, aby móc służyć biznesowi przez lata.
Proces utrzymania aplikacji rozpoczyna się płynnie. Z jednej strony wydaje się go wyznaczać czas zakończenia szkoleń użytkowników i utworzenia dokumentacji projektowej, z drugiej jednak - maintenance trwa już w momencie wdrażania pierwszych poprawek, kiedy to deweloperzy wprowadzają pierwsze usprawnienia.
Najczęściej procesy utrzymania aplikacji są obsługiwane przez ten sam software house, który dane narzędzie tworzył. To naturalna droga kontynuacji współpracy, która gwarantuje klientowi dostęp do dobrze już znanych specjalistów (choć może się zdarzyć, że procesami utrzymania rozwiązań zajmuje się odrębny zespół w ramach jednej firmy), standardów współpracy, a przede wszystkim - do twórców danego rozwiązania, co niejednokrotnie ma niebagatelne znaczenie. W końcu nikt nie zna aplikacji tak dobrze, jak jej kreatorzy.
Niezależnie od tego, czy utrzymania podejmuje się ten sam software house, czy klient nawiązuje współpracę z nowym partnerem, proces przekazania aplikacji z obszaru produkcji do utrzymania rządzi się swoimi prawami i powinien przebiegać zgodnie ze sztuką.
Podczas procesu tworzenia aplikacji powstaje szczegółowa dokumentacja całego projektu, która dokładnie opisuje poszczególne funkcjonalności, panujące pomiędzy nimi zależności - słowem każdy element tworzonej aplikacji. To zarówno niezastąpione źródło wiedzy dla zespołu utrzymaniowego jak i dla samych użytkowników, którzy co do zasady powinni w dokumentacji odnaleźć odpowiedź na wiele pytań. W zależności od stopnia zaawansowania technologicznego aplikacji dokumentacja projektowa może liczyć nawet setki stron, a jakość jej przygotowania to także wyznacznik dobrej jakości pracy software house’u.
Gdy dokumentacja jest już gotowa, przychodzi pora na transfer wiedzy. To cykl szkoleń i przekazywania know-how o całym projekcie z jednej strony na linii deweloperzy - utzrymaniowcy, z drugiej zaś - szkolenia użytkowników końcowych, którzy muszą dobrze poznać wszelkie meandry nowego rozwiązania, aby móc sprawnie z niego korzystać.
Etap transferu wiedzy jest ogromnie ważny i nie można go pominąć. Zarówno zespół, który ma zająć się utrzymaniem, jak i użytkownik, muszą w zakresie swoich potrzeb otrzymać ze strony deweloperów maksymalne możliwe wsparcie, odpowiedzi na wszystkie pytania i pełen zestaw informacji niezbędny do korzystania z gotowego produktu z sukcesem.
Wiemy już jak istotne jest powierzenie zespołowi fachowców obszaru maintenance, warto jednak w skrócie uporządkować obszary, które podlegają jego “jurysdykcji”:
Aktualizacje - każde środowisko IT, na bazie którego działa jakakolwiek aplikacja, starzeje się. Konieczność dopasowania do nowych wymagań systemowych, technologii… to konieczność przeprowadzania systematycznych aktualizacji. O tym jak ważne są update’y można przekonać się choćby na przykładzie własnego smartfona, który co chwilę prosi nas o zaktualizowanie używanych aplikacji, czy systemu operacyjnego. Zespół utrzymania aplikacji czuwa nad pojawiającymi się aktualizacjami i nowymi wersjami i proaktywnie działa na rzecz zachowania aktualności i integralności środowiska, w którym funkcjonuje aplikacja.
Migracje - czasem może okazać się konieczne np. przeniesienie danych aplikacji innego środowiska czyli tzw. migracja. To bardzo trudny i wymagający proces, wymagający uruchomienia środowisk testowych, dokładnego zaplanowania całego procesu i przewidzenia wszelkich możliwych niepowodzeń. Procesy migracyjne powinno się powierzać sprawdzonemu partnerowi, ponieważ przeprowadzone błędnie - mogą zagrozić integralności danych wytwarzanych przez firmę na przestrzeni lat.
Incydenty, błędy i CR-y - to podstawowy obszar maintenance.Codzienna praca zespołu utrzymaniowego polegająca na czuwaniu nad stabilnością systemu, monitorowaniu potencjalnych zagrożeń, wyłapywaniu błędów i wprowadzaniu drobnych usprawnień. Szerzej o tych pojęciach piszemy niżej, ale warto nadmienić, że kiedy pojawia się pojęcie “utrzymanie systemów IT”, to właśnie ten obszar jest najprawdopodobniej naszym pierwszym skojarzeniem.
monitoringchangecha
Tak często występujące obok siebie i tak często mylone: “incydent” i “błąd, defekt”. Na początek warto zauważyć, że każdy błąd jest traktowany jako incydent, ale nie każdy incydent jest błędem.
Incydentem nazywamy, w ślad za “Słownikiem pojęć testerskich”, każde zdarzenie w systemie, które wymaga zbadania. Niekoniecznie musi prowadzić ono do wykrycia błędu lub wręcz awarii oprogramowania, ale zgodnie ze sztuką i wszelkimi prawidłami maintenance, musi zostać zweryfikowane i sklasyfikowane: czy to jako niewielki bug, czy ostrzeżenie, czy też preludium do realnych problemów.
Wykrywanie incydentów następuje często dzięki systemom monitorowania środowiska IT, które alarmują zespół utrzymaniowy o przekroczeniu ustalonych wskaźników; wykrywają je także sami użytkownicy, którzy zgłaszają potencjalne zagrożenia zespołowi specjalistów, a ci je sprawdzają, opisują i - jeśli zaistnieje taka potrzeba - wdrażają odpowiednie działania.
Monitoring incydentów to klucz do sprawnego funkcjonowania każdego rozwiązania IT. Często pozwala on zareagować w porę na potencjalne zagrożenie jeszcze zanim doprowadzi ono do poważnej awarii, której skutki mogą poważnie odbić się na funkcjonowaniu biznesu klienta.
Change Request (ang. żądanie zmiany), potocznie zwane CR-em, to mniejsze i większe usprawnienia i zmiany inicjowane przez użytkowników, które wpływają na komfort korzystania z systemu. W toku korzystania z aplikacji może się okazać, że np. przycisk z poleceniem “drukuj” powinien znajdować się na dole, a nie na górze okienka, bądź przycisku “drukuj” brakuje, a aby wywołać to polecenie użytkownik musi niepotrzebnie wykonać kilka kliknięć.
To właśnie moment, w którym powstaje potrzeba złożenia CR-a, którego przedmiotem jest przeniesienie lub dodanie przycisku. Działanie z pozoru proste, ale z jednej strony ogromnie podnoszące komfort korzystania z aplikacji, z drugiej zaś - wymagające wdrożenia procedury wykonania zmiany przez zespół maintenance. Każda zmiana w aplikacji musi bowiem zostać uwzględniona w dokumentacji projektowej i dokładnie opisana, a także zostać poddana standardowym procedurom testowym.
Dobrze, gdy software house ma specjalny system do zarządzania CR-ami, czyli miejsce gdzie można je zgłosić i np. obserwować postęp prac. Jednak w przypadku mniejszych projektów często wystarczy komunikacja mailowa lub ustalenia poczynione podczas spotkań.
Service Level Agreement, SLA (pol. umowa o gwarantowanym poziomie świadczenia usług) to podstawowe pojęcie związane z nawiązywaniem współpracy z software house’em, zwłaszcza jeśli mowa o obszarze utrzymania. SLA pomaga nakreślić ramy współpracy, pożądane wskaźniki oraz sprecyzować oczekiwania klienta i przełożyć je na zapisy umowy.
SLA może wskazywać na minimalny czas dostępności systemu, szybkość reakcji na poszczególne zgłoszenia, czy procent błędów usuniętych z systemu poniżej określonego czasu. Ten obszar umowy o współpracy często podlega twardym negocjacjom, ale jest niezbędny do dobrze zaplanowanej współpracy.
Bez ram nadawanych przez SLA współpraca może rozczarować klienta, a brak sztywnych ram może być przyczyną wielu nieporozumień, które w efekcie mogą znacznie utrudnić współpracę i proces rozwiązywania incydentów oraz innych działań. Dlatego negocjacjom SLA warto poświęcić tyle czasu, ile jest koniecznie.
Wiemy już czym są tajemnicze CR-y, SLA czy tytułowy maintenance. Jak jednak wybrać firmę, która przejmie opiekę nad obszarem utrzymania aplikacji zapewniając możliwie najwyższy standard realizacji tych usług?
Często decydujemy się na kontynuację współpracy z software house’em, który stworzył oprogramowanie. Jeśli jednak z jakiegoś powodu musimy szukać następny na rynku, warto zwrócić uwagę na te trzy podpowiedzi:
Udokumentowane doświadczenie firmy i zespołu
Nie bój się poprosić o referencje, przeczytaj case study z poprzednich realizacji - to wszystko pomoże zweryfikować, czy software house ma odpowiednie kompetencje do tego, aby zaopiekować się Twoją aplikacją. Dobrym pomysłem jest też odbycie wizyt referencyjnych lub referencyjnych rozmów telefonicznych, podczas których można poznać opinię o firmie przekazaną bezpośrednio przez klienta.
O sile firmy stanowi nie tylko jej portfolio, ale także i ludzie: regularne certyfikacje deweloperów, wszelkie potwierdzone umiejętności a nawet dzielenie się przez nich wiedzą na konferencjach i branżowych spotkaniach - to punkty w CV potencjalnego zespołu, na które warto zwrócić szczególną uwagę.
Transparentna forma współpracy
Sprawdź według jakich metodyk pracuje software house i czy ten sposób działania ci odpowiada. Dowiedz się, czy będziecie działać w metodykach zwinnych czy kaskadowych, w jaki sposób będziesz mógł monitorować jakość i postęp prac, za pomocą jakiego narzędzia zgłosisz incydent czy prośbę o CR. Wybierz firmę, z którą będzie Ci się dobrze współpracowało.
Praca oparta o SLA i jasne zasady
Wynegocjuj dobre warunki SLA, ale bądź pewny, że software house będzie w stanie je wypełnić. Nawet jeśli zaproponujesz wyśrubowane normy, które będą niemożliwe do spełnienia, szanse na udaną i satysfakcjonującą współpracę są niewielkie.
Wypracujcie wspólnie jasne zasady współpracy, zarówno te zawarte w postanowieniach umowy, jak i te mniej formalne. Obszar utrzymania i serwisu to długofalowa kooperacja często w bardzo trudnych momentach. Bez solidnych ram współpracy będzie Wam trudno działać na rzecz “zdrowej” i dobrze rozwijającej się aplikacji.
Czytaj więcej:
Wszystko co musisz wiedzieć o wdrażaniu systemu IT i jego kosztach
Jeśli chcesz być na bieżąco z treściami Programy™, obserwuj nas.