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.
„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.
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?
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.
- Materiał wejściowy
Arkusze, dokumenty, przykłady błędów i obecny obieg informacji.
- Reguły
Role, uprawnienia, historia, wyjątki i kryterium poprawnego wyniku.
- Zakres MVP
Jedna ścieżka użytkownika oraz funkcje potrzebne do jej obsługi.
- Specyfikacja
Makiety, model danych, integracje, cena i harmonogram.
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
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 |
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.
Pytania i odpowiedzi
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.