Lista kontrolna umowy na wykonanie strony
Większość sporów przy projektach stron nie dotyczy jakości, tylko oczekiwań, których nigdzie nie zapisano. Umowa nazywająca właściwe rzeczy zapobiega niemal wszystkim z nich, a jej przeczytanie zajmuje godzinę.
Ten przewodnik omawia, co powinno się w niej znaleźć, dlaczego każdy punkt istnieje, i na których klauzulach nalegać w razie wątpliwości.
Zakres: część powodująca najwięcej sporów#
«Zbudować stronę» to nie zakres. To powinno być zapisane wprost.
- Liczba unikalnych szablonów, a nie liczba podstron. Pięćdziesiąt podstron na czterech szablonach to mały projekt.
- Co jest w środku: projekt, budowa, wprowadzenie treści, migracja, integracje, testy.
- Czego nie ma w środku — to najważniejsze zdanie w całej umowie.
- Kto pisze teksty i kto dostarcza zdjęcia.
- Liczba rund projektowych i definicja, czym jest runda.
- Wspierane przeglądarki i urządzenia oraz założony poziom dostępności.
- Cele wydajnościowe, jeśli są istotne, wyrażone mierzalnymi wartościami.
- Jakie języki i kto dostarcza tłumaczenia.
Wykonawca, który sam z siebie zapisuje, czego nie obejmuje, przeszedł zwykle już przez spór o zakres — a to dobry znak.
Własność, dostępy i wyjście#
Te punkty wydają się abstrakcyjne, dopóki nie zechcesz zmienić dostawcy, a wtedy tylko one się liczą.
| Punkt | Co umowa powinna mówić |
|---|---|
| Kod źródłowy | Przechodzi w całości na ciebie z płatnością końcową |
| Pliki projektowe | Też twoje, łącznie z plikami źródłowymi |
| Domena | Zarejestrowana na twoją firmę, z twoim dostępem |
| Hosting | Na twoim koncie albo przenoszalny na żądanie |
| Konta zewnętrzne | Analityka, poczta, płatności — na twoją firmę |
| Licencje zewnętrzne | Które i kto je opłaca później |
| Przekazanie | Dokumentacja i przekazanie dostępów przy zakończeniu |
| Wykorzystanie w portfolio | Mogą pokazać; rozsądnie na to pozwolić |
Domena i hosting na nazwisko wykonawcy to najczęstszy sposób, w jaki firmy zostają uwiązane. Sprawdź to przed podpisaniem, a nie przy odchodzeniu.
Płatności, terminy i zmiany#
Te trzy są powiązane: kto kiedy płaci, co wyznacza datę i co się dzieje, gdy zakres rośnie.
- Płatności etapami powiązane z dostawami, a nie z datami kalendarzowymi.
- Zaliczka jest normalna; pełna przedpłata nie.
- Rata końcowa po odbiorze, na tyle istotna, by miała znaczenie.
- Wzajemne zależności: termin się przesuwa, jeśli spóźnisz teksty, i to powinno tam być.
- Procedura zmian: każde rozszerzenie dostaje pisemną wycenę przed startem.
- Stawka godzinowa za pracę poza zakresem, ustalona z góry.
- Co się dzieje przy opóźnieniu po obu stronach — nie tylko po twojej.
- Warunki rozwiązania: jak się kończy i co wtedy jest płacone i przekazywane.
Gwarancja, utrzymanie i odpowiedzialność#
Część dotycząca okresu po uruchomieniu, i ta, której najczęściej brakuje.
| Punkt | Rozsądne ustalenie |
|---|---|
| Okres poprawek | Trzydzieści do dziewięćdziesięciu dni bez kosztu |
| Czym jest błąd | Nie działa jak ustalono — nie: nowe życzenie |
| Czas reakcji | Dni robocze przy zwykłych zgłoszeniach, szybciej przy awarii |
| Utrzymanie | Osobna umowa, z wyraźną listą |
| Podatności bezpieczeństwa | Kto łata, w jakim terminie |
| Dane osobowe | Umowa powierzenia, jeśli przetwarzają dane |
| Odpowiedzialność | Ograniczenie do wartości umowy jest zwyczajowe |
| Spory | Jakie prawo, jaki sąd — krótko, ale obecne |
Rozróżnienie «błąd» od «nowe życzenie» powoduje po uruchomieniu najwięcej tarć. Jedno zdanie definiujące to oszczędza miesiące dyskusji.
Najczęstsze pytania
Czy potrzebuję umowy przy małym projekcie?
Tak, choć może być krótka. Dwie strony ustalające zakres, cenę, momenty płatności, własność i to, czego nie ma w środku, pokrywają większość tego, co idzie nie tak. Małe projekty to właśnie te, w których nikt niczego nie zapisuje i w których zakres niepostrzeżenie się podwaja.
Co, jeśli wykonawca chce zachować własność kodu?
To powód, by dopytać. Przy kodzie na zamówienie kod po zapłacie powinien być twój. Wyjątkiem jest własna platforma albo framework wykonawcy — wtedy dostajesz licencję zamiast własności, co może być rozsądne, o ile umowa mówi, co się dzieje, gdy odejdziesz albo gdy oni zamkną działalność.
Ile zapłacić z góry?
Zaliczka jednej czwartej do jednej trzeciej jest zwyczajowa i rozsądna. Pełna przedpłata nie, bo usuwa motywację do dokończenia. Powiąż resztę z dostawami, które widzisz — zaakceptowany projekt, oddana budowa, strona na żywo — zamiast z datami kalendarzowymi, które mogą się przesunąć.
Co powinna obejmować gwarancja?
Wady tego, co dostarczono: rzeczy, które nie działają jak ustalono. Nie: nowe życzenia, zmiany wywołane aktualizacją przeglądarki po miesiącach ani problemy spowodowane twoimi własnymi zmianami. Trzydzieści do dziewięćdziesięciu dni jest zwyczajowe. Zadbaj, by umowa definiowała, czym jest błąd, inaczej będziesz o tym dyskutować w najgorszym momencie.
umowa na wykonanie stronyumowa web developmentzakres projektuwłasność kodu źródłowegozlecenie stronygwarancja strony
