Jak zaplanować MVP i nie przepalić budżetu

Jak zaplanować MVP, żeby nie przepalić budżetu? Zacznij od hipotezy, a nie od listy funkcji: jedno pytanie biznesowe, jeden proces, który działa od początku do końca, mierniki ustalone przed startem i z góry określony moment decyzji. Wszystko, co nie pomaga odpowiedzieć na to pytanie, wypada z pierwszej wersji. Poniżej opisuję, jak to rozpisać krok po kroku, co zwykle warto wyciąć, czego nie wolno, i co zrobić, gdy MVP już działa.

MVP (minimum viable product), czyli minimalna wersja produktu, ma jedno zadanie: tanio i szybko sprawdzić, czy pomysł działa w prawdziwym świecie. Budżet przepala się wtedy, gdy MVP zamienia się w pierwszy etap pełnego systemu, tylko z gorszą jakością.

Czym MVP jest, a czym nie jest

MVP to najmniejsza wersja, która pozwala prawdziwym użytkownikom wykonać prawdziwe zadanie i daje dane do decyzji. Nie jest to makieta do pokazania zarządowi ani okrojona kopia docelowego systemu.

Te trzy rzeczy często się mylą, a każda służy czemu innemu:

• prototyp sprawdza, czy użytkownik rozumie interfejs, i może w ogóle nie mieć zaplecza,
• proof of concept sprawdza, czy coś da się technicznie zrobić, na przykład czy dane z dwóch systemów da się połączyć,
• MVP sprawdza, czy ludzie z tego korzystają i czy to się opłaca.

Jeśli po rozmowie z zespołem nie umiesz powiedzieć, które z tych trzech pytań zadajesz, zatrzymaj się. To najtańszy moment na korektę.

Hipoteza: od czego zacząć planowanie MVP

Zaplanowanie MVP zaczyna się od jednego zdania, które da się potwierdzić albo obalić. Sprawdza się prosty szablon: wierzymy, że określona grupa użytkowników zrobi określoną rzecz, bo ma określony problem, a poznamy to po konkretnym mierniku w ustalonym czasie.

Weźmy jako przykład hurtownię, która przyjmuje zamówienia od stałych klientów mailem i telefonicznie. Pomysł to portal zamówień B2B. Hipoteza mogłaby brzmieć tak: stali klienci będą składać powtarzalne zamówienia sami przez portal, bo dziś czekają na potwierdzenie od handlowca. Poznamy to po tym, ilu zaproszonych klientów złoży przez portal drugie zamówienie w ciągu pierwszych tygodni.

Zwróć uwagę, że hipoteza nie mówi nic o wyszukiwarce, aplikacji mobilnej ani programie lojalnościowym. Te rzeczy mogą mieć sens później. Na razie pytamy tylko, czy klienci w ogóle zmienią nawyk.

Jeden proces od początku do końca

MVP powinno obsłużyć jeden proces w całości, a nie kilka procesów do połowy. Użytkownik musi przejść całą ścieżkę i dostać efekt, bo inaczej nie wiesz, czy porzucił proces przez pomysł, czy przez brakujący kawałek.

W przykładzie hurtowni taki proces to: logowanie, katalog z cenami danego klienta, koszyk, złożenie zamówienia, potwierdzenie. Zamówienie musi gdzieś trafić. W MVP nie musi to być od razu automatyczna integracja z ERP. Może to być mail do działu handlowego albo plik, który ktoś raz dziennie wczytuje do systemu.

To ważna zasada: część pracy może być ręczna za kulisami, dopóki użytkownik dostaje to, co obiecano. Ręczna obsługa kosztuje czas zespołu, ale jest tańsza niż integracja zbudowana dla pomysłu, który się nie sprawdzi. Gdy hipoteza się potwierdzi, ręczne kroki są pierwszymi kandydatami do automatyzacji, a o tym, kiedy automatyzacja procesów się opłaca, piszę osobno.

Co wyciąć z zakresu MVP, a czego nie ruszać

Wycinasz wszystko, co nie wpływa na odpowiedź na hipotezę, i zostawiasz to, co chroni ludzi i dane. Najczęściej z pierwszej wersji wypadają funkcje wygody i automatyzacje zaplecza.

Funkcja	W MVP	Co zamiast niej
Rozbudowany panel administracyjny	nie	proste zarządzanie przez zespół techniczny albo import z arkusza
Pełna integracja z ERP	zwykle nie	eksport i import plików albo przekazanie zamówienia mailem
Płatności online	zależy od procesu	faktura z terminem płatności, jeśli tak dziś płacą klienci
Aplikacja mobilna	nie	strona, która dobrze działa na telefonie
Rozbudowane role i uprawnienia	nie	jedna lub dwie role
Raporty i wykresy	nie	eksport danych i analiza w arkuszu

Są też rzeczy, których nie wycinam nigdy, bo ich brak kosztuje więcej niż oszczędność:

• bezpieczeństwo logowania, aktualne biblioteki i szyfrowane połączenie,
• zgodność z RODO, jeśli przetwarzasz dane osobowe,
• kopie zapasowe danych, które wprowadzają użytkownicy,
• pomiar, czyli zbieranie danych potrzebnych do mierników,
• jakość tego jednego procesu, który testujesz.

Ostatni punkt jest najczęściej łamany. Jeśli zamówienie przez portal raz na jakiś czas się gubi, klienci wrócą do maila i hipoteza upadnie z powodów, które nie mają nic wspólnego z pomysłem.

Mierniki: jak zaplanować MVP, żeby wynik coś znaczył

Mierniki ustalasz przed startem, razem z progiem, który uznasz za sukces, i datą, kiedy oceniasz wynik. Ustalone po fakcie zawsze da się dopasować do tego, co wyszło, i wtedy MVP niczego nie rozstrzyga.

Dobre mierniki dla MVP są nieliczne i dotyczą zachowania ludzi, a nie liczby funkcji. Wystarczą jeden główny i jeden lub dwa pomocnicze:

1. Miernik główny odpowiada wprost na hipotezę, w przykładzie: ilu klientów wraca i składa kolejne zamówienie przez portal.
2. Miernik kosztu pokazuje, ile pracy ręcznej wymaga obsługa jednego zamówienia.
3. Miernik jakości pokazuje liczbę błędów i zgłoszeń od użytkowników.

Potrzebny jest też punkt odniesienia. Jeśli nie wiesz, ile dziś trwa obsługa zamówienia mailowego, nie powiesz, czy portal coś poprawił. Zmierzenie stanu obecnego bywa najtańszą częścią całego projektu, a później nie da się go odtworzyć.

Budżet, czas i umowa na MVP

Na MVP najlepiej ustalić stały limit czasu i budżetu, a zakres traktować jako zmienny. Odwrotne podejście, czyli stały zakres i niepewny termin, prowadzi do tego, że MVP rośnie, bo każda funkcja wydaje się niezbędna.

W praktyce oznacza to kilka decyzji przed podpisaniem umowy:

• maksymalny budżet i data pierwszego udostępnienia użytkownikom,
• lista funkcji ułożona według ważności, z której wykonawca realizuje tyle, ile zmieści się w limicie,
• rezerwa na poprawki po pierwszym kontakcie z użytkownikami, bo zawsze są potrzebne,
• osoba po stronie firmy, która ma czas na decyzje co tydzień.

Taki układ dobrze pasuje do rozliczenia czasu pracy z limitem. Różnice między modelami umów opisałem w tekście fixed price czy time and materials, a składniki samej wyceny w artykule o tym, ile kosztuje system dedykowany. Przy wyborze wykonawcy zapytaj wprost, czy robił już MVP i co z niego wycinał. Więcej pytań do wykonawcy znajdziesz w poradniku jak wybrać software house.

Błędy, przez które MVP kosztuje za dużo

Większość przekroczeń budżetu bierze się z kilku powtarzalnych decyzji, a nie z pecha. Warto je znać, zanim zaplanowanie MVP trafi na spotkanie zarządu.

• Zbyt wielu odbiorców naraz: MVP dla klientów, handlowców i magazynu jednocześnie to trzy produkty, a nie jeden.
• Dopisywanie funkcji w trakcie: każda prośba brzmi rozsądnie, ale razem przesuwają termin pierwszego kontaktu z użytkownikami.
• Dopracowany wygląd przed sprawdzeniem pomysłu: czytelny interfejs jest potrzebny, dopieszczona grafika jeszcze nie.
• Brak właściciela po stronie firmy: gdy nikt nie ma czasu na cotygodniowe decyzje, wykonawca zgaduje, a zgadywanie kosztuje.
• Odkładanie startu do pełnej gotowości: MVP, które czeka, aż będzie kompletne, przestaje być MVP.

Jeśli zauważysz u siebie dwa z tych sygnałów, wróć do hipotezy i sprawdź, czy każda funkcja na liście nadal na nią odpowiada. Dobrze zaplanowane MVP to w dużej mierze sztuka odmawiania.

Co po MVP: trzy możliwe decyzje

Po okresie testu podejmujesz jedną z trzech decyzji: rozwijać, zmienić kierunek albo zamknąć. Każda jest dobrym wynikiem, jeśli zapada na podstawie mierników ustalonych na początku.

Rozwijać warto, gdy miernik główny przekroczył próg. Wtedy pierwszym krokiem nie są nowe funkcje, tylko uporządkowanie tego, co zrobiono na skróty: ręczne kroki do automatyzacji, kod pisany pod szybki test do przeglądu, architektura do sprawdzenia pod większy ruch. Jeśli MVP było budowane rozsądnie, ten etap jest krótki.

Zmienić kierunek trzeba, gdy użytkownicy korzystają, ale inaczej, niż zakładano. W przykładzie hurtowni klienci mogą używać portalu nie do zamawiania, tylko do sprawdzania stanów i cen. To też cenna informacja, bo wskazuje inny problem do rozwiązania.

Zamknąć projekt należy, gdy miernik główny jest daleko od progu, a rozmowy z użytkownikami nie wskazują łatwej poprawki. Zamknięcie MVP po kilku miesiącach kosztuje ułamek tego, co utrzymywanie systemu, z którego nikt nie korzysta.

Na start wystarczy jedna strona: hipoteza, opis procesu, lista funkcji z podziałem na w MVP i później, mierniki z progiem i datą oceny, limit budżetu. Z taką kartką wiesz, jak zaplanować MVP z wykonawcą, i łatwo porównasz oferty. Jeśli chcesz ją przygotować razem, zobacz, jak wygląda współpraca ze mną.