Kolejny odcinek podcastu Prawo dla Biznesu to ciąg dalszy, a zarazem półmetek, tematyki dotyczącej prawnych aspektów IT.
Tym razem z podcastu dowiesz się tego, jak prawidłowo ułożyć stosunki z software housem, czyli innymi słowy porozmawiamy o tym, jakie aspekty umowne są ważne w umowie na stworzenie, wdrożenie i utrzymanie oprogramowania. W szczególności, po raz kolejny, pojawią się kwestie dotyczące tego:
- w jakich sytuacjach optymalna jest praca waterfallowa,
- w jakich sytuacjach najlepiej wybrać agile,
- czy agile to umowa bez „twardych” postanowień,
- jakie są istotne odrębności przy umowach body leasingu.
Zapraszam do słuchania oraz do pobrania bezpłatnego niemal 200 stronicowego ebooka Prawo dla Biznesu. IT, w którym znajdziesz prawie 200 stron informacji na temat najważniejszych aspektów prawnych w IT!
- Zapisz się na newsletter -> https://mailchi.mp/cc5a6cdc6fb8/newsletter-dla-biznesu
- Ebook Prawo dla Biznesu. IT – http://bityl.pl/YLATo
- Prawo dla Biznesu. E-commerce – https://bit.ly/3dKZWy7
Słuchaj podcastu
Cześć,
Z tej strony Piotr Kantorowski, a to już piąty odcinek dotyczący prawnych aspektów IT. Dzisiaj powiemy jak prawidłowo ułożyć umowę z softwere house’m i jak może to być rozegrane w kontekście możliwych wariantów współpracy. Ostatnio mówiłem o rodzajach umów, które mogą być podpisane, chociaż w dużej mierze skupiałem się tam na kwestii prawa autorskiego. Jest ona istotna, w każdym razie na tej płaszczyźnie pojawiają się najdalej idące problemy, jeżeli nie będzie coś uregulowane w sposób należyty. Z drugiej jednak strony nie wyczerpuje to regulacji umownych między stronami, jest w zakresie umowy trochę więcej kwestii wymagających omówienia, są też kwestie przed szereg, w kontekście pozostałych postanowień umownych. O tym chciałem dzisiaj opowiedzieć. Trochę w kontekście tego podziału na umowy waterfall i agile. Powiem też kilka słów o body leasingu, pojawił się on ostatnio i dzisiaj też się pojawi, jest tam istotna odrębność, którą chciałbym wyeksponować także dzisiaj. Zanim przejdziemy do kwestii waterfall, agile czy body leasing to chciałem zacząć od kwestii podstawowej, nie będzie to oznaczenie stron w umowie, o tym już mówiłem. W każdym razie zacznijmy od tego, że taka umowa dotycząca IT może być
w zależności od tego, mówimy tu o umowach B2B, o umowach o pracę może zaznaczę, zostanie zupełnie pozostawiona w ramach poprzedniego odcinka, a w ramach współprac B2B, możemy ułożyć sobie umowę żeby była to umowa o dzieło albo umowa o świadczenie usług. Mówiąc tę rzecz od razu prostuję – jest to pewne daleko idące uproszczenie w kontekście, który będzie tu nas najbardziej interesować. Najczęściej takie umowy w IT są umowami mieszanymi, tzn. mają elementy umowy o dzieło i umowy zlecenia, natomiast umowy zlecenia, umowy o świadczenie usług, ostatnio tłumaczyłem jaka jest w tym zakresie różnica, natomiast jakby istotne jest przede wszystkim to, że jeśli stworzenie oprogramowania zostanie uregulowane w sposób, który odpowiada umowie o dzieło, będzie to niosło określone skutki prawne istotne z perspektywy twojej, jako softwere house’u, jako zamawiającego, a jeśli będzie to ułożone w kierunku umowy o świadczenie usług, także będzie to miało określone skutki prawne. Jakie? Już tłumaczę. Otóż myślę, że to nawet wybrzmi w tym momencie, ale umowa o dzieło jest umową rezultatu, umowa o świadczenie usług jest umową starannego działania, co oznacza, że w przypadku, kiedy podpiszemy umowę o dzieło mamy pełne prawo oczekiwać, że to, na co się umówiliśmy, zostanie wykonane, bo nie umówiliśmy się „po ludzku” na robienie, tylko umówiliśmy się na zrobienie. W przypadku umowy o świadczenie usług sprawa wygląda nieco inaczej. My się tam najczęściej umawiamy nie na zrobienie tylko na robienie. To daleko idące uproszczenie i już dorzucam do tego kilka istotnych elementów. Po pierwsze, trzymając się umowy o dzieło, jako pierwszej, nie będziemy związani umową jeżeli umówimy się na świadczenie niemożliwe, tzn. jeżeli okaże się w trakcie programowania, że stworzenie danego oprogramowania jest obiektywnie niemożliwe, podkreślam, obiektywnie niemożliwe, to znaczy, że nikt nie może tego zrobić, a nie, że my nie możemy tego zrobić, i my tu się możemy czasem postawić w jednej linii i dać się porównywać z Elonem Muskiem, to znaczy oczywiście stawiam go, jako pewną figurę retoryczną, natomiast chodzi generalnie o to, że ta niemożliwość świadczenia musi mieć obiektywny charakter, a nie subiektywne przyczyny po naszej stronie. Z kolei umowa starannego działania nie polega na tym, że my powiemy „o nie, nie wyszło, ale się staraliśmy”, to jesteśmy zwolnieni z każdej odpowiedzialności wynikającej z niewykonania umowy. Chodzi tu o staranne działanie, które jednak zachowuje standardy profesjonalizmu i najnowszej wiedzy technicznej, która w IT zmienia się dynamicznie. Oczywiście może to być z ograniczeniem w umowie do języków oprogramowania z takim czy innym wskazaniem na to, jak ta umowa będzie wykonywana i przez jaki pryzmat będziemy oceniać czy ona była wykonywana starannie czy nie, jednak finalnie mamy sytuację, że to staranne lub niestaranne działanie nie sprowadza się do tego, że my złożymy oświadczenie, że działaliśmy starannie i zwalnia nas to z odpowiedzialności. Staranne działanie jest także w ujęciu obiektywnym, nie ograniczamy się do umów IT, to jest zasada umów starannego działania, więc tu mamy podstawową kwestię, na którą powinniśmy zwrócić uwagę i będzie to miało wydźwięk i znaczenie szczególnie przy umowach wdrożeniowych, bo w takiej sytuacji najczęściej kończy się niepowodzeniem dana umowa, dana współpraca biznesowa, co niekoniecznie wiąże się wprost z tym, że któraś strona coś zrobiła źle, czasem po prostu dana sytuacja przebiega, tak przebiegają szczególnie przy zwinnych umowach, tych agile, wzajemne relacje dynamicznie się zmieniające, że danego wdrożenia nie daje się zrobić. Wspomnę, że z mocy przepisów inaczej wygląda kwestia wyjścia z umowy, która ma gdzieś korową część umowy o dzieło, a inaczej w przypadku świadczenia usług, ale ten temat zostawię, bo jestem orędownikiem, i o tym powiem później, żeby to uregulować umownie, bo często, może nawet zawsze, jak podejdziemy do tego na zasadzie świadomych decyzji, a nie oddania wszystkiego w ręce prawa, które wcale nie powstało wczoraj i nie powstało w związku z IT, w przypadku umowy o świadczenie usług czy umowy o dzieło, no to możemy jednak na tym wszystkim wyjść dużo korzystniej niż w sytuacji, w której będziemy się opierać tylko na przepisach prawa.
Idąc dalej mamy kolejną kwestią, która już będzie trochę bardziej dwutorowa. Powiem tak, więcej czasu poświęcę umowom zwinnym agile, a mniej waterfall, tu podkreślę, że w przypadku waterfall coś, co się często powtarza także w prawnych kontekstach, że tego typu umowy są wyśmienite, ale w przypadku zleceń, które są gdzieś, można to tak nazwać, w pełni możliwe do przewidzenia, co do tego, jakie kroki trzeba podjąć żeby taką umowę wykonać. Krótko mówiąc jeżeli mamy zlecenie stworzenia prostego oprogramowania, które było wielokrotnie tworzone wcześniej, a w tym przypadku jest to kwestia specyficznych funkcjonalności dla naszej konkretnej firmy, sytuacji, to myślę, że wykorzystanie rozwiązań waterfall jest jak najbardziej okej, możemy przyjąć, że każda firma, która w sposób prawidłowy swoje zadania wykonuje, każda firma z zakresu IT, czyli softwere house, będzie nam w stanie ten projekt wykonać w sposób co najmniej zadowalający, bo wykonywanie tego projektu nie wiąże się z długotrwałością, co w świecie IT może wywoływać liczne zmiany, których nie jesteśmy w stanie w żadnej mierze przewidzieć na początku realizacji umowy, ani też nie przewidujemy, że będziemy zmieniać jakiekolwiek wytyczne, które daliśmy na początku i które zostały wpisane w umowie – krótko mówiąc, jeżeli zlecamy coś, co powstanie szybko, jest przewidywalne, waterfall jest jak najbardziej w porządku. Metoda kaskadowa jest w największym uproszczeniu, metodą, która przewiduje od początku do końca, że w ramach tej konkretnej umowy będzie stworzone to konkretne rozwiązanie. Cała podbudowa, czyli to, czy jest przeniesienie majątkowych praw autorskich czy są licencje, to nie jest istotne z perspektywy agile czy waterfall, tu zdecydowanie mamy do czynienia, w tym konkretnym kontekście, uregulowaniami niestanowiącymi o różnicy między agile a waterfall, w każdym razie umowa ta nie zakłada zmian jej treści, sposobu wykonywania, w trakcie jej realizacji i to jest jej różnica. Oczywiście nie musi być tak, że w waterfall odbiór oprogramowania nastąpi dopiero po jego pełnym wykonaniu, może być tak, że odbiór oprogramowania nastąpi czy będzie następował etapami, natomiast od początku do końca wiem, co jest realizowane i zakładamy, że to zrealizowane tak czy inaczej być musi. O agile można powiedzieć trochę więcej, przy czym zacznę od rzeczy, która pokutuje, mianowicie często ludzie twierdzą, że zwinna umowa to jest umowa, gdzie w zasadzie mamy określane dwie rzeczy: że robimy i stawkę godzinową. Tu podkreślam, że „robimy” nie oznacza, że wiemy co robimy i ustaliliśmy co robimy, czyli krótko mówiąc niektórzy uważają, że w zwinnych umowach pojawia się tylko postanowienie, że za jednostkę czasu wykonawca otrzymuje określone wynagrodzenie. Moim zdaniem taka umowa nie jest umową zwinną, to, że zwinna umowa będzie się dostosowywać do zmieniającego się otoczenia, sytuacji, ale nie oznacza, że nie powinniśmy w niej określić przedmiotu tej umowy, czyli przekładając to na sytuację w IT, to nie powinniśmy w ramach zwinnej umowy określić co my w ogóle będziemy robić. Myślę, że to jest wręcz podstawowa kwestia, w kontekście agile odsyłam cię do jednego z pierwszych odcinków o IT, z Jędrzejem Paulusem rozmawiałem na ten temat więcej, dzisiaj jest trochę streszczenie i zestawienie z innymi istotnymi w kontekście formułowania umów, rzeczami. Przede wszystkim, przed szereg, absolutnie nie zgadzam się z tezą, że zwinna umowa to umowa bez wskazania przedmiotu. Powiem w ten sposób – jeżeli nie określimy żadnych parametrów usługi czy dzieła, które ma być wykonane na naszą rzecz, to możemy się jedynie finalnie spotkać z sytuacją, w której dostaniemy nie to, co chcieliśmy i nie wtedy kiedy miało być, za pieniądze, o których nawet nie myśleliśmy, jeżeli chodzi o ich wielkość i finalnie nie będziemy mogli mieć żadnych zarzutów, bo jednak przedsiębiorców wiążą co do zasady umowy, które podpisali. A z takiej umowy wynika, że miał softwere house robić, a niekoniecznie wynika co miał robić i czego nie robi z bieżącymi ustaleniami, dopóki było to zgodne ze sztuką, no to trudno będzie jakiekolwiek sensowne zarzuty wywodzić. Kolejną ważną rzeczą w umowach agile jest to, żeby dobrze ustalić proces współpracy. Dobrym wzorcowym jest scrum, gdzie każda osoba ma swoją rolę w ramach zespołu pracującego nad oprogramowaniem. Rzecz jasna są też osoby odpowiedzialne ze strony zamawiającego, choć product owner może być też już ustanowiony w ramach softwere house’u, choć uważam, że nie jest to dobre rozwiązanie. Jeżeli już to szukajmy firmy zewnętrznej, która tego product ownera przejmie, chociaż dobrze jest jak ktoś kontroluje pracę wykonawcy, czy ona odpowiada intencji zamawiającego. Nie mówię już co do poprawności, ale co do intencji zamawiającego, czyli czy program wykonuje te funkcje, o które nam chodziło. Dlatego nie polecam tego rozwiązania, żeby product owner był ze strony wykonawcy, ze strony softwere house, jednak istotne jest żeby ustalić kto, komu ma akceptować co, czyli krótko mówiąc kto jest odpowiedzialny za dane wycinki pracy, kto jest odpowiedzialny za dostosowanie danych rozwiązań do innych rozwiązań, ale też ważne jest żeby ustalić, że część decyzyjności nie jest na najwyższym poziomie, nie należy do zarządu, a jest po stronie osób, które są na pierwszej linii ognia, z którymi można pewne rzeczy na bieżąco ustalać, określać
i decydować o tym, jak ma rozwijać się projekt. Ważne jest też żeby pewne rzeczy były na wyższym poziomie, bo krótko mówiąc, oczywiście nie wszystko ma akceptować zarząd i nie można dać pracownikowi pełnomocnictwa do tego, żeby dokonywał w zasadzie wszystkich czynności od zawarcia umowy począwszy, natomiast tak jak zespół deweloperów prawdopodobnie powinien mieć wiele kompetencji technicznych w swoim zakresie, tak np. nie wiem czy byłoby wskazane żeby zespół deweloperów posiadał prawo do rozwiązania umowy z inną firmą. To wydaje mi się powinno być w kompetencji innego podmiotu. I to kolejna rzecz, która powinna być w zwinnej umowie uregulowana. Podkreślę, że kwestie tego rodzaju, także przy umowie waterfall, powinno być uregulowane kto komu, co przekazuje i kto jest odpowiedzialny za akceptację, którego elementu w całym procesie. Na to zwracam uwagę. Kolejna kwestia – dobrze jest w zwinnych umowach, które są zawierane do pewnych kwestii innowacyjnych, może nie technologicznie, ale często rynkowo są innowacyjne, ustalić, że umowa będzie wykonywana
w pierwszym rzucie do momentu stworzenia MVP, czyli Minimum Viable Product, w każdym razie uważam, że jest to istotne, bo uchroni obie strony w różnym co prawda zakresie, ale uchroni, to znaczy zwrócenie na to uwagi w umowie da sygnał wykonawcy, żeby pewne rzeczy wycenił przy założeniu, że niekoniecznie będzie umowa kontynuowana. Z drugiej strony nie będzie zmuszało zamawiającego do kontynuowania umowy, jeżeli okaże się, że jest to niecelowe, uwzględniając efekty wdrożenia MVP na rynek. Jest tu ważnym rozwiązaniem również to, że często do tego typu zwinnych umów wprowadza się prawo opcji – rozwiązania, które sprowadza się do tego, że jedna strona umowy ma możliwość jednostronnego stwierdzenia „robimy to” albo „nie robimy tego”. Krótko mówiąc rozszerzenia albo skrócenia umowy. Myślę, że w przypadku IT będziemy tu mówić o prawie opcji do rozszerzenia zakresu umowy po jakimś kamieniu milowym, niż do jego zawężenia, ale może jest to kwestia mojego spojrzenia na to, żeby to w tę stronę uregulować, a nie w drugą. Może to jest też efekt ostatnich doświadczeń na kanwie tego typu spraw, że tak to widzę. To są czasem kwestie, które potrafią się w człowieku i jego ocenach zmieniać. Czy powinno się to prawo opcji uregulować w kierunku ograniczania zakresu pierwotnego czy rozszerzania tego zakresu. Teza na ten moment – w IT raczej rozszerzanie byłoby bardziej trafionym rozwiązaniem, ale nie twierdzę, że jak przyjdzie do momentu, w którym zlecasz mi przygotowanie umowy to będę tego samego zdania, bo nie jest tak, że tylko jedno z tych rozwiązań jest poprawne a tego typu rzeczy potrafią się u człowieka zmienić, jeżeli chodzi o jego oceny. Jest to kolejna rzecz, która powinna być ujęta w zwinnych umowach. Jak to ujmiesz to kwestia dokonania pewnych wyborów.
Ważna jest również interakcyjność. Projekt powinien być podzielony na części, które mają sens ekonomiczny, gospodarczy czy techniczny. W scrumie będą to dla przykładu sprinty, kamienie milowe i z tymi rzeczami powinniśmy wiązać budowanie umowy. Kolejny ważny element to akceptacja poszczególnych etapów pracy. Uczulam – nie musicie wprowadzać sztywnych kryteriów z założenia na początku umowy do każdego etapu. Etapy mogą się między sobą różnić, mogą być różne oczekiwania w danym etapie co do bezbłędności wykonywanych prac. Nie polecam nie ustalać tego w ogóle, można to ustalić przed danym sprintem, żeby było wiadomo, na jakich zasadach dojdzie do odbioru, bo w innym przypadku dojdzie do sporu i każda ze stron będzie twierdzić, nie wiadomo która trafnie, że miała być umowa realizowania w ten sposób, że określona kategoria błędów jest dopuszczalna. Błędy krytyczne, wiadomo, które prowadzą do niefunkcjonowania programu w ogóle, nie będą mogły być tłumaczone, ale jest też trochę kategorii błędów, które pewne usprawiedliwienie i dopuszczalność przejścia do kolejnego etapu można by im było przypisywać. Na to też warto zwrócić uwagę. Jest to moim zdaniem kolejna istotna rzecz przy umowach agile.
Następna istotna rzecz to będzie kwestia dotycząca tego, że mamy te prawa autorskie, ale nie będę o nich mówił dużo, w poprzednim odcinku powiedziałem o nich bardzo dużo. Pamiętajcie jednak, że czy jest umowa skonstruowana, jako umowa o świadczenie usług czy jako umowa o dzieło, przyjmując korowe zakresu umowy, bo to najczęściej będzie umowa tak czy tak nienazwana, to pamiętajcie, żeby te prawa autorskie świadomie uregulować i pamiętajcie, że program komputerowy może wymagać później modyfikacji i dobrze by się było uniezależnić od wykonawcy, jeżeli jesteś zamawiającym, albo uzależnić od siebie zamawiającego, jeżeli jesteś softwere house’m. Decyzja zależy od ciebie i od tego, po której stronie tej umowy się znajdziesz.
Kolejna ważna rzecz to odpowiedzialność stron. Podstawową kwestią jest to, że na kanwie prawa cywilnego, co do zasady odpowiadamy na zasadzie takiej, że jeśli istnieje związek przyczynowy między naszym działaniem a powstałą szkodą to jest to zakres naszej odpowiedzialności. Podam przykład rozjaśniający. Jeśli kupiliśmy maszynę w leasingu i jest wpisane oprogramowanie, które ma tę maszynę w jakiś sposób synchronizować z innymi urządzeniami, które już mamy i to oprogramowanie nie powstanie w czasie, w którym zakładaliśmy, a co więcej, na skutek tego nie byliśmy w stanie puścić jakiejś określonej produkcji, to za to softwere house, za to, że nie zarobiliśmy na tej produkcji, nie będzie odpowiadał cywilnie, chyba, że rozszerzymy jego działalność, co w kontekście softwere house nie wyrażałbym zgody, skupiłbym się na tym, żeby jednak w tym zakresie swoją odpowiedzialność co najmniej pozostawić na poziomie wynikającej z przepisów, więc tak mniej więcej należy rozumieć związek przyczynowy, przy czym kolejną rzeczą istotną jest to, że możemy w umowie wprowadzić kary umowne. Powiem tak, papier wszystko przyjmie i kary umowne można wprowadzić w dowolnym rozmiarze, tylko nie zawsze sąd je zasądzi, bo jak kara jest wygórowana, albo umowa została wykonana prawie w całości to są podstawy do miarkowania kar umownych. Od drugiej strony sytuacja jest taka, że jeżeli w umowie nie wskażemy, że nasza szkoda jest wyższa od zasądzonej kary umownej to nie będziemy mogli dodatkowego odszkodowania dochodzić, a jeżeli tak zastrzeżemy, takie prawo będzie nam przysługiwać. Nie można o tym zapomnieć, bo jest to ważne w newralgicznych sytuacjach.
Ostatnią rzeczą są kwestie exit planu. Pamiętajmy, żeby wprowadzić sobie uregulowania, które pozwalają nam wyjść z umowy, jeżeli uznamy, że jej dalsza realizacja jest bezcelowa. Zróbmy to na pierwszym etapie, trochę zastanówmy się, czy sprawa wygląda tak, że wyjście z dnia na dzień z umowy jest dobrym dla wszystkich rozwiązaniem. Może warto poszukać konsensusu co do czasu, żeby ani nie musiał zgłaszać wniosków o ogłoszenie upadłości zamawiający na skutek konieczności zapłacenia wynagrodzenia, mimo, że oprogramowanie straciło jakikolwiek sens gospodarczy dla niego, ani softwere house, bo został z setką programistów, którzy pracowali nad projektem, a z dnia na dzień projekt został zakończony. To są w zasadzie wszystkie najważniejsze rzeczy dotyczące zwinnych umów.
Pozwolę sobie wspomnieć o scrumie. Tutaj sprawa wygląda tak, że wbrew pozorom scrum jest czymś, co prawu jest znane. Może nie tak, że jest umowa na wykonanie czegokolwiek w scrumie, natomiast są interpretacje podatkowe, gdzie się ten scrum pojawia. One są w kontekście, o którym będę mówił i który mógł być poruszony w odcinku z Łukaszem Gągałą, czyli w kontekście IP boxu, i w kontekście kosztów uzyskania przychodu 50%, ale to jeszcze poczekajmy. Kluczowe elementy tej metody pracy to przejrzystość, na to chciałem zwrócić uwagę. Inspekcje, czyli stała kontrola procesu i adaptacje, czyli wprowadzenie możliwości dostosowywania tego, co jest w ramach umowy wykonywane do zmieniających się warunków. Kolejną ważną kwestią są funkcje, w ramach zespołu projektowego właściciel projektu, zespół deweloperów, scrum master, to są rzeczy, które powinny się w dobrze skonstruowanej umowie scrumowej znaleźć, powinny być rozpisane, każdy powinien mieć określone swoje role, każdy proces powinien mieć odpowiedni zakres kontroli i o tym należy pamiętać, po której byś stronie nie stał. Oczywiście o kwestiach formułowania umów mógłbym mówić długo, tylko jaki to ma finalnie cel, że przez 2-3 h opowiem ci szczegółowo jakie powinny mieć postanowienia tego rodzaju umowy. Dobrze skonstruowana umowa, szczególnie agile, wymaga udziału specjalisty w postaci prawnika, z drugiej strony wcale nie jest inaczej przy umowach waterfall, wydaje się tylko, że są one prostsze – jest tam wiele elementów, które można zepsuć pisząc taką umowę, dlatego lepiej zlecić to specjaliście.
Na koniec ostatnia rzecz w kontekście wspomnianego wcześniej body leasingu. Mianowicie czy to umowa rezultatu, czy umowa starannego działania, modelowy body leasing to umowa starannego działania, gdzie przynajmniej za samą koordynację zespołu odpowiedzialność ponosi osoba ze strony zamawiającego, co może komplikować dochodzenie roszczeń, jeżeli się dane rozwiązanie, nad którym pracuje zespół deweloperów, okaże niepowodzeniem, przy czym też nie należy traktować tych słów tak, że nie należy zawierać umów body leasingowych, wszystko zależy od konkretnej biznesowej sytuacji i w ten sposób pewne kwestie należy oceniać. Jeżeli chodzi o sporządzanie umów to na ten odcinek jest to już wszystko, co chciałem ci powiedzieć. Uczulam, że mogą pojawić się jeszcze inne kwestie tego dotyczące. Z całą pewnością do umów wrócę, może w następnym odcinku. Na dzisiaj to już wszystko, bardzo dziękuję. Przypominam jeszcze, że do nabycia jest nasza pierwsza książka „Prawo dla biznesu. E-commerce”, myślę, że temat e-commerce jest związany z IT. Zapraszam również do podcastu, który nagrywam
z moją żoną Agnieszką Kantorowską. Zapraszam.
