Pierwszy tydzień nie powinien polegać na budowie przypadkowych ekranów. Najpierw zamykamy problem, użytkownika, główny przepływ, dane, integracje i kryterium sukcesu. Następnie powstają makiety, fundament projektu oraz pierwszy pionowy fragment, który łączy interfejs, logikę i zapis danych. Dokładny rytm zależy od projektu, ale po siedmiu dniach klient powinien widzieć decyzje i działający kierunek, nie tylko obietnicę.
- Dni 1-2 służą zamknięciu problemu, danych i zakresu.
- Makieta sprawdza przepływ, zanim koszt trafi w pełny development.
- Pierwszy pionowy fragment powinien przejść od interfejsu do bazy.
- Nowe pomysły trafiają do backlogu zamiast rozszerzać tydzień bez końca.
„Czy po tygodniu zobaczę coś działającego?”
Klient słusznie chce szybko zobaczyć postęp. Jednocześnie zbyt wczesne kodowanie może utrwalić błędny model danych lub niejasny przepływ. Dobry pierwszy tydzień łączy krótką analizę z małym dowodem technicznym. Nie kończy się samą prezentacją slajdów, ale też nie obiecuje całego produktu w kilka dni.
Pierwszy tydzień ma zmniejszyć ryzyko całego projektu
Najważniejsze decyzje podjęte na początku dotyczą granic produktu. Kto jest pierwszym użytkownikiem? Co uruchamia proces? Gdzie powstają dane? Kto zatwierdza wynik? Co może pójść źle? Odpowiedzi kierują architekturą i pozwalają uniknąć budowy funkcji, które później trzeba usuwać.
Decyzje architektoniczne poprzedzają efektowny interfejs
W systemie dokumentacji hamulców kluczowe pytanie brzmiało: co stanie się z edycją, gdy tablet straci internet przy torze. Odpowiedź wymagała podejścia offline-first, lokalnej bazy w przeglądarce i kolejki synchronizacji. Traktowanie offline jako późniejszego dodatku zmieniłoby fundament aplikacji.
W ewidencji tras najważniejsza była decyzja, że centralna baza jest źródłem prawdy, a arkusz służy wyłącznie do eksportu. Obie decyzje powstały z procesu, nie z wyglądu ekranów.
Przykładowy plan siedmiu dni
Poniższy rytm jest przykładem, nie obietnicą identycznego harmonogramu dla każdego projektu. Przy gotowych materiałach może być szybszy. Przy regulacjach, trudnych danych lub braku dostępu do API analiza może potrwać dłużej.
| Dzień | Główny rezultat |
|---|---|
| 1 | problem, użytkownik, cel i miernik sukcesu |
| 2 | obecny proces, przykłady danych, role i wyjątki |
| 3 | zakres MVP oraz jawna lista elementów na później |
| 4 | makieta głównego przepływu i szybka akceptacja |
| 5 | model danych, integracje, bezpieczeństwo i plan wdrożenia |
| 6 | repozytorium, środowiska i pierwszy pionowy fragment |
| 7 | prezentacja działającego kierunku, feedback i plan kolejnej iteracji |
Czego potrzebujemy od klienta w pierwszym tygodniu
Szybki start wymaga jednej osoby decyzyjnej, dostępu do przyszłych użytkowników i przykładów danych. Klient nie musi pisać specyfikacji, ale powinien odpowiadać na pytania oraz sprawdzać makiety i wersję roboczą bez wielodniowych przerw.
- jedna osoba zatwierdzająca zakres i priorytety
- 2-3 prawdziwe przykłady dokumentów lub rekordów
- dostęp do osób wykonujących proces na co dzień
- informacje o wymaganych integracjach i właścicielach kont
- szybka odpowiedź na makiety oraz pytania o wyjątki
Przygotuj sześć odpowiedzi przed dniem pierwszym
Opisz problem, użytkownika, obecny proces, oczekiwany wynik, systemy i budżet. Dzięki temu pierwsze spotkanie może służyć wyborowi zakresu, a nie ogólnemu poznawaniu pomysłu. Po rozmowie powinieneś wiedzieć, co wchodzi do pierwszej wersji i jak będzie wyglądał pierwszy tydzień.
Pytania i odpowiedzi
Czy po siedmiu dniach MVP jest gotowe?
Zwykle nie. Typowy termin całego MVP wynosi 2–6 tygodni. Po pierwszym tygodniu powinien być jasny zakres, fundament i pierwszy działający fragment produktu.
Kiedy zaczyna się programowanie MVP?
Po potwierdzeniu głównego przepływu, danych i zakresu. W małym projekcie setup oraz pierwszy pionowy fragment mogą powstać jeszcze w pierwszym tygodniu.
Co może opóźnić pierwszy tydzień?
Brak osoby decyzyjnej, niedostępne dane, nieznane warunki API, niejasne wymagania regulacyjne oraz długie oczekiwanie na feedback.