Stworzenie aplikacji w modelu MVP (Minimum Viable Product) – jak prawidłowo skonstruować umowę?

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.

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ą.

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.

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

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.