|
19 grudnia 2023 | Ostatnio zmodyfikowano 13 czerwca, 2024 o 12:24 | Czas na przeczytanie: 10 minut
Pozostałe Artykuły
MVP – co to jest i na czym w ogóle polega idea Minimum Viable Product?
Minimum Viable Product można porównać do próbki oferowanej odbiorcom w celu dokonania oceny ich potrzeb i oczekiwań. To jeden z iteracyjno-przyrostowych modeli tworzenia biznesu, ale także projektowania aplikacji komputerowych, pozwalający na dopasowywanie kolejnych etapów rozwoju produktu do otoczenia konkurencyjnego. Za ideą MVP stoi przede wszystkim przekonanie, że każdy produkt można ulepszyć, jeszcze lepiej odpowiadając na potrzeby targetu. Dlatego niezbędnym elementem tworzenia aplikacji są testy i z reguły jest ich dużo.
Oczywiście MVP aplikacji powinien trafić do odbiorców, ponieważ tylko wtedy twórcy otrzymują rzetelny feedback. Oczywiste jest, że MVP jest jedynie punktem wyjścia, natomiast jego kolejne wersje będą coraz lepsze. Takie założenie zakłada dużą dynamikę zmian, którą należy odzwierciedlić w umowie.
Zobacz również: Umowa z web developerem. Aspekty prawne
Określenie celu umowy MVP aplikacji
Mimo że aplikacje MVP nie stanowią docelowej wersji oprogramowania, nadal ich stworzenie musi opierać się na określonej dokumentacji projektowej. Dlatego kontrakt powinien dokładnie określać, osiągnięcia jakiego rezultatu oczekują strony. W przypadku sięgnięcia po zwinne metodyki programowania większe znaczenie niż szczegółowa dokumentacja ma omówienie kluczowych założeń w zakresie:
- funkcjonalności
- niezawodności.
Na drugi plan schodzą zagadnienia związane z użytecznością i designem, które będą precyzowane na kolejnych etapach prac. Często w ramach celu umowy określa się jedynie języki programowania i framework, bez konkretnych szczegółów dotyczących założeń, które będą się wielokrotnie zmieniały się w czasie trwania projektu.
Z uwagi na to, że odbiorca z założenia zetknie się z nie do końca dopracowaną wersją aplikacji, należy dołożyć staranności, aby te opcje, które są dostępne, działały niezawodnie.
Harmonogram prac w kontekście umowy MVP
Dużą część tworzenia MVP aplikacji stanowią testy przeprowadzane przez developerów, ponieważ to one tak naprawdę pozwalają odpowiedzieć na pytanie, czy dany program działa poprawnie. Dlatego prace IT powinny być podzielone na kolejne etapy, które będą zamknięte przez kamienie milowe (ang. milestones), ale w obrębie każdego etapu twórca zachowuje daleko idącą autonomię w działaniu.
Model MVP musi uwzględniać przekazywanie feedbacku od odbiorców do twórców. Dlatego w umowie należy dokładnie określić:
- w jaki sposób użytkownik może przekazywać informację zwrotną;
- kiedy twórca jest zobligowany do wprowadzenia zmian w aplikacji (oraz za jakie wynagrodzenie);
- w jakim terminie mają zostać wprowadzone zmiany i jak wygląda procedura ich akceptacji.
Z uwagi na dużą dynamikę prac ważne jest, aby już od pierwszego dnia pracy zadbać o dokładne rozpisanie poszczególnych sprintów (ich czasu trwania i celu) oraz określenie backlogu, czyli najważniejszych czynności do wykonania. Każdy developer dysponuje też ograniczonymi zasobami ludzkimi i technologicznymi, dlatego podział tych zasobów także należy uwzględnić w kontrakcie. Dla zapewnienia większej płynności prac skład zespołów powinien być podawany rodzajowo, a nie personalnie, aby łatwiej można było dokonać zamiany konkretnych osób w razie braków kadrowych.
Warto pamiętać, aby zaplanować przynajmniej kilka dni odstępu między ukończenie jednego milestone’a a rozpoczęciem drugiego, na wypadek, gdyby zespół zetknął się z nieprzewidzianą w harmonogramie sytuacją.
Zobacz również: Regulamin aplikacji mobilnej – czym jest i co powinien zawierać ?
Feedback i rozwój aplikacji w modelu MVP
Projektowanie w modelu MVP Minimum Viable Product aplikacji bazuje na kolejnych powtórzeniach i przyrostach, podobnie jak Scrum lub Agile. Różnica między wymienionymi rozwiązaniami polega jednak na tym, że o ile w typowym Agile powstaje od razu cała, kompletna aplikacja, w przypadku MVP developer przygotowuje jej uproszczoną (ale sprawną!) wersję, która z założenia będzie rozwijana.
Dlatego w umowie należy dokładnie opisać kwestie związane z feedbackiem. Jeżeli budżet nie został od razu określony dla całego projektu, należy dokonać oceny, czy nadal prace mieszczą się w jego ramach.
Typowym elementem umów IT o nie do końca sprecyzowanym przedmiocie jest tzw. DoD (ang. Definition of Done). To dokładnie opisana sytuacja (np. poprzez przygotowaną dokumentację techniczną), w której można uznać, że feedback został uwzględniony, a zamawiający nie zgłasza zastrzeżeń do prac programistycznych. Definicja DoD jest prostym sposobem na to, aby zapobiec nieuzasadnionej eskalacji żądań ze strony zlecającego.
Zobacz również: Umowa na stworzenie oprogramowania w modelu Scrum
Co z prawami autorskimi do aplikacji MVP?
Tworzenie aplikacji IT w zasadzie zawsze będzie wiązało się z powstaniem praw autorskich, dlatego już na samym początku należy ustalić, komu będą one przysługiwały i w jakim zakresie.
W przypadku autorskich praw majątkowych konieczne będzie ich przeniesienie na zamawiającego w drodze umowy o przeniesienie praw autorskich (dla niej wymagana jest forma pisemna, pod rygorem nieważności). Licencja na ogół nie będzie tutaj wystarczająca, ponieważ po upływie okresu jej obowiązywania całość praw powróci do wykonawcy.
Przenosząc prawa autorskie majątkowe, należy pamiętać, że:
- w kontrakcie powinny znaleźć się szczegółowo opisane pola eksploatacji (niekoniecznie wszystkie możliwe, muszą one jednak korespondować z rzeczywistym sposobem wykorzystania utworu);
- umowa powinna jasno określać moment, w którym dochodzi do przejścia praw autorskich;
- pól eksploatacji nie można domniemywać;
- przeniesienie praw musi dotyczyć konkretnego utworu, a nie wszystkich utworów danego twórcy (innymi słowy nie można przenieść od razu praw do aplikacji MVP wszystkich utworów będących jej częścią, które dopiero powstaną);
- co do zasady twórcy należne jest wynagrodzenie za każde pole eksploatacji osobno.
Zobacz również: Licencja na oprogramowanie – co zawiera, rodzaje, jak ją wypowiedzieć?
W kontekście programu komputerowego należy zwrócić uwagę na art. 75 ust. 4 pkt 2 ustawy o prawie autorskim, zgodnie z którym autorskie prawa majątkowe obejmują również prawo do zmiany układu lub jakichkolwiek innych zmian w programie.
Oznacza to, że jeżeli prawa do aplikacji w wariancie MVP raz zostały przeniesione, nie ma potrzeby przenoszenia ich wraz z każdą kolejną iteracją, chyba że wskutek prac powstanie zupełnie nowy utwór, np. nowy moduł do już istniejącego programu. Jednocześnie warto rozgraniczyć:
- kod źródłowy – chroniony jako program komputerowy (analogicznie do utworów literackich);
- pozostałe utwory (np. muzyczne lub graficzne);
- elementy niebędące utworami, jak proste okienka, ramki i szablony pozwalające na korzystanie z aplikacji, ale bez cech charakterystycznych dla utworu.
W przypadku osobistych praw autorskich ustawa nie przewiduje możliwości ich przeniesienia na inny podmiot. Twórca może jednak złożyć oświadczenie, w którym zobowiąże się do ich niewykonywania. Warto wspomnieć, że jednymi z przejawów praw osobistych autorskich są możliwość domagania się oznaczenia autorstwa utworu (każdego jego egzemplarza), a także nadzór nad sposobem korzystania z utworu, czyli prawo do zweryfikowania czy utwór jest udostępniany w zaakceptowanej przez twórcę postaci.
Odpowiednie zarządzania prawami autorskimi ma kluczowe znaczenie z punktu widzenia zamawiającego oraz twórcy. Nieprawidłowe postanowienia w umowie mogą doprowadzić do sytuacji, w której wraz z kolejną iteracją aplikacji uwzględniającą np. zupełnie nową szatę graficzną niemożliwe stanie się opublikowanie aplikacji, ponieważ strony nie przeniosą praw autorskich w odpowiednim zakresie.
Więcej informacji w artykule: Prawa autorskie do programu komputerowego
Jak obliczyć i określić wynagrodzenie w umowie MVP?
Z uwagi na rozwojowy charakter aplikacji MVP wynagrodzenie zazwyczaj obejmuje bazę oraz wynagrodzenie dodatkowe za kolejne etapy rozwoju aplikacji. Baza najczęściej jest określona poprzez przyjęcie stawki godzinowej lub dziennej poszczególnych członków zespołu. Może być ona jednakowa lub inna dla każdego specjalisty.
W interesie zamawiającego jest z kolei określenie wynagrodzenia ryczałtowego za każdy sprint lub osiągnięty milestone. W takim modelu to software house ponosi jednak ryzyko nieprawidłowego oszacowania workloadu, a w konsekwencji – strat wynikających z niedoszacowania obciążenia pracą. Z drugiej strony – pozwala zamawiającemu lepiej kontrolować budżet.
Kompromisowym rozwiązaniem może być np. określenie bazy oraz dodatkowego wynagrodzenia za każdą nieplanowaną wcześniej zmianę w związku z feedbackiem zgłoszonym przez użytkowników.
Zobacz również: Umowa wdrożeniowa na algorytm AI
Co jeszcze powinna zawierać umowa o aplikację MVP?
Choć projekt MVP (Minimum Viable Product) nie jest jeszcze ostateczną wersją software’u, który otrzymają użytkownicy, nadal wymaga on zapewnienia jego zgodności z prawem. W praktyce oznacza to konieczność:
- stworzenia regulaminu korzystania z usługi zgodnie z ustawą o świadczeniu usług drogą elektroniczną;
- zaprojektowania polityki prywatności oraz informacji o plikach cookies;
- pozyskania niezbędnych oświadczeń i zgód, jeżeli podczas korzystania z aplikacji przetwarzane są dane osobowe użytkowników (obecnie jest to standard z uwagi na to, że większość programów i usług wymaga założenia konta użytkownika).
Dodatkowo należy pamiętać, że w przypadku aplikacji kierowanych np. na rynek finansowy, jak narzędzia do analizy giełdowej czy nowy rodzaj rachunku maklerskiego może pojawić się konieczność zapewnienia zgodności z procedurą AML.
Należy też upewnić się – w sytuacji, kiedy aplikacje jest adresowana do konsumentów, czy jej regulamin nie zawiera klauzul abuzywnych.
Zobacz również: Aspekty prawne umowy na stworzenie bazy CRM
Kiedy warto zdecydować się na stworzenie aplikacji w modelu Minimum Viable Product (MVP)?
Głównymi zaletami modelu Minimum Viable Product jest szybki czas tworzenia aplikacji oraz relatywnie niska cena projektu. Z uwagi na fakt, że aplikacje nie jest w pierwotnej wersji dopracowywana, a jedynie powstają jej główne ramy, developer może oddać ją w krótszym czasie, a nad realizacją zadań spędza czas mniejsza liczba pracowników.
Z reguły za wyborem MVP przemawiają wątpliwości co do trafności pomysłu. Przedsiębiorca, który nie jest pewien, czy odbiorcy będą zainteresowanie jego pomysłem, może zweryfikować przynajmniej główne funkcjonalności aplikacji. W miarę otrzymywania feedbacku od kolejnych grup możliwa będzie rozbudowa oprogramowania. Drugą przyczyną, która decyduje o rozwoju software’u w modelu MVP, jest niski budżet. Dlatego tego rodzaju założenia są często domeną startupów na początkowym etapie ich istnienia.
Warto pamiętać, że, choć aplikacja w modelu MVP pozwala na zaoszczędzenie wydatków, nie może oferować zbyt mało możliwości dla użytkowników. Jeżeli odbiorcy poczują, że otrzymali niedopracowany produkt, które nie spełnia ich oczekiwań, rośnie ryzyko, że nie będą zainteresowani inwestowaniem w jego rozwój.
Stworzenie umowy o napisanie aplikacji z zachowaniem założeń koncepcji MVP Minimum Viable Product wymaga zastosowania mechanizmów, które pozwolą na dynamiczne wprowadzenie zmian w razie potrzeby. Aby w sposób zrozumiały określić prawa i obowiązki obu stron umowy warto skorzystać ze wsparcia kancelarii prawnej z wieloletnim doświadczeniem w tworzeniu umów IT. Nasi prawnicy pomogą podczas negocjacji, a także zaprojektują umowę, która należycie zabezpieczy interesy reprezentowanej strony.
Zobacz również: Umowa utrzymaniowa a umowa rozwojowa na wdrożone oprogramowanie
Pytania i odpowiedzi
Najprostszym sposobem będzie zawarcie z wykonawcą – obok umowy o stworzenie aplikacji – również umowy NDA, zobowiązującej developera oraz jego pracowników do zachowania poufności. W takim kontrakcie należy sprecyzować m.in., które informacje objęte są szczególną ochroną.
Strony mogą umówić się na współpracę m.in. przez określoną liczbę sprintów albo oznaczony czas. Można też określić w umowie docelową (w pełni rozwiniętą) postać aplikacji.
Wstępnym projektem aplikacji jest często tzw. proof of concept. To eksperymentalna implementacja założeń projektu tworzonych na potrzeby wewnętrzne, która ma wykazać, czy dany pomysł ma szansę cieszyć się zainteresowaniem odbiorców. Stworzenie proof of concept zwykle jest pierwsze niż MVP. Warto pamiętać, że same idee nie podlegają ochronie prawnoautorskiej, ale już sposób ich wyrażenia tak. Oznacza to, że dokumentacja techniczna, niezależnie od ochrony NDA, jest zabezpieczona także na gruncie własności intelektualnej.
Zaufali nam:
