Artykuł (jak i wiele innych na tym blogu) powstał z obserwacji tego jak wiele firm czy klientów rozumie określenie „gwarancja” a jak „wsparcie techniczne”. Wielu je całkowicie myli albo stawia pomiędzy nimi znak równości. Bez względu jednak jak są interpretowane te słowa, oczekiwanie jest jedno – opieka nad oprogramowaniem i zapewnienie szybkiej reakcji w razie awarii. I faktycznie obie te usługi są niejako opieką nad oprogramowaniem ale w bardzo różnorodnym zakresie o których tu napiszę. Poniższy tekst jest skierowany głównie do osób i firm rozpoczynających swoją przygodę z projektami internetowymi.

Czym jest gwarancja?

Gwarancja jest usługą polegającą na zapewnieniu klienta w określonych ramach czasowych (np. 1 roku), że produkt będzie w tym czasie w pełni sprawny. Jeśli przyjmiemy zakres funkcjonalny, który klient akceptuje przy podpisaniu protokołu odbioru jako zgodny z oczekiwaniami i ostateczny wówczas w jego zakresie, wszystkie istniejące już funkcjonalności powinny zachowywać się zgodnie z oczekiwaniami. Jeśli teraz jakaś funkcjonalność lub jej fragment przestaje działać  i uniemożliwia realizację scenariusza testowego wówczas można taki problem potraktować jako usterka w ramach gwarancji. Dodajmy jeszcze kwestie serwera na którym ta aplikacja działa – jest to środowisko nierozłączne z samą aplikacją i jego zmiana lub istotna modyfikacja również może spowodować błędy często nieobjęte gwarancją. Kilka najprostszych przykładów usterek gwarancyjnych:

• Obiekt nie chce się usunąć
• Edytowany formularz się nie zapisuje
• Wyszukiwany dokument przestał pojawiać się na liście wyników
• Sortowanie produktów alfabetycznie wczytuje listę błędnie posortowaną
• Paginacja artykułów w sklepie nie działa
• Użytkownik nie może aktywować swojego konta ponieważ pojawia się na ekranie błąd 
• Nie dochodzi e-mail z aktywacją konta
• Wybierając filtr produktów nic się nie dzieje
• i tak dalej…

Jak widzicie błędy podlegające gwarancji to uszkodzenia istniejących już funkcjonalności. Coś co było i działało na etapie odbioru a z jakiś powodów później przestało działać. Następnie takie zgłoszenia gwarancyjne realizowane są zgodnie z procedurami. Opisaliśmy je tu: https://gogomedia.pl/blog/zarzadzanie-projektami/jak-obslugiwac-i-zglaszac-bledy-w-web-aplikacji/ Są jednak również rzeczy interpretowane przez klienta jako błędy podlegające gwarancji a w rzeczywistości nimi nie są. Kilka przykładowych typów błędów:

• Wyszukiwanie produktów działa wolno (o ile w umowie nie było wymogów wydajnościowych taka praca kwalifikuje się pod prace optymalizacyjne)
• W sortowaniu brakuje opcji sortowania po cenie (to jest brak funkcjonalności sortowania po cenie a nie jej błędnego działania. Jeśli było by w aplikacji zaimplementowane już „sortowanie po cenie” a źle działało – wówczas kwalifikowało by się pod gwarancję. W tym wypadku nie)
• Produkt można przypisać tylko do jednego producenta a my musimy przypisać do dwóch (to również brak konkretnej funkcjonalności polegającej na przypisaniu do wielu producentów)
• Po aktualizacji PHP 5.1 do PHP 5.6 na serwerze aplikacja przestała działać (to zależy od warunków umowy ale w wielu przypadkach oprogramowanie tworzy się zgodnie z najnowszymi w danej chwili technologiami, jeśli pojawi się coś nowego później co klient na własną odpowiedzialność wdroży – jest to element za który gwarant odpowiedzialności brać nie może)
• Nieautoryzowane modyfikacje kodu źródłowego (jeśli ktoś poza firmą wykonującą oprogramowanie modyfikuje je na swój użytek wówczas prawie zawsze gwarancja jest zrywana natychmiastowo)
• Brakujące dane w web aplikacji, np. podmiana regulaminu (cokolwiek co wymaga przez podwykonawcę uzupełnienia lub zmiany)
• oraz wszelkie zmiany treści, zasad działania funkcjonalności i wszystko co wymaga modyfikacji logiki aplikacji (dla przykładu: na etapie odbioru wszystkie pola formularza rejestracji były wymagane,  po pewnym czasie klient prosi jednak o usunięcie wymogu wypełnienia jednego pola – np. imienia i nazwiska )

Pamiętajmy: Błędami nie są modyfikacje, zmiany, optymalizacje, usprawnienia czy „uzupełnienia funkcjonalności”. Bardzo często zdarza się, że po odbiorze projektu klient wraca i mówi, że brakuje „takiej i takiej” funkcjonalności. Jeśli nie ma jej opisanej w umowie a tym bardziej nie ma żadnych zastrzeżeń w protokole odbioru to po prostu nie powinno jej tam być. Wykonawca pomimo swoich dobrych intencji nie jest wracać do ustaleń słownych ze spotkań sprzed np. pół roku i dochodzić czy coś miało być zrobione czy nie. Zakres funkcjonalny i jego wykonanie potwierdza protokół odbioru i do klienta należy upewnienie się czy otrzymany produkt całkowicie zgadza się z jego oczekiwaniami a odręczny podpis na protokole potwierdza, że nie ma zastrzeżeń do odbieranego produktu. Oczywiście są sytuacje kiedy projekt odbierany jest z zastrzeżeniami ale wówczas muszą być one jasno spisane w protokole a ich realizacja zaplanowana w czasie. Następnie, kiedy dane zgłoszenie zakwalifikuje do naprawy gwarancyjnej wpada do grupy priorytetów. Polega ona na tym, że błędy uniemożliwiające działanie projektu są realizowane najszybciej (np. w ciągu 1 dnia) natomiast te mniej istotne w ciągu 2 tygodni (tutaj jest to opisane dokładniej). I tak w praktyce jest, że zgłaszane błędy i zastrzeżenia o niskim priorytecie są najpierw zbierane a następnie a później podczas ustalonego okienka serwisowego poprawiane i  wdrażane. A dlaczego tak się dzieje? Ze względu na organizację pracy. Jeśli podwykonawca nie świadczy usług wsparcia premium wówczas w okresie gwarancji nie ma nikogo, kto by się Twoim oprogramowaniem na bieżąco opiekował.

Wsparcie techniczne

Spotkaliśmy się z różnym nazewnictwem – „support premium”, „gwarancja premium”, „rozszerzony mainteance” itd. Polega to głównie na znacznie większej opiece nad gotowym produktem/projektem ze strony wykonawcy. Ta „większa opieka” ma wiele znaczeń ponieważ rodzajów wsparcia technicznego jest sporo i bardzo często klient sam dobiera sobie jej zakres pod realne potrzeby. Podstawowe parametry (cechy) wsparcia:

• Czas reakcji i podjęcie realizacji zgłoszenia
• Ilość roboczogodzin miesięcznie na prace rozwojowe
• Zakres prac serwisowych
• Monitoring bieżący aplikacji
• Opieka nad produktem (szybkość odpowiedzi na zadawane pytania, wspieranie użytkowników, udzielanie rad i porad w ramach aplikacji)
• Na podstawie zbieranych danych i monitoringu opracowywanie rekomendacji rozwojowych w obszarze technologicznym
• Jeśli wsparcie techniczne to obejmuje, również dbanie o kompatybilność oprogramowania z nowymi wersjami przeglądarek, interpretatorów języka, bazami danych itd. – czyli przedłużanie żywotności i gotowości do rozwoju oprogramowania
• Obsługa serwerowa

Finalnie korzystanie ze wsparcia technicznego to gwarancja spokoju i świadomość, że specjaliści nad nią na bieżąco czuwają i szybko reagują na wszelkie pojawiające się problemy. Co więcej to stabilność rozwoju oraz drobnych modyfikacji oprogramowania w ramach pakietów miesięcznych roboczogodzin zespołu IT. W przypadku wsparcia technicznego każde zgłoszenie uwagi, zmiany, modyfikacji jest rozpatrywane i realizowane z wysokim priorytetem.  W przeciwieństwie do gwarancji nic nie czeka długich dni na sprawdzenie lub zrealizowanie. Nie ma ryzyka odrzucenia jakiejkolwiek zmiany czy rozbudowy. Jeśli jednak okaże się, że zgłaszane uwagi przekraczają  dostępny miesięczny pakiet godzinowy – wówczas klient dopłaca tylko różnicę wg. zazwyczaj stawek preferencyjnych. Moim zdaniem wsparcie techniczne jest usługą nie tyle przydatną co konieczną dla każdego dynamicznie rozwijającego się start-up’u. Nawet jeśli firma inwestująca w projekt nie widzi na początku takiej potrzeby – prawie zawsze zaczyna rozważać jej uruchomienie już po kilku tygodniach od uruchomienia oprogramowania.

Koszty wsparcia technicznego vs. gwarancji

Bez dwóch zdań gwarancja przy dobrze napisanej aplikacji wiąże się z bardzo niskimi kosztami obsługi dla wykonawcy. Jej koszty oblicza się na podstawie prognozowanych i możliwych problemów z wyprodukowanym oprogramowaniem tym samym w skali miesiąca udział podwykonawcy w pracach gwarancyjnych powinien być znikomy. Wyjątkiem jest fakt kiedy oprogramowanie napisane jest błędnie i przez dłuższy okres zgłaszana jest duża ilość zastrzeżeń i błędów co angażuje wykonawce znacznie czasowo. Z naszego doświadczenia log-worki gwarancyjne w skali roku rzadko przekraczają 50 roboczogodzin czasu pracy developerów (dla projektu na poziomie 1000-1300 roboczogodzin). Zupełnie inaczej mają się koszty wsparcia technicznego czyli po prostu opieki firmy podwykonawcy nad projektem. W tym wypadku zespół IT bardzo aktywnie bierze udział w pracach nad produktem i jego rozwojem. Jego zaangażowanie czasowe oraz zakres opieki ustalany jest indywidualnie w umowie z właścicielem serwisu/aplikacji. Popularny model wsparcia polega między innymi na:

• miesięcznym pakiecie roboczogodzin developerów przy rozwoju i utrzymaniu oprogramowania
• pełnego monitoringu zdarzeń w aplikacji i przeciwdziałanie sytuacjom niepożądanym
• kompleksowej opiece od strony serwerowej
• bardzo szybka reakcja na wszystkie zgłoszenia klienta i priorytetowa ich realizacja
• ciągłe prace jakościowe utrzymujące oprogramowanie na wysokim poziomie jakości i kompatybilności ze zmieniającym się oprogramowaniem towarzyszącym (np. interpreter PHP)

Ile to kosztuje? Jest to usługa bardzo spersonalizowana i dopasowywana do potrzeb projektu nie mniej jednak trzeba być gotowym na znacznie większe wydatki niż w przypadku podstawowej usługi gwarancyjnej. Koszty opieki i wsparcia technicznego zazwyczaj wycenia się w stawkach miesięcznych. Wsparcie techniczne w oprogramowaniu można przyrównać troszkę do administrowania budynkiem (czy to biurowcem czy osiedlem) – niby bez tej administracji wszystko będzie dobrze ale tylko przez krótki czas. Prędzej czy później będzie konieczna.