MVP, czyli o zwinnym podejściu do zakresu przedsięwzięcia

O MVP słyszy się często wśród analityków. MVP to Minimum Viable Product, czyli minimalnie wykonywalny produkt. Tłumaczenie nie jest doskonałe, dlatego też dalej będę pisał o MVP.

Pojęcie MVP pojawiło się po raz pierwszy w 2001 roku. Jego autorem jest Frank Robinson. Natomiast w 2011 roku Eric Ries, swoją książką Metoda Lean Startup spopularyzował to pojęcie. W jego ujęciu MPV to produkt posiadający jedynie podstawowy zestaw funkcji wydany w celu przetestowania nowego pomysłu na biznes i oceny reakcji osób korzystających z tego rozwiązania.

Idea MVP jest pozyskanie informacji zwrotnej na wczesnych etapach przygotowania produktu lub usługi i iteracyjne dostosowanie produktu do faktycznych i rzeczywistych oczekiwań użytkowników. Informacja zwrotna od pierwszych klientów na temat MVP powinna umożliwić podjęcie między innymi następujących decyzji:

  • czy produkt w ogóle budzi ich zainteresowanie, a jeśli tak to
  • jakich funkcjonalności poszukują klienci lub użytkownicy produktu.

MVP to bardziej proces, a nie produkt. Tym bardziej że MVP nie jest produktem z minimalną liczbą elementów, ale ma podstawowe funkcje wystarczające do wdrożenia pomysłu.

Dlaczego piszę o MVP?

Otóż wielokrotnie  spotykam się z sytuacją, gdy chcemy zrobić coś szybko. Mamy pomysł na zmianę w oprogramowaniu, zmianę procesu biznesowego. I nagle zmiana, która miała być mała rośnie. Niejako przy okazji dodajemy więcej zmian albo chcemy by proces był już w 100% zautomatyzowany. Rośnie lista wymagań, interesariuszy, budżet. Całość z małej zmiany przechodzi w coś dużego i skomplikowanego.  Niestety na końcu nie wszyscy są zadowoleni. Efekty różnią się od pierwotnych oczekiwań.

Z tego tez powodu stosowanie zasad MVP pomaga dotrzeć do odpowiednich i właściwych rezultatów. MVP opiera się na filozofii lean i zakłada iteracyjny proces budowania, następnie pomiaru i uczenia się, aż produkt całkowicie zaspokoi potrzeby interesariuszy. MVP ma na celu uniknięcie budowania niepotrzebnych produktów niezależnie czy to są nowe funkcje aplikacji, integracje czy też zmieniony proces biznesowy.

W zależności od kontekstu forma MVP może być różna. Czasem będzie to kilka funkcji aplikacji spięte „interfejsem białkowym”, a czasem zmiana procesu biznesowego bez zmian w aplikacjach.  MVP w procesie wytwórczym oprogramowania jest niezbędny, ponieważ pozwala na podzielenie się pomysłem na temat produktu i testowania go na jego odbiorcach lub jego uczestnikach.

Warsztaty, makiety, tworzenie działających fragmentów rozwiązania, iteracyjna budowa rozwiązania pomaga w zrozumieniu potrzeb intersariuszy. MVP to musi być produkt, który z racji swojej funkcji będzie pożądany przez docelową grupę jego odbiorców. To taki „must have” funkcji, taki zestaw minimalnych cech i funkcjonalności, które rozwiązanie musi spełnić.

Z drugiej strony nie można wpaść w pułapkę iteracyjności. Wiem, że robiąc kilkanaście warsztatów może pojawić się moment, w którym pojawią się „przydasie” albo inne niepotrzebne działanie. To jak z pakowaniem torby na wakacje. W pewnym momencie bierzemy rzeczy, które być może założymy pod warunkiem, że …. 🙂

Czy to oznacza, że budując iteracyjne „omijamy” te aspekty. Absolutnie nie. Będą sytuacje, w których nasz MVP nie zadziała. Opiszmy takie sytuacje by użytkownik (interesariusz) wiedział jak ma postąpić. Jeśli wspomniane sytuacje zaczną pojawiać się częściej to… w kolejnej iteracji rozwiniemy nasz produkt właśnie o ten aspekt.

MVP ma jeszcze jedno ograniczenie. W branżach ściśle regulowanych takich jak bankowość czy ubezpieczenia nie można w każdym miejscu zastosować tego podejścia. Sprawozdawczość, kontrola i inne aspekty regulowane przepisami prawa mogą utrudnić zastosowanie MVP do produktów bankowych i ubezpieczeniowych. Można natomiast MVP stosować jako podejście w marketingu, sprzedaży czy też optymalizacji procesów wewnątrz takich organizacji.

W moim odczuciu MVP jest niezbędną częścią tworzenia aplikacji. To taki zdrowy minimalizm, w którym nie marnujemy zasobów i robimy to co jest dokłanie potrzebne i niezbędne. MVP to włożenie minimalnego wysiłku i pieniędzy przygotowanie zmiany. Dzięki informacji zwrotnej buduje się kolejne wersje, które odzwierciedlają konkretne potrzeby intersariuszy.  Robienie to co jest dokłanie potrzebne i niezbędne pozwala nie tylko zaoszczędzić czas i pieniądze, ale także daje satysfakcje zarówno tworzącym, jak i korzystającym z rozwiązania.

I takiej właśnie pracy i produktów Ci życzę 🙂

Podobne wpisy

  • Czynność: Planowanie Sprintu (Sprint Planning Meeting) Na Spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym […]
  • Czas a modelowania w języku UML Czasami dostaję pytanie: Ile kosztuje modelowanie w UML? Moja odpowiedź brzmi: Dużo, ale koszty się zwracają z zyskiem. Skąd ten zysk skoro modelowanie w UML to czas ludzi, którzy zamiast […]
  • Analiza luk – moja podcastowa rozmowa Dziś na stronie AnalizaIT pojawił się podcast, na którym rozmawiam z Hanią Wesołowską na temat analizy luk. W trakcie rozmowy poruszamy wiele ciekawych tematów dotyczących wyszukiwania […]
  • Model – Driven Development udoskonalona metoda wytwarzania aplikacji cz.1 Tegoroczny kwiecień to moje małe święto. Dziesiąta rocznica blogowania.  Pomyślałem, że może warto jest wrócić do tego co było przed blogiem. Przed blogiem już trochę pisałem. Potem moją […]
  • Zarys Scrum Zasadnicze cechy SCRUM, w bardzo dużym uproszczeniu, to: iteracyjnie przyrosty wartości samoorganizujące się zespoły klient, bądź Właściciel Produktu, który dostarcza zespołowi […]
Reklama

3 komentarze dla “MVP, czyli o zwinnym podejściu do zakresu przedsięwzięcia”

  1. Ciekawy temat. Według mnie w tle MVP powinna iść filozofia maksymalnej efektywności tzn. bardzo świadome wyciskanie maximum efektów przy minimalnym nakładzie. Zauważyłem też, że zwinność i częste interacje coraz częściej pojawiają się w procesach biznesowych firmy. Na przykład: częstsze spotkania na weryfikację pomysłów i ustalenia, niż długie narady z długim czasem na wdrożenie działań. Chyba rzeczywistość wymusiła taki sposób szybkiego reagowania 🙂

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry