Umowa na stronę powinna opisywać zarówno efekt pracy, jak i sposób korzystania z niego po zakończeniu projektu. Brak ustaleń dotyczących domeny, licencji lub dostępów może utrudnić późniejsze utrzymanie i zmianę wykonawcy. Poniższa lista pomaga przygotować kwestie do uzgodnienia w konkretnej umowie.
Trzy scenariusze, w których tracisz dostęp do strony
Domena pozostaje pod kontrolą wykonawcy. Ustal abonenta domeny, dostęp do konta rejestratora i procedurę przekazania obsługi. Sam dostęp do edycji strony nie daje kontroli nad domeną.
Hosting jest częścią niejasno opisanej usługi. Sprawdź, kto wykonuje kopie zapasowe, jak można je uzyskać i co dzieje się po zakończeniu współpracy. Własna kopia plików może nie wystarczyć bez bazy danych i konfiguracji.
Prawa lub licencje są niedoprecyzowane. Kod własny, biblioteki open source, fonty i zdjęcia mogą mieć różne zasady wykorzystania. Przeniesienie praw do części projektu nie oznacza przejęcia praw do wszystkich użytych elementów.
12-punktowa checklist: co musi być w umowie
Własność i prawa
1. Prawa do rezultatów. Wskaż utwory, zakres praw lub licencji, pola eksploatacji oraz moment ich przekazania. Dokument powinien uwzględniać wymogi odpowiedniej formy prawnej.
2. Kontrola domeny. Zapisz dane abonenta, dostęp administracyjny, odnowienia i procedurę zmiany podmiotu obsługującego domenę.
3. Hosting. Ustal właściciela konta, zakres dostępu, rozliczenia oraz warunki eksportu i migracji.
4. Repozytorium i dokumentacja. Opisz sposób i termin przekazania kodu, konfiguracji oraz instrukcji uruchomienia. Odbiór techniczny i przejście praw mogą być odrębnymi zdarzeniami.
Termin i zakres
5. Harmonogram. Uwzględnij etapy, zależności od materiałów klienta, zatwierdzenia i sposób uzgadniania zmian terminów.
6. Odpowiedzialność za opóźnienia. Ustal konsekwencje niewykonania zobowiązań i warunki ewentualnych kar umownych. Nie zakładaj automatycznej stawki ani jednego standardu dla wszystkich projektów.
7. Poprawki i zmiana zakresu. Opisz sposób zgłaszania uwag, liczbę uzgodnionych rund i zatwierdzanie pracy wykraczającej poza kontrakt.
8. Odbiór. Ustal scenariusze testowe, kryteria akceptacji i sposób dokumentowania usterek. Parametry wydajności powinny mieć określone warunki pomiaru.
Wsparcie po wdrożeniu
9. Zakres utrzymania. Rozróżnij naprawę błędów, aktualizacje i rozwój funkcji. Określ okres oraz zasady rozliczenia każdego rodzaju pracy.
10. Obsługa zgłoszeń. Wskaż kanały kontaktu, priorytety i uzgodnione czasy reakcji lub realizacji. SLA obowiązuje w takim zakresie, w jakim zostało uzgodnione.
Dane i bezpieczeństwo
11. Lista dostępów. Uwzględnij CMS, repozytorium, DNS, hosting i analitykę. Konta powinny mieć wskazanych właścicieli, a uprawnienia odpowiadać zadaniom.
12. Dane osobowe. Ustal role stron i zakres przetwarzania. Jeżeli wykonawca przetwarza dane w imieniu klienta, potrzebne są odpowiednie ustalenia dotyczące powierzenia, bezpieczeństwa oraz zakończenia przetwarzania.
Czerwone flagi w rozmowie z wykonawcą
Sygnałem do wyjaśnienia jest odmowa opisania licencji, brak możliwości eksportu danych lub niejasne zasady utrzymania. Nie traktuj ustnej obietnicy jako zamiennika zapisu w umowie. Tak samo nie zakładaj, że każda zależność harmonogramu od klienta jest nieprawidłowa — ważne, aby była określona i możliwa do rozliczenia.
Jak pracujemy w Q-Dev
Q-Dev jest ofertą software house QA10. Zakres, cenę i harmonogram ustalamy indywidualnie. Projekt ma cztery etapy: projekt, MVP, wdrożenie oraz szkolenie i rozpoczęcie utrzymania.
Po każdym etapie odbywa się spotkanie i powstaje dokument z uzgodnioną liczbą poprawek. Po jego zatwierdzeniu możliwe są dwie dodatkowe rundy zmian w wykonanej pracy na danym etapie. Zmiany mogą wpłynąć na termin; cena zmienia się przy wyjściu poza zakres kontraktu. Pierwsze sześć miesięcy utrzymania jest w cenie. Prawa do kodu przechodzą na klienta po rozliczeniu całego projektu.
Umowę na taki projekt strony możesz omówić w kontekście linii Q-Dev Site.