MVP aplikacji w cztery tygodnie: jak to wygląda w praktyce

Dlaczego MVP, a nie od razu pełny system

Firmy, które zamawiają od razu „pełny system ze wszystkimi funkcjami”, najczęściej dostają go po 6-9 miesiącach — i wtedy okazuje się, że część założeń z briefu była nieaktualna, bo firma w tym czasie zmieniła proces. MVP odwraca tę logikę: najpierw najmniejsza wersja, która realnie działa na produkcji, potem rozwój na podstawie tego, jak jest używana.

To podejście sprawdza się szczególnie tam, gdzie proces nie jest w 100% ustandaryzowany — czyli w większości średnich firm produkcyjnych, usługowych i handlowych. Zamiast zgadywać wszystkie wyjątki na starcie, wyjątki odkrywa się na realnych danych i dodaje do aplikacji tam, gdzie faktycznie występują.

Tydzień 1 — warsztat i mapa procesu

Rozmawiamy z ludźmi, którzy wykonują pracę, nie tylko z zarządem. Powstaje mapa procesu z zaznaczonymi miejscami, w których traci się czas, oraz lista danych, które muszą krążyć między działami.

W firmie serwisującej sprzęt gastronomiczny ten etap ujawnił, że zgłoszenia serwisowe wpływały trzema różnymi kanałami (telefon, mail, WhatsApp), a każdy technik prowadził własną notatkę w telefonie. Bez tej wiedzy MVP zostałoby zaprojektowane wokół jednego kanału, który w praktyce odpowiadał za mniej niż połowę zgłoszeń.

Tydzień 2 — klikalny prototyp

Zanim powstanie kod produkcyjny, dostajesz interfejs, po którym da się klikać. Zespół ocenia go na własnych przykładach — poprawka na tym etapie kosztuje minuty zamiast dni.

To moment, w którym najczęściej wychodzą braki w założeniach: brakujący status zamówienia, pole, którego nikt nie wspomniał na warsztacie, albo raport, bez którego kierownik zmiany nie jest w stanie podjąć decyzji. Prototyp kosztuje ułamek ceny gotowej aplikacji, więc to najtańszy moment na błędy.

Tydzień 3 — rdzeń aplikacji

Budujemy najważniejszy przepływ end-to-end: dodanie rekordu, obsługa, zamknięcie, raport. Bez modułów „na wszelki wypadek”.

W praktyce oznacza to świadome odłożenie na później funkcji, które wydają się ważne, ale nie są krytyczne dla pierwszego użycia — np. zaawansowane filtry w raportach czy integrację z drugorzędnym systemem. Liczy się, żeby rdzeń działał bezbłędnie na prawdziwych danych, zanim doda się dekoracje.

• Jeden pełny przepływ, nie dziesięć niepełnych
• Dane testowe zastąpione realnymi przykładami z firmy
• Podstawowe uprawnienia: kto widzi, kto edytuje, kto zatwierdza

Tydzień 4 — realne dane i start

Import danych, uprawnienia, krótkie szkolenie i praca pilotażowa na jednym zespole. Dopiero po pilotażu rozszerzamy zakres — już na podstawie tego, jak aplikacja jest używana.

Pilotaż na jednym zespole albo jednym oddziale ma kluczowe znaczenie: pozwala złapać problemy przy niskim ryzyku, zanim system trafi do wszystkich lokalizacji. W sieci sklepów z artykułami budowlanymi pilotaż na jednym oddziale ujawnił, że raport zamknięcia dnia musi uwzględniać różnicę w godzinach pracy kas — czego nie było widać na etapie warsztatu.

Co dzieje się po pierwszym miesiącu

MVP to początek, nie koniec projektu. Po pilotażu następuje faza iteracji: dodawane są funkcje, na które faktycznie jest zapotrzebowanie, a nie te, które wydawały się istotne na etapie planowania. Zwykle w ciągu kolejnych 2-3 miesięcy aplikacja rozszerza się na pozostałe zespoły i zyskuje dodatkowe integracje.

Ważne jest, żeby te iteracje planować w krótkich cyklach — dwutygodniowych lub miesięcznych — z jasną listą priorytetów ustaloną razem z zespołem, który z aplikacji korzysta na co dzień. To oni najlepiej wiedzą, co blokuje ich pracę.

Najczęstsze błędy

Zanim zaczniesz projekt, warto poznać pułapki, w które regularnie wpadają inne firmy — unikniesz ich taniej niż ktoś, kto uczy się na własnych błędach.

• Próba zmieszczenia w MVP wszystkich funkcji, które kiedykolwiek mogą się przydać, zamiast jednego pełnego przepływu.
• Pominięcie warsztatu z osobami wykonującymi pracę na rzecz rozmów wyłącznie z kierownictwem.
• Uruchomienie na wszystkich zespołach naraz, bez pilotażu na jednej grupie.

Co zrobić w tym tygodniu — checklista

Nie trzeba czekać na duży projekt, żeby zacząć porządkować temat. Poniższe kroki da się wykonać bez angażowania budżetu.

• Wybierz jeden proces i jeden zespół pilotażowy przed startem.
• Zapisz maksymalnie 5 funkcji, bez których MVP nie ma sensu — resztę odłóż.
• Zaplanuj klikalny prototyp przed pierwszą linijką kodu produkcyjnego.
• Ustal z góry, po jakich 2-3 wskaźnikach ocenisz sukces pilotażu.

Przykład liczbowy z praktyki

Firma serwisowa uruchomiła MVP do rejestrowania zgłoszeń w 4 tygodnie, ograniczone do jednego kanału zgłoszeń i trzech statusów. Pilotaż objął 4 techników. Po miesiącu średni czas obsługi zgłoszenia spadł z 3,1 dnia do 1,4 dnia, co przy 120 zgłoszeniach miesięcznie oznaczało wyraźnie szybszą rotację zleceń i mniej telefonów z pytaniem o status.