Dokument wymagań strony: co w nim napisać
Dokument wymagań istnieje po to, by ty i wykonawca mówili o tym samym projekcie. Nie musi być długi. Musi być konkretny we właściwych miejscach.
Ten przewodnik pokazuje, co uwzględnić, co pominąć i które sekcje eliminują najczęstsze spory.
Sekcje, których nie może zabraknąć#
Każda z nich istnieje, bo jej brak powoduje przewidywalny problem.
- Kontekst i cele. Czym firma się zajmuje i co strona ma osiągnąć, w liczbach.
- Odbiorcy. Kto odwiedza i z jakim pytaniem.
- Lista podstron. Wszystkie, pogrupowane według szablonu, z zaznaczeniem nowych.
- Funkcje. Formularze, wyszukiwarka, filtry, strefa zalogowana, cokolwiek.
- Integracje. Każdy system zewnętrzny, z osobą odpowiedzialną za dostęp.
- Treść. Kto pisze, kto fotografuje, kto wprowadza i do kiedy.
- Wymagania techniczne. Języki, dostępność, wydajność, wspierane przeglądarki.
- Poza zakresem. Najważniejsza sekcja dokumentu.
- Terminy i odpowiedzialni. Kto decyduje i co się dzieje przy opóźnieniu.
Sekcja «poza zakresem» eliminuje więcej sporów niż wszystkie pozostałe razem. Napisz ją, nawet jeśli wydaje się oczywista.
Jak pisać wymagania, które da się zweryfikować#
Wymaganie nieostre jest nieweryfikowalne, a co nieweryfikowalne, to dyskutowane na końcu projektu.
| Nieostre | Weryfikowalne |
|---|---|
| Strona ma być szybka | LCP poniżej 2,5 s na głównych szablonach w 4G |
| Ma działać na telefonie | Używalna od 360 px, testowana na realnych urządzeniach |
| Ma być dostępna | Zgodna z WCAG 2.1 na poziomie AA na głównych szablonach |
| Łatwa w obsłudze | Zespół tworzy i publikuje podstronę bez programisty |
| Nowoczesny design | Zgodny z księgą znaku; trzy propozycje wstępne |
| Zoptymalizowana pod SEO | Edytowalne tytuły, mapa strony, dane strukturalne, przekierowania |
| Obsługuje wiele języków | PL i EN na starcie; struktura pod dodanie kolejnych |
Czego nie umieszczać#
Zbyt szczegółowe dokumenty kosztują czas pisania, czas czytania i odbierają wykonawcy możliwość zaproponowania czegoś lepszego.
- Nie narzucaj technologii bez powodu. Podaj problem; rozwiązanie zostaw ofercie.
- Nie pisz treści każdego przycisku. To rozstrzyga się przy ekranach.
- Nie projektuj strony słowami. Referencje wizualne działają lepiej niż opisy.
- Nie dodawaj funkcji «na przyszłość» bez wyraźnego oznaczenia jako etap drugi.
- Nie kopiuj wymagań z innego dokumentu bez sprawdzenia, czy pasują.
- Nie proś o to, czego nie użyjesz. Każda funkcja ma koszt budowy i utrzymania.
Jeśli dokument dla strony firmowej przekracza dziesięć stron, prawdopodobnie specyfikujesz rozwiązanie zamiast problemu.
Używanie dokumentu w trakcie projektu#
Dokument nie jest do zarchiwizowania po podpisaniu. To punkt odniesienia rozstrzygający spory.
- Wyślij ten sam dokument wszystkim kandydatom, by dostać porównywalne oferty.
- Załącz go do umowy, żeby ustalony zakres był zakresem zapisanym.
- Gdy ktoś prosi o coś nowego, sprawdź dokument zanim zaczniesz rozmawiać o terminie.
- Zapisuj zmiany zakresu, z wyceną, zanim praca się zacznie.
- Używaj listy podstron jako listy kontrolnej treści w trakcie budowy.
- Przy odbiorze przejdź weryfikowalne wymagania jedno po drugim.
Najczęstsze pytania
Jak długi powinien być dokument?
Dla strony firmowej wystarczy pięć do dziesięciu stron. Dla dużego projektu z integracjami dwadzieścia do trzydziestu. Jeśli znacznie to przekraczasz, prawdopodobnie specyfikujesz rozwiązanie zamiast problemu — a takie dokumenty bywają ignorowane przez wszystkich, łącznie z autorami.
Czy podawać budżet?
Tak. Wykonawca może wtedy zaproponować najlepszy możliwy projekt w tej kwocie zamiast zgadywać. Kto nie podaje budżetu, dostaje oferty różniące się dziesięciokrotnie i nie może ich porównać. Wystarczy przedział; nie trzeba ujawniać dokładnej granicy.
Kto powinien napisać dokument?
Ktoś po stronie klienta, kto zna biznes, najlepiej ze wsparciem kogoś znającego się na web. Jeśli poprosisz agencję, naturalnie opisze projekt, jaki lubi robić — co może być nawet dobre, ale przestaje służyć porównywaniu ofert. Jeśli tak robisz, zapłać za ten etap osobno.
Co jeśli wymagania zmienią się w trakcie?
Prawie zawsze się zmieniają, a dokument tego nie blokuje — porządkuje to. Miej procedurę zmian: każda nowa prośba dostaje pisemną wycenę przed startem. Problemem nie są zmiany, tylko zmiany wchodzące bez korekty terminu i budżetu.
dokument wymagań stronybrief strony internetowejspecyfikacja stronyzakres projektu webzapytanie ofertowewymagania serwisu
