Kiedy firma chce zbudować oprogramowanie, w pierwszej rozmowie prawie zawsze padają trzy skróty: POC, prototyp i MVP. Bywają używane wymiennie, a to prosta droga do nieporozumienia. Każde z tych pojęć odpowiada na inne pytanie, powstaje na innym etapie i pochłania inny budżet.
Pomylenie ich ma realne skutki: źle oszacowany koszt, nierealny termin, rozjechane oczekiwania między zespołem a zarządem, czasem produkt, który nie odpowiada na żadne pytanie. Poniżej rozkładamy te trzy pojęcia na czynniki pierwsze i pokazujemy, dlaczego MVP z wersją beta ma niewiele wspólnego.
Skąd bierze się zamieszanie wokół tych pojęć
Wszystkie trzy pojęcia dotyczą wczesnych etapów pracy nad produktem, dlatego łatwo je pomieszać. Problem zaczyna się, gdy jedno słowo w głowach dwóch osób oznacza coś zupełnie innego.
Zarząd słyszy „zrobimy MVP” i widzi tańszą, niedokończoną wersję docelowej aplikacji. Zespół produktowy ma na myśli najmniejszy produkt, który realnie działa i można go oddać użytkownikom. Dwie osoby, jedno słowo, dwa różne budżety i dwa różne terminy. Zanim padnie pierwsza wycena, warto ustalić, o którym z trzech artefaktów mowa.
POC, czyli sprawdzenie, czy to w ogóle zadziała
POC (proof of concept) odpowiada na jedno pytanie: czy zakładane rozwiązanie da się w ogóle zbudować w wybranej technologii. POC pomija wygląd i pytanie o to, czy użytkownicy zechcą produktu. Sprawdza wyłącznie techniczną wykonalność.
Przykłady sytuacji, w których POC ma sens:
- Czy zintegrujemy system ERP z API kuriera tak, aby statusy przesyłek aktualizowały się w czasie rzeczywistym.
- Czy model uczenia maszynowego rozpozna typ dokumentu z dokładnością, która wystarczy do automatyzacji.
- Czy dana biblioteka udźwignie przetwarzanie plików o rozmiarze, który zakłada projekt.
Efektem POC jest zwykle skrypt albo fragment kodu, który po udzieleniu odpowiedzi ląduje w koszu. To materiał wewnętrzny, przeznaczony dla zespołu. POC robimy wtedy, gdy w projekcie tkwi konkretne ryzyko techniczne. Jeśli takiego ryzyka nie ma, ten krok można pominąć.
Prototyp, czyli jak to będzie wyglądać i działać dla użytkownika
Prototyp odpowiada na inne pytanie: jak użytkownik przejdzie przez produkt, czy ścieżka ma sens i czy interfejs komunikuje to, co powinien. Prototyp pokazuje, jak coś będzie wyglądać i jak się klika, zanim powstanie kosztowny kod.
Warstwa pod spodem prototypu nic nie robi. Dane są udawane, przyciski prowadzą do kolejnych zaprojektowanych ekranów, a całość służy do rozmowy i testów. Dzięki temu można wychwycić błędy w logice ekranów i zebrać opinie, zanim programiści napiszą pierwszą linijkę produkcyjnego kodu.
Poziomy dokładności prototypu
Low-fidelity: szkice na papierze lub proste wireframe’y. Skupiają się na układzie i przepływie, bez kolorów i szczegółów. Powstają w kilka godzin i świetnie nadają się do szybkiego odrzucania słabych pomysłów.
High-fidelity: klikalny projekt w Figmie lub podobnym narzędziu, z realnym wyglądem i interakcjami. Ten etap jest u nas częścią prac nad projektowaniem i UX, bo pozwala przetestować produkt z użytkownikami niemal tak, jakby był gotowy.
Kluczowa cecha prototypu jest taka, że to narzędzie do komunikacji i walidacji. Jeśli zawiera kod, ten kod jest jednorazowy.
MVP, czyli najmniejszy produkt, który realnie działa
MVP (minimum viable product) odpowiada na pytanie rynkowe: czy ludzie zechcą korzystać z podstawowej wartości produktu, a często również za nią zapłacić. Odpowiedź przychodzi w postaci działającego produktu, którego używają prawdziwi użytkownicy na prawdziwych danych.
Najważniejsze słowo to „viable”, czyli zdolny do działania. MVP działa na produkcji, opiera się na realnym kodzie i można go dalej rozwijać. Ma wąski zakres przy pełnej jakości wykonania. Jeden podstawowy scenariusz dopracowany porządnie daje więcej niż dziesięć funkcji zrobionych połowicznie. Najczęściej budujemy takie MVP jako aplikacje webowe lub aplikacje mobilne.
Czego MVP nie jest:
- Prototypem z udawanymi danymi podanym realnym użytkownikom jako produkt.
- Skryptem POC dorobionym naprędce do interfejsu.
- Pełną, docelową aplikacją, z której na siłę wycięto połowę funkcji tuż przed terminem.
Dlaczego MVP i wersja beta to dwie różne rzeczy
Skoro MVP działa na produkcji i trafia do użytkowników, łatwo pomylić go z wersją beta. Różnica leży w zakresie, etapie i celu.
Wersja beta to etap produktu, który ma już niemal pełny docelowy zakres. Udostępnia się ją ograniczonej grupie, żeby wyłapać błędy i zebrać opinie tuż przed publiczną premierą. Zakres jest szeroki, moment jest późny, a pytanie brzmi: czy gotowa rzecz działa poprawnie.
MVP to pierwsza, celowo wąska wersja produktu. Jej zadaniem jest sprawdzenie podstawowej hipotezy. Zakres jest wąski, moment jest wczesny, a pytanie brzmi: czy ten produkt w ogóle powinien powstać w większej skali. Beta testuje jakość skończonej całości, MVP testuje sens pomysłu w jego najmniejszej użytecznej formie.
POC, prototyp i MVP w jednym zestawieniu
Poniższa tabela porządkuje trzy pojęcia według tego, co dla każdego z nich najważniejsze.
| Aspekt | POC | Prototyp | MVP |
|---|---|---|---|
| Na jakie pytanie odpowiada | Czy da się to zbudować w tej technologii | Jak to będzie wyglądać i działać dla użytkownika | Czy ludzie zechcą z tego korzystać i za to zapłacić |
| Forma | Skrypt, spike, kod jednorazowy | Od szkicu po klikalny projekt w Figmie | Działający produkt na realnym kodzie |
| Odbiorca | Zespół i osoby techniczne | Zespół, interesariusze, użytkownicy testowi | Pierwsi realni użytkownicy i klienci |
| Trafia do użytkowników | Nie | Do testów, w kontrolowany sposób | Tak, na produkcji |
| Kod produkcyjny | Nie, kod jest jednorazowy | Zwykle brak | Tak, rozwijany dalej |
| Typowy czas | Kilka dni do 2-3 tygodni | Kilka dni do kilku tygodni | Kilka tygodni do kilku miesięcy |
Jak dobrać właściwy krok do swojego projektu
Nie każdy projekt potrzebuje wszystkich trzech etapów. Wybór zależy od tego, gdzie leży największa niepewność.
- Ryzyko techniczne: zacznij od POC.
- Niepewność co do ścieżki użytkownika lub zakresu: zrób prototyp.
- Pomysł potwierdzony technicznie i na papierze: buduj MVP.
W wielu projektach kolejność wygląda tak: POC, jeśli jest potrzebny, następnie prototyp, a na końcu MVP. Część zespołów pomija POC, bo nie ma ryzyka technicznego, i przechodzi od prototypu prosto do MVP. Ważne jest, żeby każdy krok odpowiadał na pytanie, które faktycznie blokuje decyzję.
Najczęstsze błędy przy MVP
- Nazywanie prototypu MVP i oddanie realnym użytkownikom produktu z udawanymi danymi.
- Rozdmuchanie zakresu MVP do rozmiarów pełnego produktu, przez co walidacja przychodzi za późno i za drogo.
- Pominięcie walidacji i przejście od razu do pełnej budowy, bez sprawdzenia hipotezy.
- Traktowanie MVP jako produktu niskiej jakości, co kończy się wnioskami wyciągniętymi z danych zebranych na zepsutym produkcie.
Najczęstsze pytania
Czy każdy projekt potrzebuje POC?
Nie. POC ma sens tylko wtedy, gdy w projekcie tkwi konkretne ryzyko techniczne. Jeśli technologia jest sprawdzona, ten krok można pominąć i przejść do prototypu lub MVP.
Ile kosztuje MVP?
Koszt zależy od zakresu podstawowej hipotezy, którą chcesz sprawdzić. Cała sztuka polega na utrzymaniu wąskiego zakresu. Wtedy budżet finansuje walidację hipotezy, zamiast funkcji, których nikt jeszcze nie potwierdził.
Czy MVP można rozwijać dalej?
Tak i na tym polega jego sens. MVP powstaje na realnym kodzie, więc po potwierdzeniu hipotezy rozwija się go w pełny produkt, zamiast pisać wszystko od nowa.
Prototyp czy od razu MVP?
Jeśli ścieżka użytkownika lub zakres funkcji są niepewne, zacznij od prototypu. Prototyp jest tańszy i szybszy, a pozwala poprawić projekt zanim wejdzie w grę kosztowny kod produkcyjny.
Od czego zacząć w Devhound
W Devhound zaczynamy od nazwania pytania, na które faktycznie potrzebujesz odpowiedzi. Dopiero potem dobieramy narzędzie: POC do ryzyka technicznego, prototyp do ścieżki i zakresu, MVP do sprawdzenia produktu na rynku. Dzięki temu budżet finansuje walidację, zamiast zgadywania.
Jeśli planujesz projekt i chcesz ustalić, który z tych kroków ma u Ciebie sens, napisz do nas. Przejdziemy przez Twój pomysł i wskażemy najkrótszą drogę do sprawdzenia go w praktyce.
