Brief aplikacji / pierwsza rozmowa
Nie mam briefu. Czy warto rozmawiać z wykonawcą?
Nie potrzebujesz gotowego briefu, aby sensownie porozmawiać o aplikacji. Zobacz, jakie informacje wystarczą do określenia pierwszego zakresu i wyceny.
KRÓTKA ODPOWIEDŹ
Tak. Dobry wykonawca nie oczekuje kompletnej specyfikacji na pierwszej rozmowie. Wystarczy, że umiesz opisać problem, użytkownika, obecny proces, oczekiwany wynik, ograniczenia i realny budżet. Specyfikacja techniczna powinna być rezultatem analizy, a nie warunkiem rozpoczęcia rozmowy.
- Problem i obecny proces są ważniejsze niż lista ekranów.
- Do pierwszej oceny wystarczy sześć konkretnych odpowiedzi.
- Wykonawca powinien pomóc oddzielić rdzeń produktu od pomysłów na później.
- Wycena bez pytań o użytkowników, dane i wyjątki jest tylko zgadywaniem.
Z PRAKTYKI TWOJSOFTWARE
W systemie ewidencji znajomości tras punktem wyjścia nie był formalny brief. Były arkusze, obowiązek prowadzenia historii i pytania administratora, na które Excel nie odpowiadał. Dopiero z tego powstał zakres MVP za około 12 000 zł netto.
01
Wewnętrzna myśl: „Bez briefu zmarnuję czas wykonawcy”
Wiele osób odkłada rozmowę, bo nie ma makiet, nazw technologii ani listy wszystkich funkcji. To rozsądna obawa, ale prowadzi do złej kolejności. Klient opisuje biznes i ograniczenia. Wykonawca przekłada je na przepływy, dane, architekturę i plan realizacji.
Najgorszym rozwiązaniem jest samodzielne dopracowywanie przez kilka miesięcy dokumentu, który opisuje niepotwierdzone założenia. Długi brief nie musi być dokładny. Może tylko precyzyjnie opisywać niewłaściwy produkt.
02
Stanowisko: najpierw problem, dopiero potem specyfikacja
Pierwsza rozmowa ma odpowiedzieć na trzy pytania: jaki wynik ma dać produkt, kto wykona najważniejszy proces i co dziś uniemożliwia osiągnięcie tego wyniku. Jeśli te odpowiedzi są jasne, można zaproponować mały zakres. Jeśli nie są jasne, kolejna lista funkcji tylko zwiększy niepewność.
- Jaki problem występuje dzisiaj i jak często?
- Kto jest głównym użytkownikiem pierwszej wersji?
- Jak proces wygląda bez nowej aplikacji?
- Po czym po 30-60 dniach poznamy, że wdrożenie działa?
- Jakie dane, dokumenty i systemy są już używane?
- Jaki budżet i termin są racjonalne dla pierwszego etapu?
03
Dowód: od arkusza do działającego systemu
Firma transportowa prowadziła ewidencję znajomości tras w osobnych arkuszach pracowników. Zamiast kopiować arkusze do chmury, opisaliśmy reguły: kto może edytować dane, jak długo przechowujemy historię, jak administrator kontroluje karty i jak wygląda wymagany eksport PDF.
Ta analiza doprowadziła do ważnej decyzji architektonicznej. Baza danych została źródłem prawdy, a arkusz pozostał wyłącznie silnikiem eksportu. MVP kosztowało około 12 000 zł netto i powstało w około dwa miesiące aktywnego developmentu. Formalny brief nie był początkiem. Był efektem uporządkowania rzeczywistego procesu.
- 01
Materiał wejściowy
Arkusze, dokumenty, przykłady błędów i obecny obieg informacji.
- 02
Reguły
Role, uprawnienia, historia, wyjątki i kryterium poprawnego wyniku.
- 03
Zakres MVP
Jedna ścieżka użytkownika oraz funkcje potrzebne do jej obsługi.
- 04
Specyfikacja
Makiety, model danych, integracje, cena i harmonogram.
04
Usunięcie obawy: co przygotować zamiast pełnego briefu
Nie musisz znać Reacta, Supabase ani sposobu synchronizacji danych. Przygotuj dwa lub trzy prawdziwe przykłady: plik, dokument, wiadomość albo zrzut obecnego narzędzia. Pokaż też jeden typowy przypadek i jeden trudny wyjątek. To daje więcej informacji niż ogólny opis kilkudziesięciu ekranów.
Po rozmowie powinieneś otrzymać podsumowanie zakresu, listę założeń, elementy poza pierwszą wersją, budżet i kolejny krok. Jeżeli wykonawca od razu wycenia wszystko bez pytań, brak briefu nie jest największym ryzykiem.
- 1-3 przykładowe dokumenty lub rekordy, po anonimizacji danych
- opis jednego pełnego procesu od początku do wyniku
- lista osób, które używają lub zatwierdzają dane
- najczęstsze błędy oraz sytuacje wyjątkowe
- informacja, co musi wejść do pierwszej wersji, a co jest tylko pomysłem
05
Kwalifikacja: kiedy rozmowa ma sens, a kiedy jest za wcześnie
Rozmowa ma sens, gdy potrafisz wskazać problem, osobę odpowiedzialną za decyzje i przybliżony budżet. Nie musisz wiedzieć, jak system ma być zbudowany. Za wcześnie jest wtedy, gdy jedynym założeniem jest „chcę aplikację jak popularny produkt, tylko lepszą”, ale nie wiadomo dla kogo i po co.
| Jest sens rozmawiać | Najpierw doprecyzuj |
|---|---|
| Znasz problem i obecny proces | Masz tylko luźną listę funkcji |
| Masz dostęp do przyszłych użytkowników | Nikt nie może przetestować wersji roboczej |
| Akceptujesz mały pierwszy zakres | Pierwsza wersja ma zawierać całą wizję |
| Jest osoba podejmująca decyzje | Każdy interesariusz może zmieniać kierunek |
06
Zaproszenie: sześć odpowiedzi wystarczy na pierwszy krok
Opisz problem, użytkownika, obecny proces, oczekiwany wynik, ograniczenia i budżet. Na tej podstawie można wskazać rozsądny zakres pierwszej wersji oraz pytania, które trzeba zamknąć przed wyceną. Jeśli wolisz przygotować materiał samodzielnie, skorzystaj też z naszego pełnego szablonu briefu.
FAQ
Pytania, które pojawiają się najczęściej.
Czy można wycenić aplikację bez briefu?
Można podać orientacyjny przedział po opisaniu problemu, użytkowników, danych i integracji. Stała cena wymaga później potwierdzenia konkretnego zakresu oraz założeń.
Czy wykonawca przygotowuje specyfikację?
Tak, analiza i przygotowanie zakresu technicznego powinny należeć do wykonawcy. Klient dostarcza wiedzę o procesie, użytkownikach, danych i ograniczeniach biznesowych.
Ile informacji wystarczy przed pierwszą rozmową?
Wystarczy opis problemu, głównego użytkownika, obecnego procesu, oczekiwanego wyniku, używanych narzędzi oraz przybliżonego budżetu i terminu.
NASTĘPNY KROK
Nie masz briefu? To nie blokuje pierwszego kroku.
Odpowiedz na sześć krótkich pytań. Na tej podstawie otrzymasz kierunek, orientacyjny zakres i informację, co warto doprecyzować.