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
Metodyka wytwarzania oprogramowania

O tym, że systemy się rozrastają a ich stopień złożoności wzrasta logarytmicznie nie trzeba chyba nikomu tłumaczyć. By budować i więcej

Architektura systemów

Obserwując zmiany na rynku zauważyłem, że rola architektury systemów (architektury oprogramowania) rośnie. Dziś w wielu organizacjach myśli nie tylko a więcej

NATO Architecture Framework

Technik i obszarów, które możemy modelować jest bardzo wiele. Ponadto powstało wiele szablonów, ram, frameworków, które mówią co i jak więcej

Zasada TAO w procesie wytwórczym oprogramowania

W co większych firmach lub przy okazji dużych przedsięwzięć zwanych projektami, analitycy to nie jedna lub dwie osoby a grupa więcej

Reklama
MODESTO - licencje Enterprise Architect

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. Wymagane pola są oznaczone *

Przewiń do góry