MVP – Minimum Viable Product

Metodyki zwinne często są atakowane za rzekomą “niską jakość produktu”. Za dostarczanie “wydmuszek” i rzeczy “niedokończonych”. Pora rozprawić się z tym mitem przywołując jednego z oskarżonych: MVP czyli Minimum Viable Product.

 

Minimum Viable Product czyli uśmiech użytkownika

Podręcznikowa definicja MVP pochodzi z amerykańskiego środowiska startupowego i określa produkt, który posiada tylko tyle funkcjonalności, że zadowolić tych klientów, którzy najczęściej obcują z nowinkami (ang. early adopters).

“You’re selling the vision and delivering the minimum feature set to visionaries, not everyone.” – Steve Blank

Nasza definicja Minimum Viable Product to “minimalny zestaw cech produktu, który powoduje u użytkownika uśmiech”. Jeśli dostarczymy cokolwiek mniej, to nasz typowy odbiorca już kręciłby nosem. Naszym zadaniem jest oddać mu taki produkt, żebyśmy mogli zweryfikować w praktyce największe obawy i nadzieje dotyczące naszego pomysłu.

Więcej o naszym podejściu do MVP, a także jakości w Scrum, możecie posłuchać na naszym kanale YouTube i w filmiku poniżej:

 

Po co MVP?

Po co w ogóle zawracać sobie głowę czymś takim jak Minimum Viable Product? Dlaczego nie dostarczyć od razu finalnej wersji naszego produktu i uniknąć narzekania na to, że “czegoś brakuje”? Z drugiej strony – skąd mamy znać wszystkie wymagania? Przecież nie przeprowadzimy najpierw wielomiesięcznej analizy…

Jest to dobrze znany problem i jeden z powodów, dla których decydujemy się na metodykę agile, gdzie pracujemy iteracyjnie. Oddając do użytkowników małe kawałki rozwiązania zapewniamy sobie szybką informację zwrotną, zbieramy istotne wymagania i podejmujemy strategiczne decyzje w momencie, w którym jeszcze są one tanie.

W tworzeniu MVP kluczowe jest to, żeby zawrzeć w nim te hipotezy dotyczące naszej wizji, strategii i produktu, które chcemy przetestować małym nakładem sił i środków na rzeczywistych użytkownikach. Bo przecież lepiej być zaskoczonym po miesiącu pracy, niż po trzech latach.

 

Minimum Viable Startup

Podejście Minimum Viable Product jest jednym z ulubionych strategii w startupowym świecie. Trzeba pamiętać, że im dłużej przygotowujemy nasz produkt, tym większe ponosimy koszty. Lepiej jak najszybciej zderzyć działającą w docelowy sposób wersję z oczekiwaniami odbiorców i wyciągnąć lekcje bądź nawet zaniechać dalszego marnowania pieniędzy.

To, że nasz produkt musi działać w docelowy sposób ponownie podkreśla, że nie może on być niskiej jakości. Chcemy poznać reakcje użytkowników na naszą ideę, która nie powinna być zakopana pod stertą trywialnych błędów i niedogodności.

Tak więc MVP to nie tylko pojęcie z wachlarza Lean Startup, to także strategia biznesowa. Wspomnieć tutaj można chociażby znaną wszystkim Teslę, która zaczęła od drogich i robionych prawie-że ręcznie Roadsterów, by potem w oparciu o reakcje klientów przygotować produkcję bardziej zaawansowanych modeli S i X.

Czy Tesla Roadster był niedopracowanym samochodem? Na pewno nie. Czy mógł być zrobiony lepiej? Tak, ale nikt nie wiedział w jaki sposób, zanim faktycznie nie trafiły one na rynek i nie pojawiły się pomysły na usprawnienia zarówno w procesie produkcji jak i w samym produkcie.

 

Agile MVP

Metodyki agile skupiają się na “satysfakcji odbiorcy”. Podobnie sytuacja ma się ze Scrumem, który obiecuje pomóc “w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości”. Zmniejszony koszt i czas do wdrożenia to tylko miłe skutki uboczne.

Skoro główne priorytety dla wszystkich zwinnych podejść to maksymalizacja wartości i satysfakcja odbiorcy (a nie wydajność czy oszczędność), to MVP wpisuje się w ten stan umysłu idealnie.

Dzięki Minimum Viable Product możemy przetestować nasze pomysły na tym, kto potencjalnie będzie za nie płacił dużo pieniędzy. Jeżeli już pierwsza używalna wersja naszego produktu wywoła na jego twarzy szeroki uśmiech, to możemy spokojnie otwierać szampana i pracować dalej.

Jeżeli zaś nasz Minimum Viable Product nie spotka się z ciepłym przyjęciem, to może oznaczać to jedną z trzech rzeczy: zbyt mało funkcjonalności (nie osiągnęliśmy progu minimum), zbyt niska jakość (za dużo błędów), nietrafiony pomysł (to się po prostu nie przyjmie).

“Jak bardzo możemy być leniwi, żeby klient i tak był zadowolony.” – #białko

Określenie właściwej przyczyny naszego niepowodzenia pozwoli nam zaoszczędzić mnóstwo pieniędzy, sił i środków. Bo przecież z założenia MVP jest tani w wytworzeniu. A przynajmniej w porównaniu do kosztownego fiaska produktu tworzonego całymi latami w najgłębszej tajemnicy.

Musimy być tylko ze sobą brutalnie szczerzy, bo zdarzyć się może, że wszyscy, którym pokażemy nasze dzieło powiedzą “nie”. I wtedy trzeba pamiętać, że “viable” to znaczy “posiadający potencjał do sukcesu”. A potencjał, to nie jest jeszcze gwarancja.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: