Wprowadzenie

Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, albo gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, albo w sporach, także przedsądowych, między dostawcą oprogramowania i zamawiającym. Bywa, że jest to już etap pisania opinii dla sądu. Tu razem kilka spostrzeżeń z tych analiz.

Na marginesie. W sporach przedsądowych i sądowych wynik ekspertyzy absolutnie nie może być “zamówiony”, czego niestety często oczekują, nie raz wręcz żądają pod groźbą odmowy zapłaty za tę usługę, zamawiający takie ekspertyzy. Bywa to tym bardziej żenujące, że roszczenia takie wysuwają czasami prawnicy zlecających, czyli osoby znające prawo i – teoretycznie – stosujący zasady etyki w swojej pracy.

Wiele lat uważałem, że winni są dostawcy, którzy powinni wykazać się możliwie najwyższym profesjonalizmem, a tego nie robią. Jakiś czas temu zmieniłem jednak zdanie (nie o profesjonalizmie dostawców).

Poza realizowanymi projektami, prowadzę także szkolenia oraz zajęcia ze studentami studiów niestacjonarnych i podyplomowych: to nie raz doświadczeni praktycy. Na wykładach i ćwiczeniach staram się pokazać “jak to robić dobrze”, jednym z elementów tego “jak to robić dobrze” jest “jak nie robić tego źle” i dyskusje na ten temat.

Dlaczego zmieniłem zdanie?

Zarówno własne doświadczenie, jak i dyskusje ze studentami, przekonały mnie, że generalnie celem dostawcy jest maksymalizacja zysków. Co mi stale mówią uczący się u mnie praktycy? Klient nasz pan, mamy robić wszystko co chce klient bo on za to płaci, a to, czy to co klient chce ma sens, nie ma znaczenia bo to problem klienta (chyba każdy konsultant i programista dostawcy słyszy to od swojego przełożonego raz dziennie).

Jak klient nie wie czego chce, to na jego koszt próbujemy.

W 2018 artykuł o porażce wdrożenia w LIDL kończyłem słowami:

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystąpią? (źr.: Porażka za 2 mld zł. Lidl wycofuje się z wdrożenia SAP – Jarosław Żeliński IT-Consulting)

We wnioskach z porażki HERTZ w 2019 roku czytamy:

ZARZĄDZANIE ARCHITEKTURĄ IT WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

więc winny jest zamawiający…

Umowa efektu a staranne działanie

W prawie cywilnym wyróżniono dwie podstawowe formy świadczenia zamówionej usługi:

1. Umowa o dzieło
2. Umowa zlecenia

Scharakteryzowane zostały w następujący sposób:

Umowa o dzieło

Art. 627. Przez umowę o dzieło przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, a zamawiający do zapłaty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umowę zlecenia przyjmujący zlecenie zobowiązuje się do dokonania określonej czynności prawnej dla dającego zlecenie.

§ 2. W braku odmiennej umowy zlecenie obejmuje umocowanie do wykonania czynności w imieniu dającego zlecenie. Przepis ten nie uchybia przepisom o formie pełnomocnictwa.

[zotpressInText item=”{5085975:CRCTGBQT}”].

W powszechnej i utrwalonej opinii prawników i w orzecznictwie przyjmuje się, że:

“Umowa zlecenia jest umową starannego działania. Zleceniobiorca zobowiązuje się do starannego działania i za to właśnie odpowiada, a nie, jak w przypadku umowy o dzieło, za rezultat pracy. W umowie należy więc dokładnie opisać czynności, jakie ma wykonywać zleceniobiorca, by później można było ocenić, czy zlecenie zostało wykonane oraz czy zostało wykonane w sposób staranny.” [zotpressInText item=”{5085975:QDAU3MZU}”]. A także, że “…można stwierdzić, iż w zobowiązaniach starannego działania dłużnik zobowiązuje się jedynie do dołożenia należytej staranności w zmierzaniu do ustalonego celu, z tym że jego osiągnięcie pozostaje poza treścią stosunku zobowiązaniowego. Natomiast w przypadku zobowiązania rezultatu na dłużniku ciąży powinność osiągnięcia oznaczonego z góry, sprecyzowanego rezultatu, przy czym ten rezultat to określony fakt, w nastąpieniu którego wierzyciel jest zainteresowany, prawny i ekonomiczny skutek oznaczony w treści zobowiązania, nie zaś sama czynność, którą dłużnik powinien podjąć.” [zotpressInText item=”{5085975:EJ6PPMEQ}”].

Podsumowując można stwierdzić, że

1. Umowa o dzieło to umowa, w której dający zamówienie z góry opisuje to co chce otrzymać (dzieło), a przyjmujący zamówienie zobowiązuje się to dostarczyć (wykonać dzieło).
2. Zlecenie to umowa, w której przyjmujący zlecenie działa w imieniu dającego zlecenie, w konsekwencji za efekt zleconej pracy odpowiada dający zlecenie.

Znakomita większość umów na dostarczenie oprogramowania to, umowy starannego działania, a tak zwane umowy “agile” mają taki charakter z zasady. Tu za uzyskany efekt zawsze odpowiada Zamawiający.

A jeżeli dostawca jest nierzetelny? Jest takie ryzyko, jednak odpowiedzialnością zamawiającego jest także nadzór na pracami wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria oprogramowania, na tle innych obszarów inżynierii, jest młodą dziedziną, która nie wykształciła dedykowanego prawodawstwa, tak jak np. inżynieria budowlana, która ma “swoje” prawo budowlane. Z tego też powodu, jedynym źródłem opisów postępowania są tak zwane dobre praktyki, standardy oraz analogie, stosowane także – w obszarze inżynierii – do prawa budowlanego.

Na diagramie ‘Iteracyjno-przyrostowy proces tworzenia oprogramowania’ zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie [zotpressInText item=”{5085975:GMJDZZJ4}”]. Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna ‘pętla iteracyjna rozwoju i utrzymania’ nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnieniem w toku wdrażania zmian w firmach.

Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) [zotpressInText item=”{5085975:IWL4AAEZ}”]. Z reguły robi to wtedy wykonawca przyjmujący zamówienie [zotpressInText item=”{5085975:IWL4AAEZ}”]. Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający [zotpressInText item=”{5085975:N4KMEKC8}”]. Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć, za efekt efekt biznesowy z zasady odpowiada “biznes” [zotpressInText item=”{5085975:6J8ZX2MR}”]. 

W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt: w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności. Nowe funkcjonalności powstają w toku rozwoju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania.

Wdrożenie

Projekty wdrożeniowe (dostarczanie oprogramowania) mogą być realizowane przez bieżące zlecanie konkretnych prac usługodawcy, lub poprzez opisanie oczekiwanego efektu jako wymaganego rozwiązania i zawarcie Umowy o dzieło z przyjmującym zamówienie, co zobrazowano na diagramie Podsumowanie stanu wiedzy. W obu przypadkach Zamawiający ponosi skutki swojej decyzji bo:

1. jako zleceniodawca (umowy T&M) sam ustala co i jak ma zostać wykonane,
2. jako zamawiający określony efekt (umowy o dzieło), sam ustala oczekiwany efekt (produkt) w dniu zawarcia umowy (jako opis przedmiotu zamówienia).

Odpowiedzialność przyjmującego zamówienia polega albo na starannym działaniu, albo na zgodności tego co dostarczy z tym co zamówiono, w rozumieniu oczekiwanego efektu. Jeżeli przedmiotem zamówienia jest oprogramowanie, czyli narzędzie pracy zamawiającego, tylko zamawiający ponosi odpowiedzialność za skutki wdrożenia tego co zamówił [zotpressInText item=”{5085975:WRPWYI5X},{5085975:5VXLI5XY}”]. Dostawca odpowiada wyłącznie za przedmiot umowy [zotpressInText item=”{5085975:EJ6PPMEQ}”].

Tak więc zamawiający zawsze dostanie to co chce, ale nie koniecznie to co jest mu faktycznie potrzebne. Innymi słowy, na rynku rządzonym przez dochody i zyski, dostawca oprogramowania zawsze będzie pracował pod dyktando zamawiającego (lub za jego zgodą) i będzie to robił do wyczerpana budżetu zamawiającego.

Bardzo ciekawe są blogi dostawców oprogramowania. Wielu ich autorów faktycznie stara się, ale cóż… jeden z ciekawszych wpisów na ten temat jest zatytułowany “The art (and science) of collecting requirements: top 3 mistakes vendors make“. Autor z perspektywy dostawcy, zwraca uwagę na trzy kluczowe przyczyny porażek: uznanie, że to użytkownik odpowiada za wymagania, mieszanie wymagań z pomysłami na ich realizację, niedoceniania macierzy śladowania. To, popełnianie tych błędów, niestety jest najczęściej spotykaną cechą analiz prowadzanych właśnie przez dostawców oprogramowania, a za wszystko i tak płaci nabywca. W bardziej naukowy sposób (szczególnie krytykując wymagania pisane językiem naturalnym przez zamawiającego) opisali to bardzo dokładnie Šenkýř i Kroha [zotpressInText item=”{5085975:LXK8VA68}”].

Konkluzja jest taka, że za nieudane wdrożenia odpowiada zawsze zamawiający.

Główną winą zamawiającego jest to, że zamawia usługi, których istoty nie rozumie więc pozostawia wykonawcę praktycznie bez nadzoru, oddając mu niemalże nieograniczone uprawnienia co do zakresu projektu. Pierwszym zaś samobójczym krokiem jest zlecenie analizy wymagań i projektowanie wybranemu wcześniej dostawcy oprogramowania. Biorąc pod uwagę rynkowy konflikt interesu dostawcy i odbiorcy (zamawiający maksymalizuje żądania a dostawca maksymalizuje zysk), jest to prosta droga do porażki, jaką jest także znaczne przepłacenie.

Pytani pracownicy dostawców zawsze odpowiadają, że przecież celem jest “dowiezienie projektu”, niestety nie jest jednak żadną sztuką “w końcu dostarczyć oprogramowanie”. Sztuką jest to zrobić zgodnie z obietnicą daną pierwszego dnia projektu, a z własnego wieloletniego doświadczenia wiem, że to możliwe. Sztuką jest także to, by dalszy rozwój i utrzymanie nie były najdroższym projektem świata.

Szanowni państwo: podpisując z dostawcą oprogramowania umowę “czas i materiał”, i zlecając temu dostawcy także analizę wymagań, kopiecie sobie grób.

Za co odpowiada dostawca? Za staranne działanie, jednak stosowanie nieadekwatnych metod nie jest działaniem niestarannym, i dlatego w sądach z reguły przegrywają zamawiający a nie dostawcy oprogramowania. Wykazanie starannego działania przez dostawcę oprogramowania jest bardzo proste: comiesięczne opłacone faktury “za pracę” dostawcy oprogramowania są tak naprawdę uznaniem jego starannego działania przez zamawiającego. Pozostaje tu jedynie kwestia etyki dostawcy, ale to temat na osobne opracowanie.

Tak więc podejmując decyzję o wdrożeniu pomyślcie Państwo o ryzyku:

Zamiast podsumowania: negatywna selekcja

Jedną z ciekawszych rzeczy w mojej karierze zawodowej są prawnicy i księgowi. Sa to role bardzo znaczące w firmach, a zarazem bardzo niebezpieczne bo mają i realną władzę decyzyjną i najczęściej cechują się dużym konserwatyzmem a wiedza tych osób o informatyce jest bardzo pobieżna. Problem pojawia się, gdy taka osoba zaczyna decydować o projekcie informatycznym nie mając do tego kompetencji. Praktyka pokazuje, że wiele kastomizacji systemów ERP to skutek wymagań postawionych przez te dwie role.

Obie te role mają duża odpowiedzialność w firmach, dlatego na etapie zawierania umów często stosują bardzo restrykcyjne formy “ochrony interesu swojego mocodawcy”, co bardzo często skutkuje negatywną selekcją dostawców (niekorzystne dla sienie umowy zawierają tylko desperaci). Bardzo ciekawy opis tego zjawiska opisała mec. Renata W. Lewicka w swoim artykule “ZASKAKUJĄCE ODKRYCIE: WISHFUL THINKING RZĄDZI W IT“. Księgowi mają także tendencje to zachowawczego stosowania metod rachunkowości, do jakich są przyzwyczajeni, co często koliduje z nowoczesnymi systemami FK oferowanymi na rynku.

I nie piszę tu o swoich doświadczeniach a tym co widzę w audytowanych firmach.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wstęp

W artykule na temat ochrony know-how napisałem:

Projektant (analiza biznesowa i projektowanie), na podstawie wymagań (biznesowych) Inwestora tworzy autorskie dzieło jakim jest Projekt rozwiązania. Na tej podstawie powstają Projekt implementacji i Kod aplikacji. Wszystkie te dokumenty chroni prawo autorskie, jednak Projekt implementacji i Kod aplikacji to dzieła zależne, pierwotnym utworem jest tu Projekt rozwiązania. Dlatego autor Projektu rozwiązania ma ustawowy nadzór autorski nad jego realizacją. (źr. Ochrona know-how Prawo autorskie)

Dzisiaj opiszę problem prawnych zależności pojęciowych w projekcie informatycznym i odpowiedzialności (zobowiązań) stron umów, oraz to, jakie ma to konsekwencje w zawieranych umowach. Artykuł ten to także przykład zastosowania elementów analizy systemowej w takich rozważaniach (do stworzenia modelu pojęciowego wykorzystano symbole diagramu faktów notacji SBVR¹ oraz diagramu komunikacji UML², zostały one tu użyte w sposób bardzo intuicyjny, więc czytelnicy nie powinni mieć problemu z ich prawidłową interpretacją).

Artykuł adresuje do tych moich czytelników, którzy biorą udział w ustalaniu treści umów na dostarczenie oprogramowania.

Wybrane umowy cywilnoprawne i ich specyfika

Scharakteryzuję tu umowy i słownictwo opisane w kilku ustawach ustawach:

1. Kodeks Cywilny Tytuł XV. Umowa o dzieło³
2. Kodeks Cywilny Tytuł XXI. Zlecenie⁴
3. Ustawa o prawie autorskim i prawach pokrewnych⁵
4. Ustawa o zwalczaniu nieuczciwej konkurencji⁶

Są to trzy odrębne akty prawne i niestety nieco różne słownictwo zostało użyte w każdym z nich. Każda z nich rodzi inne zobowiązania⁷. Korzystając z zasady (logika rachunku zdań) zamiennego stosowania pojęć i ich definicji w zdaniu⁸, można uporządkować pojęcia użyte w tych umowach i doprowadzić do ich spójności w następujący sposób (model pojęciowy, notacja SBVR – diagram faktów, linia z pustym grotem wskazuje na pojęcie będące generalizacją, czytamy to np. zamawiający jest typem podmiotu prawa):

Rys. Dziedzinowy model pojęciowy (notacja SBVR)

Z perspektywy umów o dzieło podmiotami (podmiot prawa) zawierającymi umowę są przyjmujący zamówienie i zamawiający. Przedmiotem umów o dzieło jest powstanie dzieła, produktu pracy przyjmującego zamówienie (s.j.p. produkt: coś co powstało).³ Zobowiązaniem zamawiającego jest dostarczenie przyjmującemu zamówienie, niezbędnych materiałów i zapewnienie ich odpowiedniej jakości. Materiały te to często treści, które mogą stanowić tajemnicę przedsiębiorstwa zamawiającego, ich ochrona (właściwe oznaczenie⁹) spoczywa na zamawiającym, który tu dostarcza ten materiał⁹.  Zobowiązaniem przyjmującego zamówienie jest dostarczenie określonego dzieła powstałego z użyciem otrzymanych materiałów (przypominam, że informacje to także materiał). Specyficznym typem dzieła jest utwór, w tym przypadku przyjmujący zamówienie jest także twórcą⁵.

Treść umowy musi zawierać opis tego co zamówił zamawiający, przyjmujący zamówienie musi wiedzieć i rozumieć co ma wykonać. Jeżeli wartość umowy przekroczy pewien próg ryzyka dla choćby jednej jednej ze stron, dostarczane przez zamawiającego materiały powinny być przekazywane w formie pisemnej (materiał dowodowy w razie sporu).

Wynagrodzenie w umowach o dzieło jest ustalane w momencie zawierania umowy, jednak są prawne możliwości jego zmiany w trakcie jej realizacji (Art. 630 KC), dlatego warto w tych umowach wpisywać także np. stawkę godzinową lub dzienną wynagrodzenia przyjmującego zamówienie na wypadek konieczności korekty wyceny.

Z perspektywy umów zlecenia, podmiotami (stronami) umowy są: dający zlecenie i przyjmujący zlecenie. Przedmiotem umowy zlecenia jest działanie przyjmującego zlecenie (zobowiązanie przyjmującego zlecenie do należytego wykonywania czynności prawnych) w imieniu dającego zlecenie.⁴ Tu realizacja umowy jest relatywnie prosta, bo przyjmujący zlecenie działa w imieniu dającego zlecenie (Art. 734 KC). W efekcie przyjmujący zlecenie ponosi odpowiedzialność wyłącznie za jakość swojej pracy a nie za powstający produkt, nadzór nad pracami sprawuje z zasady dający zlecenie.

W obu rodzajach umów pojawia się pojęcie przekazanego materiału, materiałem tym są tu często informacje. Art. 11. pkt. 4 Ustawy⁶ mówi:

Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.

Oznacza to, że podmiot dostarczający materiały odpowiada za ich prawidłowe oznaczenie, przyjmujące zamówienie lub zleceniobiorca, ma obowiązek ochrony otrzymanych materiałów zgodnie z wytycznymi  przekazującego te materiały. Często spotykam się z tezami prawników:

?Kara umowna zgodnie z prawem jest oderwana od szkody i jej rozmiaru. To znaczy nie trzeba wykazać szkody, aby móc otrzymać karę umowną. Nie możemy egzekwować szkody uznaniowo, a zamiast tę szkodę miarkować egzekwujemy całą karę umowną. Powyższe oparte jest na art. 484 Kodeksu cywilnego, zgodnie z którym: 1. W razie niewykonania lub nienależytego wykonania zobowiązania kara umowna należy się wierzycielowi w zastrzeżonej na ten wypadek wysokości bez względu na wysokość poniesionej szkody.?

Jednak Art.484. to dział zobowiązań, dotyczy dłużnika i jego zobowiązań z tytułu świadczeń umownych zaś zachowania poufności nie jest świadczeniem, to niezachowanie poufności jest naruszeniem ogólnie obowiązującego prawa. Kwestie ochrony informacji stanowiących tajemnicę przedsiębiorstwa reguluje USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, w szczególności Art. 11. a możliwe sankcje za łamanie tego zakazu Art.18.i Art. 23 tej ustawy. Ewentualna szkoda spowodowana takim ujawnieniem wymaga jej wykazania przed sądem na zasadach ogólnych. Podpisywanie umów o zachowaniu poufności z klauzulami mówiącymi o jednostronnym orzekaniu o niedochowaniu obowiązku ochrony otrzymanych informacji i stosowaniu dorozumianych kar umownych przenosi całe ryzyko na zleceniobiorcę i nie ma uzasadnienia (jednak podpisanie takiej umowy to zgoda na tę praktykę).

Umowy cywilnoprawne mogą mieć charakter mieszany, jednak należy w takich przypadkach bardzo precyzyjnie definiować przedmioty tych umów, tak by nie było wątpliwości z czego konkretnie jest rozliczana  (kto i jakie ma zobowiązania) każda strona umowy.

Umowy na wykonanie i dostarczenie oprogramowana

Opiszę tu sytuację stanowiącą idealizację projektu informatycznego, którego zakresem jest dostarczenie oprogramowania. Idealizacja to metoda badawcza pozwalająca na stworzenie modelu sytuacji docelowej uznaną za idealną (optymistyczną), pozwalającego na ocenę stopnia wykonalności projektu lub osiągnięcia tego celu. Pozwala generalizować i abstrahować od zbędnych detali. Swego czasu opisywałem błędy popełniane często przez prawników w umowach, konkluzja była taka:

Jak więc nazwać przedmiot umowy? Autorzy [kanc. Maruta Wachta sp. j.] szukają nazwy dla pojęcia ?Oprogramowanie dostosowane do wymagań Umowy, w tym wymagań funkcjonalnych i pozafunkcjonalnych?. Rzecz w tym, że przedmiotem umowy może być (i z reguły jest) coś znacznie bardziej złożonego niż oprogramowanie, bo oprogramowanie ? jak już wyżej napisano ? nigdy samo z siebie nie jest ?czymś działającym?. Nie da się stwierdzić poprawności  działania oprogramowania bez jego uruchomienia na komputerze (w jakimś środowisku), dlatego samo oprogramowanie NIGDY nie powinno być przedmiotem umowy! W branży inżynierskiej, w IT także, mówi się o rozwiązaniach (tu informatycznych), które są systemami (ale system to pojęcie szersze, bo możemy mówić o systemie ochrony zdrowia, którego małą częścią będzie oprogramowanie). (żr.: Wzorcowe klauzule w umowach IT | | Jarosław Żeliński IT-Consulting)

Wdrażanie systemów IT, praktycznie zawsze jest (powinno być) umową o dzieło, zleceniem w tej umowie mogą być wybrane prace, tylko te co do których zleceniodawca ma przekonanie, że ma kompetencje do ich nadzoru.

Poniższy diagram obrazuje referencyjną realizację projektu dostarczenia oprogramowania  w postaci dwóch odrębnych etapów: Etap I to Umowa na projektowanie, Etap II to umowa na realizację projektu (tu projekt jako specyfikacja techniczna). Charakter tych umów (dzieło lub zlecenie) zależy od szczegółów ich treści. Tu przedstawiono sytuacje idealną: oba etapy to umowy o dzieło, w etapie drugim projektantowi (robi to Inwestor) zlecamy (zlecenie) nadzór autorski nad pracami Realizatora:

Rys. Role w projektach informatycznych (notacja UML)

W pierwszym etapie Projektant dostarczy dzieło będące opisem tego, jakie oprogramowanie ma w drugim etapie dostarczyć podmiot realizujący dostawę oprogramowania. Materiałem jaki ma otrzymać przyjmujący zamówienie od zamawiającego, są wszelkie informacje do tego wymagane. Zobowiązaniem Projektanta jest opracowanie Projektu. projekt jest wymaganiem dla Realizatora, stanowi opis przedmiotu zamówienia (dla drugiego etapu).

-> Nie jest to wbrew pozorom, tak zwany wodospad, gdyż projekt nie musi (i nie powinien być) detaliczny a realizacja jednoetapowa. Obecny etap rozwoju inżynierii  oprogramowania operuje pojęciem architektury, projekt systemu to jego architektura, detaliczną konstrukcję projektuje Realizator, robi to dla każdego komponentu osobno (czytaj: metoda iteracyjno-przyrostowa tworzenia oprogramowania).

W drugim etapie, jakim jest pozyskanie przez inwestora potrzebnego mu oprogramowania, przedmiotem umowy (zobowiązaniem) jest także dzieło. Tu jednak jest to albo cudze dzieło (tu utwór) czyli dostarczana jest licencja na cudze oprogramowanie i usługa (zlecenie) jego wdrożenia, albo dzieło (oprogramowanie) jest produktem przyjmującego zamówienie (ten zobowiązuje się do jego wytworzenia i wdrożenia). W tym etapie materiałem dostarczonym przyjmującemu zamówienie jest produkt pierwszego etapu, czyli dzieło projektanta (Projekt) stanowiące opis przedmiotu zamówienia. Biorąc pod uwagą fakt, że jest to utwór (zakładam, że prawa majątkowe do Projektu zostały przekazane inwestorowi, co powinno mieć miejsce) jego autor, w ramach umowy zlecenia, sprawuje (w takich projektach z reguły płatny) nadzór autorski.

W przypadku gdy oprogramowanie powstaje w ramach umowy o dzieło, stanowi ono utwór. Jeżeli materiał dostarczony przez zamawiającego także stanowi utwór (produkt I Etapu) będący projektem, dostarczone oprogramowanie jest dziełem zależnym, co pokazano poniżej:

Rys. Dziedzinowy model pojęciowy w obszarze inżynierii oprogramowania (notacja UML)

Zarówno Specyfikacja (jeżeli jest projektem) jak i Kod programu są utworami, Ważna uwaga: materiały opisowe zamawiającego przekazywane Projektantowi są ideą, dlatego Projektant tworzy utwór pierwotny  (Specyfikacja powinna być Projektem: metody opisu wymagań zorientowane na modele) a nie utwór zależny. Gdyby było inaczej, praca Projektanta była tu zbędna.

Podsumowanie

Podstawowym zaleceniem dla inwestorów jest oddzielanie etapów projektowania i realizacji oraz zlecenie realizacji tych etapów odrębnym podmiotom. Rok temu, pisząc o tym jak opracować przedmiot zamówienia zamawiając oprogramowanie, napisałem:

Najważniejszym celem porządkowania pojęć w umowach, są kwestie praw stron i ochrony know-how. Bez wyraźnego rozdzielenia praw do Specyfikacji i Kodu programu, pojawiają się ogromne problemy z ustaleniem praw stron. Na tym tle wszelkie formy prowadzenia projektów i wdrożeń ograniczające powstawanie dokumentów, szczególnie wszelkich Specyfikacji, popularnie zwane metodami zwinnymi (Agile), prowadzą do ogromnych problemów. Typową konsekwencją tak zwanego zwinnego podejścia, jest przejmowanie praw do know-how przez wykonawców (niestety często celowe): autor Kodu programu, który to kod powstał z pominięciem tworzenia Specyfikacji oprogramowania, wyłącznie na podstawie wywiadów z przyszłymi użytkownikami i ich przełożonymi, ma do tego kodu wszelkie prawa, a Zamawiający żadnych (musiał by je nabyć od twórcy kodu). (źr.: Przedmiot Zamówienia ? instrukcja nie tylko dla prawników, na zupę pomidorową | | Jarosław Żeliński IT-Consulting)

Uwagi na temat projektów z jakimi spotykam się jako biegły u moich klientów:

1. Jeżeli zamawiający zbyt ogólnie opisze przedmiot zamówienia w umowie, traci nad nią panowanie, jeżeli zaangażuje dostawce w formie umowy zlecenia, jako dający zlecenie praktycznie w 100% ponosi odpowiedzialność za uzyskane efekty (mimo, że nie ma do tego kompetencji merytorycznych).
2. Ustne zbieranie materiałów (tak zwane wywiady, warsztaty, burze mózgów) przez przyjmującego zamówienie, stanowi ogromne ryzyko dla zamawiającego, bo nie ma on żadnych możliwości dochodzenia swoich racji w sporach (brak dowodów). Podpisywanie notatek i raportów z takich spotkań niewiele zmienia, bo ich autorem jest przyjmujący zamówienie (to on prowadzi te warsztaty), który z reguły ma ogromną przewagę merytoryczną nad zamawiającym.
3. Połączenie tych dwóch etapów w jeden, i bezpośrednie zamówienie analizy i projektowania u dostawcy oprogramowania, na podstawie tylko ogólnego opisu jego cech, prowadzi do sytuacji, w której przyjmujący takie zamówienie (dostawca oprogramowania) sam sobie stawia wymagania, często forsuje formę umowy zlecenia, i zleceniodawca ponosi 100% ryzyka, bo nie ma wiedzy merytorycznej by nadzorować zleceniobiorcę a bierze na siebie całą odpowiedzialność za skutki jego pracy. Biorąc pod uwagę fakt, że idee (ogólny opis wymagań biznesowych) nie podlegają ochronie, prawa autorskie do tak powstałego oprogramowania pozostają przy jego tworcy.

Zalecenia dla inwestorów:

1. Z zasady dzielić projekty na dwa etapy: analizę i projektowanie oraz dostarczenie oprogramowania. Oba powinny realizować odrębne i niepowiązane podmioty (konflikt interesów).
2. Żądać by produktem pierwszego etapu był projekt oprogramowania a nie tylko specyfikacja wymagań, bo ta nie jest projektem.
3. Żądać od projektanta także usługi nadzoru autorskiego (jako projektant ponosi on także odpowiedzialność za dostarczony przez dostawcę oprogramowania produkt).
4. Żądać od dostawcy oprogramowania wykonania koncepcji wdrożenia (projekt implementacji), bo to gwarantuje możliwość dochodzenia odszkodowań od dostawcy oprogramowania. Jeżeli na etapie tworzenia koncepcji wdrożenia, przyjmujący zamówienie  nie zgłosi uwag do materiałów jakie dostał (projekt), ponosi wszelkie konsekwencje skutków swojej pracy.

Są to kluczowe ryzyka w projektach. Generalnie należy zawsze przestrzegać zasady by nie łączyć w projekcie ról stwarzających ryzyko konfliktu interesów.

Wstęp

Temat wynagrodzeń dyskutowany jest od pewnego czasu, na ich zbyt niski poziom narzeka wielu. Pracodawcy i szeroko pojęci liberałowie, bronią się przed zarzutami o wyzysk [[machiawelizmem]]: “wolno wszystko to co nie jest zabronione” i dodają, że przecież ludzie się na niskie wynagrodzenia godzą, nikt ich nie zmusza, więc w czym problem? Czy aby na pewno nikt lub nic ich nie zmusza?

Bardzo ciekawa ocena zjawiska w Forbes:

Wiadomo bowiem nie od dziś, że na etapie negocjowania wynagrodzenia między zatrudniającym a zatrudnionym, istotne znaczenie ma różnica miedzy tym, co pierwszy finansuje jako brutto i tym, co ten drugi otrzymuje jako netto. […] Eksperci podatkowi podkreślają, że istotną funkcją konstrukcji fiskalnych jest stymulowanie przez państwo (regulatora), określonych zachowań podatników. Wyżej opisane przykłady pokazują, że państwo trzymające się kurczowo odrealnionych rozwiązań podatkowych oraz różnicujące korzyści podatkowe, lub parapodatkowe, przy umowach wykorzystywanych przez zatrudniających i zatrudnianych do tych samych celów, wspiera patologie, z którymi później musi walczyć. (Źródło: Skąd się biorą umowy śmieciowe?)

Pomyślałem, że to dobry materiał na systemową analizę.

Metoda

Bardzo dobrą praktyką i metodą analizy jest stworzenie opisu (modelu) ideału badanego zjawiska, wykonanie analizy i ocena na ile ideał różni się od badanego stanu faktycznego, jakie ograniczenia powodują, że ideał jest nieosiągalny (jeżeli nie jest) i jaki ma to wpływ na wynik analizy (obliczeń, opisu mechanizmu).

… zdefiniowanie ideału pozwala ocenić (zmierzyć) odstępstwo konkretnego projektu od niego [od ideału]. To pozwala ocenić ryzyko takiego projektu. Fizyka ma np. nieistniejące w naturze ciało doskonale czarne, po co? Z jednej strony by model i wzór do obliczeń był prosty (i zrozumiały) i by móc ocenić (uwzględnić) błąd wyników opisujących rzeczywistość. Zdaję sobie sprawę, że to filozofia, ale taki mam cel , nie tylko analizować i modelować ale w 100% rozumieć (Czym jest a czym nie jest tak zwany model dziedziny systemu).

Rynek pracy i umowy o świadczenie pracy

Popatrzmy na przedsiębiorstwa i rynek pracy. Najpierw kilka definicji:

praca 1. ?celowa działalność człowieka zmierzająca do wytworzenia określonych dóbr materialnych lub kulturalnych? 3. ?zajęcie, zatrudnienie jako źródło zarobku; też: instytucja, w której się pracuje zarobkowo? (Źródło: praca – Słowniki PWN)

dzieło 1. ?utwór literacki, naukowy lub artystyczny, zwłaszcza dużej wartości? 2. ?praca, działanie? 3. ?efekt czyjejś pracy lub jakichś procesów? (Źródło: dzieło – Słowniki PWN)

zlecenie 1. ?polecenie wykonania czegoś? 2. ?umowa, w której osoba lub instytucja zobowiązuje się do wykonania jakiejś pracy? (Źródło: zlecenie – Słowniki PWN)

Przedsiębiorstwo to zasoby, są nimi także tak zwane “zasoby ludzkie” czyli pracownicy. Każde przedsiębiorstwo, w ramach realizacji procesów operacyjnych,  wymaga stałego dostępu do określonych zasobów, ludzie także są tymi zasobami. Przedsiębiorstwo do sprawnego funkcjonowania potrzebuje:
1. stałego dostępu do określonych umiejętności w celu wytwarzania oferowanych na rynku produktów,
2. okazjonalnego wykonania pracy wymagającej określonych umiejętności,
3. okazjonalnego dostarczenia określonego produktu.

Idźmy dalej. Sytuacja idealna, firma funkcjonuje na rynku:
1. jeżeli firma ma stałe źródło przychodu, czyli dostarcza na rynek swoje produkty w sposób nieprzerwany, zatrudnia grupę pracowników jako stałą obsadę (wymagane stałe zasoby), ta grupa pracowników ma stabilną pracę, pracodawca  gwarantuje im (musi) utrzymanie,
2. jeżeli firma potrzebuje okazjonalnie i na krótko nietypowych umiejętności, na ten krótki czas zatrudnia kogoś i korzysta z jego umiejętności, daje wszelkie wymagane do wykonania pracy wyposażenie, płaci za tę prace, nieco więcej niż “zwykłemu pracownikowi”, bo jest to praca dorywcza (taki najemny pracownik sam dba o siebie, także w przerwach między jednym a drugim kontraktem, to też kosztuje),
3. jeżeli firma potrzebuje okazjonalnie określonego produktu (czyjegoś dzieła) za określone pieniądze płaci komuś za jego wykonanie, ten ktoś tworzy produkt z pomocą swoich środków.

Model przedsiębiorstwa działającego na rynku:

Powyższy model pomoże nam stworzyć system pojęciowy dla “rynku pracy”, tworząc definicje tych (trzech) pojęć będziemy przestrzegali zasady wyłączonego środka (np. jeżeli coś jest umową zlecenie to nie jest żadną inną z tych trzech umów). Obecnie mamy do czynienia z trzema rodzajami zatrudnienia, jak wyżej:

• umowa o pracę (świadczenie pracy, w domyśle stałe),
• umowa zlecenia  (zatrudnienie kogoś na określony czas w celu wykonywania określonej pracy czyli czasowego wykorzystania określonej umiejętności),
• umowa o dzieło czyli wytworzenie i pozyskanie określonego przedmiotu (zatrudnienie kogoś w celu otrzymania produktu czyjejś samodzielnej pracy).

Dzisiejsza relacja pracodawca-pracobiorca jest bardzo niesymetryczna. Pracy z reguły zawsze jest mniej niż ludzi (utrzymujące się na jakimś poziomie bezrobocie) więc pracodawca ma przewagę, możliwe jest, że w nieuczciwy sposób ją wykorzysta. Pracownik to nie tylko siła robocza ale także człowiek z jego potrzebami, koszt jego “funkcjonowania” da się określić.

Załóżmy, że chcące przeciwdziałać potencjalnej nieuczciwości pracodawców Państwo chce ustalić zasady, jakie powinny one być? Powinny utrudnić “psucie” opisanych wyżej “idealnych” relacji i wyrównać szanse pracobiorcy. Powinno jednak prawo nadal chronić także pracodawców.

Opisane wyżej trzy potrzeby firm to odpowiednio: Wariant 1. to umowa o pracę, chroni obie strony tej umowy. Wariant 2. Umowa zlecenia (w prawie cywilnym: starannego działania). Wariant 3. to umowa o dzieło (w prawie cywilnym umowa efektu).

Nadużycia

Pierwsza ważna rzecz w toku oceny i analizy: ważne jest by te trzy pojęcia (ich prawne definicje) się wykluczały, wtedy nie będzie nadużyć w postaci zastępowania jednym umów drugimi. Podstawą może być uznanie, że zatrudnienie kogoś na umowę zlecenia lub o dzieło świadczy o tym, że nie ma sensu zawieranie z kimś takim umowy o pracę, gdyż fakt dania komuś zlecenia lub zamówienie dzieła, świadczy o tym, że nie jest to stałe korzystanie z umiejętności tej osoby. Wobec tego wystarczy uznać, że np. kontrakt z tą samą osobą na ponad 3 miesiące to z automatu umowa o pracę, a umowa o dzieło może być zawierana a tą samą osobą tylko raz, a kolejna po okresie nie  krótszym niż 3 miesiące (ten okres to tylko przykład). W przeciwnym wypadku oznacza to, że umiejętności tej osoby są stale potrzebne i należy ją zatrudnić na stałą umowę o pracę z zakresem obowiązków stosownym do potrzeb firmy i umiejętnościami zatrudnianego.

Oczywiście powyższe, sposób na blokowanie patologii, na pewno wymaga większej precyzji, jednak celem moim było tylko pokazanie podejścia. Potrzeba istnienia umów cywilnoprawnych w prawie jest. Co do ich obecnego nadużywania, to jest to moim zdaniem skutek złego prawa, to jest złych definicji tych umów w ustawach, szczególnie umowy o pracę (posiadanie szefa, zasobów od pracodawcy itp.).

Generalnie łamana jest kluczowa reguła: praca stała to etat, praca “dorywcza” to umowy cywilno-prawne, ich koszty są różne bo różne obciążenia i ryzyka ponoszą pracobiorca i pracodawca, jak słusznie zauważył Prof. Blikle swego czasu, śmieciowi są raczej niektórzy pracodawcy, bo jako monopoliści na rynku pracy narzucają “dorywczy” charakter pracy pracownikom, innymi słowy przerzucają wszystkie ryzyka i koszty na pracobiorców wmawiając im dodatkowo, że Ci nie płacąc “danin” państwu więcej zarabiają, jest to ukrywanie faktu, że pracujący tak pozbawiają się wielu praw np. do emerytury czy służby zdrowia.

Wnioski: samozatrudnienie

To “nowomowa” korporacyjna forsująca na rynku coś co nazywam “pseudofirmy”. Jeżeli ktoś pracuje na rzecz jednej firmy i jego obciążenie godzinowe to pełny zakres ustawowego czasu pracy w miesiącu lub określona jego część, to znaczy że jest pracownikiem tej firmy (w myśl definicji powyżej) na cały etat lub jego część. Czym więc jest “coś”  co nie jest ani podmiotem gospodarczym (potocznie zwanym firmą) z rygorami przedsiębiorczości i jej pełnej opłacalności (po prostu firmą, tu polecam ustawę o dzielności gospodarczej), nie jest osobą pracująca na umowę zlecenia lub umowę o dzieło?  Pod wpływem nacisków pracodawców budujących zyski poprzez (tu) obniżanie  kosztów pracy, powstało na świecie (bo nie tylko w Polsce) pojęcie “samozatrudnienia”, co tak na prawdę jest rezygnacją pracobiorcy z wszelkiej ochrony prawnej jaką ma pracownik firmy (jest traktowany jak firma, czyli ponosi 100% konsekwencji własnego działania).

Kuriozum to powstało, gdyż obchodzenie prawa poprzez utrzymywanie pracownika przez dłuższy czas na umowach cywilnoprawnych jest ograniczane przez prawo. Zmuszenie pracownika do zarejestrowania działalności gospodarczej pozwala na przerzucenie na niego, nie raz, wszystkich kosztów np. stanowiska pracy i dodatkowo przenosi odpowiedzialność prawną na skutki wykonywanej pracy (bo to firma a nie pracownik). Fakt wystawiania faktur przez samozatrudnionego przerzuca na niego także wszelkie daniny takie jak podatki i składki. Tak więc samozatrudniony wyłącznie traci, gdyż najczęściej stosowaną praktyką jest przejście na samozatrudnienie bez zmiany (albo i z obniżeniem) kosztu po stronie byłego pracodawcy.

Kilka ciekawych artykułów:

Coraz więcej przedsiębiorstw zmusza pracowników do samozatrudnienia, czyli zakładania własnych firm, z którymi pracodawca zawiera umowy o dzieło.Dzięki temu redukuje wysokie koszty pracy. Budzi to jednak niepokój ZUS, któremu może z tego powodu zabraknąć pieniędzy na wypłaty bieżących emerytur. (Źródło: Patologiczne samozatrudnienie | Poradnik Pracuję) 

Nikt nie wie, ile jest w Polsce firm jednoosobowych. GUS określa ich liczbę na ok. 1,1 mln. Stanowią prawie jedną czwartą sektora małych i średnich firm. Tylko ilu z nich rzeczywiście można określić przedsiębiorcami, a ilu jest nimi tylko z nazwy? (Źródło: Polscy przedsiębiorcy mimo woli. Fala fałszywego samozatrudnienia – Temat dnia – Forsal.pl ? Biznes, Gospodarka, Świat) 

Przedsiębiorcy tylko z nazwy. Zmuszeni do samozatrudnienia przez pracodawców, uciekający przed bezrobociem *Źródło: Przedsiębiorcy tylko z nazwy. Zmuszeni do samozatrudnienia przez pracodawców, uciekający przed bezrobociem – GazetaPrawna.pl ) 

Na jednym z forów LinkedIn pojawiła się niedawno “propozycja”, jak pisać tak zwane “umowy Agile”.  Uznałem, że kilka komentarzy warto tu dla Państwa umieścić.

Nie będę komentował całej tej propozycji, odniosę się jedynie do tego co wzbudziło moje “zainteresowanie”, a mianowicie to w jaki sposób usługodawcy, stosujący tak zwane zwinne metody, podchodzą do realizacji swoich projektów.

4. Przedmiot umowy. Odwołując się bezpośrednio do metodologii Agile, powinniśmy w tym miejscu umieścić CEL jaki stawia sobie klient, a pomóc w jego realizacji chce dostawca. Namawiam, aby poświęcić wystarczającą ilość czasu i maksymalnie w kilku zdaniach zdefinować i opisać rzeczywisty cel. Jest to o tyle ważne, że pomoże nie zgubić się w trakcie realizacji projektu. W momencie kiedy zakończymy projekt będziemy mogli wrócić do niego i zweryfikować czy został osiągnięty. […]

Pierwszy problem to termin “metodologia Agile”, która, obawiam się, że nie istnieje. Jedyne co znajdziemy  (szukaj w Google) to strzępy prób definicji oraz “słynny” Manifest Agile”, który to tekst nie jest żadną metodologią (sł. j.polskiego: metodologia – nauka o metodach badań naukowych stosowanych w danej dziedzinie wiedzy). Ten Manifest nie jest nawet opisem metody (sł. j.polskiego: metoda – świadomie stosowany sposób postępowania mający prowadzić do osiągnięcia zamierzonego celu). Manifest nie mówi “co i jak zrobić by…”, nie jest metodą, to raczej tylko pryncypia (sł. j.polskiego PWN: pryncypium – najważniejsza dla kogoś lub dla czegoś zasada albo wartość).

Jeżeli uznać, że celem umowy jest “CEL jaki stawia sobie klient” to pytanie brzmi: kto i co realizuje? Bo jeżeli Ktoś ma cel, to realizuje go “ten Ktoś” kto go ma, a nie ktoś inny. Ale CEL jak najbardziej jest ważny. Jednak jeżeli moim celem jest np. zamieszkanie w domu, to jest to Mój cel. Celem ekipy budowlanej jest postawienie dla mnie domu (zlecenie) a nie zamieszkanie w nim. Mój CEL (cel Klienta) raczej nie jest ani celem umowy z developerem, ani celem developera (celem developera jest postawić dom i otrzymać za to wynagrodzenie).

Czytamy dalej.

8. Warunki wynagrodzenia i terminy płatności. To bodaj najbardziej istotny z punktów umowy, który różni się od dotychczas spotykanych w ?starych? umowach. Jego treść w pełni odwołuje się do wartości i prawd metodologii Agile.

Tu dla porządku przypomnę tak zwany Manifest Agile (źr. http://agilemanifesto.org/):

(1) Ludzi i interakcje ponad procesy i narzędzia, (2) Działające oprogramowanie ponad obszerną dokumentację, (3) Współpracę z klientem ponad formalne ustalenia, (4) Reagowanie na zmiany ponad podążanie za planem.

Tak więc są to niestety faktycznie jedynie pewne pryncypia czy wartości ale nie metoda.

Najważniejsza zmiana polega na tym, że dostawca cyklicznie, w krótkich okresach czasu 1-2 tygodni, dostarcza działające rozwiązanie, a odbiorca na bieżąco odbiera i płaci za nie. Dla ułatwienia, rozliczenia finansowe następują na koniec każdego miesiąca, kiedy to wystawia się fakturę zbiorczą za cztery iteracje, (w przypadku sprintów tygodniowych). W przypadku realizacji krótszych projektów oczywiście robi się to szybciej.

Zgadzając się na takie rozliczenia, strony umowy akceptują partnerskie podejście do projektu. Dostawca szybko dostarcza skończone, przetestowane i działające rozwiązanie, a odbiorca na bieżąco płaci za nie. Ważne jest aby okres rozliczeniowy nie był dłuższy niż 1 miesiąc. Pozwala to obu stronom umowy na bieżącą, (miesięczną), weryfikację i potwierdzenie chęci dalszej współpracy. 

(źr. cytatów: Jak skonstruować umowę Agile?).

Powyższy tekst (opis realizacji umowy) to nic innego jak jednak stara Umowa Zlecenia znana z Kodeksu Cywilnego (Art. 750 [Umowy o świadczenie usług] Do umów o świadczenie usług, które nie są uregulowane innymi przepisami, stosuje się odpowiednio przepisy o zleceniu.). Jest to tak zwana umowa starannego działania. Generalnie, umowa taka nie daje Nabywcy (Klient) żadnego zabezpieczenia jakości i efektu, gdyż to on wybiera i angażuje Zleceniobiorcę, który obiecuje, że dochowa staranności. Cechą umowy Zlecenia jest możliwość jej wypowiedzenia w dowolnym momencie (i tu autor faktycznie ma rację).

Czy Klient ma jakąś możliwość obrony przed  nierzetelnym wykonawca usługi? Na szczęście ma (KC):

Art. 740 [Obowiązki zleceniobiorcy] Przyjmujący zlecenie powinien udzielać dającemu zlecenie potrzebnych wiadomości o przebiegu sprawy, a po wykonaniu zlecenia lub po wcześniejszym rozwiązaniu umowy złożyć mu sprawozdanie. Powinien mu wydać wszystko, co przy wykonaniu zlecenia dla niego uzyskał, chociażby w imieniu własnym.

Tu jednak warto zwrócić uwagę na to, że w przypadku sporu wartość będą miały jednie pisemne “wiadomości” i “sprawozdania”.  Czy się to komuś podoba czy nie, jak na razie, nie ma żadnych “zwinnych umów”, są umowy zlecenia (umowa starannego działania) i o dzieło (umowa efektu). Zaś w kwestii zakwalifikowania danej umowy do jednej z powyższych, decyduje jej treść a nie tytuł. Umowa Zlecenia, co ciekawe, nie zawiera pojęcia “licencji” czy “praw”, te zawiera umowa o dzieło (tak zwana umowa efektu). Tak więc polecam Państwu krótkie konsultacje z prawnikiem, przed zawarciem “zwinnej umowy”, by ocenić jakie ryzyko podejmujecie, bo w umowie zleceniu, wykonawca – pracując i pobierając wynagrodzenie – nie podejmuje żadnego ryzyka, nie licząc, możliwości zerwania trwającej umowy z wykonawcą (co niestety bardzo często ma miejsce w przypadku projektów programistycznych).  W takich umowach 100% ryzyka bierze na siebie Klient. Pewien cynizm tej umowy polega a tym, że to, co Klient “odbiera i płaci” np. co dwa tygodnie, to nie “rozwiązanie” które jest Jego Celem a jakiś bieżący fragment prac… gotowy produkt jest celem projektu, on będzie “dostarczony” na zakończenie.