Skuteczne stworzenie i wdrożenie oprogramowania w organizacji zawsze jest sukcesem firmy IT, która taki projekt realizuje. Błędy zostają poprawione, oprogramowanie zostaje odebrane i jest wykorzystywane w ramach bieżących procesów klienta. Innymi słowy, to zwieńczenie zajmującego i skomplikowanego projektu.
Czy aby na pewno?
Często okazuje się, że po jakimś czasie pojawiają się pomysły na dodatkowe funkcjonalności, zmiany layoutu albo optymalizacja UX. W innych przypadkach wdrożone oprogramowanie z założenia jest jedynie pierwszym krokiem i podstawą, która od samego początku używania ma być doposażana w dodatkowe funkcjonalności i rozwijana na bieżąco.
To zaś wymaga prowadzenia dalszych prac programistycznych.
Jeżeli chcesz dowiedzieć się co powinno się znaleźć w umowie wdrożeniowej, wpis na ten temat jest tutaj: umowa wdrożeniowa.
I teraz ważna sprawa – sam fakt, że mieliśmy zawartą umowę wdrożeniową (umowę o wykonanie projektu IT) nie oznacza, że twórca/software house, który to oprogramowanie wykonał, musi je rozwijać.
To niby oczywista sprawa, ale w praktyce zdarzają się przypadki, gdy klient, po wykonanym projekcie, co jakiś czas zgłasza „prośby o poprawki” (pomimo odbioru projektu), które tak naprawdę obejmują po prostu dodanie nowych funkcjonalności albo zmianę tego co wcześniej zostało wykonane zgodnie z wymogami klienta.
Tego typu działania to po prostu nowe prace. Zwykle nie obejmują ich ani naprawy gwarancyjne ani standardowe usługi serwisowe, które mogą wynikać z umowy wdrożeniowej.
Trzeba je więc zrealizować na bazie odrębnej umowy, za osobnym wynagrodzeniem.
Czy prace rozwojowe wymagają w ogóle umowy?
Często zdarza się tak, że dokonanie jakichś zmian w istniejącym oprogramowaniu nie jest w żaden sposób formalizowane. Po prostu klient przesyła informację o oczekiwanych zmianach do software house’u. Wykonawca to wycenia, prace są realizowane, a na końcu klient płaci fakturę. Bez żadnej formalnej umowy. Czy tak można?
Teoretycznie można – takie ustalenia dokonane np. za pomocą poczty elektronicznej też będą stanowiły prostą umowę o dzieło. Natomiast w takim przypadku pojawia się problem praw autorskich do tych zmian. Brak wyraźnego uregulowania tej kwestii skutkuje bowiem tym, że prawa autorskie nie są przekazywane na rzecz klienta, a więc formalnie to twórca (software house) pozostaje ich właścicielem. A to problem, którego lepiej uniknąć.
Jak to rozwiązać?
Przed rozpoczęciem takich prac strony mogą zawrzeć umowę o realizację prac rozwojowych, nazywaną też „umową o rozwój oprogramowania” (nazwa jest tu drugorzędna).
Taka umowa, zgodnie z prawem może być:
umową o dzieło – jeżeli dotyczy konkretnego projektu, który obejmuje realizację prac, których efekt jest znany z góry (a przynajmniej jego ogólne założenia są znane),
umową ramową, w ramach której będą zawierane poszczególne umowy o dzieło – w takiej umowie strony regulują ogólne założenia dot. realizacji prac, sposoby komunikacji, odpowiedzialność itp. Poszczególne prace są realizowane na podstawie zamówień, które składa klient, zgodnie z zasadami opisanymi w treści umowy ramowej,
umową o świadczenie usług – taka umowa po prostu zakłada, że usługodawca (software house) będzie prowadził ciągłe prace rozwojowe dot. oprogramowania. Ustalenia dot. realizacji konkretnych zadań mogą być dokonywane na bieżąco, zgodnie z zapotrzebowaniem klienta. Z reguły takie ustalenia nie wymagają żadnej szczególnej formy i są dokonywane np. mailem, przez oprogramowanie do zarządzania projektami albo jakiś internetowy komunikator.
Co powinno znaleźć się w umowie rozwojowej?
Przedmiot i zakres współpracy
W umowie rozwojowej trzeba opisać jakie działania będą realizowane przez wykonawcę na rzecz klienta. Sposób szczegółowości takich regulacji będzie zależał od tego z jaką umową mamy do czynienia.
Oznacza to, że nie zawsze musimy szczegółowo wskazywać tego:
co zostanie wykonane przez wykonawcę,
jakie cele mają być osiągnięte w ramach współpracy,
jakie funkcje mają być dodane do rozwijanego programu,
jakie działania mogą podejmować użytkownicy programu po zmianach.
Takie kwestie opisywane są w umowach, które dotyczą realizacji konkretnego zakresu prac - czyli wspomnianych przeze mnie wcześniej umowach o dzieło. Opis dokładnego sposobu realizacji prac będzie różnił się w zależności od tego jaką metodykę realizacji projektu wybierzemy.
Jeśli chcesz dowiedzieć więcej o tym jak tworzyć umowy dotyczące realizacji projektów IT w modelu zwinnym, kliknij tutaj: umowy w metodykach zwinnych, agile i scrum
W przypadku ogólnych umów rozwojowych (ramowych lub o świadczenie usług) takie szczegóły nie są wymagane. Wystarczające będzie wskazanie tego jakie oprogramowanie będzie rozwijane oraz jaki ogólny zakres działań ma być wykonywany przez firmę IT. Czasem też wskazuje się np. technologie, w których wykonawca się specjalizuje albo to jakie kompetencje powinni posiadać członkowie zespołu, którzy będą pracowali nad projektem. Szczegóły dotyczące konkretnych prac są ustalane pomiędzy stronami później.
Zasady komunikacji stron
W umowie rozwojowej warto zastrzec w jaki sposób strony będą się ze sobą komunikować. Dobrym rozwiązaniem jest:
wskazanie osób odpowiedzialnych za bieżącą komunikację stron – sugeruję tu też dodać wzmiankę, że przedstawiciel klienta ma prawo do wiążącego zlecania prac zespołowi programistycznemu oraz akceptowania efektów. Dzięki temu zabezpieczymy się przed ewentualnym zarzutem dot. tego, że dana osoba nie miała kompetencji np. do tego, aby zaakceptować wycenę jakichś prac albo odebrać efekty działań wykonawcy,
wskazanie tego, za pomocą jakich narzędzi strony się będą komunikowały. Jeżeli w bieżącej współpracy stron wykorzystywany jest np. Slack albo Jira, to warto wskazać w umowie, kto zapewnia dostęp do tego narzędzia oraz że ewentualne ustalenia dot. prac mogą być realizowane właśnie poprzez takie rozwiązanie,
opis w jaki sposób klient będzie zlecał prace zespołowi programistycznemu (to istotne zwłaszcza przy umowie ramowej albo umowie o świadczenie usług) – w niektórych przypadkach strony po prostu ustalają, że klient powinien zamieszczać opisy wymagań w ramach oprogramowania do zarządzania projektami. Następnie, wykonawca lub usługodawca akceptuje je albo zgłasza jakieś uwagi oraz dokonuje wyceny prac (o ile strony ustaliły, że takie wyceny będą przygotowywane). Czasem strony wolą nieco bardziej sformalizować ten proces i ustalić np. że szczegóły dot. realizacji konkretnych zadań będą ustalane w ramach jakiegoś formularza zamówienia, w których wpisywane są szczegółowe wymagania klienta, wysokość wynagrodzenia należnego wykonawcy albo termin wykonania prac. Obie strony biorą udział w przygotowaniu, a następnie akceptują taki formularz. Niezależnie od tego na jakie rozwiązanie się zdecydujecie, opiszcie to w swojej umowie.
Odbiory i akceptowanie prac
Standardem jest opisywanie w umowie rozwojowej zasad dot. akceptowania tego co przygotował wykonawca. W zależności od tego na ile istotne są wykonywane prace i potencjalne ryzyka, możemy mieć do czynienia z różnym poziomem szczegółowości takich uregulowań.
W przypadku bardziej złożonych projektów, w umowach opisuje się np. zasady dokonywania testów elementów przygotowanych przez wykonawcę oraz weryfikowania ich współdziałania z działającym już oprogramowaniem w ramach osobnego środowiska testowego.
Dopiero po wstępnej akceptacji takich testów oraz wprowadzeniu ewentualnych poprawek, żądanych przez klienta, dokonuje się uruchomienia nowych funkcjonalności w ramach produkcyjnej wersji oprogramowania.
Co więcej, w umowie możemy wskazać też czego mogą dotyczyć zgłoszenia błędów lub prośby o poprawki (tak aby klient nie rozszerzał zakresu prac, zwłaszcza jeśli podlegają one wcześniejszej, wiążącej wycenie), a także jaki jest maksymalny czas na ich zgłaszanie.
Podpisywanie protokołów odbioru nie jest wymagane, ale jak najbardziej można je wykorzystywać – to już kwestia upodobań stron i zasad ich współpracy. W praktyce częstym rozwiązaniem jest mniej formalna akceptacja efektów prac, np. poprzez potwierdzenie prawidłowości wykonania prac za pomocą oprogramowania do zarządzania projektami albo po prostu „milczące” przyjęcie efektów bez zgłaszania jakichkolwiek uwag.
Niezależnie od tego na jakie rozwiązanie się zdecydujemy, powinno ono zostać wskazane w umowie.
3. Wynagrodzenie w umowie rozwojowej
Prace wykonane w ramach umowy rozwojowej trzeba jakoś rozliczyć. Postanowienia, które tego dotyczą raczej nie są rewolucyjne i opierają się z reguły na jednym z trzech modeli:
wynagrodzeniu ryczałtowym – w takim przypadku wykonawca dokonuje wyceny na samym początku, gdy klient przedstawia swoje wymagania dotyczące realizacji konkretnych prac. W praktyce model ten stosuje się najczęściej w przypadku umów o dzieło, gdy cele działań programistycznych są określone na samym początku,
wynagrodzeniu kosztorysowym - na pierwszy rzut oka wynagrodzenie to jest podobne do modelu ryczałtowego - wykonawca też dokonuje wyceny na etapie otrzymania wymagań klienta. Natomiast wraz z samą wyceną, wykonawca wskazuje też podstawy jej ustalenia - np. szacunki dotyczące liczby godzin, które są potrzebne aby zrealizować poszczególne założenia i wprowadzić do oprogramowania różne nowe funkcje. W takim przypadku prawo jest nieco bardziej elastyczne jeśli chodzi o zmiany wysokości wynagrodzenia w przypadku wystąpienia jakichś nieoczekiwanych kwestii w trakcie projektu,
wynagrodzeniu za przepracowane godziny/dni robocze – ten model wynagrodzenia opiera się o to ile czasu poświęcili członkowie zespołu programistycznego na realizację poszczególnych zadań dla klienta. Model ten jest zwykle spotykany w przypadku umów o świadczenie usług, gdy prace są realizowane na bieżąco, zgodnie z aktualnym zapotrzebowaniem klienta. Nie ma jednak przeszkód, aby zastosować go również do prac, których zakres i cel jest znany od początku.
W praktyce gospodarczej pojawiają się też różne rozwiązania stanowiące połączenie powyższych systemów. Przykładowo, na początku strony mogą ustalić stałe stawki za godzinę pracy członka zespołu programistycznego. Następnie stanowią one podstawę do dokonywania szacunkowych wycen poszczególnych prac. Takie wyceny są realizowane na bieżąco, wraz z otrzymywaniem od klienta zleceń lub próśb o wykonanie poszczególnych prac.
W zależności od ustaleń stron, wyceny te mogą mieć charakter niewiążący (szacunkowy) lub wiążący dla stron. Dodatkowo, strony mogą uzgodnić, że takie wynagrodzenie może podlegać modyfikacjom również w trakcie prac, np. w związku z dokonywaniem przez klienta zmian założeń albo wystąpieniem jakichś nieprzewidzianych problemów.
4. Prawa autorskie
To ważny element umów rozwojowych. Prace dotyczące rozwoju oprogramowania mogą (i w przypadku projektów IT z reguły tak będzie) skutkować wytworzeniem utworów w rozumieniu przepisów o prawie autorskim.
Utwory te często mają charakter odrębny od podstawowego oprogramowania, które jest przedmiotem rozwoju. Innymi słowy, do istniejącego utworu (programu) dodajemy nowe funkcje, zmieniamy layout albo zasady działania programu – czyli nowe utwory.
To skutkuje tym, że do tych nowych utworów klient też musi nabyć jakieś prawa. Takie prawa uzyskamy z reguły poprzez:
przeniesienie autorskich praw majątkowych przez software house na rzecz klienta,
udzielenie przez software house licencji na wykorzystanie utworu przez klienta – w tym przypadku uprawnionym (właścicielem) do utworów pozostaje software house, acz klient może korzystać z takich utworów, zgodnie z postanowieniami dot. licencji.
Uwaga – fakt przeniesienia praw autorskich do oprogramowania wykonanego na podstawie umowy wdrożeniowej/umowy o wykonanie projektu IT, nie oznacza, że również późniejsze elementy, dodane do tego programu, będą automatycznie objęte takim przeniesieniem – nawet jeśli prace zostały wykonane przez ten sam software house.
Jeżeli chcesz dowiedzieć się więcej na temat przenoszenia praw autorskich i udzielania licencji do oprogramowania, zachęcam Cię do zapoznania się z poniższym wpisem: Prawa autorskie do programów komputerowych czyli licencje i umowy dotyczące aplikacji.
5. Odpowiedzialność
Na pierwszy rzut oka można uznać, że zasady odpowiedzialności w umowie rozwojowej powinny być zbliżone do tych, które są zamieszczane w umowach wdrożeniowych. To generalnie prawda, natomiast często zawierają one doprecyzowanie i modyfikację następujących kwestii:
ograniczenia odpowiedzialności mogą być uregulowane w inny sposób – zdarza się, że wykonawcy (zespoły programistyczne) ograniczają swoją odpowiedzialność za szkody związane z realizacją umowy wdrożeniowej np. do kwoty kontraktu. W przypadku dużej ilości drobnych prac takie rozwiązanie nie będzie najszczęśliwsze – zamiast tego można więc np. oprzeć ograniczenie odpowiedzialności o wysokość wynagrodzenia, które klient zapłacił software house’owi w danym kwartale lub roku,
odpowiedzialność będzie dotyczyła tego co software house wykonał w ramach umowy – czasami jest tak, że oprogramowanie wykorzystywane przez klienta jest rozwijane przez więcej niż jeden podmiot – w takim przypadku powszechne jest wyraźne zawieranie zastrzeżeń w umowach, że dany software house nie odpowiada za błędy spowodowane zmianami, które są wprowadzane przez samego klienta albo inne firmy IT. Podobnie, software house nie odpowiada zwykle za te nieprawidłowości, które wynikają np. z błędnego działania infrastruktury klienta albo usług świadczonych przez inne podmioty.
6. Serwis i gwarancja
Teoretycznie nie ma przeszkód, aby w umowie rozwojowej ustalić zasady dotyczące usuwania błędów w ramach przygotowanych elementów albo udzielenia na nie jakiejś gwarancji.
Czasem powoduje to jednak problemy z ustaleniem zakresów gwarancji, zwłaszcza gdy np. standardowa gwarancja na oprogramowanie podstawowe (to, które jest przedmiotem rozwoju) już wygasła. Pojawiają się bowiem trudności w ustaleniu z czego wynika dana nieprawidłowość i czy na pewno podlega ona naprawom gwarancyjnym.
W takim przypadku rozwiązaniem, które zabezpiecza interesy obu stron i precyzuje to w jaki sposób serwisowane będzie oprogramowanie, jest zawarcie osobnej umowy serwisowej, która wskazuje:
czego dokładnie dotyczą naprawy,
w jaki sposób są one realizowane i jak klient może zgłaszać ewentualne usterki,
jakie wynagrodzenie przysługuje firmie IT z tytułu realizowania takich napraw.
Jeśli chcesz dowiedzieć się więcej na temat tworzenia umów serwisowych kliknij tutaj: umowy serwisowe dotyczące oprogramowania.
Podsumowanie
Umowa dot. rozwoju oprogramowania ma całkiem sporo wspólnych elementów z umową wdrożeniową. Niemniej jednak, niektóre jej postanowienia będą dość charakterystyczne. Nie każdą umowę wdrożeniową da się łatwo przerobić na umowę dot. rozwoju oprogramowania, zwłaszcza jeśli ta druga będzie miała charakter świadczenia usług zgodnie z bieżącymi potrzebami klienta.
Jeśli masz jakieś dodatkowe pytania dotyczące umów o rozwój oprogramowania, możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.
