Sposób określenia specyfikacji i wymagań klienta przy realizacji projektu informatycznego może mieć konsekwencje nie tylko natury technicznej, ale i prawnej.

Realizacja projektów informatycznych jest nieuchronnie powiązana z ryzykiem odpowiedzialności cywilnej wobec użytkowników. Wszystko za sprawą możliwości pojawienia się wad w dostarczonych rozwiązaniach. Nie ma tu miejsca na drobiazgową analizę przyczyn błędów powstających w projektach informatycznych. Część z nich ma swoje źródła w aspektach technologicznych, część zaś powiązana jest głównie z czynnikiem ludzkim. Należy też uwzględnić wzrastający stopień skomplikowania systemów IT oraz szerokie grono osób pracujących nad nimi. W rezultacie nawet najbardziej drobiazgowa analiza komponentów software'owych nie gwarantuje pełnego sukcesu.

Co więc zrobić, aby uniknąć roszczeń odszkodowawczych? Najprościej już na etapie projektowania rozwiązania pokusić się o sformułowanie zasad i zakresu ewentualnych wyłączeń odpowiedzialności producenta. Trzeba przy tym rozróżnić dwie modelowe sytuacje: produkty ogólnodostępne na rynku oraz przygotowywane na konkretne zamówienie. Trzeba pamiętać, że z uwagi na to, iż integralnym elementem większości złożonych projektów IT jest oprogramowanie komputerowe, to wokół niego koncentruje się głównie ewentualna odpowiedzialność cywilna.

Generalne zasady

Rozpowszechnioną tendencją jest lapidarne ujmowanie w licencjach, iż wszelka odpowiedzialność producenta została ograniczona w maksymalnym zakresie, przewidzianym przepisami prawa. W istocie, zgodnie z przepisami kodeksu cywilnego, wykluczona jest bowiem jedynie eliminacja odpowiedzialności za szkody wyrządzone umyślnie. W odniesieniu do projektów informatycznych trudno wyobrazić sobie jednak takie sytuacje. Jednocześnie innym, dostrzegalnym trendem jest wyznaczanie górnego pułapu ewentualnej odpowiedzialności producenta oprogramowania do wysokości wartości aplikacji. Zabiegi takie dyktuje jednak bardziej konkurencja rynkowa niż przepisy prawne. Rozszerzony zakres odpowiedzialności z tytułu wadliwości oferowanego projektu jest jednak bez wątpienia atrakcyjny z punktu widzenia klienta.

Na indywidualne zamówienie

Inaczej przedstawia się sytuacja, gdy mamy do czynienia z projektem tworzonym na indywidualne zamówienie klienta. Tutaj z reguły wchodzą w grę odpowiednie unormowania Ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (dalej jako ustawa). "Droga na skróty" w ramach tworzenia projektu, a w rezultacie pojawienie się błędów, doprowadzi w takiej sytuacji do odpowiedzialności cywilnej o wiele szybciej niż w przypadku produktów dostępnych dla wszystkich konsumentów.

Na wstępie niebagatelne znaczenie ma określenie ram projektu jeszcze przed podpisaniem kontraktu. Jest to ułatwienie dla obu stron, które pozwala uniknąć choćby części sporów w toku realizacji zamówienia. Zwłaszcza przy rozbudowanych projektach nie można lekceważyć potrzeby sprecyzowania wszystkich oczekiwań klienta. Co prawda z reguły istnieje możliwość aneksowania umowy, co w przypadku dynamicznego rozwoju projektu nie będzie wyjątkową sytuacją. Nie zawsze rozwiąże to jednak wszystkie problemy. Przepisy ustawy przewidują, iż zamawiający w razie wykrycia "usterek", czyli cech, które nie odpowiadają jego oczekiwaniom, może wyznaczyć odpowiedni termin do ich usunięcia. Jeśli wadliwość nie zostanie wyeliminowana, w grę wchodzi bądź odstąpienie od umowy, bądź obniżenie umówionego wynagrodzenia. Nigdy nie zdarzy się jednak tak, że wynagrodzenie to będzie niższe niż 25% pierwotnie wskazanego.

Przykładowe usterki

Dla przykładu, w przypadku indywidualnych reali-zacji projektów IT brak zapewnienia kompatybilności pomiędzy już funkcjonującymi, a przygotowywanymi rozwiązaniami doprowadzić może do wspomnianej odpowiedzialności producenta. Chodzić może także o specjalne potrzeby zamawiającego, takie jak uwzględnianie określonych standardów technicznych, czy "dostępności" zawartości stron WWW dla niepełnosprawnych użytkowników, importu danych z innych aplikacji itp. Wszystko zależy, rzecz jasna, od sformułowania zapisów umowy. Im bardziej szczegółowe wymagania co do specyfikacji technicznej finalnego projektu, tym mniejsza swoboda w ramach jego opracowania. Ma to swoje konsekwencje zarówno na płaszczyźnie stricte technicznej, jak i prawnej. Mamy tu bowiem do czynienia z przygotowywaniem "produktu", który w założeniu musi współdziałać poprawnie z istniejącymi komponentami (zazwyczaj na poziomie hardware, a czasem także software).

Realizacja projektu informatycznego to czasem wielostopniowe powiązania kontraktowe. Przykładem może być "podzlecanie" wykonania jego fragmentów programistom z innych firm. Z punktu widzenia klienta fakt ten nie będzie miał większego znaczenia. W razie wadliwości projektu - niezależnie których komponentów kodu to dotyczy - będzie on kierował swoje roszczenia bezpośrednio do producenta rozwiązania IT. Roszczenia związane z usterkami wygasają wraz z przyjęciem zamówionego rozwiązania. Istotne pozostaje przy tym wyznaczenie terminu ewentualnego kwestionowania zamówionego produktu. O ile strony nie zdecydują inaczej, będzie to 6 miesięcy. Jeśli w tym czasie kontrahent nie zawiadomi o ewentualnych wadach, przyjmuje się, że nie kwestionował niczego.

Wady prawne

Odrębnym zagadnieniem jest odpowiedzialność za "wady prawne" projektu IT, czyli implementację komponentów naruszających prawa osób trzecich. Chodzi głównie o przywłaszczanie autorstwa fragmentów cudzego kodu. Nie będzie miało przy tym większego znaczenia, jak duża część zrealizowanego projektu została dotknięta taką wadą. Dodatkowo, sam model dystrybucji rozwiązań nie wpływa zasadniczo na kwestie ewentualnej odpowiedzialności cywilnej. Wspomniane zasady dotyczą więc także rozwiązań open source. Jednocześnie specyfika posiłkowania się dostępnymi już komponentami wolnego oprogramowania wzmaga konieczność zweryfikowania, czy "zewnętrzny" kod nie ingeruje w uprawnienia osób trzecich. W przypadku wad prawnych kontrahent może odstąpić od umowy i żądać naprawienia szkody.

Testowanie produktów

Inne zagadnienie to przekazywanie projektów IT zewnętrznym podmiotom w celu ich przetestowania przed wdrożeniem. Testowanie wiąże się nierozerwalnie z elementem przewidywania, w jakich sytuacjach może funkcjonować rozwiązanie. To z kolei - w dużym uproszczeniu - pozwala na identyfikację źródeł jego ewentualnych błędów. Praktyki takie w żadnym wypadku nie wyłączą całkowicie odpowiedzialności cywilnej producenta bezpośrednio wobec zamawiającego. Na wypadek sporu cywilnego stają się jednak argumentem przemawiającym za dochowaniem przez producenta należytej staranności przy wykonywaniu zamówienia. Dodatkowo, w zależności od sformułowań umowy przewidującej obowiązek testowania aplikacji - chociażby pod kątem konkretnych konfiguracji sprzętowych - w razie ujawnienia się błędów na etapie komercyjnych (praktycznych) zastosowań produktu, realne staje się dochodzenie przez producenta roszczeń z tytułu nienależytego wykonania umowy przez testera. Z kolei samo powierzenie przetestowania produktu "pod kątem ewentualnych błędów" z reguły nie otworzy drogi do ewentualnej odpowiedzialności testera. Zwłaszcza że integralnym elementem weryfikacji jakości produktu informatycznego jest wychwycenie uchybień, których występowania nie przewidział producent.

Warto zaznaczyć, że można pokusić się o umowne zastrzeżenie wyłączające możliwość rozpowszechnienia produktu w wersji przekazanej do testów. Wydaje się to szczególnie istotne przy przekazywaniu kodu źródłowego. Można też iść krok dalej, zobowiązując drogą kontraktową do zachowania w tajemnicy wszelkich informacji związanych z przeprowadzanymi testami. Woli stron pozostawia się przy tym sprecyzowanie formy, w jakiej zostaną przekazane wyniki testów - dokumentacja, zestawienia błędów, ewentualne propozycje ich usunięcia. Z perspektywy przepisów prawa większego znaczenia nie będzie miało to, czy chodzi o test obciążeniowy, czy też dotyczący funkcjonalności projektu.