Obserwowany od wielu lat rozwój technologii wymagających zastosowania specjalistycznego oprogramowania zdecydowanie sprzyja powstawaniu firm typu software house zajmujących się jego tworzeniem. Pomimo faktu, że działający w tej branży przedsiębiorcy z reguły cechują się profesjonalizmem oraz zatrudniają wyłącznie wysoko wykwalifikowany personel, prowadzone przez nich projekty w 69% kończą się niepowodzeniem, co w rezultacie może doprowadzić do konfliktu z klientem.
Choć przyczyny niewykonania lub nienależytego wykonania zlecenia są bardzo różne i nie zawsze wynikają z winy software house, negatywne konsekwencje tych zdarzeń często istotnie utrudniają jego bieżącą oraz przyszłą działalność (m.in. przez straty wizerunkowe). Aby zatem wyeliminować lub znacznie ograniczyć prawdopodobieństwo ich wystąpienia, warto zawczasu podjąć odpowiednie działania zabezpieczające. Jakie? – o tym piszę w niniejszym artykule.
Odsłuchaj także podcastu!
Listen to „69% projektów IT kończy się fuckupem, jak się zabezpieczyć? Jaka jest odpowiedzialność?” on Spreaker.Ten odcinek znajdziesz także na Spotify, Apple Podcast lub w Twojej innej ulubionej aplikacji.
Dlaczego projekty IT nie idą zgodnie z planem?
Przyczyny skutkujące nieprawidłową realizacją projektu lub jego nieukończeniem mogą w sposób niezauważony powstać już na samym początku współpracy z klientem i wydać swoje „zatrute owoce” dopiero po pewnym czasie.
W tym kontekście należy wskazać przede wszystkim na rozbieżności co do końcowego rezultatu projektu, którego wizja po stronie klienta może znacząco różnić się od wizji SH. Wskazane rozbieżności wynikają najczęściej ze zbyt ogólnych założeń projektu (nieuwzględniających istotnych szczegółów), błędnej identyfikacji potrzeb klienta oraz braku przedstawienia przez software house kompleksowej wizji proponowanego rozwiązania.
W rezultacie, „produkt końcowy” może nie odpowiadać oczekiwaniom klienta nawet wówczas, gdy formalnie spełnia wszystkie założenia początkowe.
Problemy w toku prac IT
Problemy zagrażające prawidłowej realizacji projektu mogą pojawić się także już w toku prac i wynikać z ich błędnej organizacji. Nie każdy specjalista z zakresu IT posiada bowiem umiejętności w dziedzinie planowania i zarządzania projektami (szczególnie w przypadku ich dużej ilości), dlatego powinien ściśle współpracować z osobą (menedżerem), która takie umiejętności posiada. Brak takiej osoby (odpowiadającej za harmonogram prac i podział zadań) może w łatwy sposób doprowadzić do opóźnienia w realizacji projektu lub jego ukończenia z przekroczeniem zaplanowanego budżetu lub terminu.
Project manager
Wyznaczenie osoby odpowiedzialnej za koordynację projektu pozwala dodatkowo zminimalizować ryzyko „samowolnej” zmiany założeń projektu przez pracownika SH. Wbrew pozorom, takie sytuacje rzeczywiście mają miejsce i przeważnie nie wynikają ze złej woli, lecz z chęci zastąpienia pierwotnego rozwiązania innym, które w ocenie pracownika będzie lepiej odpowiadało potrzebom klienta. Zważywszy jednak, że pierwotny wybór dokonany przez klienta często wynika z istotnych przyczyn (np. finansowych, organizacyjnych), tego rodzaju „nadgorliwość” może stać się przyczyną poważnego sporu.
Zdarzenia losowe fuckupem IT
Niezależnie od przyczyn mniej lub bardziej zawinionych przez SH, niepowodzenie projektu może być skutkiem zdarzeń zupełnie od niego niezależnych.
W tym miejscu należy wskazać przede wszystkim na przypadki siły wyższej (takie jak choćby pandemia COVID-19 i wojna rosyjsko-ukraińska), mogące skutkować utratą kluczowego personelu (np. w wyniku choroby) lub niedostępnością niezbędnych zasobów (np. w wyniku przecięcia łańcuchów dostaw, drastycznego wzrostu cen). Inną, mniej „drastyczną” przyczyną, jest zmiana założeń projektu dokonana przez klienta już w trakcie jego realizacji.
O ile taka zmiana nie musi sama w sobie stanowić istotnego problemu, dokonywanie jej bez określonej procedury (np. na bieżąco, drogą mailową) lub poza postanowieniami zawartej wcześniej umowy (bez jej aneksowania) może wygenerować chaos, którego późniejsze opanowanie będzie bardzo trudne.
Jak wyglądają statystyki w branży IT?
Choć wielu przedstawicieli SH może pozostawać w przekonaniu, że powyższe problemy ich nie dotyczą, w rzeczywistości ryzyko ich wystąpienia powinni traktować jako bardzo prawdopodobne. Prawdziwość tego twierdzenia potwierdzają statystyki dotyczące powodzenia projektów IT zawarte w raportach międzynarodowej firmy The Standish Group, która podzieliła badane projekty na następujące kategorie:
- projekty zakończone pełnym sukcesem (czyli w granicach przewidzianego budżetu oraz zgodnie z harmonogramem i oczekiwanymi założeniami co do funkcjonalności)
- projekty zakończone z problemami (czyli z przekroczeniem budżetu, opóźnieniem lub w sposób niezgodny z oczekiwanymi założeniami co do funkcjonalności)
- projekty niezrealizowane z powodu porzucenia lub anulowania
Podsumowanie statystyk The Standish Group z lat 1995, 2015 i 2020 znajduje się w poniższej tabeli.
| Projekty zakończone pełnym sukcesem | Projekty zakończone z problemami | Projekty niezrealizowane | |
| 1995 r. | 16,2% | 52,7% | 31,1% |
| 2015 r. | 29% | 52% | 19% |
| 2020 r. | 31% | 50% | 19% |
Jak wynika z powyższego, prawdopodobieństwo wystąpienia problemów podczas realizacji projektu wynosi ok. 70%, dlatego zdecydowanie warto zawczasu przygotować się w taki sposób, aby im zapobiec albo zminimalizować ich negatywne skutki.
Bez umowy ani rusz
Najlepszym i jednocześnie najprostszym sposobem zabezpieczenia się przed większością potencjalnych trudności, jest uregulowanie całokształtu współpracy z klientem w ramach zawartej z nim umowy.
Przeczytaj także: Co powinna zawierać dobra umowa wdrożeniowa IT?
Choć niekiedy postrzegana jest ona jako zbędny formalizm, w rzeczywistości zapewnia obu stronom poczucie bezpieczeństwa, a ponadto jest przejawem profesjonalizmu danego software house.
Wreszcie, zawarcie umowy jest niekiedy niezbędnym warunkiem realizacji celów współpracy, np. przeniesienia na klienta autorskich praw majątkowych lub udzielenia mu licencji wyłącznej.
Niezależnie od powyższego warto pamiętać, że realizacja projektu wyłącznie na podstawie mailowych lub telefonicznych ustaleń z klientem również prowadzi do zawarcia umowy. Wynika to z faktu, że przepisy Kodeksu cywilnego przypisują określonym czynnościom znaczenie prawne niezależnie od tego, czy zostały one spisane w formalnym dokumencie.
Przykładowo, klient sklepu spożywczego może zawrzeć umowę sprzedaży bochenka chleba wręczając kasjerowi odpowiednią sumę pieniędzy i zabierając ze sobą podane przez niego pieczywo.
Z uwagi na fakt, że nawiązanie współpracy z klientem nieuchronnie prowadzi do zawarcia umowy, w interesie obu stron jest zapewnienie sobie możliwości jednoznacznego ustalenia jej treści oraz powrotu do niej w każdym czasie. Ciągnące się przez dziesiątki, a nawet setki wiadomości wątki mailowe zdecydowanie nie są w tym kontekście ani wygodne, ani pewne, dlatego warto już na samym początku „zamknąć” cały projekt w jednym dokumencie.
Jakby tego było mało, zawarcie formalnej umowy pozwala przyporządkować do niej odpowiednie przepisy Kodeksu cywilnego (np. o umowie o dzieło), co w razie sporu ma niebagatelne znaczenia (strona przeciwna może bowiem próbować dowodzić, że zastosowanie mają przepisy korzystne dla niej). Ponadto, postanowienia umowy mogą modyfikować całkiem sporo przepisów Kodeksu i kształtować je w sposób korzystny dla SH.
Potrzebujesz pomocy przy weryfikacji swojej umowy z klientami? Wypełnij formularz i umów się na rozmowę z nami!
(Dalsza część artykułu poniżej.)
Newsletter, który pomoże Ci rozwinąć 
Twoją firmę technologiczną lub software house pod kątem prawnym i biznesowym.
Dołącz do społeczności właścicieli, kadry zarządzającej i managerskiej w firmach technologicznych i software house! Otrzymuj co 2 tygodnie najważniejsze informacje.
Więcej o naszym newsletterze „Let’s talk tech” przeczytasz pod linkiem: https://letstalktech.pl/
Po zapisaniu się odbierz od nas powitalnego maila z bonusami m.in. bezpłatne nagrania webinarów i szkoleń dla startupów i branży tech!
W razie problemów, napisz do nas. Sprawdź folder spam/oferty.
Aktywując przycisk pod formularzem, akceptujesz nasz Regulamin (w zakresie dotyczącym Newslettera) oraz wyrażasz zgodę na otrzymywanie treści edukacyjnych, informacji o produktach i usługach kancelarii Creativa Legal Korol Szczudło adwokaci sp.p., np. o nowych artykułach, kursach on-line, czy zniżkach. Przeczytaj, w jaki sposób przetwarzamy Twoje dane osobowe w naszej Polityce prywatności.
Projekt finalnego rozwiązania, brief i dokumentacja techniczna
Niezbędnym załącznikiem do każdej umowy zawieranej z klientem powinien być projekt rozwiązania, którego stworzenie jest zadaniem software house. Zważywszy, że tego typu dokument powstaje w ramach praktycznie każdej współpracy, zazwyczaj wystarczy dołączenie go do umowy jako jej integralnej części.
Aby projekt spełniał swoją rolę, powinien być możliwie jak najbardziej szczegółowy i kompleksowo opisywać dane rozwiązanie. Dzięki temu, obie strony będą dokładnie wiedziały do czego zmierzają, co pozwoli uniknąć późniejszych nieporozumień.
Niekiedy zdarza się, że w toku realizacji projektu SH lub klient wpada na pomysł wprowadzenia w nim zmian, np. w celu poprawienia efektywności rozwiązania lub zmniejszenia kosztów jego eksploatacji. Na wypadek takiej sytuacji, umowa powinna przewidywać procedurę zgłaszania takich zmian, połączoną z uprawieniem SH do rekalkulacji wynagrodzenia i ustalenia nowego harmonogramu prac. Ważne, aby wskazane modyfikacje zostały w sposób jednoznaczny zaakceptowane przez obie strony, co powinno zostać utrwalone np. na piśmie lub drogą mailową. Nawet bowiem jeżeli klient ustnie da SH „wolną rękę” w zakresie poprawiania projektu, w razie sporu może łatwo o tym „zapomnieć” i twierdzić, że takich ustaleń nigdy nie było.
Oczywiście w sytuacji, gdy umowa przewiduje dopiero stworzenie takiej dokumentacji na start w ramach pierwszego etapu współpracy, należałoby odpowiednio to opisać w umowie.
Inna sprawa, że przy współpracy na zasadach agile, należałoby opisać zasady współpracy w ramach sprintów i ustalić zasady wzajemnego kontaktu.
Harmonogram prac
Kolejnym załącznikiem do umowy zawartej z klientem powinien być harmonogram realizacji projektu, określający etapy prac oraz terminy ich ukończenia. Co ważne, nie musi on zawierać dokładnych dat ukończenia poszczególnych etapów, lecz może wyznaczać je jako dzień przypadający w okresie rozpoczynającym się od określonego zdarzenia (np. w terminie 7 dni roboczych od dnia otrzymania uwag klienta). Tak skonstruowany harmonogram jest bardziej elastyczny i tym samym lepiej „znosi” nieprzewidziane wypadki (np. opóźnienie klienta).
Choć po stronie SH może pojawić się pokusa przyciągnięcia klienta ofertą błyskawicznej realizacji projektu, wpisywanie do harmonogramu napiętych terminów nie jest dobrym pomysłem. Należy bowiem pamiętać, że nie sposób z góry przewidzieć wszystkich możliwych komplikacji (np. braku przekazania istotnych informacji od klienta), dlatego warto zostawić sobie zapas w postaci kilku dodatkowych dni na dany etap prac lub uzależnić przejście do kolejnego etapu od odpowiednich czynników.
Takie rozwiązanie jest korzystne również dla klienta, który zapewne wolałby poczekać trochę dłużej i być pewnym ukończenia projektu zgodnie z planem, niż niemiło zaskoczyć się z powodu jego opóźnienia.
Niezależnie od powyższego, warto umieścić w umowie katalog przypadków, w którym terminy realizacji projektu automatycznie ulegają wydłużeniu.
Biorąc pod uwagę fakt, że przyczyny uzasadniające takie wydłużenie będą miały charakter obiektywny, nie powinny wzbudzić one wątpliwości klienta. Ważne, aby umowa przewidywała procedurę niezwłocznego zawiadomienia klienta o wystąpieniu danej przyczyny, aby w razie późniejszego sporu nie mógł zarzucić SH, że została ona „wymyślona” po czasie.
Wynagrodzenie software house
Kwestie finansowe są bez wątpienia jednym z bardziej „newralgicznych” aspektów współpracy z klientem, dlatego powinny one zostać uregulowane w sposób niebudzący wątpliwości. Na rynku występują różne formy wynagrodzenia np. time and material, fixed fee.
W tym zakresie, przydatne jest sporządzenie kompleksowego kosztorysu uwzględniającego nie tylko wynagrodzenie pracowników SH, lecz także wszelkie koszty dodatkowe (np. zakupu licencji na oprogramowanie, dojazdów do siedziby klienta).
Ponadto, kosztorys może zawierać wycenę czynności opcjonalnych, z których klient może, a nie musi skorzystać (np. szkolenia dla pracowników).
Oprócz kwoty wynagrodzenia, równie ważnym aspektem jest termin jego uiszczenia. W tym zakresie, strony mogą wybrać jedną spośród wielu możliwych opcji, np. zapłatę w ratach lub w kombinacji „zaliczka przed realizacją, a reszta po realizacji”. Ważne, aby umowa precyzyjnie określała termin zapłaty wynagrodzenia (lub jego części), co pozwoli uniknąć późniejszych nieporozumień w tej kwestii.
W przypadku, gdy realizacja projektu przypada na okres niestabilności gospodarczej (taki jak obecny), pożądanym rozwiązaniem jest wprowadzenie do umowy klauzuli waloryzacyjnej, automatycznie dostosowującej wysokość wynagrodzenia do aktualnej sytuacji na rynku. W tym celu, strony powinny odwołać się do wybranego, obiektywnego wskaźnika, np. jednego z publikowanych przez Główny Urząd Statystyczny.
Oczywiście to tylko jedna z możliwości, w zależności od sposobu rozliczania się z klientem, można przedsięwziąć dodatkowe zabezpieczenia.
Zabezpieczenie przed nieprzewidzianymi sytuacjami
Choć umieszczanie w umowach klauzul odwołujących się do siły wyższej kojarzy się współcześnie z pandemią COVID-19 i wojną rosyjsko-ukraińską, tego rodzaju postanowienia przydatne są również w „spokojniejszych” czasach. Przykładowo, zdarzenie takie jak pożar budynku, w którym znajduje się lokal software house, może skutecznie sparaliżować jego pracę na tygodnie lub miesiące (np. w wyniku spalenia lub zalania zgromadzonego sprzętu i dokumentacji), co uniemożliwi należyte wywiązanie się z zawartych wcześniej umów. Aby zatem zabezpieczyć się na wypadek takiej sytuacji, strony powinny wprowadzić do umowy katalog okoliczności, które uznają za działalnie siły wyższej.
Znam przypadki, gdzie trzeba było eskortować na szybko programistów z Ukrainy i Białorusi do Polski, aby z jednej strony zadbać o ich bezpieczeństwo, a z drugiej o operacyjność firmy.
W zależności od konkretnych ustaleń, klauzula siły wyższej może uprawniać do wydłużenia terminu realizacji projektu lub jego wstrzymania, podwyższenia wynagrodzenia lub nawet wypowiedzenia umowy. W tym ostatnim przypadku, umowa powinna określać zasady rozliczenia dotychczasowej współpracy oraz ewentualnego przekazania klientowi dotychczas zrealizowanych prac.
Błędem często spotykanym w klauzulach siły wyższej jest uwzględnienie w nich wymogu zgody obu stron na modyfikację lub rozwiązanie umowy, której uzyskanie w przypadku rzeczywistego działania siły wyższej jest w praktyce niemożliwe. Potwierdzeniem tej konkluzji jest choćby nieprzejednana postawa właścicieli galerii handlowych, którzy – pomimo zamknięcia tych obiektów na czas covidowego lockdown’u – nie zgadzali się na obniżenie czynszu najemcom poszczególnych lokali. Z uwagi na ten i inne przykłady, klauzula siły wyższej powinna działać automatycznie, czyli bez konieczności uzyskiwania akceptacji stron umowy.
Software house ma problem, co dalej?
W przypadku wdrożenia przez software house rozwiązań opisanych we wcześniejszej części artykułu, nawet w przypadku wystąpienia problemu w realizacji projektu nie będzie miał on powodów do paniki czy choćby większych obaw.
Załóżmy jednak, że projekt był realizowany wyłącznie w oparciu o umowę pobraną z Internetu lub nie regulującą powyższych kwestii oraz ustalenia mailowe i telefoniczne, które zupełnie nie regulowały takich kwestii jak choćby przedłużenie terminu realizacji, przekroczenie budżetu lub działanie siły wyższej. Jakimi roszczeniami dysponuje wówczas klient i jak SH może się przed nimi bronić?
Zakończenie współpracy przez klienta
Pierwszą myślą nasuwającą się klientowi w przypadku wystąpienia problemu w realizacji projektu, jest najczęściej zakończenie współpracy z danym software house.
Do zakończenia umowy konieczne będzie odstąpienie od niej albo jej wypowiedzenie. Jeżeli strony nie ustaliły wcześniej, który z wymienionych sposobów posłuży do zakończenia ich współpracy, wybór jednego z nich będzie uzależniony od prawnej kwalifikacji umowy zawartej przez klienta i SH w sposób dorozumiany.
Mówiąc w uproszczeniu, umowę zawartą pomiędzy software house a klientem można zakwalifikować jako umowę o dzieło albo umowę o świadczenie usług. Kluczowym elementem przesądzającym o przyporządkowaniu konkretnej umowy do jednego z wymienionych typów jest jej przedmiot, czyli rodzaj zobowiązania zaciąganego przez SH. W przypadku gdy zobowiązanie SH polega na:
- osiągnięciu konkretnego, uzgodnionego wcześniej rezultatu (np. stworzeniu oprogramowania) – mamy do czynienia z umową o dzieło
- wykonywaniu określonych czynności w sposób ciągły, bez określonego z góry rezultatu końcowego (np. prac serwisowych, supportu) – mamy do czynienia z umową o świadczenie usług
W praktyce dość często zdarza się, że współpraca stron obejmuje elementy zarówno umowy o dzieło, jak i umowy o świadczenie usług – w takim przypadku konieczne będzie dokonanie oceny, które z tych elementów mają charakter przeważający. Niezależnie, niekiedy możliwe będzie „podzielenie” poszczególnych aspektów współpracy pomiędzy dwie odrębne umowy (jedną o dzieło i drugą o świadczenie usług), co będzie skutkowało koniecznością osobnego zakończenia ich bytów. Nie trzeba chyba dodawać, że opisane kwestie niemal zawsze będą przedmiotem sporu między stronami, dlatego jednoznaczne uregulowanie ich w formalnej umowie jest tak istotne.
Odstąpienie od umowy o dzieło
Jeżeli zawarta umowa zostanie zakwalifikowana jako umowa o dzieło, sposobem zakończenia jej bytu będzie odstąpienie od niej. Zgodnie z przepisami Kodeksu cywilnego, klient może uczynić to, gdy:
- opóźnienie SH w realizacji projektu jest tak duże, że jego ukończenie w umówionym terminie jest nieprawdopodobne (jeżeli zatem strony nie określiły z góry terminu realizacji projektu, odstąpienie od umowy z tej przyczyny jest niemożliwe). Ponadto przyjmuje się, że klient może odstąpić od umowy także wówczas, gdy na skutek opóźnienia SH, termin realizacji projektu już upłynął,
- SH realizuje projekt wadliwie (czyli niezgodnie z powszechnie przyjętymi standardami realizacji takich projektów) albo w sposób sprzeczny z umową (czyli samodzielnie modyfikuje początkowe ustalenia z klientem). Aby odstąpienie z tej przyczyny było możliwe, klient musi wcześniej wezwać software house do zmiany sposobu wykonania na prawidłowy i wyznaczyć mu w tym celu odpowiedni (czyli realny) termin.
Niezależnie od powyższego, w przypadku stworzenia w ramach projektu programu komputerowego będącego utworem w rozumieniu ustawy o prawie autorskim i prawach pokrewnych, klient będzie mógł odstąpić od umowy także wówczas, gdy ukończony program okaże się wadliwy, a SH nie usunął wad w wyznaczonym przez klienta odpowiednim terminie dodatkowym.
Skutkiem odstąpienia od umowy będzie traktowanie jej tak, jak gdyby nigdy nie została zawarta. Tym samym, każda ze stron ma obowiązek zwrócić drugiej wszystko, co otrzymała od niej w ramach wykonywania umowy. Oznacza to, że SH będzie miał obowiązek zwrócenia klientowi całości otrzymanego wynagrodzenia, natomiast po stronie klienta wystąpi obowiązek zwrotu przekazanych przez SH rezultatów prac (np. oprogramowania). Co ważne, nawet jeżeli odstąpienie nastąpi jeszcze przed wydaniem oprogramowania klientowi, SH nie będzie mógł domagać się od niego zapłaty za dotychczas wykonaną pracę.
Niezależnie od powyższego, klientowi odstępującemu od umowy może przysługiwać roszczenie odszkodowawcze opisane w dalszej części artykułu.
Wykonanie zastępcze
Tytułem uzupełnienia warto wskazać, że w przypadku, gdy SH realizuje projekt wadliwie albo w sposób sprzeczny z umową, klient – zamiast odstępować od umowy – może skorzystać z roszczenia alternatywnego, obejmującego poprawienie lub dalszą realizację projektu przez inny podmiot na koszt i niebezpieczeństwo SH (jest to tzw. wykonanie zastępcze). Szerzej o tej instytucji napiszę w innym artykule, który opublikuję już niedługo.
Jak podkreśliłem we wcześniejszej części artykułu, umowa może modyfikować niektóre postanowienia prawa, co dotyczy także uprawnienia do odstąpienia od umowy. Jeżeli zatem zawarta umowa będzie określała zasady dokonywania odstąpienia, znajdą one zastosowanie w pierwszej kolejności (dlatego warto ukształtować je w sposób korzystany dla SH).
Przeczytaj więcej w artykule: Wykonanie zastępcze w umowie IT
Wypowiedzenie umowy o świadczenie usług IT
W odróżnieniu od umowy o dzieło, umowa o świadczenie usług nie została odrębnie uregulowana w Kodeksie cywilnym, którego przepisy nakazują odpowiednie stosowanie do tej umowy przepisów o umowie zlecenie.
Oznacza to, że w przypadku zakwalifikowania zawartej umowy jako umowy o świadczenia usług, sposobem zakończenia jej bytu będzie jej wypowiedzenie.
Jeżeli strony w żaden sposób nie uzgodniły przyczyn wypowiedzenia umowy oraz okresu wypowiedzenia, klient może uczynić to w każdym czasie, bez podania przyczyny i ze skutkiem natychmiastowym.
Należy przy tym zaznaczyć, że wypowiedzenie nie powoduje uznania umowy za nigdy nie zawartą (jak przy umowie o dzieło), zatem SH może domagać się od klienta zapłaty wynagrodzenia proporcjonalnego do ilości dotychczas wykonanych prac (nawet jeżeli przyczyny wypowiedzenia leżą po stronie SH).
Ponadto, jeżeli klient wypowie umowę bez ważnego powodu, SH przysługuje prawo żądania naprawienia wynikłej z tego faktu szkody. Zważywszy jednak, że w omawianym przypadku przyczyną wypowiedzenia będzie nieprawidłowe świadczenie usług przez SH (przeważnie stanowiące ważny powód), roszczenie odszkodowawcze raczej nie znajdzie zastosowania.
Z uwagi na fakt, że kodeksowe zasady wypowiadania umów o świadczenie usług mogą skutkować ich nietrwałością (wynikającą choćby z natychmiastowego skutku wypowiedzenia), w umowie zawartej z klientem warto uwzględnić zarówno katalog przyczyn uzasadniających wypowiedzenie oraz odpowiedni okres wypowiedzenia (np. 1 miesiąc).
Odpowiedzialność za szkody
W przypadku, gdy nieprawidłowa realizacja projektu przez software house będzie skutkowała wystąpieniem szkody po stronie klienta, będzie mógł on domaga się jej naprawienia poprzez zapłatę odszkodowania. Wbrew pozorom, wystąpienie takiej szkody nie jest rzadkim przypadkiem, co ilustrują poniższe przykłady:
Przykład nr 1
Klient zlecił SH stworzenie oprogramowania, które będzie niezbędne do świadczenia usług na rzecz kontrahenta klienta. W wyniku nieukończenia prac przez SH w umówionym terminie, klient musiał zapłacić swojemu kontrahentowi karę umowną. Z uwagi na fakt, że zapłata kary wynikała z nienależytego wykonania umowy przez SH, klient będzie mógł domagać się zapłaty odszkodowania o równowartości zapłaconej kary.
Przykład nr 2
Klient zlecił SH stworzenie sklepu internetowego, którego uruchomienie w określonym terminie było warunkiem wypłaty na rzecz klienta środków pochodzących od inwestora. W wyniku nieukończenia prac przez SH w umówionym terminie, inwestor nie dokonał wypłaty na rzecz klienta oraz postanowił zakończyć z nim współpracę. Chociaż w zaistniałej sytuacji klient nie poniósł szkód w aktualnie posiadanym majątku, lecz utracił spodziewane korzyści, które mógł osiągnąć w przypadku prawidłowej realizacji projektu przez SH, może domagać się od SH zapłaty odszkodowania o równowartości tych korzyści.
Jeżeli umowa w żaden sposób nie modyfikowała zasad odpowiedzialności odszkodowawczej software house (np. nie wyłączała odpowiedzialności za utracone korzyści lub nie ograniczała odpowiedzialności SH do określonej kwoty), SH jest zobowiązany pokryć powstałą szkodę w całości.
Może on jednak uwolnić się od tego obowiązku, jeżeli wykaże, że szkoda powstała na skutek okoliczności, za które software house nie ponosi winy.
Innymi słowy SH musi dowieść, że w ramach realizacji projektu dochował należytej staranności, a szkoda jest rezultatem zdarzeń całkowicie od niego niezależnych (np. siły wyższej).
Z uwagi na dość częste korzystanie przez SH z usług podwykonawców warto dodać, że występujące po ich stronie nieprawidłowości nie mogą wpływać na zakres odpowiedzialności software house wobec klienta. Oznacza to, że nawet jeżeli nienależyta realizacja projektu wynika z błędów podwykonawców, podmiotem odpowiedzialnym z tego tytułu pozostaje wyłącznie SH, który powierzył im wykonanie określonych prac.
Z wymienionych względów, w umowach z podwykonawcami powinny znajdować się postanowienia określające zasady ich odpowiedzialności w tego typu sytuacjach (np. zastrzegające obowiązek zapłaty kary umownej).
Kto płaci odszkodowanie?
Jeżeli pod stronie software house powstanie obowiązek zapłaty na rzecz klienta określonej kwoty tytułem odszkodowania, tożsamość osoby odpowiedzialnej za jego wykonanie będzie zależała od formy prawnej, w której działa SH. W przypadku, gdy jest on prowadzony w formie:
- jednoosobowej działalności gospodarczej – podmiotem zobowiązanym do zapłaty będzie przedsiębiorca prowadzący tą działalność (zakres jego odpowiedzialności rozciąga się na cały posiadany przez niego majątek osobisty),
- spółki osobowej – podmiotem zobowiązanym do zapłaty będzie w pierwszej kolejności spółka, a jeżeli jej majątek okaże się niewystarczający – jej wspólnicy (odpowiadający całym majątkiem osobistym). Tytułem uzupełnienia należy dodać, że w przypadku komandytariuszy spółki komandytowej, ich odpowiedzialność jest ograniczona, a w przypadku akcjonariuszy spółki komandytowo-akcyjnej – całkowicie wyłączona,
- spółki kapitałowej (np. sp. z o.o., P.S.A.) – podmiotem zobowiązanym do zapłaty będzie wyłącznie spółka (odpowiedzialność jej wspólników jest całkowicie wyłączona).
Uzupełniając powyższe warto dodać, że jeżeli egzekucja należności z majątku spółki z ograniczoną odpowiedzialnością okaże się bezskuteczna, za jej zobowiązania odpowiadają swoim majątkiem członkowie jej zarządu. Mogą oni jednak uniknąć tej odpowiedzialności, jeżeli we właściwym czasie podejmą działania zmierzające do ogłoszenia upadłości spółki albo jej restrukturyzacji.
Przeczytaj więcej o spółkach w naszych artykułach:
- Prosta spółka akcyjna – kompendium wiedzy
- Spółka z ograniczoną odpowiedzialnością – kompendium wiedzy
- Porównanie spółek: Prosta spółka akcyjna, Spółka z ograniczoną odpowiedzialnością, Spółka akcyjna – w formie prostej tabeli!
Skorzystaj z 15 minutowej bezpłatnej konsultacji
Skorzystaj z 15 minutowej bezpłatnej konsultacji, podczas której udzielę odpowiedzi na Twoje pytania i sprawdzimy, czy mogę pomóc w rozwoju Twojego biznesu.
Napisz do mnie poprzez poniższy formularz i umów się na rozmowę.
Uzupełnij poniższy formularz, jeżeli np.:
- masz pytania z zakresu o którym pisałem w tym artykule,
- szukasz najlepszego rozwiązania dla swojego problemu,
- chcesz wiedzieć, jak wygląda współpraca z nami, terminy oraz koszty.
Konsultacja trwa 15 minut i jest bezpłatna. Jeżeli będziesz potrzebował dłuższej pomocy, ustalimy zakres Twoich pytań, wątpliwości i to, jak możemy Ci pomóc w prowadzeniu Twojego biznesu.
Po przesłaniu formularza skontaktujemy się z Tobą w ciągu 24h w celu ustalenia dalszych szczegółów.
Przed wysłaniem wiadomości zapoznaj się z naszą Polityką prywatności.
I na koniec
Mam nadzieję, że niniejszy artykuł przybliżył Ci zagadnienie nienależytego wykonania umowy przez software house oraz przekonał do wdrożenia w Twojej organizacji rozwiązań pozwalających zapobiec negatywnym skutkom takich zdarzeń lub istotnie je zminimalizować.
Zważywszy, że do uniknięcia znacznej większości potencjalnych problemów wystarczy zawarcie z klientem dobrze napisanej umowy, koszty jej przygotowania z pewnością zwrócą się z nawiązką.
Zdecydowanie lepiej (i taniej) jest bowiem „być mądrym przed szkodą”, niż szukać profesjonalnej pomocy dopiero wówczas, gdy może ona jedynie minimalizować poniesione straty.
Zdjęcie dodane przez cottonbro.
