Bardziej wyrazistym przykładem może być np. katastrofa spowodowana złym działaniem komputerowych systemów sterowania, ostrzegania, alarmowania, monitoringu itp. Jeżeli rozpatrywać np. informatyczne systemy medyczne, lotnicze lub kolejowe, to wniosek, że ich twórca nie może wyrzekać się odpowiedzialności za jakość pracy swojego produktu, jest chyba oczywisty.

W zasygnalizowanych przypadkach problemem jest udowodnienie, że kupione oprogramowanie było faktycznie przyczyną strat. Zagadnienie komplikuje się jeszcze bardziej, gdy efekty wadliwego działania uwidaczniają się po pewnym czasie, np. po 3 latach (taki jest okres kontroli finansowej izb skarbowych).

W ciągu ostatnich kilku lat media szeroko informowały o procederze nielegalnego kopiowania oprogramowania. W celu ochrony producentów ustanowione zostało prawo autorskie. Na temat tej ustawy napisano już wiele i nie ma powodu rozpatrywać tego tematu kolejny raz. Należy jednak zastanowić się nad art. 556-566 kodeksu cywilnego, dotyczącymi odpowiedzialności za wady dostarczanego produktu. Sprzedawca ponosi według nich odpowiedzialność z tytułu rękojmi za ewentualne skutki wadliwego działania programów. Dla posiadaczy wadliwego oprogramowania szczególnie interesujący jest art. 566. Stanowi on m.in., że kupujący "...może żądać naprawienia szkody poniesionej wskutek istnienia wady..." oraz "...może żądać tylko naprawienia szkody, którą poniósł przez to, że zawarł umowę, nie wiedząc o istnieniu wady..." Jest to mocne narzędzie dochodzenia swoich praw.

Odrębnym zagadnieniem jest sprawa zamawianego oprogramowania. Zazwyczaj jest ono przeznaczone do ściśle określonych, wąskich zastosowań.

Kto zawinił?

wykorzystanie profesjonalnych i specjalistycznych programów komputerowych, ułatwiających zarządzanie firmami, bankami, placówkami handlowymi itp. wciąż wzrasta. Prawdziwą karierę robią arkusze kalkulacyjne, programy finansowo-księgowe, fakturujące, obsługi bankowej, relacyjne bazy danych.

Mimo że na rynku oprogramowania znajduje się pokaźna oferta wszelkiego rodzaju narzędzi komputerowych, realizujących niekiedy wyrafinowane funkcje i spełniających specyficzne zapotrzebowania użytkowników, zdarza się, że oferta rynkowa nie spełnia wszystkich wymagań czy potrzeb zainteresowanego. Specyfika potrzeb użytkownika wymaga w takiej sytuacji zamówienia oryginalnego oprogramowania, wykonanego specjalnie dla niego.

Decyzja taka łączy się zazwyczaj z wielokrotnie większymi kosztami niż zakup gotowego oprogramowania. Zamawiający ma prawo sądzić, że oprogramowanie będzie dokładnie spełniało jego oczekiwania. Ale gdy użytkownik stwierdza, że program, za który zapłacił o wiele więcej niż za gotowy, nie funkcjonuje tak, jak by sobie życzył, powstaje pytanie: kto zawinił? Zamawiający czy wykonawca programu?

Odpowiedź wydaje się oczywista. Zamawiający jest przekonany, że wykonawca powinien zrealizować wszystkie jego oczekiwania, natomiast druga strona broni się zazwyczaj brakiem precyzyjnych wytycznych na temat zakresu funkcjonalnego programu. Dobrze, jeżeli strony potrafią osiągnąć dojść do porozumienia, gorzej natomiast, jeżeli spór rozstrzygnąć musi sąd. W takiej sprawie proces może być bardzo skomplikowany.

Aby uniknąć takich sytuacji, zainteresowani, zarówno zamawiający, jak i wykonawcy oprogramowania, powinni pamiętać o kilku istotnych zasadach, których nieprzestrzeganie może skończyć się na sali sądowej.

Patrzyć na ręce

Przede wszystkim zamawiający powinien precyzyjnie określić swoje potrzeby w zakresie funkcji, jakie powinien realizować zamawiany program. Etap ten można nazwać formułowaniem założeń wstępnych.

Jeżeli zamawiający nie jest w stanie precyzyjnie określić założeń (a przeciętny użytkownik nie potrafi tego zrobić), powinien zatrudnić profesjonalistę - projektanta systemów. Założenia wstępne, zanim zostaną przekazane wykonawcy, powinny być przez zamawiającego zweryfikowane i zatwierdzone. Dla zleceniobiorcy z kolei, istnienie założeń wstępnych jest najlepszym zabezpieczeniem przed rozszerzaniem wymagań w trakcie realizacji zlecenia. Zdarza się tak, zwłaszcza gdy zleceniodawca dochodzi do wniosku, że dobrze byłoby rozbudować funkcje zamawianego programu. Bez spisanych wymagań trudno jest po pewnym czasie stwierdzić, co tak naprawdę było przedmiotem umowy. Postępowanie takie, z pozoru wydłużające proces powstawania produktu, jest bardzo istotne i może zapobiec wielu niepotrzebnym problemom.

Przy wyborze wykonawcy dobrze jest sprawdzić, jakie ma on osiągnięcia w dziedzinie programowania - np. czy inne napisane przez niego programy działają dobrze. Należy wybierać wykonawcę, który dobrze zna daną dziedzinę. Znawca systemów operacyjnych nie wykona dobrze programu księgującego, nawet jeśli tak twierdzi.

W momencie przekazania wersji "beta" programu rozpoczyna się okres tzw. "eksploatacji nadzorowanej". W okresie tym zleceniodawca powinien zgłosić wszelkie spostrzeżenia i uwagi, a wykonawca jest zobowiązany do bezpłatnego poprawienia błędów. W tym momencie szczególnie widać, jak ważne są założenia wstępne. Obydwie strony mogą zweryfikować sugestie partnera. Gdy nie ma takich założeń, wykonawca może twierdzić, że zrobił to, co do niego należało, podczas gdy zamawiający jest niezadowolony. W poczuciu dobrze pojętego interesu obydwu stron, należy rozpocząć współpracę od precyzyjnego opisu funkcji programu.