Prototyp, MVP czy większy produkt — co zbudować na obecnym etapie?

Masz pomysł na aplikację, SaaS, marketplace albo portal. Lista funkcji rośnie, ale nadal nie wiadomo, co powinno powstać jako pierwsze.

Jedna osoba proponuje prototyp. Druga mówi, że bez MVP niczego nie sprawdzisz. Trzecia chce od razu zbudować większy produkt, żeby za kilka miesięcy nie zaczynać od nowa.

Wybór nie powinien zaczynać się od nazwy wariantu. Najpierw ustal:

Jeżeli potrzebujesz zobaczyć i pokazać jeden scenariusz, właściwym zakresem może być prototyp. Jeżeli użytkownik ma wykonać prawdziwe zadanie w działającym środowisku, bliżej Ci do MVP. Jeżeli od początku musi współpracować kilka ról, procesów i integracji, potrzebny może być większy produkt.

Ten artykuł pomoże Ci wybrać między trzema wariantami używanymi w ofercie DaVinci: prototypem, MVP i większym produktem. Nie zastępuje analizy konkretnego projektu. Daje ramę, dzięki której łatwiej odróżnić funkcję potrzebną teraz od funkcji, którą można świadomie odłożyć.

Nie pytaj najpierw „co zbudować”, tylko „co ma się wydarzyć”

Lista funkcji nie mówi jeszcze, jaki produkt jest potrzebny. Dwa projekty z logowaniem, panelem i płatnościami mogą mieć zupełnie inne cele.

W pierwszym przypadku założyciel chce pokazać inwestorowi lub przyszłemu klientowi, jak będzie działał najważniejszy przepływ. Nie potrzebuje jeszcze obsługi prawdziwych płatności, odzyskiwania hasła ani pełnego panelu administracyjnego. Potrzebuje wiarygodnego demonstratora i odpowiedzi na konkretne pytania.

W drugim przypadku firma ma pierwszych użytkowników gotowych pracować na systemie. Musi przechowywać dane, kontrolować dostęp i obsłużyć pełny scenariusz. Sam ekran wyglądający jak produkt nie wystarczy.

Dlatego przed rozmową o technologii nazwij zdarzenie, które ma nastąpić po zbudowaniu wersji:

• osoba decyzyjna ma zobaczyć i zrozumieć sposób działania;
• użytkownik ma przejść jeden scenariusz i przekazać informację zwrotną;
• pierwszy klient ma móc użyć produktu w uzgodnionym zakresie;
• firma ma uruchomić obsługę kilku ról albo procesów;
• zespół ma zebrać dane potrzebne do następnej decyzji.

To nadal nie gwarantuje popytu, przychodu ani poprawności pomysłu. Pozwala jednak zbudować wersję, której zakres odpowiada temu, czego firma chce się dowiedzieć albo co chce uruchomić.

Czym różni się prototyp, MVP i większy produkt

Prototyp: sprawdza koncepcję lub pokazuje przepływ

Prototyp to model produktu. Może mieć formę klikalnych ekranów, demonstratora technicznego albo małego narzędzia obejmującego jeden scenariusz. Jego szczegółowość zależy od pytania, na które ma odpowiedzieć.

Prototyp pasuje do obecnego etapu, gdy:

• chcesz pokazać sposób działania bez budowania całego zaplecza;
• największa niewiadoma dotyczy przepływu, interfejsu albo jednej funkcji;
• rozmowa na podstawie opisu nie wystarcza i potrzebny jest działający przykład;
• nie ma jeszcze podstaw, żeby projektować pełny system ról, płatności i integracji;
• małe narzędzie może rozwiązać jeden zamknięty problem bez szerszej platformy.

Trzeba jawnie opisać jego granice. Prototyp może wyglądać przekonująco, ale nie musi być gotowy do obsługi prawdziwych danych, obciążenia, płatności czy wymagań bezpieczeństwa. Osoba oglądająca wersję powinna wiedzieć, co działa naprawdę, a co jest symulacją.

W aktualnej ofercie DaVinci prototyp albo małe narzędzie zaczyna się od 5 000 PLN netto. Cena dotyczy ustalonego zakresu, jednego głównego scenariusza i wersji gotowej do pokazania lub testu.

MVP: pozwala wykonać pełne zadanie

MVP jest pierwszą działającą wersją produktu o świadomie ograniczonym zakresie. Litera „M” nie oznacza zbioru niedokończonych funkcji. Litera „V” wymaga, żeby wersja była użyteczna dla wybranego użytkownika w wybranym scenariuszu.

MVP pasuje, gdy:

• znasz użytkownika, problem i główną pracę do wykonania;
• użytkownik ma przejść proces od początku do końca;
• produkt ma działać w środowisku produkcyjnym;
• potrzebne są konta, role, dane, płatności albo konkretne integracje;
• po uruchomieniu chcesz zbierać informacje z prawdziwego użycia;
• firma ma osobę, która regularnie podejmuje decyzje o zakresie.

Dobre MVP nie próbuje być małą wersją każdego elementu z wizji. Może obsługiwać jeden typ klienta, jeden model rozliczenia i jeden główny przepływ. Pozostałe role, automatyzacje oraz wyjątki trafiają do dalszego rozwoju, jeżeli nie są potrzebne do wykonania głównego zadania.

W aktualnej ofercie DaVinci cena MVP wynosi 15 000–35 000 PLN netto. Obejmuje pierwszą wersję produkcyjną, potrzebne role i integracje, testy, wdrożenie oraz przekazanie w uzgodnionym zakresie.

Większy produkt: łączy kilka niezbędnych procesów

„Większy produkt” nie jest jedną uniwersalną kategorią rynkową. W tym artykule oznacza wariant z oferty DaVinci: rozwiązanie z indywidualną architekturą, większą liczbą ról lub procesów i etapową realizacją.

Taki wariant pasuje, gdy:

• kilka grup użytkowników musi współpracować od pierwszego uruchomienia;
• produkt obsługuje więcej niż jeden główny proces;
• dane pochodzą z kilku systemów i wymagają wspólnej logiki;
• uprawnienia, historia zmian albo wymagania techniczne nie są dodatkiem;
• firma zna proces, ma właściciela decyzji i potrafi odbierać etapy;
• odcięcie jednego z elementów przerwałoby podstawowy model działania.

W aktualnej ofercie DaVinci większy produkt zaczyna się od 35 000 PLN netto. Końcowa wycena zależy od uzgodnionego zakresu, ról, integracji, ryzyk i wymagań technicznych.

Tabela decyzji: który wariant pasuje do obecnego etapu

Nie wybieraj wariantu przez mechaniczne liczenie zaznaczeń. Jedno wymaganie może zmienić decyzję. Uprawnień do wrażliwych danych nie można odłożyć, gdy są warunkiem bezpiecznego użycia. Płatność może być symulacją w demonstratorze, lecz częścią produkcyjnego MVP, gdy należy do głównego scenariusza.

Pięć pytań, które ustalają właściwy zakres

1. Kto ma użyć tej wersji?

Nie odpowiadaj „wszyscy klienci”. Wskaż jedną grupę i konkretną sytuację.

Przykład: właściciel salonu chce dodać usługę, ustawić wolne terminy i przyjąć rezerwację. Taki opis pozwala ustalić przepływ. „Platforma dla branży usługowej” nadal jest zbyt szeroka.

2. Jakie jedno zadanie ma wykonać od początku do końca?

Pełny scenariusz ma zdarzenie początkowe, kroki, wynik i obsługę podstawowego błędu. Dla produktu subskrypcyjnego może to być: użytkownik zakłada konto, wybiera plan, płaci i otrzymuje dostęp.

Jeżeli nie da się wskazać jednego zadania, projekt może jeszcze potrzebować prototypu albo uporządkowania założeń.

3. Jaka następna decyzja zależy od tej wersji?

Produkt może mieć odblokować decyzję o:

• zmianie przepływu;
• rozpoczęciu wdrożenia produkcyjnego;
• wyborze modelu płatności;
• rozszerzeniu na kolejną grupę;
• inwestycji w dalszy zakres;
• zatrzymaniu projektu albo zmianie kierunku.

Nie każda decyzja wymaga kodu produkcyjnego. Nie każdą da się też podjąć na podstawie samej makiety.

4. Co musi być prawdziwe, a co może być symulacją?

W prototypie powiadomienie może pojawić się na ekranie bez rzeczywistej wysyłki. W MVP obsługującym klienta wiadomość może być częścią niezbędnego procesu. W produkcie finansowym lub prawnym dane, dostęp i historia działań mogą wymagać osobnego potraktowania już w pierwszym zakresie.

Zapisz te różnice przed wyceną. Inaczej dwie oferty o podobnym opisie mogą dotyczyć zupełnie innego rezultatu.

5. Kto podejmuje decyzje i odbiera wynik?

Brak właściciela produktu zwiększa zakres po cichu. Sprzedaż dopisuje funkcje dla potencjalnych klientów, operacje dla zespołu, a zarząd dla raportowania. Nikt nie rozstrzyga konfliktu.

Jedna osoba powinna odpowiadać za priorytet, akceptację granic i odbiór. Nie musi samodzielnie projektować rozwiązania. Musi jednak móc powiedzieć „to jest potrzebne teraz”, „to odkładamy” oraz „ten scenariusz spełnia kryterium”.

Cztery scenariusze wyboru

Poniższe scenariusze są przykładami modelowymi. Nie opisują wyników klientów DaVinci.

Scenariusz 1: SaaS pokazany przyszłym klientom

Założyciel zna problem i chce przeprowadzić rozmowy na podstawie konkretnego przepływu. Nie ma jeszcze użytkowników gotowych wprowadzać prawdziwe dane. Największą niewiadomą jest sposób wykonania zadania.

Właściwy punkt startu: prototyp.

Zakres może objąć ekran startowy, główny proces, wynik i podstawowe stany błędu. Pełne logowanie, rozliczenia, administracja oraz integracje mogą zostać zasymulowane, jeśli nie są przedmiotem testu.

Scenariusz 2: pierwsza wersja narzędzia dla jednej grupy

Firma ma określonych użytkowników i jeden proces, który chcą wykonać w systemie. Potrzebne są konta, zapis danych oraz panel z wynikiem. Firma potrafi ograniczyć pierwszą wersję do jednego typu użytkownika.

Właściwy punkt startu: MVP.

Zakres powinien objąć pełne zadanie, potrzebne uprawnienia, zapis danych, testy i wdrożenie. Rozbudowane raporty, drugi segment oraz dodatkowe automatyzacje można odłożyć, jeśli nie blokują głównego scenariusza.

Scenariusz 3: marketplace z dwiema stronami transakcji

Produkt musi połączyć kupującego, sprzedającego i operatora. Potrzebne są różne konta, publikacja oferty, wyszukiwanie, transakcja, status oraz obsługa sytuacji, w której jedna strona nie wykona kroku.

Właściwy punkt startu: MVP albo większy produkt, zależnie od liczby niezbędnych procesów.

Prototyp może pomóc sprawdzić doświadczenie obu stron, ale nie potwierdzi działania transakcji. MVP jest możliwe, jeżeli firma ograniczy kategorię, sposób rozliczenia i obsługiwany scenariusz. Większy produkt ma sens, gdy od startu trzeba obsłużyć kilka modeli transakcji, złożone role i integracje, których nie można świadomie odłożyć.

Scenariusz 4: portal dla klientów istniejącej firmy

Firma zna proces, dane i role, bo obsługuje je dziś ręcznie. Klient ma widzieć status, pracownik aktualizować realizację, a osoba zarządzająca zatwierdzać wyjątki. Portal ma pobierać dane z używanych systemów.

Właściwy punkt startu: większy produkt, jeśli wszystkie role i integracje są potrzebne do działania procesu.

Jeżeli pierwszą wersję można ograniczyć do podglądu statusu dla jednej grupy, MVP może być wystarczające. Decyzja zależy od tego, czy pozostałe role są częścią podstawowego przepływu, czy dalszym etapem.

Jak odciąć funkcje, które nie są potrzebne w pierwszej wersji

Najprostsza lista priorytetów ma trzy kolumny:

Dla każdej funkcji dopisz użytkownika, zdarzenie początkowe i oczekiwany wynik. „Panel administracyjny” jest nazwą obszaru. „Administrator blokuje konto, a użytkownik traci dostęp i otrzymuje informację” jest scenariuszem możliwym do wyceny i odbioru.

Zwróć uwagę na funkcje, które wyglądają jak dodatki, ale mogą być warunkiem użycia:

• uprawnienia do danych;
• zgody i wymagane informacje;
• obsługa płatności oraz zwrotów;
• podstawowa administracja;
• import albo eksport danych;
• reakcja na błąd integracji;
• historia ważnych działań.

Nie każdy produkt potrzebuje ich wszystkich. Trzeba sprawdzić je względem realnego scenariusza, a nie kopiować listę z innej aplikacji.

Kryteria odbioru dla każdego wariantu

Nazwa wariantu nie jest kryterium odbioru. „Zrobimy MVP” nie mówi, co klient otrzyma i po czym pozna, że zakres został wykonany.

Kryteria prototypu

Przykładowe kryteria:

• odbiorca może przejść uzgodniony przepływ;
• wszystkie ekrany potrzebne do testu są dostępne;
• miejsca symulowane są jawnie oznaczone;
• prototyp działa na ustalonych urządzeniach;
• zespół ma scenariusz prezentacji albo badania;
• wiadomo, które wnioski wpłyną na następny zakres.

Kryteria MVP

Przykładowe kryteria:

• wybrany użytkownik może wykonać główne zadanie od początku do końca;
• role widzą i zmieniają wyłącznie uzgodniony zakres danych;
• potrzebne integracje przechodzą opisane scenariusze;
• podstawowe błędy nie pozostawiają użytkownika bez informacji;
• produkt jest wdrożony w uzgodnionym środowisku;
• przekazanie obejmuje ustalone prawa, kod, konta, dane i dokumentację.

Kryteria większego produktu

Przykładowe kryteria:

• każda rola przechodzi swoje scenariusze oraz przekazania między procesami;
• zakres jest podzielony na etapy z osobnym odbiorem;
• zależności między modułami i integracjami są opisane;
• uprawnienia, historia zmian i obsługa wyjątków odpowiadają wymaganiom;
• odpowiedzialność za środowisko, utrzymanie i dalszy rozwój jest ustalona;
• firma ma jedną listę elementów odebranych, odłożonych i wyłączonych.

Kryteria trzeba dopasować do produktu. Nie są gwarancją popytu ani wyniku biznesowego. Chronią obie strony przed sytuacją, w której ten sam opis zakresu oznacza dwie różne rzeczy.

Błędy, przez które zakres rośnie bez końca

1. Nazywanie każdej pierwszej wersji MVP

Prototyp, demonstrator i działający produkt mają inne wymagania. Jeżeli nie wiadomo, czy wersja ma obsługiwać prawdziwych użytkowników, wykonawcy mogą wycenić różne rezultaty pod tą samą nazwą.

2. Zaczynanie od listy ekranów

Ekran nie pokazuje reguł, danych, wyjątków ani odpowiedzialności. Zacznij od scenariusza użytkownika. Ekrany wynikną z jego kroków.

3. Budowanie po jednej funkcji z całej wizji

Pięć niedokończonych procesów nie tworzy użytecznej pierwszej wersji. Lepiej domknąć jeden przepływ niż zbudować początek każdego modułu.

4. Traktowanie przyszłego rozwoju jako argumentu za budową wszystkiego teraz

Kod można przygotować do rozwoju bez implementowania każdej przewidywanej funkcji. Architektura powinna uwzględniać znane wymagania, ale zakres wykonania nadal może być wąski.

5. Pomijanie właściciela decyzji

Jeżeli każda osoba może dopisać funkcję, a nikt nie może jej odrzucić, stała cena i harmonogram tracą podstawę. Zmiana zakresu wymaga jawnej decyzji o wpływie na koszt i plan.

6. Mylenie demonstracji z produkcją

Klikalny prototyp może dobrze pokazywać pomysł. Nie oznacza to, że ma gotową bazę danych, zabezpieczenia, monitoring, obsługę błędów i skalowanie. Granica powinna być opisana przed prezentacją.

7. Oczekiwanie, że samo MVP potwierdzi popyt

Działający produkt daje możliwość obserwowania użycia i zbierania informacji. Nie gwarantuje, że rynek go kupi. Jeżeli największa niewiadoma dotyczy samej potrzeby lub gotowości do zapłaty, przed budową albo równolegle może być potrzebny osobny test rynku.

Jak przygotować projekt do wyceny

Nie potrzebujesz kompletnej dokumentacji technicznej. Przygotuj jedną stronę odpowiedzi:

1. Dla kogo jest produkt?
2. Jaki problem lub zadanie obsługuje?
3. Co ma zrobić użytkownik od początku do końca?
4. Jaką decyzję ma odblokować pierwsza wersja?
5. Które dane są prawdziwe, a które mogą być testowe?
6. Jakie role muszą działać od początku?
7. Jakie integracje są konieczne do głównego scenariusza?
8. Co świadomie nie wchodzi do pierwszej wersji?
9. Kto podejmuje decyzje o zakresie?
10. Po jakich scenariuszach odbierzesz rezultat?

Jeżeli te odpowiedzi są wystarczająco konkretne, można przejść do projektowania i wyceny. Jeżeli najważniejsze założenia nadal zmieniają się przy każdej rozmowie, opcjonalna analiza i specyfikacja mogą uporządkować przepływ, ryzyka, kryteria odbioru i koszt budowy.

W DaVinci taka analiza kosztuje 2 500 PLN netto. Kwota jest odliczana od budowy rozpoczętej w ciągu 30 dni. Analiza nie jest obowiązkowa przed każdym projektem. Gdy użytkownik, problem, zakres i kryteria są gotowe, można przejść bezpośrednio do wyceny.

Wybierz najmniejszy zakres, który odblokuje prawdziwą decyzję

Prototyp, MVP i większy produkt nie tworzą drabiny jakości. Nie trzeba przechodzić przez każdy wariant.

Jeżeli najważniejsze pytanie dotyczy koncepcji albo przepływu, zacznij od prototypu. Jeżeli znasz użytkownika i chcesz uruchomić pełne zadanie, wybierz MVP. Jeżeli podstawowy model od początku wymaga kilku ról, procesów i integracji, zaplanuj większy produkt etapami.

Dobry zakres:

• ma jednego właściciela decyzji;
• opisuje użytkownika i pełny scenariusz;
• oddziela elementy prawdziwe od symulowanych;
• wskazuje funkcje świadomie odłożone;
• ma kryteria odbioru;
• nie obiecuje wyniku, którego sama budowa nie może zagwarantować.

Jeżeli masz pomysł, ale nie wiesz, który wariant odpowiada obecnemu etapowi, podczas bezpłatnej 30-minutowej rozmowy sprawdzimy użytkownika, cel, główny przepływ, ryzyka i stan przygotowania. Wynikiem rozmowy może być brak dopasowania, rekomendacja analizy albo przejście do wyceny uzgodnionego zakresu.