MVP oznacza minimum viable product. Produkt MVP posiada najbardziej istotne dla produktu funkcjonalności, które są następnie testowane na rynku, aby sprawdzić czy może odnieść sukces.

Aby przeprowadzić wstępne testy, produkt potrzebuje tylko najbardziej niezbędnych funkcji. Wersja produktu MVP jest najbardziej rozsądnym narzędziem, zarówno pod względem czasu, jak i pieniędzy, pomagającym określić potencjał produktu. Metodę MVP można wykorzystać do opracowania dowolnego produktu, w tym aplikacji mobilnych i stron internetowych.

Wiele utalentowanych ludzi wywarło wpływ na koncepcję MVP. Ale najbardziej znany był autor metodologii "Lean Startup" Eric Ries. Zdefiniował MVP jako: MVP to taka wersja produktu, która pozwala zespołowi zebrać maksymalną ilość potwierdzonej wiedzy o klientach przy najmniejszym wysiłku. Ogólnie rzecz biorąc, celem tego produktu jest sprawdzenie popytu. Reakcja rynku określa, czy zainspirujesz się do rozszerzenia działalności, czy po prostu przestaniesz.

Jak widać z powyższej wypowiedz, MVP oferuje wiele przy niskim koszcie, jednak nie jest pozbawione ryzyka. Wystarczy niepoprawnie dobrać zakres funkcjonalności które mają pojawić się w MVP aby zainteresowanie odbiorców było za małe a tym samym nie potwierdziło naszy hipotez, z kolei umieszczenie zbyt dużej liczby funkcjonalności może wywindować koszty, a w razie porażki w potwierdzeniu idei produktu tracimy zainwestowany wkład.

Jak MVP współpracuje z projektami IT?

Idealne jest przetestowanie swojego pomysłu, zanim wydasz dużo pieniędzy. Obecnie programowanie oferuje wiele frameworków i bibliotek, co znacznie przyspiesza czas programowania i zmniejsza koszty.

1. Przygotowanie

Etap polega na zebraniu informacji dotyczących projektu, jego celów oraz idei. Podczas tego etapu powinny zapaść decyzje dotyczące tego co robić w MVP a co zostawić na później, kiedy już pomysł będzie zwalidowany. Do tego kroku trzeba podejść bardzo restrykcyjnie gdyż od niego zależy ilość pracy jaką włożymy w projekt w późniejszych krokach. Dorzucanie zbyt dużej ilości funkcjonalności spowoduje dłuższy czas pracy oraz wielokrotne przesuwanie "ostatecznego" terminu. Z kolei zbyt mała liczba funkcjonalności może wpłynąć na negatywny odbiór przez użytkowników końcowych. Zasadą jest, aby w MVP umieścić tylko te funkcjonalności które są "core" całego pomysłu i bez których projekt nie ma powodów do istnienia. Posłużę się przykładem Facebooka, jako, że każdy wie jak działa i jakie ma funkcjonalności. Jezeli budowalibyśmy MVP aplikacji mobilnej dla Facebooka, na początek ograniczylibyśmy się tylko do głównej funkcjonalności czyli wyświetlanie feedu oraz możliwości komentowania i interakcji z postami. Wszelkie dodatki w postaci grup, stories, sklepów czy stron marek zostawilibyśmy na później, pamiętajmy w końcu jesteśmy dopiero w fazie testowania projektu.

2. Projekt prototypu

Kiedy już zdecydowaliśmy co znajdzie się w naszym MVP, pora na stworzenie projektu w postaci user stories lub makiet UI/UX. Nie jest to krok obowiązkowy, ale podobnie jak w kroku pierwszym, na tym etapie zdecydujemy czym powinniśmy się zajmować. Unikniemy dzięki temu pokusy robienia dodatkowych "ficzerów" podczas developmentu.

3. Kodowanie

Często najdłuższy i najbadziej kosztowny etap całego procesu powstawania MVP. To właśnie dwa poprzednie kroki miały na celu rozplanowanie prac a tym samym minimalizację ilości pracy na tym etapie. Dobrze wykonane etapy przygotowania i projektowania powinny z bardzo dużą dokładnością przybliżyć nam czasochłonność prac deweloperskich tym samym pokazując orientacyjne koszty.

Jeżeli chodzi o sam development, tutaj także przyda się doświadczony team leader lub zespół programistów posiadajacych doświadczenie w MVP. Jak zawsze w pracy programisty istnieje duża pokusa wdrażania rozwiązań w stylu "sztuka-dla-sztuki", jest to dziwna przypadłość programistów polegająca na pisanie kodu w taki sposób aby przygotować się na potencjalne problemy skalowalności w przyszłości lub budowania rozwiązań według najnowszych szyków technologicznych. Nie jest rzadkim zjawiskiem gdy projekt opóźnia się lub jego koszty wykraczają poza budżet ponieważ programiści spędzają zbyt wiele czasu nad jednym z modułów, podczas gdy ilość tej pracy nie ma szans na zwrot w przyszłości. Dlatego MVP tyczy się także programowania, należy pisać prosty, nieskomplikowany kod i budować architekturę aplikacji w taki sposób aby miała jak najmniej komponentów "ruchomych".

4. Walidacja lub Pivot

Ostatni etap to walidacja projektu. To właśnie wtedy nasi pierwsi użytkownicy poznają produkt i ich zachowanie mówi nam o tym co powinniśmy zmienić. Albo nasz pomysł okazuje się udany i rozwijamy go dalej albo decydujemy o zawieszeniu projektu. W takim wypadku z takiej porażki należy wyciągnać jak najwięcej wniosków, błędy które popełniamy dużo nas uczą, niekiedy okazuje się, że uzytkownicy zaczynają korzystać z naszego MVP w zupełnie inny sposób niż na początku to przewidywaliśmy. To jest moment na pivot, czyli dostosowanie produktu pod wymgania użytkowników które spływają po okresie użytkowania, czasem pivot może się okazać zmianą produktu o 180 stopni.

Na koniec krótka lista DO & DONT'S.

DO:

• Zachowaj minimalną ilość funkcjonalności wysokiej jakości
• Bądź zorientowany na duży rynek
• Pamiętaj o modelu biznesowym który pozwoli na monetyzację
• Monitoruj i dostosowuj się do zachowań użytkowników
• Wejdź na rynek jak najszybciej
• Badaj konkurencję
• Wymyśl plan marketingowy i strategię, które przyciągają dużą liczbę użytkowników

DONT:

• Nie dodawaj zbędnych funkcjonalności
• Nie opóźniaj wejścia na rynek dodając coraz to nowe funkcjonalności
• Nie obawiaj się zacząć od nowa, jeśli wyniki MVP nie będą korzystne