Czego należy uważać podczas zawierania umowy o dzieło w rozwoju systemów?
Umowy zawierane w projektach rozwijających systemy IT to głównie umowy o dzieło i umowy o świadczenie usług. Zarówno dla użytkowników, jak i dostawców, korzyści i wady zastosowania każdego typu umowy są różne, ale zrozumienie ich charakterystyki i uwzględnienie czynników do rozważenia przy zawieraniu umowy jest ważne. W tym artykule omówimy umowy o dzieło w kontekście prac rozwojowych systemów IT.
Rozwój systemu i umowy o dzieło
Czym jest umowa o dzieło?
Podstawowym krokiem do zrozumienia, czym jest umowa o dzieło, jest sprawdzenie bezpośrednio w tekście prawnym, jakie są warunki jej zawarcia.
Artykuł 632
Umowa o dzieło powstaje, gdy jedna ze stron zobowiązuje się do ukończenia pewnej pracy, a druga strona zobowiązuje się do zapłaty wynagrodzenia za wynik tej pracy.
Kluczowym słowem jest tutaj “ukończenie pracy”. Typowym przykładem umowy o dzieło jest budowa budynku, która wymaga wykonania prac budowlanych. Na przykład, “ukończenie pracy” może oznaczać zbudowanie domu lub budynku do określonego terminu, co oznacza spełnienie zobowiązania. Jeśli prace budowlane nie postępują zgodnie z planem i termin jest przekroczony, odpowiedzialność za niewykonanie zobowiązania może być nałożona pod pewnymi warunkami. Jeśli jednak “ukończenie pracy” jest raz uznane, problem niewykonania zobowiązania znika, a następnie pojawia się kwestia odpowiedzialności za wady. W tym sensie, umowa o dzieło charakteryzuje się szczególnym naciskiem na “ukończenie pracy”. Szczegółowe wyjaśnienia na temat tego, co jest uznawane za “ukończenie pracy”, można znaleźć w poniższym artykule.
https://monolith.law/corporate/completion-of-work-in-system-development[ja]
Umowy o dzieło są często stosowane nie tylko w budownictwie, ale także w projektach rozwoju systemów, które wymagają dużych koncepcji i szczegółowego planowania.
Różnica między umową o dzieło a umową o zlecenie
Gdy zrozumiesz, że umowa o dzieło jest typem umowy skoncentrowanym na “ukończeniu pracy”, zrozumiesz również charakterystykę umowy o zlecenie. Ta ostatnia skupia się nie na “ukończeniu”, ale na procesie. Na przykład, jeśli proces administracyjny był odpowiednio prowadzony, niezależnie od wyników, możliwe jest żądanie wynagrodzenia (art. 648 ust. 2), a jeśli wykonanie zostało przerwane w połowie z powodu przyczyn, które nie mogą być przypisane zleceniobiorcy, możliwe jest żądanie wynagrodzenia proporcjonalnie do wykonanej pracy (art. 648 ust. 3).
Szczegółowe wyjaśnienia na temat porównania umowy o zlecenie i umowy o dzieło można znaleźć w poniższym artykule.
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
Dlaczego umowy o dzieło są preferowane w rozwoju systemów
W umowach na rozwój systemów, umowy o dzieło są bardzo często stosowane. Powodem, dla którego umowy o dzieło są często stosowane, jest to, że mają pewne korzyści zarówno dla użytkowników zamawiających pracę, jak i dla dostawców wykonujących pracę.
Przede wszystkim, dla użytkowników, korzyścią z zamawiania pracy na podstawie umowy o dzieło jest to, że warunki spełnienia zobowiązania są łatwe do określenia w formie “ukończenia pracy”. Innymi słowy, jest jasne, że zasada nie wymaga płatności, dopóki praca nie jest “ukończona” (nawet jeśli później pojawią się problemy z odpowiedzialnością za wady, takie jak odkrycie błędów). To jest szczególnie atrakcyjne dla użytkowników, którzy nie chcą ryzykować, że będą musieli zapłacić więcej, jeśli prace potrwają dłużej niż przewidywano, lub jeśli koszty pracy będą wyższe niż przewidywano. Istnieje duża wygoda w zarządzaniu budżetem, płacąc stałą kwotę za wynik równoważny “ukończeniu”.
Z drugiej strony, dla dostawców wykonujących pracę, istnieją pewne korzyści z przyjmowania zamówień na podstawie umowy o dzieło. Umowy o dzieło mogą przynieść większy zysk niż umowy o zlecenie, jeśli są dobrze zarządzane.
Jeśli “ukończenie pracy” jest warunkiem spełnienia zobowiązania, to z punktu widzenia strony wykonującej pracę, nie ma znaczenia, ile kosztuje proces dojścia do “ukończenia” (w przypadku rozwoju systemów, większość kosztów to koszty pracy). W ten sposób, zarówno dostawcy, którzy chcą zwiększyć swoje marże, jak i użytkownicy, którzy chcą łatwiej zarządzać swoim budżetem, mają swoje powody, dlatego umowy o dzieło są bardzo preferowane w rozwoju systemów.
Na co zwrócić uwagę podczas zawierania umowy o dzieło
Chociaż umowa o dzieło ma swoje zalety zarówno dla użytkownika, jak i dostawcy, dla dostawcy zawarcie takiej umowy bez odpowiedniego zastanowienia wiąże się z ryzykiem. Przede wszystkim, konieczność “ukończenia pracy” do wykonania zobowiązania oznacza, że zasada nie jest zwolniona z odpowiedzialności za niewykonanie zobowiązania bez ukończenia produktu. To jest również powód, dla którego często występują problemy, takie jak konieczność poświęcenia czasu na dostarczenie produktu, nawet jeśli prowadzi to do strat, na przykład z powodu błędów w szacunkach ze strony dostawcy.
Więc na co należy zwrócić uwagę podczas zawierania umowy o dzieło? Spójrzmy na to poniżej.
Upewnij się, że wymagania systemu i warunki akceptacji są jasne z góry
W umowie o dzieło ważne jest, oczywiście, jasne określenie warunków “ukończenia pracy”. Zazwyczaj, “ukończenie pracy” oznacza treść umowy ustalonej w fazie definiowania wymagań. Jednak w praktyce, w miarę postępu prac rozwojowych, może być wymagane wprowadzenie zmian po fakcie, co oznacza, że wymagania “ukończenia pracy” mogą również ulec zmianie. Włączając te elementy, ważne jest, aby dokumentować historię zmian specyfikacji. W poniższym artykule omówiono, jak zarządzać zmianami w projekcie rozwoju systemu z punktu widzenia prawa.
https://monolith.law/corporate/howto-manage-change-in-system-development[ja]
W związku z tym tematem, również skuteczne w zapobieganiu problemom w przyszłości jest wcześniejsze ustalenie “akceptacji” przeprowadzanej przez stronę użytkownika. Jest to oczywiście przewidywane, że mogą wystąpić sytuacje, takie jak brak odpowiedzi od osoby odpowiedzialnej za stronę użytkownika, nawet jeśli produkt jest dostarczany. Aby uniknąć sytuacji, w której nie jest jasne, czy akceptacja jest zatwierdzona czy nie, warto ustawić określony termin dla akceptacji. To jest tzw. “klauzula domniemanej akceptacji”, która jest omówiona w poniższym artykule.
https://monolith.law/corporate/estimated-inspection-of-system-development[ja]
Ustal z góry, czy prawa autorskie będą przenoszone
Innym często występującym problemem jest przeniesienie praw autorskich. Zasada jest taka, że prawa autorskie przysługują “twórcy”, czyli w przypadku rozwoju systemu, dostawcy, ale możliwe jest również przeniesienie lub przekazanie tych praw ze względu na ich charakter. Dlatego też, ustalenie z góry, czy prawa autorskie będą przeniesione na użytkownika, może zapobiec problemom w przyszłości. Prawa autorskie i ich przeniesienie są omówione szczegółowo w poniższym artykule.
https://monolith.law/corporate/copyright-for-the-program-source-code[ja]
Inne uwagi
Jeśli chcesz zawrzeć umowę jako umowę o dzieło, bez zawierania elementów quasi-mandatu, powinieneś zwrócić uwagę na:
- utrzymanie wynagrodzenia niezależnie od czasu pracy
- jasne określenie w tytule umowy, że jest to “umowa o dzieło”
- jasne określenie klauzuli o odpowiedzialności za wady
- płatność wynagrodzenia jest równoważna z wynikiem lub produktem
Warto to mieć na uwadze.
Należy jednak unikać prostego myślenia, że jeśli w tytule umowy napiszesz “umowa o dzieło”, wszystko stanie się umową o dzieło. W praktyce, szablony umów innych firm są często używane bez zwracania uwagi na to, czy ich treść jest umową o dzieło czy quasi-mandatem. Jeśli sprawa trafi do sądu, ważniejsze niż powierzchowne elementy, takie jak słowa w tytule, są treść umowy i dotychczasowe praktyki handlowe. Należy zwrócić uwagę na ten punkt.
Podsumowanie
Jeśli weźmiemy pod uwagę powyższe punkty, łatwiej będzie nam prawidłowo przetwarzać umowy zawarte na podstawie umowy o dzieło. Słowo “zlecenie” jest używane zarówno w umowach o dzieło, jak i w umowach quasi-mandatowych. Ponadto, termin “zlecenie usług” jest zwykle używany, gdy strony mają zamiar zawrzeć umowę quasi-mandatową. Zwracanie uwagi na te drobne różnice w terminologii może być dodatkowo korzystne.
Category: IT
Tag: ITSystem Development