Czasami lubimy romantycznie opowiadać o branży IT, jako tej nowoczesnej, która rządzi się innymi prawami niż "tradycyjne", nudne sektory gospodarki. I o ile rzeczywiście w działalności "domów oprogramowania" można znaleźć elementy, które zasługują na potraktowanie w ten sposób, o tyle nie czarujmy się - tworzenie oprogramowanie to nadal wytwarzanie produktów podlegających podobnym prawom co twory innych branż usługowych. A to oznacza, że wiele pojęć znanych z klasycznego biznesu jest obecnych także w software house'ach i ogólnie przy dostarczaniu usług IT. Jedną z takich koncepcji jest znana i lubiana przez wszystkich gwarancja.
Dzisiaj przyjrzymy się, na czym polega ona w świecie dedykowanego oprogramowania, ponieważ z naszych doświadczeń wynika, że nie dla wszystkich jest to jasne. Nie ma co się dziwić - są osoby, które na wstępie ustalania założeń projektu mówią wprost, że rzadko współpracują (lub nawet nigdy tego nie robiły) z firmami IT i czują się trochę skonfudowani przed całym procesem. Dotyczy to także wiedzy o tym, co dzieje się po zakończeniu projektu. I tak, jak swego czasu wyjaśnialiśmy, na czym polega rola software house'u w takim przedsięwzięciu oraz jak można zapewnić obsługę aplikacji w późniejszym czasie w formie abonamentu, tak dzisiaj spróbujemy rozwiać wątpliwości związane z gwarancją.
Tak naprawdę sprawa jest dość prosta - w umowach z firmami IT jest zapis o zapewnieniu wsparcia w przypadku znalezienia błędów (zawinionych przez programistów) i niezgodności w pewnym ustalonym okresie liczonym od pewnego momentu. Na naszym przykładzie - Wilda Software standardowo zapewnia 12-miesięczną gwarancję na błędy znalezione w oprogramowaniu. Ten rok jest liczony od momentu odbioru danej części systemu - może być to dostarczenie całego oprogramowania, ale też wszelkie prace dziejące się po tym okresie. Czyli jeśli klient dostał system zarządzania produkcją w lipcu 2022 roku, a później w grudniu 2022 r. odebrał dodatkowo zamówiony moduł wydań magazynowych, to na tę drugą funkcjonalność gwarancja trwa aż do grudnia 2023 r.
Natomiast większy dylemat niż czas budzi zwykle zakres gwarancji. Tak, jak w przypadku produktów z innych branż, obejmuje on:
- błędne zachowanie systemu będącego przedmiotem realizacji, tj. niezgodne z wcześniejszą specyfikacją,
- oczywiste, niecelowe błędy jak np. zwracanie złego wyniku mnożenia (przykład ekstremalny, bo aby przemycić taką niedoróbkę do systemu, to naprawdę już trzeba się postarać).
Oczywiście, często w imię dobrej współpracy, w ramach gwarancji przeprowadzane są też bardzo proste zmiany np. estetyczne, czyli takie, które nie zajmują więcej niż parę godzin łącznie. Jest to kwestia uznaniona i wynikająca ze wzajemnych relacji pomiędzy klientem oraz wykonawcą.
Natomiast należy pamiętać, że gwarancja, oprócz uwzglęnienia czasu trwania, jest egzekwowana tylko i wyłącznie w momencie, kiedy błędne działanie oprogramowania nie wynika z nieuprawnionych działań klienta. Przykładowo, tak jak komputer traci bezpłatne wsparcie w momencie zerwania plomb przez użytkownika, tak oprogramowanie traci ją, gdy klient sam zmodyfikuje kod (bez wcześniejszej konsultacji z software housem) lub udostępni krytyczne informacje autoryzacyjne osobom nieuprawnionym. Oczywiście, każdy przypadek trzeba rozpatrywać indywidualnie - te przytoczone powyżej to najprostsze przykłady, które można sobie wyobrazić, aczkolwiek zawsze ważny jest kontekst.
Istnieją sytuacje, których gwarancja nie obejmuje, mimo że nie oznaczają jej natychmiastowego końca. Są to wszelkie zmiany w oprogramowaniu, które nie wynikają z wcześniejszych ustaleń, w tym takie, które stanowią dodatkową funkcjonalność względem tej, której dotyczył przedmiot wcześniejszej umowy. Może też być tak, że pewne zgłoszenie potencjalnego błędu tylko w części rzeczywiście jest obejmowane przez bezpłatne wsparcie, ale dodatkowo zawiera rzeczy wcześniej nieujęte w specyfikacji.
Specyfikacja, specyfikacja... To słowo pojawia się często nie bez powodu. W projektach IT (jak i tak naprawdę też w innych) ustalenia słowne są zazwyczaj niewystarczające, gdyż mogą być różnie pamiętane przez każdą ze stron, a nawet przez każdą osobę pracującą przy projekcie. Nie oznacza to, że zawsze musi powstać formalny dokument zwany specyfikacją wymagań oprogramowania, ale zazwyczaj jest on polecany przez rozpoczęciem prac implementacyjnych oraz wydaje się wręcz obowiązkowy przy większych realizacjach. Opcją minimum jest potwierdzanie ustalonych wersji (np. na spotkaniach) drogą mailową, co również w ostateczności może stanowić załacznik do umowy.
Oczekiwania wyrażone w formie pisemnej są niezbędne, jeśli zależy nam na klarownej współpracy i braku nerwów podczas rozpatrywania m.in. zgłoszeń gwarancyjnych. I to dla obu stron - zawsze jasne warunki gry są niezwykle istotne. Natomiast nie zmienia to faktu, że gwarancja na oprogramowanie "działa" bardzo podobnie do gwarancji znanych z innych branż i nie należy się bać z niej korzystać - także software house'owi zależy na tym, aby dostarczyć klientowi oprogramowanie, które rzeczywiście będzie przez niego używane oraz wyeliminować niedoróbki, które czasami przydarzają się podczas tworzenia szczególnie rozbudowanych systemów IT. To procentuje później w lepszych relacjach i dalszej współpracy.
Pozdrawiam i dziękuję - Jakub Rojek.