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

  • Allen, Tracy i ja W czasie prowadzanie projektów wielokrotnie przekonałem się iż umiejętność radzenia sobie z nadmiarem zadań to połowa sukcesu. W mojej pracy wiele pomogły mi książki takich osób jak Allen […]
  • Czym jest architektura sytemu? Ostatnio dużo się mówi na temat architektury systemów. W niektórych kręgach pojęcie to ma już rangę mityczną lub prawie mistyczną. Co więcej definicji jest tyle ilu jest dyskutantów.  […]
  • Wymagania na system – kontekst i granica systemu Do głównych zadań inżynierii wymagań należy m.in. akwizycja i dokumentacja wymagań na system. Aby tego dokonać należy zidentyfikować te części świata rzeczywistego, które będą miały wpływ […]
  • Nadchodzi Enterprise Architect 13 Niebawem firma Sparx System zamierza wydać kolejną wersję swojego flagowego oprogramowania. Enterprise Architect 13 zawiera sporo zmian, które są w wielu miejscach dość […]
  • Niezależny konsultant–nowy blog Nic mnie tak nie cieszy jak odkrycie, że na polskiej blogosferze pojawia się nowy blog o inżynierii oprogramowania. Tym razem takim odkryciem jest blog, który pani Ewa Wardzała. Pod dość […]
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. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry