Pewnego dnia John, utalentowany programista-amator z marzeniem o stworzeniu rewolucyjnej aplikacji, postanowił wziąć sprawy w swoje ręce. Pełen entuzjazmu i pewności siebie, zanurzył się w świat kodowania, mając jasny cel: stworzyć produkt, który zmieni oblicze branży edukacyjnej! Zapomniał tylko o jednym. Całkowicie zignorował niewinnie wyglądające trzy litery, czyli koncepcję MVP w projekcie budowy aplikacji.
John postanowił odkrywać koło na nowo. Zamiast skonsultować się z potencjalnymi użytkownikami, spędził miesiące nad doskonaleniem swojego pomysłu. Ignorując zasady Minimum Viable Product (MVP), zaczął od razu implementować wszystkie zaawansowane funkcje, które według niego uczynią aplikację wyjątkową.
Gdy wreszcie ukończył tą swoją „perfekcyjną” aplikację i zaprezentował ją światu, to feedback, jaki otrzymał z rynku, był ogromnym zaskoczeniem. Niestety, nie w takim sensie, o jaki chodziło Johnowi. Okazało się, że „nobody cares”. Pomimo ogromnych starań i godzin pracy, jego produkt nie zdobył akceptacji użytkowników, a John musiał wrócić do punktu wyjścia.
Co John mógł zrobić lepiej?
Odpowiedź jest w tym artykule. Poza tym dowiesz się też:
- Czym jest MVP
- Jak wyznaczyć zakres MVP w projekcie IT
- Dlaczego MVP nie zawsze jest związane z budowaniem oprogramowania
- Jaka jest różnica między MVP a PoC
Czym jest MVP w projekcie IT
Termin MVP, czyli Minimum Viable Product wprowadził do świata IT Eric Ries. Prosta definicja MVP z artykułu Erica to:
An MVP is the smallest version of a product you can use to start the process of learning from customers.
To zdanie idealnie oddaje sens definiowania MVP w projektach IT. Czyli rozszyfrowując znaczenie poszczególnych liter:
- Minimum = najmniejsza możliwa wersja,
- Viable = możliwa do użycia, bez braków i błędów,
- Product = która daje faktyczną wartość jako produkt.
Dzięki zbudowaniu i wypuszczeniu w szybkim czasie MVP użytkownicy otrzymują coś, co działa i faktycznie im pomaga. Jednocześnie autor rozwiązania otrzymuje informację zwrotną. Być może też czerpie nawet pierwsze zyski ze zbudowanej aplikacji. Każdy wygrywa.
Najpopularniejsze przykłady MVP to choćby Uber, który początkowo działał tylko w San Francisco, a zamawianie przejazdu odbywało się przez SMS.
Jeszcze bardziej ekstremalną wersję MVP wypuścił DropBox. Zanim w ogóle powstał produkt dla klientów, to założyciel DropBoxa przedstawił koncepcję rozwiązania w trakcie kilkuminutowego nagrania. Po tym nagraniu lista osób zainteresowanych korzystaniem z DropBoxa wzrosła z 5 000 to 75 000 w ciągu jednej nocy! To był jasny sygnał, że produkt ma spory potencjał.
Nieporozumienia w definiowaniu MVP
MVP z czasem stało się buzzwordem. Pojawia się na każdych szkoleniach i konferencjach związanych z agilem. Przez to też pojawiło się sporo nieporozumień i błędnego zrozumienia MVP. Poniżej rozprawiam się z trzema z nich.
Jak wyznaczyć zakres MVP w projekcie IT
Skoro MVP to minimalny zakres produktu, to żeby go przygotować, wystarczy:
- Określić cały zakres funkcjonalny (backlog).
- Odciąć jakiś kawałek, np. 20% od góry.
- Wypuścić to jako MVP.
I po problemie.
Czy takie podejście jest ok?
NIE!
Zakres MVP ma realizować pewne cele. Te, które są kluczowe dla użytkowników. Przynajmniej takie jest założenie. I właśnie MVP ma pomóc te założenia zweryfikować.
Czyli, planowanie zakresu MVP:
- NIE powinno zaczynać się na poziomie funkcjonalności, typu: dodajmy logowanie, wyszukiwanie według miejsca, daty itd.
- TAK, powinno być inicjowane przez określenie wartości dla użytkownika, na przykład: umożliwienie przejechania z miejsca A do B po cenie min 20% niższej niż standardowo, przy czasie oczekiwania nie dłuższym niż 50% względem tradycyjnych metod (taxi). Dopiero na tej podstawie powstają rozwiązania – funkcjonalności, które pomogą jak najszybciej osiągnąć te cele.
Wdrożenie zestawu funkcjonalności (pierwsza kropka) pozwoli sprawdzić, czy funkcjonalność działa poprawnie, bez błędów. Rozpoczynanie od wartości (druga kropka) pozwoli sprawdzić koncepcję biznesową. Czyli, czy użytkownicy będą skłonni nawet poczekać nieco dłużej na przejazd, jeżeli zapewnimy im dużo tańszą usługę.
Różnica pomiędzy tymi podejściami jest ogromna.
Podsumowując – stosując podejście MVP w projekcie IT, skupiaj się na dostarczeniu wartości użytkownikom, a nie tylko zestawu funkcjonalności.
Czy MVP musi oznaczać budowanie nowego oprogramowania
Z powyższego wynika, że drogi prowadzące do dostarczenia wartości mogą być różne. Dla użytkownika nie ma znaczenia, co jest pod spodem w rozwiązaniu IT, o ile tylko rozwiązanie spełni jego oczekiwania.
Co z tego wynika?
Dostarczenie MVP nie zawsze musi oznaczać budowanie oprogramowania od zera. Czyli proces planowania powinien wyglądać tak:
- Określony cel MVP w projekcie IT
- Ustalone rozwiązania, które szybko doprowadzą do celu
- Dobrany odpowiedni zespół, jeżeli w ogóle jest potrzebny
a NIE:
- Zorganizowany kompletny zespół
- Określony cel MVP
- Kosztowne budowanie rozwiązania od zera
Dlatego też Jeff Patton, w książce na temat User Story Mapping, zamienił MVP na MVS. Czyli Minimum Viable Solution. Podkreślił w ten sposób, że nie musi to być produkt w rozumieniu nowego oprogramowania. Czasami wystarczy arkusz w Excelu czy zakupienie i skonfigurowanie gotowego rozwiązania.
Świetnym przykładem jest zdobywający ogromną popularność Notion, w którym w kilka minut można wyklikać ciekawe rozwiązania typu CRM czy narzędzie do zarządzania projektami.
Koncepcja MVS nabiera więc ogromnego znaczenia zwłaszcza teraz, kiedy zbudowanie wstępnej wersji aplikacji jest prostsze niż kiedykolwiek. Jeżeli zainwestujesz jeden weekend w naukę obsługi narzędzi typu Power Apps czy Bubble, to będziesz w stanie opublikować MVP / MVS samodzielnie. Naprawdę!
Podsumowując – MVP może mieć dowolną formę. Jeżeli coś pozwala szybko i tanio dostarczyć wartość, to jest to prawdopodobnie najlepsza opcja. MVP nie musi być systemem informatycznym zbudowanym od zera na solidnych fundamentach.
Czy MVP w projekcie IT jest tym samym co PoC
W wytwarzaniu oprogramowania często pojawia się skrót PoC, czyli Proof of Concept. Czy PoC i MVP w projekcie IT to to samo?
NIE!
MVP skupia się na dostarczeniu realnym użytkownikom działającego produktu.
PoC to proces weryfikacji różnych koncepcji, często technicznych, zanim ktoś zainwestuje więcej czasu i pieniędzy w dane rozwiązanie. PoC może więc dotyczyć np. sprawdzenia, czy pewna biblioteka spełnia oczekiwania i można jej użyć, zamiast pisać rozwiązanie od podstaw albo, czy baza danych o konkretnych parametrach będzie wystarczająca, żeby zapewnić wydajne działanie systemu.
I chociaż PoC i MVP w projektach IT mają sporo podobieństw, takich jak:
- Krótki czas trwania
- Określone kryteria sukcesu / porażki
- Ograniczony zakres
to podstawowa różnica jest taka, że MVP odpowiada na potrzeby użytkowników, a PoC skupia się na potrzebach technicznych.
Podsumowując – MVP i PoC oznaczają zupełnie coś innego i nie powinny być używane zamiennie.
Podsumowanie – MVP w projektach IT
Zbierając to wszystko razem, MVP:
- Wymaga określenia celu i wartości dla użytkowników.
- Może być dowolnym rozwiązaniem, które prowadzi do osiągnięcia tego celu.
- Powinno być wdrożone jak najszybciej i jak najtaniej.
- Razem z MVP powinny być określone kryteria sukcesu oraz metody oceny tych kryteriów.
Zobacz też, co na temat MVP w projektach IT mówi autor tej koncepcji (tylko 3:25 oglądania).
Może zainteresuje Cię też temat User Story Mapping. Zobacz więcej w tym wpisie:
Ten artykuł zawiera linki partnerskie. Korzystając z nich wspierasz działalność bloga Project Makers. Dziękuję!
