Czego możesz oczekiwać od dostawcy w ramach gwarancji na aplikację internetową?

Choć proces stworzenia własnego serwisu, strony internetowej, czy aplikacji jest wymagający i angażujący, to warto pamiętać, że to dopiero koniec początku cyklu życia projektu.

Oprogramowanie, podobnie jak samochód, często wymaga regularnego serwisowania.

Przy podpisywaniu umowy na stworzenie strony internetowej, sklepu internetowego lub aplikacji, warto zwrócić uwagę na zapisy mówiące o odpowiedzialności wykonawcy i wymaganiach dotyczących serwisowania (np. aktualizacji oprogramowania czy też zmian w kodzie).

Strony powinny umówić się co do kosztów utrzymania oprogramowania oraz określić czas gwarancji. Zanim przejdziemy dalej warto też rozróżnić gwarancję od SLA.

Gwarancja a obsługa SLA

Gwarancja to zapewnienie wykonawcy, że wytworzone oprogramowanie będzie funkcjonować bez zarzutu co najmniej przez określony umownie czas. SLA, czyli (ang. Service Level Agreement) to osobna umowa określająca zasady współpracy po utworzeniu oprogramowania. Obsługa SLA jest dodatkową usługą, która może rozszerzać podstawową gwarancję, dając przykładowo krótsze czasy reakcji czy określając ilość godzin, którą wykonawca poświęci na rozbudowę lub Twoje zgłoszenia pozagwarancyjne.

Co powinna zawierać gwarancja na stronę internetową, sklep internetowy czy aplikację webową lub inne oprogramowanie?

Przede wszystkim warto dokładnie określić, jakie obowiązki gwarancja nakłada na wykonawcę.

Praktyką przyjętą na rynku są:

  • aktualizacja oprogramowania w trakcie gwarancji,
  • naprawy gwarancyjne w razie awarii,
  • nieodpłatne usunięcie wad, które ujawnią się w okresie gwarancji.

Czas trwania gwarancji na oprogramowanie

Rynkową praktyką w Polsce jest okres gwarancji na oprogramowanie wynoszący 12 m-cy.

Niektóre firmy mogą ofertować dłuższe okresy, ale zazwyczaj wydłużenie gwarancji poza okres jednego roku wymaga dopłaty lub innych indywidualnych ustaleń.

Gwarancja powinna określać czasy reakcji wykonawcy

Czasy reakcji wykonawcy określone w gwarancji mogą być relatywnie długie w przypadku braku umowy SLA, nawet do 14 dni.

Możesz też określić różne rodzaje zgłoszeń gwarancyjnych i maksymalne czasy reakcji wykonawcy.

Przykładowo: „błąd krytyczny”, który określisz jako blokujący główne funkcjonalności systemu, może mieć gwarancyjny krótki termin realizacji, za to „drobny błąd” może być realizowany w dłuższym okresie.

Gwarancja może też nakładać obowiązki na klienta

Zazwyczaj firmy zastrzegają utratę gwarancji w momencie dokonania modyfikacji w kodzie ze strony klienta lub innej firmy. Wynika to oczywiście z faktu utraty kontroli nad kodem i braku możliwości przejęcia pełnej odpowiedzialności za pracę osoby trzeciej, niezwiązanej z firmą wykonawcy. W praktyce może to oznaczać związanie się z wykonawcą na okres przynajmniej trwania gwarancji. W przeciwnym wypadku należy liczyć się z jej utratą. Dlatego warto zadbać o wcześniejsze określenie warunków współpracy z wykonawcą po zakończeniu projektu głównego.

Gwarancja na rozwiązanie dedykowane a „pudełkowe”

Zapisy gwarancyjne będą się różnić w zależności od tego, czy zamówione oprogramowanie to gotowy system/aplikacja internetowa dostępna na rynku, czy jest to rozwiązanie napisane specjalnie dla zamawiającego. W przypadku tego pierwszego możliwe jest, że firma będzie oferowała regularne wsparcie w postaci call center i wiele problemów będzie można rozwiązać „przez telefon” w relatywnie krótkim czasie. W takiej sytuacji zazwyczaj mamy do czynienia z pracownikami call center, którzy nie muszą być programistami. Nie naprawiają oni oprogramowania, a jedynie wskazują możliwe rozwiązania, bazując na przygotowanych skryptach.

Rozwiązania dedykowane charakteryzują się wysokim stopniem indywidualizacji oprogramowania. Oznacza to, że taki indywidualnie napisany system, strona internetowa, czy aplikacja nie jest rozwiązaniem złożonym z gotowych klocków, których działanie jest w wysokim stopniu przewidywalne. W przypadku oprogramowania dedykowanego niektóre problemy mogą wymagać głębszej analizy ze strony nie tylko jednego, ale całego zespołu programistów. Naprawienie błędu wymaga wtedy indywidualnie przygotowanego rozwiązania naprawczego, które potrzebuje wtedy przetestowania przez zespół testerów. To oczywiście wydłuża czas naprawy.

Dodaj komentarz