Brief projektu strony internetowej: Jak napisać taki, który wyceni właściwie
Studio nie wycenia twojego pomysłu. Wycenia dokument, który wysłałeś. Oto jak wygląda działający brief projektu strony internetowej w 2026 roku: co powinno się w nim znaleźć, jak opisać funkcjonalność bez niejasności i jak dokument staje się wyceną i harmonogramem.
Dlaczego niejasny brief cicho zjada twój budżet
Prosta odpowiedź: studio nie może wycenić twoich intencji, tylko twój dokument. Wszystko, co dokument pomija, obie strony wypełniają cicho i inaczej — a dwa obrazy spotykają się w końcu na demo, kiedy zmiana kursu jest kosztowna.
Weź zdanie, które brzmi całkowicie jasno: potrzebujemy strony internetowej firmy, około dziesięciu stron, z formularzem zapytania. W środku kryje się co najmniej cztery rozgałęzienia, a każde z nich kosztuje pieniądze:
- Formularz zapytania — czy to jest e-mail do skrzynki odbiorczej, czy tworzy transakcję w twoim CRM i wysyła klientowi automatyczną odpowiedź?
- Dziesięć stron — dziesięć unikalnych ekranów, każdy zaprojektowany i zbudowany osobno, czy jeden szablon wypełniony dziesięć razy?
- Treść — czy przekazujesz gotowy tekst i fotografię, czy ktoś musi to napisać i sfotografować?
- Języki — jeden, czy trzy, a kto tłumaczy?
Różnica między tanim a drogim czytaniem jest wielokrotnością, a nie błędem zaokrąglenia — i oba są uczciwe, odpowiedź po prostu nie była w tekście.
Następnie przychodzi harmonogram. Ambiwalencja przychodzi w kawałkach, każdy przebrany za jedną małą rzecz — filtr tutaj, kalkulator tam, formularz cytatu na stronie usług. Każdy brzmi jak pół godziny; razem przepisują połowę projektu, a uruchomienie opóźnia się o miesiące. Dobry dokument wymagań nie jest biurokracją; to sposób na wczesne nieporozumienie, gdy nieporozumienie jest jeszcze darmowe. Pomiń to, a klient płaci za przeróbki, podczas gdy studio ponosi koszty lub kłóci się i traci relację.
Brief, Specyfikacja, Zakres Prac — i kto je pisze
Brief to dokument wstępny — jedna lub dwie strony, które klient wypełnia: kim jesteś, co sprzedajesz, komu, dlaczego potrzebujesz strony, co lubisz i nienawidzisz w konkurencji, budżet, termin. Opisuje problem, a nie rozwiązanie, więc nie można go dokładnie wycenić — tylko oszacować w przybliżeniu.
Specyfikacja techniczna opisuje, co będzie zbudowane: lista stron, struktura każdej strony, funkcjonalność, scenariusze, integracje, wymagania administracyjne, kryteria akceptacji. Jest pisana po zrozumieniu problemu i staje się aneksem do umowy.Zakres pracy to granica — co jest w środku, a co na zewnątrz. Jedna linia mówiąca treść karty produktu jest uzupełniana przez klienta jest warta więcej niż strona eleganckiej prozy.
Kto powinien napisać specyfikację
Krótka odpowiedź: klient pisze brief, studio pisze specyfikację. Jesteś ekspertem w swojej branży — marże, sezonowość, obiekcje, które słyszą twoi sprzedawcy. Studio jest ekspertem w tym, co zepsuje się w trzecim miesiącu: jakie rozwiązania istnieją i ile każde kosztuje. Pozostawiony samemu sobie, klient wymyśla rozwiązania, w których nie ma doświadczenia, a wynik albo określa rzeczy, które nie działają w ten sposób, albo wymaga wszystkiego na raz.
Więc wzór jest taki: klient wypełnia brief; studio przeprowadza odkrycie — kilka sesji niewygodnych pytań, mapując rzeczywisty proces biznesowy — następnie pisze specyfikację, a klient ją czyta, kłóci się i zatwierdza. Odkrycie i pisanie specyfikacji to prawdziwa praca: studio, które oferuje szczegółową specyfikację za darmo, wyprodukuje formalną, wystarczającą, aby uzyskać podpis. Aby odróżnić zespoły, które naprawdę się angażują, od tych, które powielają szablony, omówiliśmy sygnały w naszym przewodniku na temat wybór studia internetowego.
Otwarcie: Cel biznesowy, odbiorcy, konkurenci
Pierwsza sekcja każdego porządnego specyfikacji odpowiada dlaczego, nie co. Pomiń to, a żadna późniejsza decyzja nie może być podjęta: każdy argument dotyczący tego, czy blok jest potrzebny, sprowadza się do kryterium, a kryterium pochodzi z celu.
Cel biznesowy
Wyraź to w terminach biznesowych, a nie w terminach strony internetowej. "Piękna, nowoczesna strona" to opinia. Cel brzmi bardziej jak: uzyskanie zapytań o instalację od właścicieli domów — w tej chwili wszystko przychodzi telefonicznie, a połowa z tego ginie, lub przenieść klientów hurtowych do samodzielnej obsługi. Pierwsze sprawia, że formularz, zaufanie i szybkość mają znaczenie; drugie, obszar konta i zamawianie jednym kliknięciem. Ten sam budżet, różne miejsca.
Publiczność
Opisz zachowanie, a nie demografię. "Mężczyźni, 25 do 45" nie mówi deweloperowi nic. To mówi:
- Kto decyduje i kto płaci — często różne osoby.
- Jak przychodzą: szukając problemu, podążając za rekomendacją, klikając w reklamę.
- Co weryfikują, zanim się zobowiążą: cena, czas realizacji, licencjonowanie, recenzje, obszar pokrycia.
- Na jakim urządzeniu są. Telefon na placu budowy z słabym sygnałem zmienia wymagania dotyczące wagi strony.
Konkurenci
Podaj trzy do pięciu linków, każdy z jednym zdaniem: co jest dobre, a co złe. Nie "ładny design", ale "ich cena jest widoczna od razu bez formularza — tego chcę." Ten nawyk oszczędza tygodnie e-maili, ponieważ przekształca gust w wymagania. I napisz szczerze, jak różnisz się od tych konkurentów: jeśli nie ma różnicy, to nie jest problem strony, a żaden front-end tego nie naprawi.
Lista stron i struktura: Gdzie znajduje się wycena
Tutaj pochodzi większość wyceny. Zasada jest prosta: licz unikalne szablony, a nie strony. Katalog z tysiącem produktów to jeden szablon karty produktu, a strona ośmiostronicowa zaprojektowana strona po stronie kosztuje więcej niż trzydzieści stron na trzech szablonach. Więc napisz listę w dwóch turach: nazwij każdą stronę, a następnie zaznacz, które są szablonowe, a które są jednorazowe.
Jak opisać stronę
Dla każdej unikalnej strony wymień bloki od góry do dołu z celem każdego. Dla strony usługowej:
- Hero: nagłówek, jednozdaniowy opis, przycisk z prośbą o wycenę.
- Co jest w zestawie — lista punktowana, pięć do ośmiu pozycji.
- Jak przebiega praca — trzy do sześciu kroków.
- Cennik: tabela poziomów lub pojedyncza linia "od"; zdecyduj podczas odkrywania.
- Powiązana praca — trzy karty, automatycznie pobrane z portfolio według tagu usługi.
- FAQ — edytowalne z panelu administracyjnego. Formularz zapytania.
Zauważ dwa zwroty, które mają kluczowe znaczenie: "pobrane automatycznie według tagu" i "edytowalne z panelu administracyjnego." To nie jest dekoracja, to godziny: blok, który edytor wypełnia ręcznie, i blok, który sam się składa z danych, to różne zadania w różnych cenach.
Nawigacja i linki między stronami
Opisz główne menu i stopkę w całości oraz jak strony się łączą: usługi prowadzą do studiów przypadków, studia przypadków wracają do usługi i formularza, artykuły do usług. Przydatnym testem jest przejście przez przyszłą stronę jako obcy — ktoś trafił na artykuł, co widzi następnie i dokąd idzie? Jeśli nie możesz odpowiedzieć, ta strona nie jest skończona. Możesz zobaczyć, jak to wygląda w naszej ostatniej pracy. I nie pisz "strona musi być responsywna" — to podstawowe wymaganie; napisz, gdzie mobilna wersja zachowuje się inaczej: tabela cenowa staje się stosowanymi kartami, filtr otwiera się na pełnym ekranie. Te miejsca pochłaniają czas, gdy pojawiają się późno.
Opis funkcjonalności bez niejasności
Klasycznym błędem specyfikacji jest opisywanie funkcji za pomocą przymiotników — wygodny filtr, inteligentne wyszukiwanie, szybkie zakupy. To nie są wymagania, to życzenia: nie możesz ich zweryfikować, nie możesz ich wycenić, a o nich można dyskutować w nieskończoność — wygodny według kogo?
Alternatywą są scenariusze: kto robi co i co z tego ma. Porównaj. Słabe: "Konto klienta z historią zamówień."Silne:
- Klient loguje się za pomocą e-maila i hasła; resetowanie hasła działa za pośrednictwem linku wysłanego e-mailem.
- Klient widzi swoje zamówienia: numer, datę, łączną kwotę, status i przycisk "powtórz zamówienie".
- Jest pięć statusów — nowe, w trakcie realizacji, wysłane, dostarczone, anulowane — ustalanych przez menedżera w panelu administracyjnym.
- "Powtórz zamówienie" przenosi przedmioty z powrotem do koszyka; wszystko, co jest niedostępne, jest pomijane, a klient jest informowany, które.
- Klient pobiera fakturę PDF, ale nie może edytować zarejestrowanej nazwy firmy — tylko menedżer może.
Druga wersja może być wyceniona w godzinach bez jednego telefonu; pierwsza tylko zgadywana, nietrafiona.
Zapisz przypadki brzegowe
Koszt rzadko jest szczęśliwą ścieżką — to wszystko wokół niej, gdzie połowa budżetu się ukrywa:
- Co się dzieje bez danych: pusty koszyk, wyszukiwanie bez wyników, kategoria bez niczego.
- Co się dzieje w przypadku błędu: płatność odrzucona, plik za duży, e-mail już zarejestrowany.
- Co widzi użytkownik, jeśli połączenie przerwie się w trakcie płatności, i kto może co robić — edytorzy i administratorzy potrzebują różnych uprawnień.
I oznacz każdy element: wymagany do uruchomienia, miło mieć, lub faza druga. To jest najlepsze narzędzie budżetowe, jakie istnieje: gdy szacowanie wraca wyższe niż się spodziewałeś, będziesz ciął celowo zamiast rąbać to, co najbliżej.
Treść, integracje, języki: Kto dostarcza co i kiedy
Więcej projektów umiera tutaj niż w jakiejkolwiek linii kodu. Strona jest gotowa, a uruchomienie nie następuje — ponieważ tekst nigdy nie dotarł, lub zdjęcia to zdjęcia z telefonu zrobione w ciemnym magazynie.
Treść
Specyfikacja musi jasno określać, kto jest właścicielem każdego typu treści i do kiedy ona istnieje:
- Tekst na stronie. Napisany przez Ciebie, przez copywritera studia, czy opracowany przez Ciebie i edytowany przez nas? Trzy ceny.
- Fotografia. Twoje archiwum, sesja zdjęciowa, czy zdjęcia stockowe? Jeśli sesja — kto ją organizuje i płaci za nią.
- Katalog. Kto wypełnia karty, skąd pochodzą opisy, w jakim formacie przychodzi eksport.
- Strony prawne. Polityka prywatności, warunki, dane firmy — terytorium klienta, ale studio powinno Cię o tym przypomnieć.
I jeszcze jedna linia: co się stanie, jeśli treść nie będzie gotowa na czas. Rozsądna odpowiedź to uruchomienie z zastępczymi treściami na uzgodnionej liście stron, a nie trzymanie gotowej strony w szufladzie przez miesiące.
Integracje
Opisz każdy z nich w ten sam sposób: który system, co się gdzie przenosi, w którym momencie, i co się dzieje, gdy to zawiedzie. "Integracja z CRM" jest bezsensowna — obejmuje zarówno dwie godziny pracy, jak i dwa tygodnie. Przejdź przez zwykłą listę — CRM, bramka płatności, wysyłka, oprogramowanie magazynowe, marketing e-mailowy, komunikatory, paragony fiskalne, analityka — i dla każdego odpowiedz na trzy pytania: czy ma API, czy jest dokumentacja, kto posiada dane dostępowe. Brak danych dostępowych to ryzyko, które powinno być w specyfikacji, a nie pojawiać się tydzień przed uruchomieniem.
Języki
Wielojęzyczność to nie przełącznik w nagłówku. To osobny model danych, osobne URL-e, osobne meta tagi, osobna praca redakcyjna i zasada dotycząca tego, co się dzieje, gdy strona nie ma tłumaczenia. Zdecyduj z góry: które języki przy uruchomieniu, które później, kto tłumaczy. Wprowadzenie drugiego języka do projektu, który nigdy nie przewidywał jednego, kosztuje więcej niż zaplanowanie tego od pierwszego dnia.
Referencje projektowe i pułapka "Zrób to jak X"
Referencje są niezbędne: bez nich projektant zgaduje Twój gust, a gustu nie da się zgadnąć przez e-mail. Ale sposób, w jaki je dostarczasz, ma znaczenie.
Pułapka "zrób to jak X" wydaje się nieszkodliwa, a staje się kosztowna. Kopiowanie czyjejś strony nie zadziała dla Twojego biznesu — inny produkt, inna publiczność, inny poziom cenowy — ale głębszym problemem jest to, że widzisz stronę internetową z zewnątrz, podczas gdy koszty są wewnątrz: za tą płynna animacją mogą kryć się trzy miesiące pracy, za żywym katalogiem integracja z magazynem, a za "tylko ładnymi zdjęciami" sesja zdjęciowa, której nie masz.
Stąd zasada: odniesienie bez komentarza jest bezużyteczne. Każdy link potrzebuje zdania mówiącego, co właściwie z niego czerpiesz:
- "Podoba mi się, że cena jest od razu widoczna, bez formularza zgłoszeniowego."
- "Podoba mi się poczucie przestrzeni — dużo powietrza, mało tekstu na ekranie."
- "Podoba mi się struktura karty produktu, nie kolory."
- "Bardzo nie podoba mi się karuzela hero."
Anty-referencje działają równie dobrze: "nie tak, zbyt korporacyjne" zawęża poszukiwania szybciej niż pięć przykładów tego, co lubisz.
Co jeszcze ustalić
Czy istnieje księga marki i jak bardzo jest wiążąca; ton — formalny czy konwersacyjny; a przede wszystkim, kto zatwierdza projekt. Projekty często utkną na zatwierdzeniach znacznie częściej niż na technologii, gdy makieta krąży do trzeciego zastępcy dyrektora i wraca z uwagami sprzecznymi z pierwszym. Wpisz nazwisko w specyfikacji — czyje "tak" jest ostateczne — i uzgodnij liczbę rund. Dwie lub trzy to norma; nieograniczona liczba to nie projekt, to hobby.
Ograniczenia techniczne, SEO i życie w panelu administracyjnym
To jest sekcja, którą klienci pomijają z "ty wiesz najlepiej." Studio rzeczywiście wie najlepiej o rozwiązaniach — ale tylko ty znasz ograniczenia, od których zaczynasz.
Ograniczenia techniczne
- Hosting i domena.Gdzie teraz znajdują się rzeczy, kto posiada dane uwierzytelniające, czy zasady regulują, gdzie mogą znajdować się dane.
- Istniejący system.Jeśli strona już istnieje — co migruje, co zostaje usunięte, co działa równolegle.
- Polityka wewnętrzna.Przegląd bezpieczeństwa, zasady dotyczące haseł, ograniczenia dotyczące usług stron trzecich.
- Własność kodu i dane osobowe.Kto jest właścicielem wyniku, co zbierasz, jak to jest usuwane na żądanie.
SEO
Określ wymagania dotyczące wyszukiwania jako mechanikę, a nie obietnice. Żadne studio nie może zagwarantować pozycji, ale każde studio musi dostarczyć fundament:
- Edytowalny tytuł, opis i nagłówki na każdej stronie — z panelu administracyjnego, bez dewelopera.
- Czytelne adresy, spójny schemat URL i mapowanie przekierowań podczas migracji.
- Strukturalne dane, mapa witryny, poprawne kanoniki i przy kilku językach, odpowiednie atrybuty językowe.
- Szybkość określona jako konkretne metryki na konkretnym urządzeniu, a nie jako "szybka."
Panel administracyjny i codzienna edycja
Najbardziej niedoceniana sekcja w każdej specyfikacji. Odpowiedz na jedno pytanie: co zmienisz samodzielnie i jak często?Odpowiedź napędza architekturę. Zmień numer telefonu raz w roku i ledwo potrzebujesz administratora; twórz nowe strony docelowe co tydzień i potrzebujesz kreatora bloków — inny system i budżet. Opisz role i co się dzieje, gdy edytor popełnia błąd: szkice, podgląd, przywracanie. I bądź szczery co do umiejętności osób, które będą z tego korzystać — interfejs stworzony dla dewelopera paraliżuje zwykłego edytora.
Kryteria akceptacji, harmonogram i zakres budżetu
Te trzy zamykają specyfikację i przekształcają ją z opisu marzenia w dokument roboczy.
Kryteria akceptacji
Kryterium akceptacji to weryfikowalne stwierdzenie. Nie "strona działa poprawnie," ale lista tego, co będzie sprawdzane:
- Każda strona z listy otwiera się; żaden link nie prowadzi do błędu.
- Formularz zapytania jest wysyłany, e-mail przychodzi, a lead pojawia się w CRM.
- Strona renderuje się poprawnie w aktualnych przeglądarkach i na telefonie.
- Metryki szybkości na stronie głównej i karcie produktu mieszczą się w uzgodnionym progu.
- Płatność kartą testową przechodzi, zamówienie jest tworzone, a e-mail potwierdzający jest wysyłany.
Ta lista chroni obie strony: klient dokładnie wie, co sprawdzić, a studio wie, gdzie jest linia mety, zamiast stawać w obliczu fazy akceptacji, która nigdy się nie kończy, ponieważ coś wydaje się nie tak.
Harmonogram
Daty w specyfikacji są zazwyczaj szkodliwe — stają się nieaktualne po dwóch tygodniach. Opisz harmonogram w etapach: makiety po zatwierdzeniu struktury, rozwój po makietach, populacja po treści. Kluczowe słowo to zależność. Terminy działają w obie strony: jeśli treść przychodzi trzy tygodnie za późno, uruchomienie się przesuwa — to arytmetyka, a nie kara. Napisz jasno, które terminy należą do klienta: zatwierdzanie makiet, dostarczanie treści, przyznawanie dostępu.
Zakres budżetu
Klienci ukrywają budżet, obawiając się, że wycena zostanie dostosowana do tej kwoty. Efekt jest odwrotny. Budżet to nie cena — to ograniczenie problemu: jeśli go wstrzymasz, otrzymasz albo propozycję, na którą cię nie stać, albo jedną przyciętą do granic rozpoznania. Zakres jest wystarczający: "myślimy w tym zakresie i omówimy więcej, jeśli będzie to uzasadnione." To, co następuje, to rozmowa inżynieryjna o tym, co pasuje do ram i co przechodzi do fazy drugiej. Aby zobaczyć, jak cena jest faktycznie ustalana i dlaczego dwa identycznie wyglądające serwisy kosztują inaczej, zobacz nasze zestawienie ile kosztuje strona internetowa w 2026 roku.
Czego nie należy umieszczać w briefie
Złe specyfikacje to nie tylko krótkie — osiemdziesięcio-stronicowy potwór to także symptom. Oto, co należy bez wahania usunąć.
Przymiotniki oceniające. Nowoczesny, wygodny, intuicyjny, wysoko konwertujący. Żaden z nich nie może być zweryfikowany. Zrób to sprawdzalne zamiast tego: zamiast "wygodnego katalogu" napisz "odwiedzający dociera do właściwego produktu w nie więcej niż trzech krokach."
Przypisane rozwiązania techniczne, jeśli nie jesteś techniczny. Linia mówiąca "zbuduj to na tym stosie," bez powodu, wiąże ręce i podnosi cenę. Zamiast tego określ ograniczenie: "nasz administrator systemu może wspierać tylko ten stos," lub "musi działać na naszym serwerze." Studio uszanuje powód i wybierze metodę.
Wszystko, na wszelki wypadek. "System powinien również umożliwiać przyszłą rozbudowę funkcjonalności" nic nie znaczy, ale sumienne studio wyceni bufor na nieznane. Płacisz za mgłę.
Kopiuj-wklej z czyjejś specyfikacji. Jest to boleśnie widoczne, gdy specyfikacja kliniki nagle rośnie o koszyk zakupowy i opcje dostawy: teraz nikt nie wie, które wymagania są rzeczywiste. Projektowanie w prozie i maszyny prawne również odpadają — jedno to zadanie makiety, drugie to zadanie umowy.
A co prawie zawsze brakuje
Druga strona: niektóre rzeczy są pomijane w dziewięciu specyfikacjach na dziesięć i nie wyglądają na ważne, dopóki nie wybuchną.
- Co się dzieje po uruchomieniu: kto aktualizuje stronę, kto ją naprawia, kto odpowiada o północy w sobotę.
- Kopie zapasowe: jak często, gdzie są przechowywane, kto weryfikuje, że rzeczywiście można je przywrócić.
- Przekazanie: dane logowania, dokumentacja, przewodnik dla redaktora, pliki źródłowe i szkolenie dla twojego zespołu.
- Co liczy się jako naprawa gwarancyjna, a co jako nowe zadanie.
Jak brief staje się wyceną — i jak radzić sobie ze zmianami
Wycena to nie liczba wyciągnięta z doświadczenia — to arytmetyka przeprowadzona na dokumencie.
Jak działa wycena
Studio dzieli specyfikację na elementy i wycenia każdy z nich w godzinach: każdy unikalny szablon, każda strona szablonowa, każda funkcja, każda integracja, administracja, testowanie, uruchomienie. Na górze znajdują się rzeczy nieobecne na liście stron, ale zawsze obecne — zarządzanie, komunikacja, poprawki, akceptacja. Z czego wynika ważna część: wycena jest tak dokładna, jak specyfikacja. Z briefu możesz podać zakres, który będzie szeroki, ponieważ jest szczery. Kiedy wykonawca czyta jeden akapit i podaje dokładną cenę, to liczba z sufitu — a na końcu sufit należy do ciebie lub do nich.
Porównuj tylko wyceny napisane na podstawie tej samej specyfikacji; w przeciwnym razie porównujesz różne projekty. Tania propozycja prawie zawsze opisuje mniej — brak testów, brak populacji treści, brak integracji — a linia mówiąca "rozwój strony internetowej — całkowity" nie może być sprawdzona, podczas gdy szczegółowa wycena dowodzi, że wykonawca przeczytał specyfikację. Nasze zakresy usługsą oparte dokładnie na tej logice: najpierw struktura, potem funkcjonalność, potem akceptacja.
Zmiany po zatwierdzeniu
Zmiany się zdarzą — firmy się rozwijają, a demo zawsze ujawnia rzeczy, których dokument nie mógł. Pytanie nie brzmi, jak ich zapobiegać, ale jak je przetwarzać:
- Zmiana jest zapisana — jako pozycja, a nie uwaga podczas rozmowy.
- Studio to wycenia: ile godzin, co się zmienia w harmonogramie, co to dotyka.
- Klient decyduje: zrobić to teraz, w fazie drugiej, czy zrezygnować, a decyzja jest zapisana jako załącznik.
Jest zasada, którą warto zapamiętać: naprawa to wtedy, gdy budowa nie odpowiada specyfikacji; zmiana to wtedy, gdy specyfikacja nie odpowiada potrzebie.. Studio naprawia pierwszy raz za darmo, a drugi wycenia. Granica jest wyznaczana przez dokument, a nie przez nastrój. A jeśli funkcja zostanie dodana, to albo coś wymaganego przechodzi do fazy drugiej, albo dodawane są pieniądze. Nie ma trzeciej opcji.
Lista kontrolna: Twój brief jest gotowy, jeśli zawiera
Przejdź przez listę. Jeśli więcej niż trzy pozycje są puste, dokument nie jest gotowy do wyceny — a wszelkie oszacowania w oparciu o niego to fikcja.
- Cel biznesowy w terminach biznesowych, a nie w terminach strony internetowej.
- Publiczność jako zachowanie: kto decyduje, jak podejmuje decyzje, co weryfikuje, jakiego urządzenia używa.
- Konkurenci: trzy do pięciu linków, każdy z notatką, co brać, a czego unikać.
- Lista stron podzielona na unikalne ekrany i szablonowe.
- Struktura każdej unikalnej strony: bloki od góry do dołu i cel każdego z nich.
- Funkcje jako scenariusze: kto robi co i co dostaje. Plus przypadki brzegowe i niepowodzenia.
- Priorytety: wymagane do uruchomienia / miłe do posiadania / faza druga.
- Treść: kto pisze tekst, kto dostarcza zdjęcia, do kiedy, i co się stanie, jeśli będzie spóźnione.
- Integracje według nazwy: co się porusza, gdzie, kiedy, co w przypadku błędu, kto ma uprawnienia.
- Języki: ile na start, kto tłumaczy, co się dzieje bez tłumaczenia.
- Projekt: adnotowane odniesienia, księga marki, kto zatwierdza, ile rund.
- Ograniczenia techniczne: hosting, dostęp, własność kodu, dane osobowe.
- SEO: edytowalne meta, schemat URL, przekierowania przy migracji, próg prędkości.
- Administrator: co edytujesz samodzielnie i jak często, role, szkice, przywracanie, szkolenie.
- Kryteria akceptacji: weryfikowalna lista, nie "działa poprawnie."
- Harmonogram etapowy z zależnościami, oraz zakres budżetu.
- Po uruchomieniu: wsparcie, kopie zapasowe, przekazanie uprawnień, granice gwarancji.
Zanim projekt się zacznie, nie próbuj wypełnić całej listy samodzielnie w jeden wieczór. Wypełnij to, co naprawdę wiesz: cel, odbiorców, konkurencję, ograniczenia, zakres budżetu. Reszta — strony, funkcje, integracje, akceptacja — zbiera się podczas odkrywania, razem ze studiem.
Dobra specyfikacja jest jak rysunek techniczny: nudny dokument, bez którego dom buduje się na oko. Godzina spędzona na sformułowaniach przed rozpoczęciem oszczędza dzień przeróbek w trakcie. Jeśli chcesz, aby specyfikacja została napisana z tobą i wyceniona uczciwie w stosunku do niej, skontaktuj się — zaczynamy od briefu i rozmowy, a dokument zazwyczaj pisze się sam.
FAQ
Kto powinien napisać specyfikację techniczną — klient czy studio?
Klient wypełnia brief; studio pisze specyfikację po etapie odkrywania. Jesteś ekspertem w swojej branży, studio zna dostępne rozwiązania i ich koszty — a klient następnie przegląda, wprowadza poprawki i zatwierdza wynik.
Jaka jest różnica między briefem a specyfikacją?
Brief to dokument wstępny na jednej lub dwóch stronach, opisujący problem i biznes. Specyfikacja opisuje rozwiązanie — strony, strukturę, funkcje, integracje, kryteria akceptacji — i staje się załącznikiem do umowy.
Czy mogę uzyskać dokładny kosztorys bez specyfikacji?
Nie. Brief daje ci zakres, a uczciwy zakres jest szeroki. Dokładna cena podana na podstawie jednego akapitu oznacza, że wykonawca zgadywał, a różnica ujawni się w połowie budowy.
Czy powinienem powiedzieć studio o moim budżecie?
Tak, przynajmniej w formie zakresu. Budżet to ograniczenie problemu, a nie cena: znając ramy, studio może zaproponować, co mieści się w ich obrębie i szczerze powiedzieć, co przechodzi do fazy drugiej.
Co jeśli chcę coś zmienić po zatwierdzeniu?
Zapisz zmianę i wycenić ją osobno. Zasada jest prosta: jeśli budowa nie odpowiada specyfikacji, to jest to poprawka i studio pokrywa koszty; jeśli specyfikacja nie odpowiada potrzebom, to jest to zmiana i zostanie oszacowana.
Ile czasu zajmuje napisanie odpowiedniej specyfikacji?
Dla strony usługowej zazwyczaj kilka dni do kilku tygodni, w tym etap odkrywania; dłużej dla skomplikowanego katalogu lub obszaru konta klienta. To praca, za którą można wystawić rachunek, a ona sama się opłaca w postaci pracy, której nigdy nie musisz wykonywać.