Brief Projektowy

Kompletny szablon briefu do współpracy z software house'em lub agencją digital. Im lepiej opiszesz projekt, tym dokładniejszą wycenę i lepszą współpracę otrzymasz. Dobry brief oszczędza tygodnie nieporozumień i setki tysięcy złotych na późniejsze zmiany.

📖 Dlaczego brief jest ważny? Badania pokazują, że 70% projektów IT przekracza budżet lub termin — głównie przez niejasne wymagania na starcie. Brief to Twój kontrakt z software housem: definiuje zakres, oczekiwania i kryteria sukcesu. Bez briefu każda strona ma inny obraz projektu w głowie.

1. Informacje o firmie i projekcie

Nazwa firmy / projektu:

Branża i model biznesowy (B2B / B2C / B2B2C):

Strona www / istniejący produkt (jeśli istnieje):

Osoba kontaktowa (imię, stanowisko, email, telefon):

Kto podejmuje decyzje w projekcie? (decision maker)

[Np. CEO, CTO, Product Manager — kto zatwierdza zakres i budżet?]

Czy są inni stakeholderzy których musimy uwzględnić?

[Np. dział prawny, IT, marketing, inwestorzy]

2. Cel i problem biznesowy

💡 Tip: Opisz problem biznesowy, nie rozwiązanie techniczne. "Chcemy aplikację mobilną" to rozwiązanie. "Nasi klienci rezygnują z zakupów bo proces jest zbyt skomplikowany na mobile" to problem — i to od niego zaczynamy.

Jaki problem biznesowy rozwiązuje ten projekt?

[Opisz problem z perspektywy biznesowej: co traci firma lub użytkownicy przez brak tego rozwiązania? Ile to kosztuje (czas, pieniądze, klienci)?]

Co chcesz zbudować? (w 2–3 zdaniach)

[Opisz produkt prostym językiem — tak jakbyś tłumaczył komuś spoza branży IT]

Jaki jest główny cel projektu?

☐ Nowy produkt / MVP od zera	☐ Rozbudowa istniejącego produktu
☐ Redesign / przepisanie istniejącego	☐ Integracja z innymi systemami
☐ Automatyzacja procesów wewnętrznych	☐ Inne: ________________

Jak zmierzysz sukces projektu? (KPI / metryki)

[Np. "Zmniejszenie czasu obsługi zamówienia z 10 do 2 minut", "100 nowych użytkowników miesięcznie", "Konwersja 5% na płatny plan", "Redukcja błędów o 80%"]

3. Użytkownicy i grupy docelowe

Kto jest głównym użytkownikiem produktu?

[Opisz personę: wiek, rola zawodowa, poziom tech-savvy, jak często będzie używać produktu, na jakim urządzeniu]

Czy są różne typy użytkowników z różnymi uprawnieniami?

[Np. Admin, Manager, Pracownik, Klient, Gość — każda rola może mieć inne widoki i funkcje]

Ilu użytkowników oczekujesz?

Horyzont	Liczba użytkowników	Jednoczesnych użytkowników
Launch (dzień 1)
Po 6 miesiącach
Po 2 latach

4. Zakres funkcjonalny

💡 Tip: Podziel funkcje na Must-have (MVP — bez tego produkt nie działa), Should-have (ważne, ale można uruchomić bez) i Nice-to-have (fajne, ale na później). To kluczowe dla wyceny i timeline'u.

Jakie platformy? (zaznacz wszystkie które dotyczą)

☐ Strona WWW (statyczna / landing page)	☐ Web App (aplikacja w przeglądarce)
☐ Aplikacja iOS (iPhone / iPad)	☐ Aplikacja Android
☐ Desktop (Windows / Mac / Linux)	☐ PWA (Progressive Web App)
☐ Panel administracyjny	☐ API / Backend only

Główne moduły / funkcje (Must-have — bez nich produkt nie działa):

[Lista funkcji kluczowych. Dla każdej: krótki opis co robi i dlaczego jest niezbędna]

Funkcje drugorzędne (Should-have — ważne, ale można uruchomić bez):

Funkcje na przyszłość (Nice-to-have — wersja 2.0):

Integracje z zewnętrznymi systemami:

System / API	Cel integracji	Priorytet
[Np. Stripe]	[Płatności online]	[Must-have]
[Np. SendGrid]	[Emaile transakcyjne]	[Must-have]

Typowe moduły — zaznacz które potrzebujesz:

☐ Rejestracja / logowanie (email)	☐ Logowanie przez Google / Apple / Facebook
☐ Panel użytkownika / dashboard	☐ Panel administracyjny
☐ Płatności online (Stripe / Przelewy24)	☐ Subskrypcje / plany cenowe
☐ Powiadomienia email	☐ Powiadomienia push (mobile)
☐ Chat / messaging	☐ Wyszukiwarka
☐ Upload plików / zdjęć	☐ Mapa / geolokalizacja
☐ Wielojęzyczność (i18n)	☐ Raportowanie / eksport danych
☐ CMS (zarządzanie treścią)	☐ Integracja z AI / ML
☐ API dla zewnętrznych partnerów	☐ Marketplace / dwustronna platforma

5. Design i identyfikacja wizualna

Czy masz gotowe projekty graficzne (Figma, Sketch, Adobe XD)?

[Tak / Nie / Częściowo — jeśli tak, podaj link]

Czy masz branding (logo, kolory, fonty, brand guidelines)?

[Tak / Nie / W trakcie tworzenia]

Styl wizualny — opisz lub zaznacz:

☐ Minimalistyczny / clean	☐ Nowoczesny / tech
☐ Korporacyjny / profesjonalny	☐ Przyjazny / playful
☐ Luksusowy / premium	☐ Inny: ________________

Przykłady stron / aplikacji, które Ci się podobają (podaj linki i co konkretnie lubisz):

[Np. "Podoba mi się nawigacja z Notion.so i kolorystyka z Linear.app. Nie podoba mi się przeładowanie treścią jak na starych stronach korporacyjnych."]

Przykłady produktów których NIE lubisz i dlaczego:

[Często równie ważne jak to co lubisz — pomaga uniknąć nieporozumień]

6. Wymagania techniczne i bezpieczeństwo

Czy masz preferencje technologiczne?

[Np. "Mamy już backend w Node.js, chcemy to zachować", "Preferujemy Firebase", "Musi działać on-premise (na własnym serwerze)"]

Wymagania dotyczące danych i bezpieczeństwa:

☐ Dane osobowe (RODO compliance wymagane)	☐ Dane finansowe / płatnicze (PCI DSS)
☐ Dane medyczne (HIPAA / regulacje zdrowotne)	☐ Dane wrażliwe / tajemnica handlowa
☐ Hosting w Polsce / UE (wymaganie prawne)	☐ On-premise (własny serwer)
☐ Certyfikaty bezpieczeństwa (ISO 27001, SOC2)	☐ Audyt bezpieczeństwa wymagany

Wymagania dotyczące dostępności (accessibility):

[Np. WCAG 2.1 AA (wymagane dla instytucji publicznych), obsługa czytników ekranu, kontrast kolorów]

Wymagania wydajnościowe:

[Np. "Strona musi ładować się w <2s", "System musi obsłużyć 1000 jednoczesnych użytkowników", "Uptime 99.9%"]

7. Timeline i budżet

Kiedy chcesz wystartować z projektem?

Kiedy chcesz mieć gotowy produkt (deadline)?

[Czy deadline jest twardy (np. targi, event, regulacje) czy elastyczny?]

Czy masz kamienie milowe pośrednie?

[Np. "MVP gotowy za 8 tygodni, pełna wersja za 6 miesięcy"]

Jaki jest Twój budżet? (przedział)

☐ do 15,000 PLN (landing page / prosta strona)	☐ 15,000 – 30,000 PLN (strona z CMS)
☐ 30,000 – 60,000 PLN (MVP / prosta web app)	☐ 60,000 – 120,000 PLN (zaawansowana aplikacja)
☐ 120,000 – 250,000 PLN (kompleksowy produkt)	☐ powyżej 250,000 PLN (enterprise / platforma)
☐ Do ustalenia po Discovery	☐ Wolę rozmawiać o zakresie, nie budżecie

Model współpracy — preferowany:

☐ Fixed price (stała cena za zdefiniowany zakres)	☐ Time & Material (płatność za czas pracy)
☐ Dedicated team (wynajęcie zespołu)	☐ Nie wiem — potrzebuję rekomendacji

8. Wsparcie po launchu i utrzymanie

Czy potrzebujesz wsparcia technicznego po uruchomieniu?

☐ Tak — SLA (Service Level Agreement) z gwarantowanym czasem reakcji

☐ Tak — retainer (stała miesięczna opłata za dostępność)

☐ Tak — ad-hoc (zlecenia na żądanie)

☐ Nie — mamy własny zespół techniczny

Czy planujesz dalszy rozwój produktu po launch?

[Tak / Nie / Nie wiem — jeśli tak, jaka jest wizja na 12–24 miesiące?]

Czy masz własny zespół techniczny który przejmie projekt?

[Jeśli tak — jakie technologie znają? To wpływa na wybór stacku technologicznego]

9. Dodatkowe informacje

Czy rozmawiałeś już z innymi software house'ami? Jeśli tak — co Ci się nie podobało?

[Pomaga nam zrozumieć Twoje oczekiwania i uniknąć tych samych błędów]

Czy masz dokumentację, badania użytkowników, dane analityczne które możemy przejrzeć?

[Np. Google Analytics, wywiady z użytkownikami, wyniki ankiet, heatmapy]

Inne uwagi, pytania lub rzeczy które uważasz za ważne:

💡 Co dzieje się po wysłaniu briefu? W Assadante po otrzymaniu briefu: (1) Analizujemy go w ciągu 24h, (2) Umawiamy bezpłatną konsultację Discovery (30–60 min), (3) Proponujemy zakres i wstępną wycenę, (4) Jeśli zdecydujemy się na współpracę — startujemy Discovery Sprint. Nie musisz znać wszystkich odpowiedzi — pomożemy Ci je doprecyzować.