Umowa z programistą bywa podpisywana z dużą wiarą w to, że „zakres jest przecież jasny”. Potem okazuje się, że jasny był tylko ogólny cel: ma działać. To trochę mało. Projekty IT potrzebują precyzji w zakresie funkcjonalności, technologii, repozytorium, etapów, testów, zgłaszania błędów i praw do kodu. Bez tego nawet dobra współpraca może utknąć na pytaniu, czy coś jest błędem, zmianą zakresu, czy nowym pomysłem.
Dobra umowa IT nie musi tłumaczyć programowania od podstaw. Powinna jednak zrozumiale opisywać, co ma zostać wykonane, jak zostanie przekazane i kiedy zamawiający może uznać pracę za odebraną. W projektach technicznych załącznik ze specyfikacją bywa ważniejszy niż najbardziej elegancki paragraf.
Zakres i specyfikacja
W umowie warto wskazać funkcjonalności, technologie, środowiska, wymagania dotyczące bezpieczeństwa, integracje, dokumentację, repozytorium oraz sposób komunikacji. Jeżeli projekt ma etapy, dobrze jest powiązać je z terminami, odbiorami i płatnościami. Dzięki temu obie strony wiedzą, kiedy kończy się etap, a zaczyna rozmowa o kolejnych pracach.
Szczególnie ważne jest opisanie materiałów dostarczanych przez zamawiającego: dostępów, grafik, treści, danych testowych, decyzji biznesowych. Programista nie powinien odpowiadać za opóźnienie, które wynika z braku dostępu do środowiska albo niezatwierdzonej makiety. Umowa może to ucywilizować, zanim projekt zacznie żyć własnym życiem.
Odbiór, błędy i zmiany
Warto ustalić procedurę odbioru: termin na testy, sposób zgłaszania uwag, definicję błędu, liczbę poprawek i zasady rozliczania zmian. W IT różnica między błędem a zmianą zakresu jest kluczowa. Jeżeli funkcjonalność działa zgodnie ze specyfikacją, ale zamawiający zmienił koncepcję, to często nie jest poprawka, tylko nowe zadanie.
Dobrym rozwiązaniem jest prowadzenie zgłoszeń w jednym miejscu i opisywanie ich możliwie konkretnie. Historia projektu w komunikatorze, mailu, arkuszu i trzech notatkach potrafi być fascynująca, ale przy rozliczeniach rzadko pomaga.
Prawa do kodu
Umowa powinna rozstrzygać prawa autorskie: czy dochodzi do przeniesienia praw majątkowych, udzielenia licencji, kiedy to następuje i na jakich polach eksploatacji. Trzeba też uwzględnić komponenty open source, biblioteki, wcześniejsze rozwiązania wykonawcy i elementy podmiotów trzecich. Nie każdy fragment kodu może być po prostu „sprzedany” w całości.
Przy wyborze wzoru umowy dla programisty warto więc sprawdzić, czy dokument mówi o repozytorium, odbiorze, prawach autorskich i zmianach zakresu. W projektach IT domysły kompilują się słabo.
Tekst ma charakter informacyjny i nie zastępuje porady prawnej udzielonej po analizie konkretnej umowy, dokumentów oraz sytuacji stron.