Umowy w metodykach zwinnych, czyli scrum, agile i kwestie prawne

Czasem spotykam się ze sporymi wątpliwościami, dotyczącymi tego jak opisać w umowie to, że oprogramowanie będzie tworzone w ramach frameworka takego jak Scrum albo, ogólnie rzecz biorąc, różnych Agile’owych sposobów tworzenia oprogramowania.

Dlaczego?

Bo na początku nie wiadomo dokładnie jaki ma być efekt prac. Co gorsza, nie zawsze wiadomo też ile będą one trwały. Potencjalne trudności można mnożyć – członkowie zespołu mogą się zmieniać, założenia projektowe ewoluują, szczegółowe ustalenie jakie technologie będą wykorzystane też może być problemem a klient zmienia zdanie. Co więc wpisać do takiej umowy?

Na szczęście nic z tych rzeczy nie musisz wpisywać. Wiem, Twój lokalny prawnik, który robił Twojej cioci rozwód w zeszłym roku, może nalegać aby opisać „przedmiot umowy” jak najbardziej szczegółowo. Najlepiej aby stworzyć wielką i długą specyfikację techniczną, która zostanie załączona do umowy. Problem w tym, że takiej specyfikacji nie masz. Nie oznacza to jednak, że Twoje interesy nie mogą zostać zabezpieczone.

I w sumie nie dziwię się temu prawnikowi, który chciałby wszystko w umowie opisać szczegółowo. On po prostu jest nauczony, że umowa o stworzenie oprogramowania to taki szczególny rodzaj umowy o dzieło. A dzieło, jak możemy przeczytać w Kodeksie Cywilnym, powinno być „oznaczone”, co oznacza, że należy skonkretyzować czym ono ma być.

Tylko, że umowa o stworzenie oprogramowania wcale nie musi być umową o dzieło.

Może być to bowiem specjalna umowa (nikt nie powiedział, że nie można tworzyć swoich – mamy w końcu zasadę swobody umów), która będzie miała elementy zarówno umowy o dzieło oraz umowy o świadczenie usług. Dodatkowo, zapewne dojdzie nam kilka innych rzeczy, takich jak przeniesienie praw autorskich albo udzielenie licencji, ewentualne usługi wsparcia/serwisu, jakaś pomoc przy wdrożeniu itp. – taka mieszanka dość mocno odbiega od standardowej umowy o dzieło, o której można przeczytać w przepisach.

Da się więc stworzyć umowę, która reguluje dokładnie współpracę stron, dotyczącą tworzenia oprogramowania przy wykorzystaniu metodyk zwinnych.

Jak napisać umowę o tworzenie oprogramowania w ramach metodyk zwinnych?

Najpierw generalne uwagi:

• Tworząc taką umowę, nie należy myśleć o niej jako tylko o umowie na czarną godzinę – umowa dot. tworzenia oprogramowania to przede wszystkim „mapa drogowa”, która pokazuje jak strony mają współpracować i co każda z nich ma robić, a nie tworzenie szeregu zabezpieczeń i wyłączeń odpowiedzialności na wypadek gdyby coś się nie udało

• Nie bójmy się opisywać tego jak współpraca powinna wyglądać – w mojej ocenie, warto do umów w branży IT (a zwłaszcza umów dot. tworzenia oprogramowania) wpisywać generalne założenia współpracy, a więc opisywać „modelowy” charakter kooperacji stron. Nie trzeba przy tym unikać opisowości – takie ogólne klauzule, które po prostu mówią jak strony mają się zachowywać mogą doprowadzić do tego, że żadne konflikty pomiędzy stronami nie powstaną, bo po prostu każdy będzie wiedział jak powinien się zachowywać - nawet jeśli nie są obwarowane jakąś odpowiedzialnością lub tym bardziej karami umownymi. Optymistyczny scenariusz? Być może, ale z obserwacji wiem, że to działa.

Napisałem ten artykuł na podstawie moich doświadczeń, związanych z tworzeniem umów dla branży IT. Nie zawsze jest to równoznaczne z „modelowym” systemem pracy w ramach metodyk zwinnych. Z tego co widzę wynika, że każda firma IT traktuje je bowiem nieco inaczej i ma jakieś odrębności. Nie jest moim zadaniem te odrębności wychwytywać – ja wyciągnąłem po prostu średnią i napisałem jak na tej podstawie można stworzyć postanowienia określające zasady współpracy pomiędzy klientem a software housem.

I jeszcze jedno – te poniższe uwagi zakładają, że product owner jest osobą zatrudnioną w software house jako człowiek odpowiedzialny za prowadzenie projektów i kontakt z klientami. Innymi słowy, jest managerem projektu, nie zaś kimś ze strony klienta. To jest bezpieczniejsze rozwiązanie, również prawnie – istnieje bowiem osoba koordynująca projekt po stronie software house, która za niego odpowiada. W innym przypadku role w umowie mogą nam się mocno rozmyć – a sytuacja gdy nie wiadomo kto za co odpowiada i klient kontaktuje się bezpośrednio z zespołem deweloperskim, może prowadzić do sporów. Jeżeli jednak software house decyduje się na oddanie tej roli klientowi, powinien upewnić się co do dwóch rzeczy:

• po jego stronie, w ramach zespołu developerskiego, będzie osoba, która może koordynować prace tego zespołu i stanowić pewnego rodzaju bufor pomiędzy product ownerem a poszczególnymi programistami/innymi członkami zespołu,

• klient zapewni udział takiego product ownera, który zna się na prowadzeniu projektów w ramach metodyk zwinnych.

Co w takim razie wpisać do umowy?

1. Przedstawiciele stron i zespół projektowy

A. W umowie wpisujemy kim są osoby kontaktowe z obu stron – często będzie to przedstawiciel klienta z jednej i product owner z drugiej strony. Podajemy oczywiście ich dane kontaktowe. W celu uniknięcia wątpliwości warto w umowie napisać, że przedstawiciel klienta ma prawo do podejmowania wiążących decyzji dotyczących projektu – w tym zmian w dotychczasowych efektach prac albo ogólnych założeniach dotyczących projektu. W umowie można dodatkowo wskazać pozostałych członków zespołu projektowego – nawet nie chodzi o imiona i nazwiska, ale np. o to, że software house deklaruje, że w projekcie będzie brało udział np. 2 seniorów, 2 midów i junior, którzy będą posiadali określone (wpisane w umowie) umiejętności. To dodatkowe zapewnienie dla klienta, które wskazuje mu, że jego projektem nie będzie zajmowało się mniej niż X osób, które mają wymagane umiejętności.

B. Ważna sprawa to ewentualne zmiany osób kluczowych – projekty mogą trwać dłuższy czas, a tym samym często konieczne uregulowanie jest tego w jaki sposób mogą zmieniać się osoby, które będą brały w nim udział. Najczęściej zmiana po prostu wymaga poinformowania drugiej strony o tym, że stara osoba odchodzi z projektu i pojawia się nowa (np. nowy programista). Niekiedy klienci życzą sobie prawa do wyrażenia zgody na taką nową osobę, tak aby móc zweryfikować jej kompetencje czy ocenić czy nadaje się do tego projektu. Zawsze zalecam dużą ostrożność w dodawaniu takich postanowień do umowy – generalnie, w mojej ocenie to software house powinien ocenić kto się nadaje do projektu a kto nie i dodatkowe decyzje klienta nie są tu wskazane, a potrafią być wręcz szkodliwe.

2. Komunikacja z klientem

A. Powinniśmy uregulować w umowie sposoby komunikacji z klientem i zasady przekazywania mu informacji. To ważna, również z prawnego punktu widzenia, sprawa. Dość oczywiste jest to, że klient powinien być informowany o tym w jaki sposób przebiega projekt. Niekiedy klient może mieć zagwarantowany dostęp do product backlogu, tak aby widzieć co się dzieje w projekcie. W innych przypadkach strony wskazują na inne miejsce, w którym np. rozpisane są poszczególne, planowane sprinty oraz to co w ich ramach ma być robione.

B. Dodatkowo, warto w umowie uregulować sposób przekazywania przez klienta ewentualnych propozycji i próśb o zmiany – np. tak aby robić to tylko w z góry opisany sposób, a nie na bieżąco, w formie takiej jaka przyjdzie do głowy akurat klientowi. Lepiej bowiem aby klient wpisywał swoje propozycje w jednym miejscu, a nie dzwonił/pisał maile każdego dnia do product ownera z nowymi pomysłami. Taki sposób komunikacji jest bardzo ważny w sytuacji gdy nie mamy precyzyjnie sprecyzowanego tego, co ma być efektem prac. To dyscyplinuje strony i po prostu ułatwia współpracę. Co równie ważne, obowiązki dotyczące aktualizowania product backlogu, terminarza, harmonogramu itp. leżą również na software house – generalnie rzecz biorąc, w umowie warto wpisać, że product owner powinien wpisywać ustalenia na bieżąco.

Co jest kluczem? Opis tego co w ramach poszczególnych sprintów ma być zrobione i jakie powinno to posiadać funkcjonalności – na tej podstawie bowiem klient powinien rozliczać software house z wykonanych prac.

Dlatego im bardziej precyzyjne będą te opisy, tym lepiej interes stron zostanie zabezpieczony (tak, obu stron). Tym samym strony powinny być zobowiązane do tego aby na bieżąco kontrolować to co mamy zapisane w ramach platformy, za pomocą której się komunikujemy i ewentualnie zgłaszać swoje uwagi.

C. Przyjmowanie feedbacku od klienta – tak jak napisałem, generalnie klient ma prawo do zgłaszania swoich uwag, próśb o poprawki i zmiany. Takie uprawnienie jest oczywiście zagwarantowane w umowie. Warto w niej również napisać jak software house powinien na takie propozycje reagować – np. powinien możliwie szybko odpowiedzieć i wskazać czy dana propozycja może zostać wprowadzona, w jakim terminie (w ramach jakiego sprintu), a jeśli może być to problematyczne (np. z uwagi na uwarunkowania techniczne) zaproponować inne rozwiązanie. Oczywiście, obowiązkiem z tym związanym, będzie również aktualizacja informacji o poszczególnych sprintach/backlogu.

D. Środowisko, w którym zamieszczane będą elementy projektu i informacje o postępach – z reguły za to środowisko odpowiada software house, który udziela dostępu do niego klientowi. To jest jak najbardziej dopuszczalne rozwiązanie – warto wpisac do umowy jakie to środowisko będzie (np. Jira, Asana, Trello). Czasem klienci chcą mieć tez dostęp np. do repozytorium w git. Nie ma problemu aby to również uregulować. Można nawet wskazać gdzie dokładnie będą znajdowały się poszczególne rzeczy i kto ma co wpisywać (np. klient ma dopisywać uwagi właśnie w tej aplikacji, a nie wysyłać je mailem gdzieś osobno – zgodnie z wcześniejszymi sugestiami dotyczącymi komunikacji),

E. Zbieranie od klienta informacji, w tym wymagań dotyczących oprogramowania. W mojej ocenie, warto uregulować w umowie to, że na początku realizacji projektu zostaną przekazane pewne kluczowe informacje. Generalnie, to software house jest odpowiedzialny za zebranie takich informacji, a klient ma współpracować i udzielać wyjaśnień możliwie szybko. Innymi słowy – to software house (np. poprzez swoich business managerów albo product ownerów) mają zadać odpowiednie pytania i zapoznać się z tym jakie są oczekiwania klienta.

Nie jest to coś co musi być (nawet w dość ogólnej formie) znane w momencie zawierania umowy – można to zrobić później, a po prostu w umowie wpisać jak będzie wyglądał ten proces (np. informacje zostaną zebrane i przekazane w terminie 2 tygodni od dnia zawarcia umowy). Przykładowo, jeśli mają być stworzone user stories lub jakiś epic z założeniami projektu, to nie muszą być załącznikiem do umowy – wystarczy, że opiszesz, że w określonym terminie i miejscu przedstawiciele stron się spotkają i stworzą takie stories.

Warto również abyś wyraźnie wskazał, że to one będą brane pod uwagę na początkowym etapie prac - tzn. zespół developerski stworzy coś co funkcjonalnie takim user stories odpowiada. Rola klienta to odpowiadanie na te pytania i udzielanie wyjaśnień. Później może również zdarzyć się tak, że klient będzie pytany o jakieś dodatkowe wyjaśnienia. Wskażmy więc w umowie, że powinien w miarę szybko udzielać odpowiedzi, a dłuższe opóźnienia (np. powyżej 2 dni roboczych) mogą powodować opóźnienie w całym projekcie, za które software house, siłą rzeczy, odpowiadać nie może.

3. Czas i terminy

A. W umowie wpisujemy częstotliwość sprintów i przekazywania informacji o efektach klientowi. Tym samym, musimy uregulować to ile sprinty będą trwały (np. dwa tygodnie każdy) i co po każdym sprincie powinno nastąpić (tzn. przekazanie klientowi efektów prac). Przekazanie efektów prac powinno nastąpić w taki sposób jaki również uregulowaliśmy w umowie – znowu odwołujemy się więc do ustalonego sposobu komunikacji/środowiska testowego itp.

B. Warto w umowie wskazać jednoznacznie, że to product owner, w porozumieniu z zespołem deweloperskim, odpowiada za wskazanie priorytetów prac, ocenianie jakie działania należy podjąć najpierw a jakie można później. Często klienci chcą mieć tu prawo do decydowania o tym co powinno zostać zrobione w danym czasie, ale w praktyce to może utrudniać współpracę a nie ją ułatwia. Możemy oczywiście klientowi dać prawo do sugerowania tego co jest ważniejsze a co mniej ważne i wskazać, że product owner powinien w miarę możliwości takie sugestie uwzględniać – ale finalna decyzja powinna być po jego stronie. To product owner ustala co jest na szczycie product backlogu i wynika to z umowy.

C. Harmonogram i jego aktualizowanie – to jest coś co też warto wpisać do umowy. Harmonogram najczęściej się opiera o sprinty i jest tworzony przez product ownera (to ważne i powinno znaleźć się w umowie). Warto wskazać, że harmonogram nie jest wiążący dla stron, bo w związku z postępami prac może ulegać zmianie (np. bo pojawią sie dodatkowe zadania do wykonania). Można jednak napisać w umowie, że w miarę możliwości strony zobowiązują się do takiego prowadzenia projektu aby skończyć go w określonym terminie – choć tu odpowiedzialność software house’u będzie ograniczona z uwagi na prawo klienta do bieżącego zgłaszania uwag/propozycji nowych funkcjonalności.

D. Estymacja godzin w ramach sprintu – niekiedy klienci życzą sobie, aby software house określał ile mniej więcej godzin będzie potrzebnych na wykonanie zadań w ramach jednego sprintu, oczywiście z uwzględnieniem konkretnych rzeczy, które powinny być zrobione (tzn. wpisujemy zadania i piszemy ile one mniej więcej zajmą). To oczywiście można zrobić, trzeba tylko wskazać na ile jest to wiążące dla zespołu deweloperskiego – tzn. czy stanowi maksymalną liczbę godzin, w ramach której software house wykona dane zadanie (czyli klient zapłaci za tyle godzin ile jest w estymacji i nie więcej) czy jest tylko szacunkiem i wskazówką.

E. Kamienie milowe – milestone’y są niekiedy wpisywane do umów. Nie ma w tym nic złego i oczywiście można to zrobić. Trzeba jednak pamiętać, że raczej powinny być oparte jedynie o jakieś kluczowe funkcjonalności, nie zaś o szczegółowe opisy tego co dokładnie w ramach poszczególnego milestone’a będzie zrobione. Niekiedy strony wskazują, że milestone’y mają charakter szacunkowy i terminy, które odpowiadają poszczególnym kamieniom milowym nie są wiążące dla software house’u. Nie ma przeszkód również aby pójść w drugą stronę i nadać im bardziej istotne znaczenie – np. po 4 sprintach uzyskujemy pierwszą wersję działającego oprogramowania (czyli mamy kamień milowy), udostępniamy to szerszemu gronu osób (np. uruchamiamy na serwerze) i wtedy dajemy sobie dłuższy czas na ewentualne testy. Po ich zakończeniu wracamy do bieżących prac i rozwijamy aplikację dalej – przy czym jesteśmy już na nieco dalszym etapie rozwoju, bo podstawowa wersja programu działa i użytkownicy z niej korzystają.

F. Opóźnienia – trzeba w tym wszystkim pamiętać o tym, że jeśli software house, jako profesjonalista wskazuje, że coś się da w ramach sprintu wykonać, to ponosi za to odpowiedzialność. Innymi słowy, skoro zespół zadeklarował, że zmieści się w terminie, to powinien to w tym terminie zrobić. Oczywiście, możemy w umowie wskazać, że drobne opóźnienia (np. w ramach jednego sprintu) nie rodzą jakichś konsekwencji, ale na to klient może się nie zgodzić. Jak więc rozwiązać taki problem? Niekiedy robi się to tak, że w umowie napisane jest, że opóźnienie nie przekraczające 5% czasu trwania całego projektu (określamy to procentowo, bo nie wiadomo ile będzie projekt trwał), liczone w dniach, nie powoduje negatywnych konsekwencji. Tym samym, nawet gdyby pojawiły się jakieś nieprzewidziane okoliczności (np. trzeba będzie dodać awaryjny „sprint” poprawkowy), to projekt po prostu ulegnie delikatnemu wydłużeniu.

G. Końcowy etap prac – z uwagi na to, że niekiedy projekty trwają w nieskończoność (zespół cały czas rozwija oprogramowanie i ciągle nad nim pracuje) nie zawsze jest to element, który ma kluczowe znaczenie. Można zawrzeć umowę na czas nieokreślony, wskazując, że po prostu zespół programistów będzie nieprzerwanie tworzył jakieś rozwiązanie na rzecz klienta. Niemniej jednak, w większości umów trzeba wskazać na zasady określenia momentu, w którym projekt uznawany jest za skończony. Przy czym, z uwagi na taka a nie inna metodologię, sugeruję aby to same strony decydowały finalnie o tym, że coś jest skończone albo nie, ewentualnie opierając się o jakieś bardzo ogólne, przedstawione przez klienta na początku, kryteria. Podobnie jak w przypadku bardziej klasycznych projektów, takie zakończenie prac powinno być potwierdzone jakimś protokołem odbioru (chociaż bardzo prostym), w którym np. wskażemy na najważniejsze funkcjonalności, które posiada stworzone oprogramowanie.

Aby nie kończyć współpracy z dnia na dzień, można wskazać, że klient ma prawo do przejścia na model „utrzymania” oprogramowania, tzn. zmniejszenie zespołu deweloperskiego i skoncentrowanie się na bieżących działaniach rozwojowych, likwidacji błędów itp.

Dzięki temu koszty zostaną ograniczone, a jednocześnie zamówiony program nadal może być jakoś rozwijany.

4. Inne ważne rzeczy

A. Kwestie techniczne – w trakcie projektów klienci często chcą mieć prawo do decydowania (albo wyrażania zgody) na określone rozwiązania techniczne, wykorzystane technologie itp. To oczywiście fajne dla nich, aby mieć takie prawo, ale byłbym ostrożny w dawaniu klientowi prawa do finalnego podejmowania tego rodzaju decyzji. Również tu ostatnie słowo powinno należeć do product ownera i zespołu devów, a nie do klienta – on może mieć prawo jedynie do sugerowania rozwiązań.

B. Testy – w umowie można uregulować zasady dot. testowania przekazanych elementów oprogramowania i wprowadzania do nich poprawek. Głównie chodzi tu o cały proces związany z udostępnieniem środowiska testowego klientowi (za co generalnie będzie odpowiadał software house), czas, w ramach którego klient może dokonać testów (np. co do zasady po każdym sprincie ma 7 dni na testy), a także dodatkowe obowiązki testerskie po stronie software house (np. tester jest częścią zespołu developerskiego).

Oczywiście wpisujemy też w umowie w jaki sposób ewentualne uwagi mają być przekazane do software house. Można tu posiłkować się ogólnymi postanowieniami dot. komunikacji pomiędzy klientem a product ownerem, tak aby nie wprowadzać w tym zakresie zamieszania. Następnie, software house powinien wprowadzić ewentualne poprawki i też warto wskazać termin, kiedy powinien to zrobić – np. w ramach następnego, rozpoczynającego się sprintu. Warto też wskazać, że nie każdy sprint musi się kończyć oddaniem czegoś co można testować (zwłaszcza na początku).

C. Definition of done – definiowanie tego pojęcia w umowie jest dość problematyczne. Przede wszystkim, możemy wskazać, że zespół deweloperski ma dostarczać skończony element po każdym sprincie, tak aby nadawał się on do użycia, miał jakieś funkcjonalne zastosowanie. Efekt sprintu powinien oczywiście zawierać te elementy, które w ramach danego sprintu miały być wykonane. Innymi słowy, punktem odniesienia jest to co zostało wpisane przez product ownera i w ramach sprintu miało być zrobione i jakie miało mieć cechy. Dodatkowo, możemy wskazać, że taki efekt prac w ramach sprintu powinien zawierać już przygotowaną dokumentację albo zostać przetestowany po stronie software house’u. Tym samym, to co zostało zrobione oczekuje na akceptację klienta, który ma prawo to przetestować i sprawdzić czy zgadza się z jego oczekiwaniami. Jeśli tak, to dany etap zostaje oznaczony jako zakończony – formalnie może robić to to przedstawiciel software house’u. I tak naprawdę w wielu przypadkach takie ogólne odniesienie się do tej kwestii wystarczy. Niemniej jednak, niekiedy w umowach pojawiają się dodatkowe postanowienia, dotyczące tego, że jakiś etap prac jest już zakończony i nie wracamy do niego, a decyzję o zakończeniu podejmuje klient. W takiej sytuacji przedstawiciel software house’u może ewentualnie wezwać (poprosić) klienta do zaakceptowania prac – jeśli klient ich nie akceptuje, to powinien wskazać co powinno zostać zrobione albo nie. Jeżeli nie zgłosi uwag do takiego „oddanego etapu” to uznajemy go za zakończony.

D. Rejestrowanie czasu pracy – w większości umów osoby pracujące nad projektem będą zobowiązane do rejestrowania czasu pracy, czyli wpisywania godzin i pisania co w ramach tych godzin robiły. To jak najbardziej poprawne aby wpisać to do umowy, wraz z obowiązkiem regularnego przekazywania tego do klienta (najlepiej po każdym sprincie, ew. z każdą fakturą). Uwaga na marginesie – czas pracy powinien być wpisany tak, aby chociaż w miarę wynikało z niego co członkowie zespołu robili. Wpisanie czasu tak, że 60 godzin zostało przeznaczone na jedno, bardzo ogólne zadanie, generalnie nie buduje zaufania i na pewno zostanie wyciągnięte przez klienta na etapie ewentualnego sporu.

E. Wynagrodzenie – w przypadku takich umów najczęściej wynagrodzenie oparte jest o stawkę godzinową/dzienną członka zespołu projektowego. Nie ma przeszkód aby praca różnych członków zespołu (np. w zależności od ich doświadczenia lub umiejętności) była różnie wyceniana. Generalnie rzecz biorąc, tak długo jak długo klient zgadza się na stawkę godzinową/dzienną, z reguły nie ma problemu i negocjacje umowne przebiegają szybko.

Trudności z kolei pojawiają się, gdy koncepcja wynagradzania jest inna i klient życzy sobie np. określenia jakiejś maksymalnej ilości godzin, które powinien zająć projekt, przy jednoczesnej konieczności prowadzenia prac zgodnie z założeniami (w tym uwzględniania ewentualnych zmian lub poprawek). Podobnie jest w sytuacji gdy klient chce po prostu stałej ceny za jeden sprint. Przenosi to bowiem część ryzyka na software house, w zakresie wstępnych ocen ile zajmie projekt lub poszczególne sprinty.

W takiej sytuacji to członkowie zespołu projektowego będą odpowiadali za ewentualne przekroczenie godzin i błędne estymacje (bo źle ocenili liczbę potrzebnych na projekt/sprint godzin) – co w praktyce oznacza, że za niektóre przepracowane godziny nikt im (albo ich pracodawcy) nie zapłaci. Mimo wszystko, jak najbardziej można to tak uregulować, jeśli software house zgadza się np. na poniesienie większej części ryzyka biznesowego projektu. Istnieją również modele pośrednie – np. wynagrodzenie za każdy kamień milowy osobno, za każde user stories albo za każdy z wpisów w backlogu.

F. W umowie można uregulować też minimalną ilość godzin, która będzie poświęcana przez pracowników zespołu deweloperskiego naszemu projektowi w ramach jednego sprintu (najlepiej oczywiście aby zajmował się on tylko jednym projektem, ale to często niewykonalne) – takie postanowienia nie pojawiają się zbyt często, ale się zdarzają.

G. Warto ustalić w jaki sposób strony powinny postępować w sytuacji gdy nie chcą już dalej współpracować – np. czy klient ma prawo do przekazanych jak dotąd etapów prac (tych, które zostały wykonane w ramach już zrealizowanych sprintów) i czy otrzymuje prawa autorskie do efektów tych prac (utworów przygotowanych w ich ramach). Z drugiej strony, software house może mieć prawo do dodatkowego wynagrodzenia w sytuacji gdy takie prawa są przekazywane pomimo tego, że projekt nie jest jeszcze zakończony. Warto również uregulować w umowie przekazanie dokumentacji dot. projektu i kopii backloga. Trzeba tu również uregulować termin wypowiedzenia takiej umowy (np. 1 miesiąc) tak aby strony nie były zaskakiwane wypowiedzeniem z dnia na dzień (oczywiście takie prawo również może być wyjątkowo przyznane, np. w przypadku naruszeń bezpieczeństwa danych albo nieusprawiedliwionego wstrzymania prac przez software house).

Oczywiście te uwagi dotyczą tylko sposobu realizacji współpracy pomiędzy stronami w ramach metodyki zwinnej. Nie dotyczą np. kwestii związanych z gwarancją lub rękojmią, odpowiedzialnością stron, karami umownymi czy też przeniesieniem praw autorskich lub udzieleniem licencji, co pewnie również znajdzie się w umowie dot. stworzenia oprogramowania. Pisałem o tym nieco tutaj.

Na zakończenie mogę dodać, że umów dotyczących projektów „zwinnych” nie należy się obawiać – jest ich coraz więcej, a tym samym szlak dotyczący tego jak powinny one wyglądać został już dawno przetarty 😊

Umowy w świecie IT bywają dość złożone, a podczas ich tworzenia trzeba wziąć pod uwagę wiele rzeczy. Jeśli masz jakieś dodatkowe pytania dotyczące takich kontraktów, możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.

#umowy #softwarehouse #oprogramowanie #agile #scrum #programowaniezwinne #metodykiprojektowe #kontrakty #umowyIT #tworzenieoprogramowania